How to Architect a DAO with Hybrid On-Chain/Off-Chain Governance

Hybrid governance is the dominant model for serious Decentralized Science (DeSci) DAOs, combining the immutable execution of on-chain voting with the flexible deliberation of off-chain forums. This architecture addresses a core tension: complex scientific decisions require nuanced discussion, but fund allocation and protocol upgrades demand cryptographic certainty. A typical stack uses Snapshot for gas-free, off-chain sentiment signaling, which then informs binding on-chain votes executed via a smart contract on Ethereum L2s like Arbitrum or Optimism. This separation allows for iterative refinement of proposals before committing irreversible actions to the blockchain.

The first architectural decision is defining your governance surface. What actions require an on-chain transaction? For a DeSci DAO, this typically includes: treasury.transfer() for grant payouts, protocol.upgrade() for smart contract changes, and membership.update() for adjusting contributor roles. These are encoded as executable functions within your governance contract, often using a framework like OpenZeppelin Governor. Off-chain processes handle everything else: research proposal ideation, peer review, working group coordination, and preliminary budget discussions. Tools like Discourse, Commonwealth, or Forefront facilitate these discussions.

Implementing this requires a clear proposal lifecycle. A common flow is: 1) Temperature Check: An informal poll on Snapshot to gauge sentiment. 2) Request for Comments (RFC): A detailed forum post incorporating feedback. 3) Binding Vote: A finalized proposal is created on Snapshot with the encoded calldata for the on-chain action. 4) Execution: Upon passing, a designated multisig or automated executor submits the transaction. Here’s a simplified example of proposal calldata for funding a grant:

codeCopy
// Target: Treasury Contract
// Value: 50,000 USDC
// Calldata: transfer(address(recipient), 50000000000)

Security and delegation are critical. Use a timelock contract between a vote's passage and its execution. This introduces a mandatory delay, providing a final window to veto malicious or erroneous proposals. For token-based voting, implement delegation (like ERC-20Votes) to allow less active members to delegate their voting power to subject-matter experts. This creates a representative democracy layer within the DAO, essential for managing the complexity of scientific evaluation where not all members are experts in every field.

Successful DeSci DAOs like VitaDAO and LabDAO operationalize this model. They use Snapshot for weekly voting on grant proposals, with execution via a Gnosis Safe multisig on Polygon. Their off-chain work happens in Discourse forums and working group calls, ensuring detailed scientific scrutiny before any on-chain commitment. The key is continuous iteration: regularly review governance parameters like proposal thresholds, voting periods, and quorum requirements based on participation data to maintain resilience and legitimacy as the organization scales.

A solid understanding of blockchain fundamentals is non-negotiable. You should be comfortable with concepts like wallets, transactions, gas, and the Ethereum Virtual Machine (EVM). Familiarity with smart contract development is critical; you'll need to write, test, and deploy contracts for your on-chain voting and treasury logic. Proficiency in Solidity and experience with a framework like Hardhat or Foundry is essential for this stage of development.

For the off-chain component, you'll need backend development skills. A common stack includes Node.js with a framework like Express.js or Fastify to build your governance API. You'll also require a database to store proposal metadata, votes, and user profiles; PostgreSQL or MongoDB are popular choices. Knowledge of RESTful API design and authentication (e.g., using SIWE - Sign-In with Ethereum) is necessary to securely connect user wallets to your off-chain service.

Your architecture will rely heavily on oracles and indexers to bridge the on- and off-chain worlds. For reading on-chain data (like token balances for voting power) into your backend, you'll use a service like The Graph for subgraphs or an RPC provider like Alchemy or Infura. To execute on-chain transactions from your server (e.g., to queue a successful proposal), you'll need a relayer or smart wallet infrastructure, such as Gelato Network or OpenZeppelin Defender, to manage private keys securely and pay gas fees.

A hybrid governance model strategically splits decision-making processes between on-chain smart contracts and off-chain systems. The core principle is to execute binding actions, like treasury disbursements or parameter updates, on-chain via a Governor contract, while handling complex discussion, voting, and computation off-chain. This separation addresses the gas cost and throughput limitations of purely on-chain voting, enabling richer proposals and participation without congesting the blockchain. Popular frameworks like OpenZeppelin Governor and Aragon OSx are built with this hybrid philosophy, using off-chain tools for proposal creation and snapshot voting before final on-chain execution.

The standard architecture involves three key layers. The off-chain layer uses tools like Snapshot for gasless voting, Discourse or Commonwealth for forums, and Tally or Boardroom for interfaces. Here, members debate and signal intent. The on-chain layer consists of the core smart contracts: a Timelock controller for secure, delayed execution; a Governor contract that validates and enacts passed proposals; and the Token contract defining voting power. The bridging layer, often a relayer or keeper network, is critical for submitting the final transaction with the voting proof (like a Merkle root from Snapshot) to the Governor contract.

Implementing this requires careful smart contract design. Your Governor contract must be configured to accept proposals from an authorized relayer address and verify off-chain vote results. A typical flow is: 1) A proposal with calldata is posted off-chain. 2) Token holders vote gaslessly, with signatures or off-chain balances recorded. 3) After the voting period, a relayer calls execute on the Governor, providing the proposal ID and a proof of the vote result. 4) The Governor validates the proof, and if successful, queues the action in the Timelock. Use EIP-712 typed structured data for signing off-chain votes to ensure cryptographic validity.

Security is paramount in the bridging layer. The relayer that submits the execution transaction is a centralization vector. Mitigations include using a decentralized keeper network like Chainlink Automation or a multi-signature council as the relayer. Furthermore, always implement a Timelock between proposal execution and action. This gives the community a safety window to react if a malicious proposal, perhaps due to a compromised relayer key, passes through the system. The timelock duration is a key governance parameter, often set between 24 hours and 7 days.

This architecture is ideal for DAOs managing complex DeFi protocols, large treasuries, or frequent parameter adjustments. For example, Uniswap governance uses off-chain Snapshot voting to signal direction, with multi-sig execution for on-chain upgrades. When designing your system, choose off-chain tools that align with your token model (e.g., ERC-20, ERC-721, ERC-1155 for voting power) and ensure your on-chain contracts have clear, audited functions for the relayer to call. The end result is a DAO that is both responsive to community input and practically scalable on Ethereum L1 or L2 networks.

The first step in building a hybrid DAO is deploying the on-chain treasury contract. This smart contract acts as the custodian for the DAO's assets, holding native tokens (like ETH, MATIC), stablecoins (like USDC, DAI), and other ERC-20 tokens. Unlike a simple multi-signature wallet, a purpose-built treasury module integrates directly with your governance framework, allowing it to receive and execute proposals. For security and standardization, many projects fork and customize established codebases like OpenZeppelin's Governor contracts or use frameworks such as Aragon OSx.

When architecting this module, you must define its execution permissions. In a hybrid model, the treasury should only execute transactions that have been formally approved through your off-chain governance process (e.g., a Snapshot vote followed by a multisig execution). This is typically enforced by setting the treasury's owner or executor to a Gnosis Safe multisig wallet or a dedicated governance module contract that validates a proposal's on-chain state. This separation ensures that no single entity can move funds without the recorded consent of the DAO.

Key functions to implement include executeTransaction(address to, uint256 value, bytes data), which processes payments or contract interactions, and receive() for accepting native assets. You should also add view functions for transparency, such as getBalance(address token) to list holdings. It's critical to include emergency security features like a timelock delay for large transactions, which can be implemented using OpenZeppelin's TimelockController. This adds a mandatory waiting period between proposal approval and fund movement, giving token holders a final window to react if an exploit is detected.

For development and testing, use a local fork of a mainnet using Hardhat or Foundry. Deploy your contract to a testnet like Sepolia or Goerli first. A basic deployment script in Hardhat might look like:

javascriptCopy
const Treasury = await ethers.getContractFactory('DAOTreasury');
const treasury = await Treasury.deploy(governanceMultiSigAddress, timelockDelay);
await treasury.deployed();

After deployment, verify the contract source code on block explorers like Etherscan to establish trust with your community.

Finally, connect the deployed treasury to your off-chain governance stack. This means configuring your Snapshot space so that successful proposals generate the calldata needed for the treasury's executeTransaction function. Tools like Tally or Sybil can help map off-chain voter identities to on-chain actions. The completed module creates a transparent, non-custodial vault where all financial actions are publicly verifiable and gated by the collective will of your DAO, forming the secure bedrock for all subsequent operations.

The off-chain stack is the primary interface for your DAO's members. It handles the social coordination layer where proposals are drafted, debated, and subjected to a preliminary vote. This process, often called a snapshot vote, occurs off-chain using signed messages, which are gas-free and allow for rapid iteration. The most common tool for this is Snapshot, a platform that lets any DAO create a space, configure voting strategies (e.g., token-weighted, quadratic), and host proposal discussions. Setting up a Snapshot space is a foundational step for any hybrid governance model.

To integrate Snapshot, you first need to define your voting strategy. This determines how voting power is calculated. A simple erc20-balance-of strategy uses token holdings at a specific block number. For more complex governance, you can use strategies like erc20-with-balance (minimum token requirement) or even a custom strategy that pulls data from a staking contract. The strategy is defined in your Snapshot space settings and is critical for ensuring the off-chain vote accurately reflects your intended governance model before the on-chain execution step.

Beyond the voting mechanism, you need a dedicated forum for discussion. Platforms like Discourse or Commonwealth are built for this. Here, a Temperature Check can gauge initial sentiment before a formal Snapshot proposal is created. A typical workflow is: 1) Forum post for discussion, 2) Snapshot vote for off-chain signaling, 3) On-chain execution via a multisig or governor contract. This layered approach filters out poorly formed proposals and builds consensus, saving gas and reducing governance fatigue.

For developers, interacting with Snapshot programmatically is key for building custom interfaces. You can use the Snapshot.js library or directly call its GraphQL API. For example, to fetch proposals for your space, you would query the Hub. This allows you to embed governance features directly into your dApp's frontend, creating a seamless experience from discussion to execution.

A cross-chain execution bridge allows a DAO's governance decisions to have effect beyond a single blockchain. This is critical for DAOs that hold assets like ETH on Ethereum, USDC on Arbitrum, or NFTs on Polygon. Without a bridge, a governance vote to, for example, deploy treasury funds to a lending protocol on Optimism would require manual, trust-dependent execution by a multisig. A bridge automates this, turning an on-chain vote into a cross-chain transaction. Popular arbitrary message bridge protocols for this purpose include Axelar's General Message Passing (GMP), LayerZero, Wormhole, and Hyperlane.

The core architectural pattern involves your DAO's Governor contract on the home chain (e.g., Ethereum) calling a bridge adapter contract. This adapter formats the governance decision—such as a contract call, token transfer, or data payload—into a message understood by the bridge protocol. The bridge then relays and verifies this message on the destination chain, where a corresponding executor contract decodes it and performs the authorized action. This creates a secure, programmable pipeline: DAO Vote -> Bridge Adapter -> Cross-Chain Message -> Executor -> On-Chain Action.

Security is the paramount concern. When evaluating a bridge, prioritize verification mechanisms. Some bridges like Axelar and Wormhole use a proof-of-stake validator set, while LayerZero employs an oracle/relayer model with configurable security stacks. You must audit the trust assumptions. Furthermore, implement rate-limiting and spending caps on the executor contract to mitigate the impact of a potential bridge compromise. Always use the bridge's native gas payment abstractions (like Axelar's Gas Services) to ensure the executor has funds to pay for gas on the destination chain, or the transaction will fail.

Here is a simplified code example using Axelar GMP. First, the Governor on Ethereum calls an adapter:

solidityCopy
// On Ethereum (Source Chain)
function executeProposal(address targetOnPolygon, uint256 amount) external onlyGovernor {
    bytes memory payload = abi.encode(targetOnPolygon, amount);
    // Payload is sent via Axelar to Polygon chain
    axelarGateway.callContract("polygon", executorContractAddress, payload);
}

The payload is relayed. On Polygon, a pre-authorized Executor contract receives it:

solidityCopy
// On Polygon (Destination Chain)
function _execute(
    string calldata sourceChain,
    string calldata sourceAddress,
    bytes calldata payload
) internal override {
    (address target, uint256 amount) = abi.decode(payload, (address, uint256));
    IERC20(usdcOnPolygon).transfer(target, amount); // Executes the vote
}

For production deployment, consider fallback mechanisms. What happens if the bridge halts or a vulnerability is discovered? Your DAO should retain the ability to execute critical functions via a traditional multisig on the destination chain. This hybrid approach ensures liveness. Furthermore, use monitoring tools like the bridge's block explorer and set up alerts for failed transactions. The integration transforms your DAO from a single-chain governance body into a cross-chain coordinating entity, capable of managing a decentralized treasury and protocol deployments across the entire ecosystem in a trust-minimized way.

The frontend orchestrator is a React or Next.js application that serves as the primary interface for DAO members. Its core responsibility is to manage the state and workflow between the on-chain voting contract (e.g., on Ethereum or an L2) and the off-chain backend (e.g., a Snapshot server or custom API). Key libraries include wagmi or ethers.js for blockchain interactions, Apollo Client for querying off-chain proposal data from a GraphQL endpoint, and a state management solution like Zustand or React Context to synchronize user sessions, voting power, and proposal statuses.

Architecturally, the app follows a unidirectional data flow. User actions, like connecting a wallet via WalletConnect or MetaMask, trigger a fetch of their voting power from the on-chain ERC20Votes or ERC721 contract. When a user creates a proposal, the frontend first submits the metadata (title, description, choices) to the IPFS via Pinata or web3.storage, receiving a content identifier (CID). This CID, along with the proposal parameters, is then sent to the off-chain backend API, which creates the proposal record in its database and on Snapshot if applicable.

For the voting interface, the orchestrator polls both data sources. It displays rich proposal details fetched from the off-chain API/GraphQL layer, while simultaneously checking the on-chain contract for the user's vote delegation status and remaining voting power. When a vote is cast, the frontend constructs the appropriate message (an EIP-712 typed data signature for off-chain or a transaction for on-chain), handles the signing process, and submits it. A crucial pattern is to implement optimistic UI updates—immediately showing the user's vote locally before confirming the transaction or signature to improve perceived performance.

State management must handle several asynchronous processes: wallet connection state, loading on-chain token balances, caching proposal lists, and tracking pending transactions. Implement custom hooks like useProposal(proposalId) that combine data from useContractRead (on-chain status) and useQuery (off-chain details). Error boundaries and clear loading states are essential, especially when RPC nodes or the off-chain API are slow. The UI should clearly distinguish between off-chain signaling votes and binding on-chain execution votes.

Finally, the orchestrator needs to facilitate the execution phase. For proposals that pass, it should provide an interface for designated executors (like a multisig or a TimelockController contract) to review the calldata and submit the execution transaction. This often involves fetching the approved proposal's actions from the off-chain backend and populating a transaction builder. The complete application should be deployed on decentralized hosting like IPFS via Fleek or Spheron to align with the DAO's decentralized ethos.