Update
Learn to interpret vote results, timelock execution, contract actions, and verification steps for proposals that have completed the governance lifecycle.
Status: published · Last reviewed:
An executed proposal is a completed governance decision with an onchain record. This guide explains how to read proposal detail pages, interpret vote outcomes, and independently verify that execution matched voter intent.
Every proposal detail page begins with a **plain-language summary** written for readers who may not read Solidity. This summary describes what the proposal intended to change—treasury policy, protocol parameters, or contributor funding—and why the proposer submitted it.
Treat the summary as orientation, not proof. The authoritative record is the set of **proposed actions** and the **execution transaction**.
> **Verify before trusting:** Always cross-check proposal actions and execution transactions through the official governance platform and a block explorer.
The voting section displays **For**, **Against**, and **Abstain** totals with percentage breakdowns and quorum progress.
Percentages are calculated from raw onchain vote integers. The portal uses bigint-safe arithmetic—vote weights are never converted to JavaScript floating-point numbers for storage or tallying.
Example from an executed proposal (`prop-4`):
**Quorum** is the minimum participation required for a valid vote. Quorum progress compares total votes cast (for + against + abstain) against the quorum threshold defined at proposal creation.
If quorum is not met, the proposal fails regardless of the for/against ratio. Check the status badge: `executed` and `succeeded` imply quorum was satisfied under the rules in effect at vote time.
Status labels map to human-readable outcomes:
| Onchain status | Portal label | Meaning | | --- | --- | --- | | succeeded | Passed | Vote succeeded; may proceed to queue | | queued | Queued | Waiting in timelock | | executed | Executed | Onchain actions performed | | defeated | Defeated | Did not pass | | canceled | Canceled | Withdrawn or canceled |
The **timeline** section orders key timestamps:
1. **Created** — proposal submitted to the governor 2. **Voting started** — voting delay elapsed 3. **Voting ended** — voting period closed 4. **Queued** — passed proposal entered timelock 5. **Executed** — timelock performed approved calls
Gaps between timestamps reflect deliberate delays—especially between queue and execute, which equals the timelock delay parameter.
Each action in an executed proposal includes:
For `prop-1`, actions targeted the Position Manager (`0xEe8c1c668d533d38db792dEEB35898fe8d3A33B1`) to update CORE bundle weights. For `prop-4`, actions targeted the Governor to register a reporting standard identifier.
Compare decoded arguments against forum discussion and documentation. If calldata does not match the described intent, treat that as a red flag before interacting with related contracts.
The **execution** section shows:
A successful execution does not guarantee every downstream effect behaved as expected—only that the approved calls ran without revert at the timelock layer. Complex migrations may require additional monitoring.
Proposals often link to:
Use these references to understand motivation and community debate, then verify independently onchain.
1. Open the proposal on Tally or this portal's proposals page and note the proposal ID. 2. On the Antfarm DAO portal, confirm status is **Executed** and review vote totals. 3. Expand each proposed action and note target addresses against the contract registry. 4. Open the execution transaction on Etherscan and confirm `from` is the timelock controller path. 5. Verify event logs and state changes match the decoded function calls. 6. Archive links for future research or delegate accountability reviews.
Yes. If approved calls revert—due to invalid parameters, insufficient permissions, or changed contract state—execution may fail. The portal marks execution success or failure when that data is available from the indexer or RPC source.
No. The Antfarm DAO website is read-only in its first release. Voting and execution occur through recognized external platforms and direct contract interaction.
Contact support@antfarmdao.com if you believe displayed data does not match onchain state. Include proposal ID, transaction hash, and explorer links.