The DAO Voted Yes. Did the AI Agent Execute the Right Deal?

What Matters

A DAO can pass a vote and execute its approved transaction perfectly while still doing the wrong thing. The gap sits between the mandate people understood, the transaction they authorized and the outcome the transaction produces. AI agents make that translation easier to automate. Treasury operators need an evidence trail that connects all three before money or permissions move.

The Signal: approval and meaning can diverge

Imagine a treasury proposal that promises to pay a contributor and gives the contributor a standing withdrawal permission as well. A voter reading the summary may approve the payment. The encoded calls may authorize both actions. A transaction can then execute without an error while leaving the treasury with a permission its voters never intended to grant.

This is a useful problem to investigate without claiming that it has become a measured epidemic of agent failures. The critical question is narrower: what evidence connects the decision to the action? An agent that writes persuasive summaries, constructs transactions and reports successful execution could repeat the same misunderstanding through every stage.

The translation problem also predates AI. Uniswap Labs and ScopeLift introduced Seatbelt to expose proposal addresses, contract verification information, state changes and events to reviewers. That historical work shows why a governance decision needs inspection beyond its headline. It does not establish that an AI system caused a particular incident. [S8]

The practical opportunity for agent-assisted governance is therefore specific: reduce the work needed to assemble, compare and preserve the evidence, while making unsupported interpretations visible.

DN Alpha Thesis: preserve the mandate through execution

DN’s proposed operating principle is that every material action should be traceable to a bounded, approved instruction and a verifiable outcome. A fluent explanation is useful evidence for review, but it cannot grant the agent additional discretion. If the mandate does not define a material choice, the workflow should expose that choice for approval.

This makes the unit of governance a reusable decision record: the version of the mandate, the authority that approved it, the exact permitted actions, the evidence checked before execution and the observed result. The record should survive the agent session, a change of service provider and a later dispute about what was authorized.

Our analysis of agent DAOs and traditional companies examines organizational structure. This article addresses a narrower operational problem: carrying one approved decision into one accountable execution.

First identify the execution architecture

The phrase “the agent executes the vote” can describe substantially different permissions. Establish which architecture applies before measuring drift.

OpenZeppelin proposals associate targets, encoded calls and attached native-currency values with a description. In its default Governor implementation, the proposal identifier hashes the targets, values, calldatas and description hash. Substituting different bound calldata changes the identifier; an executor cannot simply treat the substituted payload as the same approved proposal. [S2] [S1]

That limits where the failure can occur. The wrong interpretation might already be in the payload voters approve. Alternatively, a mandate may deliberately leave execution choices open. Those situations require different controls. Do not describe both as an agent changing an immutable vote after the fact.

Snapshot’s SafeSnap documentation makes the semantic bridge explicit: its Reality.eth question addresses whether the vote passed, whether the payload was included and whether that payload implements the described decision. It also recommends bonds, arbitration, cooldown and monitoring arrangements. Those are components to inspect in a particular deployment, not evidence that every Snapshot vote has the same execution protection. [S3]

A proposal hash is a binding reference, not a reading of intent

A hash helps answer whether two representations identify the same encoded proposal. It does not determine whether “support the contributor” means a one-time payment, an allowance, a payment stream or an administrative role. Reviewers must settle that interpretation before the relevant authority is granted.

There is another practical identification issue. OpenZeppelin’s default proposal hash excludes both chain ID and Governor address. Identical proposal inputs can therefore produce the same identifier on different governors or networks. DN recommends recording chain ID, governance contract and proposal ID together, plus the treasury and executor addresses. This is an evidence-record design recommendation, not a claim that the default hash is broken. [S1]

Distinguish the target contract from the payment recipient. For a token transfer, the call may target the token contract while the recipient appears inside its arguments. A reviewer who checks only the outer destination has not necessarily checked who receives the funds.

Preserve the approved description and payload together. If the description is later revised, retain the original and record which version actually governed approval. A corrected explanation must not quietly rewrite the historical instruction.

Build a mandate manifest before building the transaction

The following is DN’s proposed review template. It is a human-readable agreement about what evidence must be assembled. It is not an executable contract, a universal governance standard or a substitute for the deployed system’s own authorization rules.

A budget should define its accounting boundary. “Spend no more than 50,000” leaves questions if gas, bridge fees, previous payments or token approvals fall outside the displayed amount. State whether the limit concerns one transfer, total outflow, a reporting period or continuing authority. Keep unlike assets separate unless the mandate defines a conversion rule.

Use exact contract addresses and integer token units in the technical record. Symbols and rounded display values belong in the readable explanation. Both representations should be reconcilable. A discrepancy between them is a review issue, even when the summary looks plausible.

For optional conditions, an explicit reason for “not applicable” is better than an empty field. A fixed transfer may have no exchange slippage parameter. It still needs an asset, a recipient, an amount and an authorization path.

A synthetic 50,000-USDC grant exposes the difference

Illustrative scenario, not a reported DAO transaction: voters intend a one-time grant of 50,000 USDC to a named contributor after a 48-hour review period. No recurring spending authority is intended. Assume the token contract and its unit scale have been verified for the chosen deployment.

Before voting, an agent drafts a batch containing the correct transfer and an additional unlimited allowance to a helper address. Its summary describes only the grant. If the batch is approved and executed unchanged, payload integrity can be perfect while the proposed authority contradicts the stated mandate.

The remedy is to resolve the discrepancy before approval. If an already-approved payload contains the unwanted action, use the deployed governance process to cancel or replace it where permitted. Do not silently edit an approved batch and describe it as the original decision.

If the agent instead has discretionary authority to construct payments after a vote, its permissions should enforce the grant’s boundaries. A sentence saying “do not add allowances” is useful instruction; it is not evidence that the execution path prevents them.

How the review is scored

This tool records a reviewer’s evidence assessment across 12 dimensions. It does not connect to a wallet, inspect deployed contracts or decode a transaction automatically. Its purpose is to expose mismatches and missing evidence before someone authorizes an action.

Confirmed drift is the number of deviations divided by the number of reviewed dimensions. Evidence coverage is the number of reviewed dimensions divided by the number of applicable dimensions. Reviewed means either a documented match or a documented deviation. An unverified item never counts as a match.

If nothing has been reviewed, confirmed drift is not calculated. If ten reviewed dimensions match and two remain unknown, zero recorded drift is compatible with incomplete evidence. The output must retain that distinction.

Any unresolved mismatch or unknown produces HOLD. Core identity, asset, recipient, amount, action and authority fields cannot be removed as “not applicable.” Optional commercial constraints can be excluded only when they are irrelevant and the reason is recorded. A percentage never overrides a material discrepancy.

The loaded synthetic example records eight matches, three deviations and one unverified check. Coverage is 11 ÷ 12 = 91.7%; confirmed drift is 3 ÷ 11 = 27.3%. The same extra allowance affects destinations, permissions and outcomes, so these are overlapping review dimensions, not three independent incidents or a measured probability of loss. The unverified delay remains unresolved.

An all-match result means only “No mismatch recorded.” It is not an audit opinion, a probability of loss, a certification that the evidence is correct or permission to execute. Equal dimension counts keep the arithmetic reproducible; they do not imply that all failures have equal consequences.

Check the path that can actually move the funds

Safe distinguishes owner-signed transactions from actions through enabled modules. A module can execute without collecting the normal owner-signature threshold for every transaction. A treasury described as “three-of-five” therefore needs a separate explanation of its enabled module authority. [S4]

Safe’s ordinary transaction-guard tutorial covers the owner transaction path. Its separate SDK migration documentation identifies module guards as a feature of Safe v1.5.0 and later. Verify the deployed version and the configured guard for the relevant path. Installing a newer SDK does not, by itself, establish those facts about an existing treasury. [S5] [S6]

DN recommends documenting the entire authority chain: the account the agent controls, the action it requests, the module or executor accepting that request and the treasury state it can affect. Ask whether that path can create allowances, change owners, enable other modules or alter restrictions. A spending control can be undermined if the same authority can remove it.

Our AI Agent Transaction Permission Risk Index addresses the broader permission question. Here, the test is whether the particular authority being used implements this particular mandate.

Simulation provides conditional evidence

Cactus’s Seatbelt documentation describes proposal simulation on a fork, with reports covering state changes, external calls and events. It also describes overrides for time, block number and quorum. These details matter because a report’s interpretation depends on the conditions under which it was produced. [S7]

Record the block and material assumptions alongside the result. Review the effects against the mandate: destination balances, allowances, ownership and administrative state. “Did not revert” answers a narrower question than “implemented the authorized deal.”

DN recommends repeating the relevant checks when a material dependency changes before execution. Examples include an upgraded target implementation, a changed recipient record, insufficient treasury funds or an expired commercial condition. This is a proposed release rule, not a claim that every simulation service detects every change.

After execution, preserve the actual transaction reference and reconcile observed outcomes. A transaction receipt establishes execution evidence; the acceptance test establishes whether the intended outcome occurred. Do not let a success message close an unresolved accounting or permissions exception.

A practical workflow from decision to receipt

1. Freeze the mandate. Preserve the decision text, version, governance domain and permitted discretion. Escalate ambiguous material terms.
2. Construct and decode the payload. Make every call, recipient, amount and permission change readable. Retain the encoded representation.
3. Compare both representations. Review the description against the decoded actions, then check that the encoded payload is the one under review.
4. Inspect authority and timing. Establish which executor can act, what delay applies and who can intervene.
5. Simulate and resolve exceptions. Keep the assumptions, examine effects and close every mismatch or unknown before release.
6. Revalidate at execution. Confirm that material conditions remain satisfied and that the authorized payload and domain still match.
7. Reconcile and retain the record. Compare actual results with acceptance criteria, record outstanding exceptions and preserve the evidence.

OpenZeppelin separates proposer, executor, canceller and administrative powers. A Governor using a timelock needs appropriate cancellation authority for queued proposals. A delay creates time to inspect; intervention still depends on the deployed permissions and state. [S2]

The workflow should name who handles an exception and what evidence permits resumption. “Someone will notice” is not an operational control. Equally, the review process needs an authorized recovery route if its own controls fail; otherwise a prevention mechanism can become an indefinite blockage.

Methodology and limits

DN reviewed the linked primary documentation and used it to distinguish transaction binding, execution authority, simulation and outcome verification. The mandate manifest, audit dimensions and HOLD rules are DN design recommendations. The grant example is synthetic and supplies no evidence about actual DAO failure rates.

The index counts recorded assessments. It does not authenticate their evidence, measure reviewer independence or discover hidden calls. It also does not establish the legal meaning of a vote or resolve conflicting governance documents. Such conflicts require the organization’s authorized process.

Contract versions, extensions and configuration can change the mechanics described here. Check the deployment under review. The article is a decision aid for organizing evidence, not a completed assessment of a particular treasury.

Frequently asked questions

Can an AI agent change a DAO proposal after it passes?

It depends on what authority was granted. In the default OpenZeppelin design, changing bound transaction inputs changes the proposal identifier. An agent may instead have separate discretionary authority. Inspect that authority rather than assuming a passed vote permits arbitrary substitutions. [S1]

Does a matching proposal hash prove the agent understood the vote?

No. The proposed payload can embody a mistaken interpretation before approval. Compare its decoded actions with the mandate, including future permissions and side effects.

Does a passed simulation prove the deal is correct?

No. A simulation supplies evidence under specified conditions. Review the resulting changes against the intended outcome and preserve those conditions with the report.

Does a Safe owner threshold cover module transactions?

Do not assume so. Modules use a distinct execution path. Inspect that path’s authorization and restrictions, including any compatible, configured module guard. [S4]

Can a timelock reverse an incorrect payment?

A timelock is a delay before execution. It is not a reversal mechanism for a completed payment. Establish the cancellation procedure before the review window is needed.

What does a zero confirmed-drift result mean?

Only that no deviations were recorded among reviewed items. Unknowns can remain. Any unresolved deviation or unknown keeps this worksheet at HOLD; complete matching evidence still does not certify safety.

Version, corrections and primary sources

Version 1.0, 11 November 2026: initial documentation review, synthetic grant example and DN Mandate Drift Index methodology. Cactus is the current name of the platform formerly branded Tally. [S9]

To report a correction, email press@decentralised.news with the relevant passage, source and deployment version where applicable. Corrections should distinguish changed documentation from an error in the original analysis.

1. [S1] OpenZeppelin Contracts 5.x: Governance API.
2. [S2] OpenZeppelin: On-chain governance guide.
3. [S3] Snapshot: SafeSnap.
4. [S4] Safe: Smart Account Concepts.
5. [S5] Safe: Building a Guard.
6. [S6] Safe Protocol Kit: v7 migration.
7. [S7] Cactus: Seatbelt for governance.
8. [S8] Uniswap Labs: Governance Seatbelt.
9. [S9] Cactus: Brand transition.