# Borrowed governance power: what snapshots can and cannot prevent Governance that gives power to token balances must consider how that power was acquired and when it is measured. Borrowed or delegated tokens can create temporary influence under the system’s rules. Historical snapshots prevent current transfers from repeatedly changing a past vote’s weight, but they do not prove that every voter has permanent economic exposure. Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance); [Governance API](https://docs.openzeppelin.com/contracts/5.x/api/governance) Canonical: https://degreesofsatoshi.com/encyclopedia/borrowed-governance-power/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T19:18:00.092Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **Historical weight:** ERC20Votes records voting power that can be read at a past snapshot. ([How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance)) - **Timing:** Voting delay and voting period are separate governor parameters. ([How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance)) - **Execution:** A timelock adds a later stage after successful voting. ([How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance)) ## Ask whether temporary control reaches the snapshot In a block-based governor, the cited API measures a proposal’s snapshot at the end of the relevant block and voting starts afterward. A balance borrowed and returned within a single transaction does not remain as that borrower’s end-of-block balance. That does not settle every borrowing scenario. A longer loan held through the measurement time is different, and delegation or custom voting strategies can change the analysis. Evidence: [Governance API](https://docs.openzeppelin.com/contracts/5.x/api/governance) ## Each control addresses a different step The proposal threshold limits submission; the snapshot fixes voting power; the voting period allows participation; quorum and approval rules decide success; the timelock delays execution. Calling a system flash-loan resistant requires examining their actual interaction, not checking whether it has one named safeguard. Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance) ## Evaluate powers and actions, not wallet labels A token holder, delegate and treasury administrator can have different authority. Inspect how the proposed calls would use that authority and who can cancel or change them. This article explains governance-design questions; a large or borrowed vote alone is not proof of malicious intent. Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance); [Access Control](https://docs.openzeppelin.com/contracts/5.x/access-control) ## Questions ### Does using snapshots prevent every governance attack? No. It provides historical voting-power accounting; authority design, concentration, longer-lived borrowing and execution controls remain relevant. Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance); [Access Control](https://docs.openzeppelin.com/contracts/5.x/access-control) ## Claims and scope ### borrowed-governance-power-quick-answer Governance that gives power to token balances must consider how that power was acquired and when it is measured. Borrowed or delegated tokens can create temporary influence under the system’s rules. Historical snapshots prevent current transfers from repeatedly changing a past vote’s weight, but they do not prove that every voter has permanent economic exposure. Scope: {"collection":"defi","dataAsOf":"2026-10-02","blockHeight":null} ### borrowed-governance-power-fact-historical-weight Historical weight: ERC20Votes records voting power that can be read at a past snapshot. Scope: {"collection":"defi","dataAsOf":"2026-10-02","blockHeight":null} ### borrowed-governance-power-fact-timing Timing: Voting delay and voting period are separate governor parameters. Scope: {"collection":"defi","dataAsOf":"2026-10-02","blockHeight":null} ### borrowed-governance-power-fact-execution Execution: A timelock adds a later stage after successful voting. Scope: {"collection":"defi","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance) — OpenZeppelin. Governance gates, historical voting power and execution. Locator: Proposal threshold; quorum; Votes; snapshot. Retrieved: 2026-10-02T18:53:22.811Z. - [Governance API](https://docs.openzeppelin.com/contracts/5.x/api/governance) — OpenZeppelin. Precisely scoped quorum and proposal configuration. Locator: Governor; GovernorVotesQuorumFraction; GovernorSettings. Retrieved: 2026-10-02T18:53:23.077Z. - [Access Control](https://docs.openzeppelin.com/contracts/5.x/access-control) — OpenZeppelin. Privileges beyond a locked LP position. Locator: Ownership; roles; delayed access. Retrieved: 2026-10-02T18:53:23.338Z. ## Revision history - 2026-10-02: First publication after primary-source research and separate automated verification. ## Cite this entry Degrees of Satoshi editorial project. “Borrowed governance power: what snapshots can and cannot prevent.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/borrowed-governance-power/