By Heath Muchena · Sources reviewed 2026-11-13 · Original DN analysis and explicitly illustrative examples
What Matters
A historical voting-power rule, a timelock and a role map are different controls. Their names should not be collapsed into a single claim that temporary influence is impossible.
- Identify when and in which units voting power is measured.
- Keep post-vote delay separate from the measurement rule.
- Review additional authority and the actual response owner.
The DN thesis
Defensive governance review starts with the precise moment and authority boundary that gives an actor influence. DN’s map preserves those declarations and gaps without producing a takeover recipe or a security score.
1. Ask when voting power becomes fixed
A token balance is an observation at a time. Governance needs a rule for deciding which observation counts. Without that distinction, a discussion about “one token, one vote” can miss the point at which temporary control becomes usable voting influence.
ERC-5805 describes delegated voting weight and historical checkpoints, distinguishing those records from a current token balance. [1] The defensive question is which measurement the deployed governor actually uses and how that timepoint is selected for a proposal.
Do not treat the word “snapshot” as a sufficient answer. Record the rule, its clock, its relationship to proposal creation and the version that implements it. A user-interface snapshot and the contract’s authoritative voting-power lookup can be different things.
A historical measurement can prevent later movements from rewriting the same earlier record. It does not establish that the person exercising influence was a long-term economic owner, nor does it remove every route for borrowed, delegated or concentrated influence. This article maps the boundary; it does not calculate how to acquire a controlling vote.
2. Check the clock before interpreting the delay
A number such as “1” or “86,400” has no useful timing meaning without its unit and clock source. Block numbers, timestamps and other monotonic timepoints should not be silently treated as interchangeable.
ERC-6372 defines an interface for exposing a contract’s clock and mode. [2] OpenZeppelin’s governance documentation explains that the selected token clock affects the governor’s timing parameters. [3] Those sources make the unit question explicit; they do not verify a reader’s deployment.
Compare the token and governor evidence in the same chain and configuration context. Matching “block-number” labels are only a preliminary consistency observation. They do not prove the two records refer to the same source, or that an adapter or upgrade handles them correctly.
The tool retains the entered voting delay in its declared units. It does not convert blocks into an estimated number of hours. Different modes trigger a mapping review, while custom modes remain unresolved until their meaning is documented.
3. Separate the snapshot rule from the execution waiting period
Voting-power measurement, the duration of voting and the wait before execution answer different questions. One defines whose influence is counted, another determines when votes can be cast, and another provides a period before a successful decision can take effect.
A long execution delay does not retroactively change the voting-power rule. Likewise, a historical checkpoint does not guarantee that an objection can be raised or acted upon before execution. The actual response path needs people, information and authority.
OpenZeppelin describes the timelock as a distinct component in the governance execution path. [3] Its presence should be checked for the particular route being reviewed, not inferred from a different proposal type or a dashboard badge.
The worksheet distinguishes absent, unknown and explicitly zero delay. It does not add voting delay to timelock delay or produce a combined “security hours” score. No universal minimum is proposed: appropriate timing depends on the system and its actual monitoring and response needs.
4. Map the authority that can act around the ordinary path
A careful vote design can coexist with another role that can change parameters, schedule operations, cancel actions or upgrade the contracts. Such roles may be deliberate, but they must be included in the governance model rather than left in an administrator’s mental map.
OpenZeppelin’s guide identifies separate proposer, executor, canceller and administrator roles, and warns that additional authority can change how the ordinary governance path is used. [3] An execution delay alone therefore does not describe the full control structure.
Record who holds the relevant powers, how those powers can change and what evidence ties the role review to the deployed version. A claim that governance is the only path needs a reference just as a claim that an extra path exists does.
Additional authority is a review finding, not automatic proof of an exploit. The local tool does not enumerate wallets, inspect bytecode or judge a role holder’s intent. It preserves the declared path so a reviewer can ask whether the published governance story matches the actual authority structure.
5. Keep a response owner and reopen the record after changes
A delay is only useful to a defender if someone can notice the relevant event, understand it and take an authorized response. Define who monitors proposals and configuration changes, where the evidence is retained and which cancellation or escalation powers actually exist.
Do not promise that every user can exit during a waiting period. Exit may depend on separate liquidity, access and contract rules. A published pause or cancellation capability also does not prove that its operator is available or that the action will be included in time.
Update the record after a token, governor, timelock, role or upgrade-path change. Preserve the earlier version so a later review can tell which configuration was considered. A new timestamp on an old export does not refresh the role evidence.
DN’s DAO authority analysis addresses organisational powers, while its mandate-drift record follows an approved decision into an agent’s action. This article adds the narrower measurement, timing and authority questions that determine how temporary voting influence is handled. It makes no claim that an AI has executed a governance attack.
DN Governance Timing and Authority Map
Record the voting-power measurement, clock modes, separate execution delay and authority paths for one route. Numbers are settings you supply, not recommended thresholds. No block-time conversion is performed.
Use non-sensitive aliases, never credentials, personal data or confidential documents. Blank and unknown entries stay unresolved. The tool does not open evidence references.
No current record. Load a labelled example or enter your own information.
This instrument makes no network requests and uses no persistent browser storage. Its download contains the current inputs, calculation or review findings, source references and provenance. The website’s other services remain subject to its privacy policy.
Illustrative cases
These cases are invented to expose the method’s boundaries. They are not observed customers, deployments, trading outcomes or legal findings.
Illustrative historical rule and separate delay
The record reports matching clock-mode labels, a historical measurement rule and a separate execution delay. It does not establish immunity to temporary influence. The numbers are invented, not recommendations.
Illustrative current balance with zero voting delay
The measurement boundary and explicit zero delay remain review questions even though a positive timelock is reported.
Illustrative timelock without snapshot evidence
A positive execution delay does not fill the unknown voting-power rule.
Illustrative different clock modes
The declared modes differ. The tool neither converts the delay nor declares the deployment compatible.
Illustrative additional authority path
Additional authority remains visible beside the long-looking delay. The model does not decide whether the role is malicious or justified.
Illustrative missing role and response evidence
The record retains the other configuration declarations while exposing the missing authority and response references.
Methodology, assumptions and limits
The model compares declared clock-mode labels but never establishes clock-source compatibility. It retains the voting delay as a nonnegative whole count in the declared governor units and the timelock delay as a separate nonnegative whole number of seconds. Both use exact integer parsing, with a local maximum of twelve digits; this is a worksheet limit, not a protocol rule.
When timelock use is unknown or reported absent, its entered delay is inactive and retained raw. A blank active delay stays unknown, while zero remains an explicit value. Historical measurement, source references, authority paths and response ownership are evaluated independently. A timelock cannot fill a missing snapshot rule.
Complete declarations remain documented configuration only. No quorum, voting threshold, borrowing cost, attack probability or recommended delay is calculated. References are not opened or authenticated. Edits invalidate the old result and download; JSON preserves raw values, findings, inactive fields, sources and provenance.
Frequently asked questions
Does a historical checkpoint eliminate every kind of temporary influence?
No. It defines an earlier measurement boundary. It does not establish long-term ownership or remove every borrowed, delegated or concentrated source of influence.
Can a long timelock replace the snapshot rule?
No. Execution delay and voting-power measurement answer different questions. Both need their own deployed configuration evidence.
Why does the tool not convert blocks to hours?
A block count belongs to a specific clock and chain context. The tool has no live block-time model and does not infer one.
Does additional authority prove the DAO is compromised?
No. It identifies another control path to review. The tool does not inspect roles or infer intent, exploitation or security from a declaration.
Primary sources
Reviewed 2026-11-13. A later export timestamp does not update the sources.
- ERC-5805: Voting with delegation — Review-status interface proposal for delegated current and historical voting weight; not proof a deployed token conforms.
- ERC-6372: Contract clock — Review-status interface proposal exposing clock mode and timepoints; no universal block-to-time conversion.
- OpenZeppelin Contracts 5.x: On-chain governance — Implementation guidance on voting clocks, timelocks and roles; not an audit of a reader’s configuration.
Turn an evidence gap into a focused question
If the uncertain boundary is a configuration version, clock mapping or authority path, explore a focused DN Research Desk enquiry. Research scope is agreed separately; this record does not provide a contract audit or security guarantee.
Disclosure: this article links to DN’s own research service. A commercial enquiry does not purchase a favorable conclusion. This instrument is educational documentation support and does not provide personalized financial, legal or security approval.
Related DN research
About the Author
