Setting Up Governance for Non-EVM Projects

On-chain governance is a core feature for decentralized projects, allowing token holders to propose, vote on, and execute protocol changes directly. While the Ethereum Virtual Machine (EVM) ecosystem has established patterns like OpenZeppelin's Governor contracts, non-EVM chains require a different architectural approach. Projects on frameworks such as Cosmos SDK, Solana, or Substrate must implement governance logic within their native runtime or smart contract environment. This involves defining key components: a proposal system, a voting mechanism with weighted stakes, and an execution pathway for passed proposals. The design must account for the chain's unique consensus model, transaction lifecycle, and state management.

The first step is defining the proposal lifecycle. A standard flow includes: - Submission: A user deposits a bond to create a proposal containing executable code or text. - Voting Period: Token holders cast votes, with weight typically based on their staked amount. - Tallying & Execution: After the period ends, votes are tallied against a quorum and passing threshold. Successful proposals are queued for automatic execution or require a manual trigger. For example, in a Cosmos SDK chain, you would define a MsgSubmitProposal type in your application's x/governance module, specifying parameters like min_deposit, voting_period, and quorum. The voting power is usually derived from the staking module's validator set.

Implementing the voting mechanism requires integrating with your chain's staking or token model. Unlike EVM's simple token-balance voting, non-EVM chains often use bonded stake (assets locked for security) for governance weight. In Substrate's pallet_democracy, users vote with their locked funds, and the runtime uses Conviction multipliers for longer lock-ups. On Solana, a program would read voter weights from staking accounts (e.g., Marinade's mSOL) or a snapshot mechanism. You must also decide on vote aggregation: simple majority, quadratic voting, or conviction voting. Security is critical; the logic must prevent double-voting and ensure the tally is gas-efficient and resistant to manipulation.

Finally, you need a secure execution path. For parameter changes, the governance module can directly invoke a function in another module's runtime (e.g., updating a reward rate in a staking pallet). For complex upgrades, especially on chains with WebAssembly runtimes like Cosmos or Polkadot, proposals often contain the new runtime binary itself, triggering an on-chain upgrade without a hard fork. Testing is essential: use your framework's native testing tools (like cargo test for Substrate or simapp for Cosmos) to simulate full proposal lifecycles. Resources like the Cosmos SDK Governance Module and Substrate Democracy Pallet provide concrete implementation blueprints.

On-chain governance allows token holders to vote directly on protocol upgrades, treasury spending, and parameter changes. While Ethereum's EVM ecosystem has mature tooling like OpenZeppelin Governor, non-EVM chains require a different architectural approach. Key prerequisites include a native token for voting rights, a secure smart contract or program framework (e.g., Solana's Sealevel runtime or Cosmos SDK modules), and a clear specification for proposal lifecycle states—from submission and voting to execution and timelocks.

The core governance model must be defined upfront. Will you use token-weighted voting, where one token equals one vote, or a more complex system like conviction voting or quadratic voting? You must also decide on critical parameters: the minimum proposal deposit, voting period duration (e.g., 3 days on Cosmos), quorum thresholds, and the percentage needed to pass. For example, a common setup might require a 4% quorum of the total token supply and a 50% majority of votes cast to approve a proposal.

Technical implementation varies by chain. On Solana, you would write a governance program in Rust using the Anchor framework, storing proposal and vote accounts on-chain. On a Cosmos appchain, you would implement a governance module within the Cosmos SDK, leveraging its built-in x/gov module for proposal handling. For Algorand, you would use PyTeal or Reach to create a stateful smart contract that manages the proposal lifecycle. Each requires deep familiarity with the chain's execution environment and transaction model.

Security is paramount. Governance contracts control the protocol's treasury and upgrade keys, making them prime attack targets. Essential practices include conducting formal audits, implementing multi-signature timelocks for execution (a 48-hour delay is standard), and establishing a fallback emergency governance mechanism, often a multi-sig controlled by trusted entities. You should also plan for vote delegation and snapshot voting integrations, which allow users to delegate voting power without moving tokens, enhancing participation.

Finally, consider the user experience and tooling. Voters need clear interfaces to view proposals, understand changes, and cast votes. You'll need to integrate with chain-specific wallets (e.g., Phantom for Solana, Keplr for Cosmos) and indexers or subgraphs to query proposal data. Planning for off-chain discussion forums, like a Commonwealth instance or Discourse, is also crucial for healthy governance before proposals reach the chain.

On-chain governance allows a decentralized community to propose, vote on, and execute changes to a protocol. On Solana, this is implemented using Program Derived Addresses (PDAs), token-weighted voting, and a series of executable instructions. Unlike Ethereum's contract-based approach, Solana's governance logic is typically built as a standalone program that interacts with your project's core smart contracts. The primary components are a governance program (like Realms), a governed program (your protocol), and a community token used for voting power.

The most common starting point is the Realms governance platform, an open-source program maintained by Solana Labs. Realms provides a standard interface for creating DAOs, managing treasuries, and processing proposals. To integrate, your project's token mint must be registered as the governing token. Proposals are created as on-chain transactions, and voting power is calculated from a snapshot of token holders at a specific slot. Votes are weighted by the voter's token balance, with options for yes, no, and veto.

A governance proposal lifecycle involves several steps. First, a community member deposits a configurable minimum number of tokens to create a proposal. The proposal includes: the governed program's address, the instruction data to execute if passed, and a description. During the voting period, token holders cast their votes. If the proposal reaches the passing threshold (e.g., a majority of yes votes and a minimum quorum), it enters a finalizing state. A governance authority (often a multisig or the DAO itself) then executes the instruction against your program.

To make your program governable, you must design it to accept and validate instructions from a specific governance PDA. This involves adding an authority check at the start of critical functions. In your program's instruction handler, you would verify that the signer is the expected governance PDA derived from the Realms program ID and your DAO's address. This ensures only successfully passed proposals can execute privileged actions, such as updating protocol parameters or withdrawing from the treasury.

Here is a simplified code snippet for a governable instruction in a Solana program using the Anchor framework:

rustCopy
use anchor_lang::prelude::*;
use realm_governance::cpi::accounts::Governance;

#[derive(Accounts)]
pub struct UpdateProtocolFee<'info> {
    #[account(mut)]
    pub vault: Account<'info, Vault>,
    pub governance_program: Program<'info, realm_governance::program::RealmGovernance>,
    #[account(
        seeds = [b"governance", dao.key().as_ref()],
        bump,
        seeds::program = governance_program.key()
    )]
    pub governance_pda: AccountInfo<'info>,
    pub dao: AccountInfo<'info>, // The Realm/DAO account
}

pub fn handler(ctx: Context<UpdateProtocolFee>, new_fee: u16) -> Result<()> {
    // The governance_pda signer is validated by Anchor via the seeds constraint
    ctx.accounts.vault.protocol_fee_bps = new_fee;
    Ok(())
}

This struct ensures only the correct governance PDA, derived from the specific DAO, can invoke the fee update.

Key considerations for a production system include setting appropriate voting delays and timelocks to prevent rash decisions, designing a multisig fallback for emergency upgrades, and integrating with vote escrow models (like ve-tokenomics) for long-term alignment. Tools like Helium's Governance offer alternative implementations. Always audit the interaction between your program and the governance module, as the governance PDA holds ultimate upgrade authority.

The Cosmos SDK provides a robust, modular framework for building application-specific blockchains with native on-chain governance. Unlike EVM chains where governance is often a smart contract, governance here is a core module integrated at the protocol level. The x/gov module handles proposal submission, deposit collection, voting, and execution. To implement it, you must first ensure the module is added to your application's app.go file within the ModuleManager. Key parameters like MinDeposit, VotingPeriod, and Quorum are defined in the module's genesis state, giving you control over the proposal lifecycle from day one.

Governance proposals in Cosmos SDK are typed. The main types are: Text proposals for general signaling, Parameter change proposals to update module parameters on-chain, and Software upgrade proposals to coordinate chain upgrades. Implementing a custom proposal type requires defining a new message type that implements the sdk.Msg interface and registering a corresponding handler in the governance module. All proposals follow a lifecycle: 1) Submission with a minimum deposit, 2) A deposit period to reach MinDeposit, 3) A voting period where validators and delegators vote, and 4) Tallying and execution if the proposal passes.

Voting power is derived from a validator's staked tokens, not a separate token. The x/staking module provides the VotingPower for each validator, which is then delegated to the validator's chosen vote by all stakers. The governance module tallies votes weighted by this staking power. Critical parameters you must configure include quorum (minimum voting power participation), threshold (minimum Yes votes to pass), and veto_threshold. These are set in genesis and can later be changed via parameter change proposals. Use the simapp for testing governance logic in a simulated environment before launching your chain.

To submit a proposal, users interact with the chain via the gaiad or your chain's CLI. The command structure is: [chain-cmd] tx gov submit-proposal --type="Text" --title="My Proposal" --description="Details" --from mykey. For parameter changes, a JSON file defining the changes is required. As a chain developer, you must ensure your client software (CLI, REST, or gRPC) exposes these endpoints. Governance activity is queryable via commands like query gov proposals or query gov vote [proposal-id] [voter-address].

Best practices for secure governance include setting an initial MinDeposit high enough to prevent spam but accessible to the community, using a reasonable VotingPeriod (e.g., 2 weeks) for adequate deliberation, and clearly documenting the process for users. Remember, passed parameter change and upgrade proposals are automatically executed by the chain's logic. Therefore, thorough testing of proposal handlers and upgrade procedures on a testnet is non-negotiable to avoid network instability from a faulty governance decision.

Substrate's FRAME (Framework for Runtime Aggregation of Modularized Entities) provides a suite of pre-built pallets for governance, with pallet-democracy, pallet-collective, and pallet-treasury forming the core. Unlike EVM-based systems that often rely on snapshot voting or governor contracts, Substrate governance is natively integrated into the blockchain's runtime. This allows for proposals to directly execute privileged calls, such as upgrading the runtime via set_code, without requiring a separate multisig. The typical flow involves public proposal submission, a council or technical committee for fast-track voting, and a final public referendum.

To begin, you must configure the governance pallets in your chain's runtime. This involves defining parameters like voting periods, enactment delays, and deposit amounts. In your runtime/src/lib.rs file, you implement the configuration traits for each pallet. For example, configuring pallet-democracy requires specifying an Origin for root calls (like EnsureRoot or a collective), a Scheduler for enacting passed proposals, and a Currency for locking tokens during votes. The council (pallet-collective) is often set up with a specific membership origin for adding/removing members and rules for majority or unanimous voting thresholds.

A key step is establishing the proposal lifecycle. A standard proposal starts in the Democracy pallet's public queue, requiring a bond. It can be fast-tracked by the Collective (council) using pallet-democracy's external_propose functionality. Once a referendum is scheduled, token holders vote using their locked funds. Substrate supports conviction voting, where longer lock-up periods multiply voting power. After a successful vote, the proposal is scheduled for execution via the Scheduler pallet after a defined enactment delay, providing a final window for network participants to prepare for changes.

For advanced control, you can integrate the Treasury pallet to manage a community fund. Proposals to spend from the treasury are typically first approved by the council via pallet-treasury::approve_proposal, then require a final public referendum. The Technical Committee, configured as another instance of pallet-collective, can be given the power to fast-track emergency proposals, such as critical bug fixes, by shortening the enactment delay to zero. This multi-layer system balances direct community voice with the efficiency of delegated oversight.

Testing your governance setup is critical. Use the sp_io::TestExternalities environment in your runtime's test suite to simulate proposal submission, voting across multiple accounts, and final execution. Verify that a successful referendum correctly dispatches the intended call, like a sudo::sudo call to change a parameter. Remember that governance logic is part of your runtime's state; all changes are stored on-chain, making the system self-contained and transparent, a distinct architectural advantage over external smart contract-based governance common in EVM chains.

Governance is the mechanism by which a decentralized network makes collective decisions, typically involving protocol upgrades, parameter changes, and treasury management. For non-EVM projects, the core challenge is designing a system that is both secure and flexible enough to evolve. Key architectural decisions include choosing between on-chain voting (binding) and off-chain signaling (non-binding), defining eligible participants (e.g., token holders, validators), and establishing proposal lifecycle stages. Unlike EVM chains where standards like OpenZeppelin's Governor provide a template, non-EVM frameworks require custom module development, making security audits paramount from the outset.

The security of a governance module hinges on its proposal and execution logic. A critical vulnerability is the proposal execution attack, where malicious code is hidden within a seemingly benign upgrade proposal. To mitigate this, implement a timelock between a proposal's approval and its execution. This delay allows the community to review the final executable code. Furthermore, consider a multisig guardian council with the power to veto or pause execution in emergencies, acting as a circuit breaker. For chains using the Cosmos SDK, the x/gov module with a minimum deposit and voting period is the starting point, but you must carefully configure the TallyParams for quorum and threshold.

Smart contract upgrades on EVM chains often use proxy patterns (e.g., Transparent or UUPS). Non-EVM runtimes require different patterns. In Cosmos SDK, upgrades are managed via on-chain governance proposals that signal validators to switch to a new, pre-agreed software binary. The x/upgrade module handles this process. Substrate/Polkadot uses the sudo pallet or the more decentralized OpenGov (Governance v2) to dispatch a call to the system::set_code function, which replaces the entire runtime WebAssembly blob. Each method requires rigorous testing on a testnet, as a faulty upgrade can halt the chain.

When designing the voting mechanism, consider vote dilution and voter apathy. A pure token-weighted vote can lead to whale dominance. Alternatives include:

• Conviction Voting: A voter's voting power increases the longer they lock their tokens.
• Quadratic Voting: The cost of votes increases quadratically, reducing the power of large holders.
• Validator/Delegator Models: Used in Cosmos and Polkadot, where delegators' stakes back validator votes. Implementing these requires custom logic in your chain's native modules, increasing complexity and audit scope.

Finally, establish clear off-chain processes to complement the on-chain system. This includes a requirements for all proposals to have a canonical discussion thread on a forum like Commonwealth or Polkassembly, a mandatory code audit for upgrade proposals, and a disaster recovery plan specifying how to coordinate a manual intervention if the on-chain governance is compromised. The goal is a layered defense: a transparent community process, a secure on-chain execution delay, and a fallback human layer, ensuring the network can adapt safely over its lifetime.

You now have a blueprint for a functional governance system. The final step is integrating your chosen voting mechanism—whether a native module, a Cosmos SDK-based system, or a custom Substrate pallet—with your token's staking or delegation logic. This integration must be rigorously tested on a testnet. Simulate governance proposals, quorum failures, and edge cases like vote delegation changes mid-proposal. For projects using a bridge to an EVM chain for voting (e.g., via Axelar or Wormhole), conduct end-to-end tests of the message-passing flow to ensure proposal data and vote tallies are synchronized accurately and securely.

Beyond the technical launch, the long-term health of your governance depends on community engagement and clear processes. Establish transparent channels for discussion, such as a dedicated forum (e.g., Commonwealth) or Discord channel. Draft an initial governance framework document that outlines: proposal submission requirements, mandatory discussion periods, quorum and threshold levels, and the process for treasury management. Consider implementing a multisig council or a security module as a fallback during the early stages to handle critical upgrades or emergency responses, with a clear sunset plan as the decentralized system matures.

Your governance model will need to evolve. Plan for future upgrades to the system itself, which may require its own governance process. Monitor key metrics like voter participation rates, proposal throughput, and the diversity of proposal authors. Resources like the Blockchain Governance Research Forum provide ongoing analysis. The goal is to incrementally decentralize control while maintaining the agility and security required for your specific application, whether it's a Layer 1, DeFi protocol, or DAO.