Detailed Instructions

Begin by drafting your proposal in a collaborative document or forum post. The draft should clearly articulate the problem statement, proposed solution, and implementation plan. Include a detailed specification outlining technical requirements, budget, and timeline. Share this draft in the DAO's designated discussion forum (e.g., Discourse, Commonwealth) to solicit feedback. Actively engage with community members to refine the proposal, address concerns, and build consensus. This pre-submission phase is critical for identifying potential flaws and building the necessary support for a successful vote.

• Sub-step 1: Post the draft RFC (Request for Comments) in the governance forum.
• Sub-step 2: Monitor the discussion thread and respond to questions and critiques.
• Sub-step 3: Iterate on the draft based on feedback, updating the document with version history.

markdownCopy
# RFC: Upgrade Treasury Management
**Author:** 0x742d...CcA1
**Summary:** Propose migrating 20% of ETH treasury to a yield-generating strategy via Aave v3.
**Specification:** Allocate 500 ETH to the Aave Ethereum pool, using a Gnosis Safe with a 2/4 multisig for management.

Tip: Use temperature checks or informal polls within the forum thread to gauge initial sentiment before proceeding.

Detailed Instructions

Once consensus is reached, format the proposal according to your DAO's specific requirements for Snapshot. This involves creating a clear and unbiased title, a comprehensive description with links to the finalized draft, and well-defined voting choices. The voting options must be unambiguous (e.g., "For," "Against," "Abstain") and may include multiple choices for complex proposals. Set the appropriate voting period (e.g., 5 days) and quorum threshold. Ensure all referenced documents, such as technical specifications or budget breakdowns, are immutable (e.g., pinned to IPFS) and linked. The goal is to provide voters with all the information needed to make an informed decision in a single, structured interface.

• Sub-step 1: Create a new proposal on the DAO's Snapshot space (e.g., snapshot.org/#/daoname.eth).
• Sub-step 2: Input the title, description, voting choices, and strategy (e.g., erc20-balance-of).
• Sub-step 3: Set the start time, end time, and snapshot block number for voter eligibility.

codeCopy
Proposal Title: [EP-42] Execute Treasury Diversification to Aave v3
Voting System: Single choice voting
Choices: For, Against, Abstain
Snapshot Block: 19283746
Ends: 2024-10-30 23:59 UTC

Tip: Use the block number from before the proposal is posted to prevent last-minute token acquisitions from influencing the vote.

Detailed Instructions

A successful Snapshot vote signals community intent but does not execute actions. The next step is to craft the calldata for the on-chain transaction that will be submitted to the DAO's governance contract (e.g., Governor Bravo, OZ Governor). This involves encoding the function call to the target contract, such as a Treasury multisig or protocol contract. Use tools like the Tenderly Simulator or a local fork to test the transaction's effects and ensure it will not revert. The proposal must specify the exact target address, value (usually 0), calldata, and description hash. This data is then submitted via the propose function on the governance contract, which typically requires a proposal threshold of governance tokens to submit.

• Sub-step 1: Use encodeFunctionData to generate the calldata for the desired function call.
• Sub-step 2: Simulate the transaction on a forked network to verify state changes and gas costs.
• Sub-step 3: Call propose(targets, values, calldatas, description) on the governance contract.

solidityCopy
// Example: Encoding a call to a Treasury contract
bytes memory callData = abi.encodeWithSignature(
    "execute(address,uint256,bytes)",
    targetStrategy,
    500 ether,
    strategyCalldata
);
// Propose the transaction
governor.propose(
    [treasuryAddress],
    [0],
    [callData],
    "Transfer 500 ETH to yield strategy"
);

Tip: The description string should be the keccak256 hash of the proposal description used in Snapshot to maintain a clear link.

Detailed Instructions

After submission, the proposal enters a formal voting delay and then a voting period on-chain. Token holders cast votes directly from their wallets, with weight determined by their token balance at the proposal snapshot block. As the proposer, you should actively campaign for the proposal, answer technical questions, and monitor the vote tally. If the proposal achieves the required quorum and a majority of for votes, it moves to the timelock period (if applicable), where it awaits execution. After the timelock expires, any address can call the execute function on the governance contract to enact the proposal's transactions. Failure to execute before the execution deadline results in the proposal expiring.

• Sub-step 1: Track the proposal state (Pending, Active, Succeeded, Queued, Executed) via the governance contract or a block explorer.
• Sub-step 2: After a successful vote and timelock, call execute(proposalId) with the correct parameters.
• Sub-step 3: Verify the transaction succeeded on-chain and that the intended state changes occurred.

bashCopy
# Example: Checking a proposal's state using cast (Foundry)
cast call <GOVERNOR_ADDRESS> "state(uint256)" <PROPOSAL_ID>
# Returns a uint (4 = Succeeded, 5 = Queued, 7 = Executed)

# Executing the proposal
cast send <GOVERNOR_ADDRESS> "execute(uint256)" <PROPOSAL_ID> --private-key <KEY>

Tip: Use a gas-efficient relayer service or a dedicated executor bot to ensure timely execution, especially for time-sensitive proposals.

Detailed Instructions

Once your proposal is live, actively monitor its status on the governance dashboard (e.g., Tally, Snapshot, or the DAO's custom interface). Key metrics to track include the current vote tally (for/against/abstain), voter turnout percentage, and the voting power represented. Set up notifications for new votes or forum posts.

• Sub-step 1: Check the proposal page daily for new votes and delegate activity.
• Sub-step 2: Participate in the corresponding forum thread (e.g., Commonwealth, Discourse) to answer questions and address concerns in real-time.
• Sub-step 3: Monitor whale wallet activity using Etherscan or a DAO-specific tool to understand how large token holders are voting.

Tip: Use a multisig or team member to ensure 24/7 coverage during critical voting phases, especially in global DAOs.

Detailed Instructions

Community pushback is common. Your role is to de-escalate conflict and provide clarifications based on the proposal's data. If significant, legitimate flaws are raised, you may need to consider amendments.

• Sub-step 1: Logically and politely respond to each substantive objection in the forum, referencing specific sections of your proposal.
• Sub-step 2: If a critical bug or unintended consequence is found, assess if it requires a new proposal. For minor clarifications, post an addendum.
• Sub-step 3: In extreme cases, if the proposal is failing due to a fatal flaw, you may execute a withdrawal. On Compound-style governors, this might involve calling cancel(uint256 proposalId) from the proposer's address before the voting ends.

solidityCopy
// Example: Canceling a proposal on a typical governor contract
GovernorBravo gov = GovernorBravo(0xABCD...);
gov.cancel(proposalId);

Tip: Never edit the original proposal text on-chain; all changes must be transparently documented off-chain.

Detailed Instructions

A passing vote does not mean the proposal is enacted. Most systems have a timelock between vote conclusion and execution. Use this period to prepare.

• Sub-step 1: Verify the vote met all quorum and vote differential requirements definitively.
• Sub-step 2: Confirm the target smart contract addresses and calldata in the proposal are still valid and no state changes have made them dangerous.
• Sub-step 3: If the system requires it, you must call the queue function. For example, on a GovernorBravo timelock: timelock.queueTransaction(target, value, signature, calldata, eta).

solidityCopy
// Example parameters for a queue call
address target = 0x742d35Cc6634C0532925a3b844Bc9e97F4aC8A3F; // Target contract
uint256 value = 0;
string memory signature = "transfer(address,uint256)";
bytes memory data = abi.encode(recipient, 1e18); // Calldata
uint256 eta = block.timestamp + timelock.delay();

Tip: The eta (estimated time of execution) must be calculated based on the timelock's minimum delay.

Detailed Instructions

After the timelock delay has passed, anyone can trigger the execute function. As the proposer, you should ensure this happens smoothly and verify the results.

• Sub-step 1: Call the executeTransaction method on the timelock contract with the same parameters used in queue. For example: timelock.executeTransaction(target, value, signature, calldata, eta).
• Sub-step 2: Monitor the transaction on Etherscan. Confirm it succeeds and does not revert due to a changed contract state or insufficient gas.
• Sub-step 3: Perform post-execution verification. Check that the on-chain state matches the proposal's intent. If it was a treasury transfer, verify the recipient's balance. If it was a parameter change, query the new value from the contract.

solidityCopy
// Example: Verifying a parameter change via a view function
// Assume the proposal set a new `interestRateModel` address on a lending market.
CErc20Delegate market = CErc20Delegate(0xMarketAddress);
address newModel = market.interestRateModel();
require(newModel == 0xProposedAddress, "Execution failed: incorrect model set");

Tip: Keep a record of the execution TX hash and a summary of the verified outcome for the DAO's archives.

Detailed Instructions

Transparency after execution builds trust and creates a reference for future proposals. Documentation is the final, critical step.

• Sub-step 1: Create a final post in the governance forum. Title it "[EXECUTED] Proposal [ID]: [Title]".
• Sub-step 2: In the post, include the final vote tally, a link to the successful execution transaction on a block explorer, and a summary of the verified on-chain changes.
• Sub-step 3: If the proposal involved ongoing actions (e.g., a grant disbursement over time), outline the next steps and responsible parties. Link to any new monitoring dashboards or reporting channels created.

Tip: This report serves as the official record and helps the DAO measure the real-world impact of its governance decisions, informing future proposal design.