Mind the Gap: Detecting Description-Execution Mismatch Attacks in DAO Governance

The core question is: does the proposal description seen by voters faithfully correspond to the on-chain behavior executed after approval? The authors call the inconsistency between the two description–execution mismatch (DEMI).

• Governance scenario: DAOs make decisions via the propose→vote→execute process. The authors argue that most members rely on the description to understand a proposal, while the description itself cannot constrain on-chain execution.
• Existing tools: The authors state that Snapshot, Tally, etc. mainly display proposal materials; Tally's execution preview is provided by the proposer and cannot replace an independent, reproducible execution trace (§4.1, Table 5).
• Threat model: The victim system is DAO governance with executable payloads; the blockchain, contract execution, and governance infrastructure are assumed to be normal (§3.1).
  • Goals and capabilities: The attacker can manipulate any proposal description and execution payload to mislead voters, steal funds, or seize control.
  • Constraints and knowledge: Cannot bypass thresholds, quorum, timelock, or the governance lifecycle; adaptive evaluation further distinguishes gray-box and white-box.
• Core observation: The authors argue that historical proposals of the same DAO reuse lifecycle functions, so governance configuration can be reconstructed; consistency checking can be turned into finding textual evidence per action.
• Proposed defense: Lifecycle simulation generates traces, DEMI Guard builds an action–evidence mapping, and Robustness Guard checks evidence for high-risk actions. The system is positioned as a triage layer for human review before execution.

Related research centers on DAO governance security, governance tools, semantic mismatch detection, and prompt injection.

DAO security and governance mechanisms

• Dotan et al. (2023), Feichtinger et al. (2024) — analyze real governance attacks and human participation factors; Junjie Ma et al. (2024), Wei Ma et al. (2024) study governance processes and proposal quality.
• Voting-Bloc Entropy, DAVe (2024) — study decentralization degree metrics and cryptographic verification frameworks, respectively.
• Sharma et al. (2024), Tamai and Kasahara (2024), Van Vulpen et al. (2024) — study Web3 fraud, voting mechanisms resistant to whales and collusion, and upgradeable contract governance, respectively. The authors state that the above work does not provide automated, execution-based mismatch verification (§9).

Governance platforms and information display

• Snapshot, Tally, project-native portals — display descriptions, some display payloads. The authors note that Tally's simulation results are optional and submitted by proposers; Table 5 distinguishes them from independent execution results.
• Agora, DAO Stack, Compound, Arbitrum, Uniswap governance tools or forums — listed in the introduction as existing governance tools, without itemized detection experiments reported.

Documentation and execution semantic consistency

• DeFiAligner (Gan et al., 2024) — combines symbolic analysis and LLMs to check inconsistencies between documentation and deployed code. The authors argue that governance proposals also require full lifecycle simulation to obtain verifiable traces.
• Baseline methods — on Tally's 144 annotated proposals, compare All-function keyword match, High-risk keyword match, DeFiAligner-adapted, Direct query, and Evidence-mapping (Table 1). DeFiAligner-adapted uses GPT-4o.

Untrusted input and prompt injection

• Greshake et al. (2023) — study indirect prompt injection in LLM-integrated applications.
• Hines et al. (2024) — study Spotlighting defenses; the authors cite it as the basis for input isolation, treating proposal descriptions as untrusted data (§6.3).

The authors attribute the distinction of their method to independent lifecycle simulation, per-action evidence mapping, and risk-based evidence review, rather than merely displaying payloads or asking the LLM for an overall judgment.

DEMI Detection Framework separates execution trajectory generation from semantic auditing: first obtain reproducible on-chain behavior, then check whether each action has support in the description (Figure 4).

Problem Definition

• Three representations: description d is the voting basis, payload p is the execution input, and trace τ is the runtime behavior. The authors require that a third party can reproduce or verify the trajectory under the same on-chain state assumptions (§3.2).
• Mismatch definition: Cons(ϕ(d),ψ(p))=False. Here φ denotes the behavior voters expect from the description, and ψ denotes the trajectory produced by the payload; the authors define DEMI accordingly.

Lifecycle Simulation

• Profile Building: Scan propose, castVote, and execute calls in the governance contract history, extract payloads, proposers, actual voters, timing parameters, and execution formats, and reuse configurations per DAO.
• Input Building: Merge the target proposal data with the DAO Profile. The simulation fork point is set to proposalStartBlock+1; the authors state this makes the simulation use pre-execution state (§4.3, Figure 5).
• Full lifecycle: Based on Foundry forge, advance blocks and time, and locally simulate proposal, voting, queuing, and execution; use historical voter identities to satisfy the voting process rather than directly calling the execution entry point.
• Trajectory filtering: Remove read-only calls, sub-trajectories triggered by delegatecall, and segments introduced by the simulation script that are not part of the proposal's execute context; retain state-change and value-movement actions.

DEMI Guard: Action–Evidence Mapping

• Input and output: Input the description and filtered execution actions; extract minimal supporting text for each action, and output evidence, whether it is described, confidence, and a summary (Figure 7).
• Design rationale: The authors argue that full semantic equivalence between description and trajectory need not be recovered; finding explicit support per action suffices as the basis for mismatch checking.
• Aggregation configuration: The deployed model is GPT-4o, temperature=1.0, with majority voting over N=5 independent inferences (§5.2, §5.4). Appendix D.3.1 gives the full prompt.

Robustness Guard: Reviewing Evidence and Risk

• Review target: Input the description, execution actions, and mapping results; check whether the evidence comes from the original text, supports the corresponding action, and is not overly broad or divergent from the proposal's purpose (§4.5).
• Risk distinction: Table 9 lists fund operations, ownership or management rights, role permissions, contract upgrades, and dangerous operations as high-risk; the authors require more explicit evidence for these actions.
• Implementation presentation: §4.5 describes the risk constraints as appended to the DEMI Guard prompt; Appendix D.3.2 also provides an independent review prompt that receives the mapping results.
• Input isolation: The deployed version places the description in an untrusted data region and requires the model to treat it as audit material. Appendix D.3.2 gives the full prompt; Appendix D.4 and Figure 11 give evasion examples, not repeated here.

The evidence is divided into historical proposal detection, controlled adversarial evaluation, and deployment-scale scanning, and the datasets and success criteria for the three need to be understood separately.

Experimental Setup

• Models under test: GPT-4o-mini, GPT-4o, GPT-4.1, GPT-5, GPT-5.6, Claude Sonnet 4.5, Claude Opus 4.8, Claude Fable 5, Kimi K3.
• Simulated data: Ethereum full-chain scanning identified 3,681 governance-related contracts, filtering to 358 DAOs with execution history, Etherscan-verified, and supporting voting, including 10,190 executed proposals (§6.1).
• Detection data: Configuration comparison used Tally's 144 annotated proposals; the full system used 3,864, of which 893 were mismatched and 2,971 matched, with stratified 4-fold cross-validation (§5, §6.2).
• Human annotation: Two experts independently checked action-by-action, with 98.5% agreement and Cohen's κ=0.958; 58 disagreements were resolved via a third annotator and consensus among three (Appendix D.1).
• Baselines and metrics: Keyword rules, DeFiAligner-adapted, Direct query, Evidence-mapping; reported Precision, Recall, F1, and simulation coverage. Specific decision threshold values were not reported.
• Adversarial protocol: GPT-4o served as attack generator, guardrail, and voter judge; voter model temperature=0. 84 detected malicious proposals underwent 3 independent trials, each with 4 rounds of red-blue adversarial interaction (§6.3).

Main Results

According to Table 3: Tally's 144 annotated proposals, comparing Direct query and Evidence-mapping (EM) for the same model.

Swipe horizontally to read the table

Model under test	Direct Recall	EM Precision	EM Recall	EM F1
GPT-4o	46.6%	83.9%	83.0%	0.834
GPT-4.1	57.1%	84.5%	85.7%	0.851
GPT-5	62.5%	60.8%	98.9%	0.753
GPT-5.6	64.8%	76.4%	92.0%	0.835
Claude Sonnet 4.5	78.8%	68.3%	98.5%	0.807
Claude Opus 4.8	68.4%	78.6%	93.7%	0.855
Claude Fable 5	35.1%	81.4%	85.7%	0.835
Kimi K3	54.0%	62.0%	92.0%	0.741

• Cross-model trade-offs: EM has higher Recall on these models, but Precision for GPT-5, Claude Sonnet 4.5, and Kimi K3 is lower than their respective Direct query. The authors interpret this as a recall-oriented trade-off.
• Full system: Under 3,864 proposals, GPT-4o, N=5, stratified 4-fold conditions, Precision is 81.7% ±1.1%, Recall is 98.3% ±0.6%, F1 is 0.892 ±0.008 (Table 7).
• Without guardrail: In the same full dataset evaluation, Precision is 79.8% ±1.5%, Recall is 82.4% ±2.1%, F1 is 0.810 ±0.018. The authors position the system as a human review triage layer.

Simulation Coverage and Real Proposal Scanning

• Coverage results: Supported 332/358 DAOs (92.7%), obtaining execution results for 9,098/10,190 proposals (89.3%) (Table 6).
• Simulation failures: 26 DAOs and 1,092 proposals did not yield results; the authors attribute this to on-chain reverts, external oracle dependencies unavailable at fork points, and non-standard voting logic (§6.1).
• Deployment scan: With 10,190 executed proposals as the scan scope, 671 were flagged, 544 manually confirmed, 127 still awaiting project confirmation; confirmed items included 69 malicious and 475 irresponsible proposals, with 9 confirmed by projects (§7, §8).

Adaptive Attacks and Held-Out Generalization

• Knowledge conditions: White-box obtained full guardrail prompts and risk taxonomy; gray-box only knew the public method. Execution behavior remained unchanged, attackers rewrote descriptions; blue team added rules based on evasion cases.
• Defense criteria: Guardrail flagged the proposal, or voter model identified high-risk recipient or amount, both counted as defense success. The authors report defense rates near 70–80% per round; pure text cannot verify the curve positions and per-round values in Figure 10a.
• Held-out results: 84 proposals split by index, with half hardened and half attacked, across 3 trials, base guardrail white-box defense rate was 77.8%, hardened guardrail 66.7% (§6.3). Figure 10b text labels 78% and 67%; the authors suggest robustness in this process may come from structure.

Prompt Injection Stress Test

• Test content: Added 4 types of malicious instruction templates to malicious descriptions, evaluating whether they cause the guardrail to judge as consistent; template content not repeated (§6.3).
• Without input isolation: The authors report highest single-template success rate 60%, and at least one template success rate 68%. The paper does not report the sample denominators for these rates.
• With input isolation: The authors report success rate 4%, corresponding to 1 residual case; denominator not reported. This experiment did not break down the above rates by each template.

Other Ablations and Analyses

• Strategy comparison: 144 proposals, GPT-4o, DeFiAligner-adapted Precision/Recall/F1 is 63.1%/93.2%/0.752; DEMI Guard is 79.3%/100%/0.884 (Table 1).
• Rule baselines: Same 144 data, All-function keyword Precision/Recall is 60.6%/97.7%; High-risk keyword is 63.6%/39.8% (Table 1).
• Temperature: 144 data, GPT-4o EM, temperature=0.0 and 1.0 F1 are 0.834 and 0.791 respectively (Table 2).
• Inference count: 144 data, N=1/3/5/7 F1 is 0.812/0.843/0.839/0.835; Table 4 does not separately indicate the model, §5.4 explains costs based on GPT-4o rates.
• Cost and latency: The above N settings cost per proposal 0.016 USD/0.048 USD/0.080 USD/0.112 USD; the authors report parallel inference end-to-end latency close to single-run ∼8.8s (§5.4).
• Evasion cases: Appendix D.5 discusses action substitution, legitimacy wrapping, partial disclosure; the authors state risk review corrected these misjudgments of base EM, without reporting sample counts or independent accuracy for each type.

The follow-up directions explicitly proposed by the authors are cross-chain governance support and preventive measures at the governance process level; the data scope in the report also has points that need to be distinguished.

Limitations and follow-up directions noted by the authors

• Cross-chain governance: §6.1's Coverage limitations list L2-native timelocks and bridge-based voting as future work; the current scope is Ethereum L1 Governor-pattern DAOs.
• Process safeguards: §8 recommends providing reproducible execution previews before voting, structured review for high-impact proposals, and displaying risk signals; these are governance-layer mitigation directions proposed by the authors.
• Data distribution constraints: Appendix B explains that part of the full trajectories come from proprietary archive RPC that cannot be redistributed; the released materials provide a representative open subset and trajectory regeneration scripts.

Experimental coverage

• Target proposals: §2.1 only discusses proposals with on-chain executable payloads; purely social or signaling proposals, and governance actions delegated to a foundation for later execution, are outside the research scope.
• Detection and adversarial testing: full detection is validated with 4-fold cross-validation on 3,864 historical proposals; adaptive attacks use 84 detected malicious proposals, GPT-4o, 3 trials, and 4 adversarial rounds (§6.2, §6.3).
• Metric definition: the defense rate counts both guardrail interception and voter model risk identification, so it cannot be directly treated as the guardrail's independent interception rate; the denominator for the prompt injection proportion is not reported (§6.3).
• Data count inconsistency: Appendix D.1 writes 69 malicious and 475 irresponsible proposals as 893 mismatched subcategories without explaining the remaining items; §7 uses these two group counts in 544 confirmed cases in another deployment scan.
• Figures and public materials: the monetary text in Figure 2, the main-text trajectories, and later case studies have numerical or unit expression differences, so losses cannot be recalculated from them; the publicly labeled set explicitly listed in Appendix B is 144 items.

This is a study of pre-execution mismatch detection for DAO governance: an attacker can submit a plausible description but have the approved payload execute a different behavior; the voting description does not directly constrain the code.

• Method chain: Reconstruct a DAO Profile from historical transactions, simulate the full governance lifecycle on pre-execution on-chain state, then extract description evidence per action. Robustness Guard reviews evidence, and the deployed version adds untrusted-input isolation.
• Simulation coverage: On filtered active Ethereum governance data, supports 332/358 DAOs, obtains execution results for 9,098/10,190 proposals, with a proposal coverage of 89.3% (Table 6).
• Detection performance: On Tally's 3,864 annotated proposals, with GPT-4o full system and stratified 4-fold validation, average Precision is 81.7%, Recall 98.3%, F1 0.892 (Table 7).
• Models and adversarial: In an 8-model comparison on 144 proposals, EM's Recall is higher than Direct query for all (Table 3); in held-out white-box attacks, the base and enhanced guardrail defense rates are 77.8% and 66.7% (§6.3).
• Real-world scan: In a scan of 10,190 proposals, 544 mismatches were manually confirmed, including 69 malicious and 475 irresponsible proposals; the authors report that 9 of these were confirmed by the project teams (§7, §8).
• Authors' conclusion: The authors argue that per-action evidence and high-risk disclosure requirements can support pre-execution audit, but adaptive bypasses remain. The system is used to prompt human review and cannot equate model judgment with autonomous approval or rejection of proposals.