Update
A practical guide to how AGT holders move from token ownership through delegation, proposal creation, voting, timelock queuing, and onchain execution.
Status: published · Last reviewed:
Antfarm DAO governance is designed so that every meaningful protocol change follows a predictable, verifiable path on Ethereum mainnet. This article walks through each stage of that lifecycle and explains what token holders, delegates, and observers should expect at each step.
Onchain governance is not a single transaction. It is a sequence of checks—proposal thresholds, voting periods, quorum requirements, and timelock delays—that give the community time to review before code executes. Understanding this sequence helps you evaluate whether a proposal is still open for input, awaiting execution, or already finalized.
> **Data disclaimer:** Examples in this article reference demo proposals and parameters used in development. Always verify current values on the official governance portal and block explorer before making decisions.
**Antfarm Governance Token (AGT)** is the ERC-20 token that underpins participation in Antfarm DAO. Holding AGT is the entry point, but voting power is not measured directly from wallet balance alone.
AGT can be acquired through recognized market venues or transfers from other holders. The contract address for AGT on Ethereum is `0x0BF43350076F95e0d16120b4D6bdfA1C9D50BDBD`. Confirm this address on the Contracts page before interacting.
To participate in governance with meaningful weight, holders typically **lock AGT** and receive **vote-escrowed AGT (veAGT)**. veAGT is non-transferable voting power derived from locked positions. The veAGT contract (`0xDCd2B58585DF999DD145e529f09e8ACaFA6cd244`) accounts for locked balances used in proposal creation and voting.
Lock duration and decay mechanics follow protocol documentation. Longer commitments generally correspond to greater voting weight, subject to the parameters in effect at the time of locking.
Not every token holder votes on every proposal. **Delegation** allows you to assign your veAGT voting power to an address you trust—often a known delegate who publishes a statement and voting record.
Delegation does not transfer token custody. You retain ownership of your locked position while the delegate casts votes on your behalf. Review delegate participation metrics on the Delegates page before delegating.
A community member with sufficient veAGT can **submit a proposal** to the Antfarm Governor contract (`0xD63123527551F037fAAc74bf5fDA5B71569cf5af`). Proposals include a title, description, and one or more onchain actions—contract calls the timelock will execute if the vote succeeds.
The **proposal threshold** sets the minimum voting power required to create a proposal. Parameter changes to this threshold, such as those discussed in historical proposal `prop-3`, require their own governance vote.
After submission, a **voting delay** elapses before voting opens. During this window, the community can review forum threads, documentation, and decoded calldata.
Once the voting period begins, delegates and direct holders cast **For**, **Against**, or **Abstain** votes. The governor tallies vote weight from veAGT balances at the snapshot block defined by the contract.
Key concepts during voting:
Active proposals appear on the Proposals listing with status badges and quorum progress indicators.
If a proposal passes, it enters the **timelock queue** (`0x529C78Ee582e4293a20Ab60c848506eADd8723D8`). The timelock enforces a mandatory delay between passage and execution. This delay gives stakeholders a final review window for queued transactions.
Queued proposals show a distinct status on the portal. The timelock delay parameter itself can be modified by governance, as proposed in `prop-6`.
After the timelock delay expires, anyone can trigger **execution**. The governor instructs the timelock to perform the approved contract calls. Execution produces an onchain transaction hash, block number, and success or failure status.
Executed proposals—such as `prop-4` (Treasury Reporting Standards) and `prop-1` (CORE Bundle parameters)—remain permanently visible for audit. Compare the portal's plain-language summary against the execution transaction on Etherscan.
1. Read the summary and forum discussion linked from the proposal detail page. 2. Inspect decoded actions: target contract, function, arguments, and raw calldata. 3. Track status transitions: pending → active → succeeded → queued → executed. 4. Verify the execution transaction on a block explorer using the official contract registry.