How to Implement Off-Chain Voting with On-Chain Execution for Healthcare DAOs

Healthcare DAOs manage sensitive decisions involving patient data protocols, research funding, and treatment approvals. A purely on-chain voting system for every proposal is often impractical due to high gas costs and slow finality. Conversely, off-chain votes lack the immutable audit trail required for regulatory compliance and fund disbursement. The solution is a hybrid architecture: using a gas-efficient off-chain platform like Snapshot for community signaling, followed by automated, permissioned execution of passed proposals on-chain via a multisig wallet or smart contract. This separates the deliberation phase from the irreversible execution phase.

The core technical pattern involves three components. First, an off-chain voting platform (e.g., Snapshot) hosts proposals using a DAO's token holdings for weighted voting. Second, a relayer or keeper service monitors these off-chain results. Third, an on-chain executor contract holds treasury funds or admin privileges and only executes transactions when validated by a predefined set of trusted signers (a multisig) or upon receiving a verified proof of the off-chain vote. This setup ensures the DAO's intent is captured efficiently off-chain, while the actual movement of funds or updating of parameters is secured by Ethereum's consensus.

For implementation, start by deploying a Gnosis Safe multisig wallet with your DAO's core contributors as signers. Configure a Snapshot space linked to your DAO's token (ERC-20 or ERC-721). When a funding proposal passes on Snapshot, the transaction details (recipient address, amount, calldata) are formatted into a proposal.json file. A designated relayer (which could be an automated script run by a DAO member) submits this data to the Gnosis Safe transaction queue. Signers then verify the proposal hash against the Snapshot result before signing and executing the transaction on-chain, creating a permanent record.

To automate this further and reduce manual intervention, you can deploy a custom executor smart contract. This contract would be funded from the DAO treasury and programmed to execute specific actions when it receives a signed message from a verifier address. The off-chain voting result, including the proposal ID and contract calldata, is signed cryptographically by the verifier's private key. The executor contract uses ecrecover to validate this signature before proceeding. This creates a trust-minimized bridge between the off-chain vote and on-chain action, though it requires careful security auditing of the executor contract's logic.

Key considerations for healthcare DAOs include data privacy for proposal discussions, regulatory compliance for audit trails, and execution finality. Using Snapshot with IPFS ensures proposal metadata is publicly verifiable. The on-chain execution step provides the necessary non-repudiable record for financial transactions. It's critical to clearly document the governance process, specifying which types of proposals (e.g., small grants, protocol parameter changes) follow this hybrid flow and which require fully on-chain voting for maximum security. This model balances agility with the accountability required in healthcare applications.

You must have a solid understanding of blockchain fundamentals, specifically Ethereum and smart contracts. Familiarity with concepts like gas fees, transaction finality, and the EVM is crucial. For development, proficiency in JavaScript/TypeScript and Node.js is required for the off-chain components, while Solidity is essential for writing the on-chain execution contracts. A working knowledge of Git and a development environment like Hardhat or Foundry is also necessary for testing and deployment.

The architecture relies on specific Web3 tools. You will need to interact with a governance framework like OpenZeppelin Governor, which provides the base contracts for proposal lifecycle management. For off-chain voting, you will integrate a snapshot service, such as the official Snapshot.org platform or a self-hosted instance, which uses IPFS and digital signatures. Furthermore, you'll need to understand oracles or relayers—services like Chainlink Keepers or Gelato—that are responsible for submitting the final, verified vote results on-chain.

A healthcare DAO deals with sensitive data and real-world impact, so understanding data privacy and compliance considerations is vital. While vote metadata (e.g., proposal text, voter addresses) may be public, the system design must ensure no protected health information (PHI) is stored on-chain. You should also be familiar with gas optimization techniques, as the on-chain execution step incurs costs; strategies like batching transactions or using gas-efficient data structures can reduce operational expenses for the DAO treasury.

Healthcare DAOs require governance systems that are both deliberative and secure. Off-chain voting with on-chain execution is an optimal architecture for this. The model separates the proposal discussion and voting phase, conducted on a gasless, user-friendly platform like Snapshot, from the final binding execution, which occurs via a smart contract on-chain. This separation allows for complex, multi-signature proposals—common in healthcare settings involving budget allocations, protocol upgrades, or research grants—to be debated without incurring transaction fees, while ensuring the final outcome is immutably recorded and enforced on the blockchain.

The core of this architecture is a governance module smart contract, often built using frameworks like OpenZeppelin Governor. This contract holds the DAO's treasury and execution authority. It does not handle voting directly. Instead, it validates and executes transactions based on the results verified from an off-chain vote. A critical component is the relayer or executor, which is an EOA or smart contract wallet with permissions to call the execute function. This entity checks the validity of a passed proposal—including the vote hash, signatures, and voting power snapshot—before submitting the transaction that triggers the on-chain action, such as transferring funds or upgrading a contract.

Implementing this requires careful setup of the voting validation logic. When a proposal is created on Snapshot, you define a voting strategy that queries a block snapshot of token holdings or delegated voting power from the DAO's ERC-20 or ERC-721 token contract. The strategy calculates each member's voting weight. After the voting period ends, the final state—including the proposal ID, winning choice, and total voting power—is signed cryptographically. The executor fetches this data and its validity proof via the Snapshot Hub GraphQL API before relaying the transaction to the on-chain Governor contract.

Security is paramount, especially for healthcare data and funds. Key considerations include:

• Timelocks: Introduce a delay between a proposal's passing and its execution, allowing time for review and emergency cancellation if malicious intent is discovered.
• Multisig Executor: Instead of a single EOA, use a Gnosis Safe multisig wallet as the executor, requiring a threshold of trusted signers to approve the final transaction.
• Proposal Thresholds: Set minimum requirements for proposal submission (e.g., 1% of total token supply) to prevent spam.
• Vote Verification: The on-chain contract must robustly verify the off-chain vote proof to prevent spoofing, often by checking a signature from a trusted snapshot validator.

A practical code snippet for the execution function in a simplified Governor contract might look like this. It verifies an off-chain proposal hash and executes the calldata if verified:

solidityCopy
function executeProposal(
    bytes32 proposalHash,
    bytes calldata signatures,
    address[] memory targets,
    uint256[] memory values,
    bytes[] memory calldatas
) external onlyExecutor {
    require(
        isValidSignature(proposalHash, signatures),
        "Governor: invalid signature"
    );
    require(
        !executedProposals[proposalHash],
        "Governor: proposal already executed"
    );
    executedProposals[proposalHash] = true;
    for (uint256 i = 0; i < targets.length; ++i) {
        (bool success, ) = targets[i].call{value: values[i]}(calldatas[i]);
        require(success, "Governor: call failed");
    }
}

This architecture balances accessibility with security. Members can participate in governance without paying gas, leading to higher voter turnout for critical healthcare decisions. The immutable on-chain execution layer provides the necessary audit trail and security for managing sensitive operations. By leveraging established tools like Snapshot, OpenZeppelin, and Gnosis Safe, development teams can implement a robust governance system tailored to the compliance and operational needs of a healthcare DAO, ensuring decisions are both community-driven and technically enforceable.

A Snapshot space is a dedicated page where your DAO creates and manages proposals. It is not a smart contract but a front-end interface that records votes using signed messages, making it gas-free for voters. For a healthcare DAO, the space name (e.g., healthcare-dao.eth) becomes the public identity for all governance activities. You create a space by connecting your DAO's administrator wallet (like a multisig) to snapshot.org and navigating to the setup wizard. The initial configuration requires setting basic details: the space name, logo, and a cover image that reflects the DAO's medical or research focus.

The core of the setup is defining the voting strategies and validation criteria. Voting strategies determine how voting power is calculated. A healthcare DAO might use:

• The erc20-balance-of strategy with the DAO's governance token.
• The erc721-balance-of strategy if voting power is tied to NFT-based membership.
• A custom strategy like whitelist for a council of accredited medical advisors. The validation settings control who can create proposals. It is critical to restrict this to verified members, typically by setting a minimum token balance threshold (e.g., 1000 tokens) or using a whitelist of specific Ethereum addresses belonging to core team multisigs or committee wallets.

Finally, you must configure the voting system and proposal settings. Snapshot offers several systems: single-choice voting, approval voting, or ranked-choice voting. For most executable proposals, single-choice voting (For, Against, Abstain) is standard. Key parameters to set include:

• vote duration: Typically 5-7 days for adequate member deliberation.
• quorum: The minimum percentage of total voting power required for a proposal to be valid. A healthcare DAO might set a high quorum (e.g., 20%) for significant fund allocations.
• approval threshold: The percentage of For votes needed to pass (e.g., 51% simple majority or 66% for major changes). These settings are enforced off-chain by Snapshot and will directly inform the conditions checked by your on-chain execution contract in later steps.

An execution bridge is a trusted component that listens for finalized votes from your off-chain voting platform (like Snapshot) and submits the corresponding transaction to the blockchain. This requires a relayer—a server or serverless function that holds a private key with gas funds to pay for transactions. The relayer's core logic is to: - Fetch the proposal result and calldata from the voting platform's API. - Verify the proposal has passed and the execution is authorized. - Construct and sign the target transaction. - Broadcast it to the network (e.g., Ethereum, Polygon).

For security, the relayer should implement strict validation before executing any transaction. This includes checking: *The proposal's unique identifier and state (e.g., closed and passed). *The on-chain timestamp to ensure execution occurs within a valid time window after the vote ends. *That the calldata (target contract address, function selector, and arguments) matches what was originally proposed and has not been tampered with. A common pattern is to store a hash of this calldata on-chain during the proposal creation (Step 1) for the relayer to verify against.

You can build a relayer using various tools. A simple Node.js script using Ethers.js v6 and the Snapshot.js SDK is a common approach. The script would periodically poll the Snapshot GraphQL endpoint for proposal objects where state is closed and scores indicate a passing vote. For production, consider using a serverless function (AWS Lambda, Vercel Edge Function) triggered by a webhook from Snapshot to avoid constant polling. Ensure the function's environment securely stores the relayer wallet's private key using a service like AWS Secrets Manager or Doppler.

Here is a simplified code snippet demonstrating the core execution logic in a Node.js environment:

javascriptCopy
import { ethers } from 'ethers';
import { getProposal } from '@snapshot-labs/snapshot.js';

const provider = new ethers.JsonRpcProvider(RPC_URL);
const wallet = new ethers.Wallet(RELAYER_PRIVATE_KEY, provider);

async function executeProposal(proposalId) {
  // 1. Fetch and validate proposal from Snapshot
  const proposal = await getProposal(proposalId);
  if (proposal.state !== 'closed' || !proposal.scores.some(s => s > proposal.quorum)) {
    throw new Error('Proposal not executable');
  }

  // 2. Reconstruct the transaction
  const tx = {
    to: proposal.execution.to,
    data: proposal.execution.data
  };

  // 3. Send the transaction
  const txResponse = await wallet.sendTransaction(tx);
  console.log(`Transaction hash: ${txResponse.hash}`);
}

For a healthcare DAO managing a medical research grant fund, the execution might call a distributeGrant(address researcher, uint256 amount) function on a Treasury contract. After the relayer submits the transaction, the on-chain event completes the governance cycle, moving funds based on the community's verified vote. It's critical to monitor the relayer for failures and implement retry logic with nonce management. Consider using a service like Gelato Network or OpenZeppelin Defender to automate and secure this relay process with built-in monitoring and access controls.

The core architecture separates the voting mechanism from the execution of results. We use off-chain voting via tools like Snapshot to gather member sentiment without incurring gas fees, which is essential for broad participation. The voting result, a simple hash of the proposal details and the outcome, is then relayed to an on-chain executor contract. This contract validates the off-chain vote's authenticity using a signed message from a trusted address (the DAO's multisig or a designated relayer) before executing the encoded transaction.

The smart contract logic centers on permission and verification. The executor contract, often inheriting from OpenZeppelin's Ownable or governor contracts, maintains a whitelist of valid proposal hashes and authorized signers. When a relayer submits a transaction for execution, the contract checks that the provided signature corresponds to a known signer and matches the proposal data. This prevents replay attacks and ensures only legitimately passed proposals are enacted. The execution typically involves a low-level .call() to a target contract, such as a treasury or a patient data access manager.

Here is a simplified Solidity snippet for the core verification function:

solidityCopy
function executeProposal(
    address target,
    bytes calldata payload,
    bytes32 proposalHash,
    bytes memory signature
) external {
    bytes32 ethSignedHash = keccak256(abi.encodePacked(target, payload)).toEthSignedMessageHash();
    require(ethSignedHash == proposalHash, "Invalid hash");
    require(isValidSignature(proposalHash, signature), "Invalid signature");
    (bool success, ) = target.call(payload);
    require(success, "Execution failed");
    emit ProposalExecuted(proposalHash);
}

The isValidSignature function would recover the signer address from the signature and verify it against the DAO's approved signer set.

For the off-chain component, a typical workflow uses the Snapshot strategy pattern. You define a custom strategy that connects to your healthcare DAO's membership registry (e.g., an ERC-20 token for contributors or an ERC-1155 for credentialed members) to determine voting power. The proposal creation includes the encoded target and payload data that will later be used on-chain. After the voting period ends, an off-chain script (a "relayer") generates the final proposalHash, signs it with the DAO's private key, and submits the transaction to the executor contract.

Key security considerations include signer key management—the signing key should be held in a hardware wallet or multisig—and proposal hash construction. The hash must uniquely encode the target address, calldata, and a nonce to prevent collisions. Furthermore, implement a timelock between vote conclusion and execution eligibility. This provides a safety window for members to audit the on-chain transaction before it affects the protocol, which is non-negotiable for managing sensitive healthcare operations or fund allocations.

This pattern, used by protocols like Uniswap and Compound for sensitive upgrades, provides a robust framework. It balances decentralized input with secure, accountable execution. For a healthcare DAO, this could govern changes to research grant parameters, updates to data access rules in a DataDAO, or allocations from a pharmaceutical development treasury, ensuring every action is transparently voted on and verifiably executed.

Healthcare DAOs manage sensitive decisions, from fund allocation to protocol upgrades, requiring governance that is both transparent and compliant. A hybrid model using off-chain voting for deliberation and on-chain execution for finality is optimal. Off-chain platforms like Snapshot allow for gas-free, flexible voting with detailed proposals, while the on-chain component, typically a Timelock Controller or multisig wallet, enforces a delay and provides a final, immutable record on-chain. This separation enhances security by allowing for human review before any transaction is finalized, a critical safeguard for healthcare applications.

The core architecture involves three components: a voting interface (e.g., a frontend integrating Snapshot), a data layer (Snapshot's IPFS-based storage of votes and proposals), and an execution layer (a smart contract like OpenZeppelin's TimelockController). Votes are cast off-chain using signed messages, which are aggregated to determine the outcome. A successful proposal's execution payload—the encoded call data for the on-chain action—is then queued in the Timelock. This introduces a mandatory waiting period, allowing token holders to audit the pending action before it is automatically executed.

Implementing this starts with the on-chain executor. Deploy a TimelockController contract, designating the DAO's treasury or governor contract as the proposer and a multisig as the executor for added security. The timelock delay should be set based on the proposal's criticality; a 48-72 hour window is standard for major decisions. The off-chain setup requires creating a space on Snapshot.org, configuring the voting strategy (e.g., token-weighted voting using an ERC-20 like $HEALTH), and linking the validators to verify voting power from the correct blockchain.

Here is a simplified example of a proposal's lifecycle in code. First, a proposal's execution calldata is generated off-chain. After Snapshot voting passes, this calldata is submitted to the Timelock:

solidityCopy
// Pseudocode: Queuing a proposal in the Timelock
bytes32 proposalId = timelock.hashOperationBatch(
    targets, // [address of treasury contract]
    values,  // [0]
    payloads, // [calldata to transfer funds]
    predecessor, // bytes32(0)
    salt // unique identifier
);
timelock.scheduleBatch(targets, values, payloads, predecessor, salt, delay);

After the delay, any address can call timelock.executeBatch(...) to perform the action. This pattern ensures no single party can execute transactions unilaterally.

Key security considerations for healthcare DAOs include vote privacy and regulatory compliance. While Snapshot votes are public, using a private voting infrastructure like Vocdoni or clr.fund may be necessary for sensitive decisions. The timelock delay is a defense against malicious proposals, but the proposal creation power must also be secured, often gated by a minimum token threshold or a multisig. Furthermore, all execution transactions should be verified against the original proposal hash to prevent calldata manipulation between the vote and execution phases.

This pattern balances agility with auditability. Healthcare DAOs can iterate quickly on governance proposals off-chain without incurring gas costs for every voter, while maintaining a cryptographically verifiable and deliberate on-chain record for all executed actions. For production systems, integrate monitoring tools like Tenderly to alert on timelock queues and consider using Safe{Wallet} as the executor for multi-signature requirements, creating a robust governance framework suitable for managing real-world healthcare assets and protocols.

The hybrid model combining OpenZeppelin Governor with a Zero-Knowledge (ZK) proof system like Semaphore addresses critical healthcare needs: patient privacy, regulatory compliance, and operational efficiency. By keeping vote casting and tallying off-chain, you protect sensitive participant data and avoid prohibitive on-chain gas costs for large member bases. The on-chain execution via a smart contract treasury ensures transparent, immutable enforcement of the DAO's collective decisions, creating a verifiable audit trail.

To implement this, your next steps should follow a structured development path. First, define your governance parameters: voting delay, voting period, proposal threshold, and quorum. These will be encoded in your Governor contract. Second, integrate your identity and voting system. For a ZK-based approach, use Semaphore to create a group for verified DAO members and generate off-chain proofs for anonymous voting. The voting result (e.g., a Merkle root of the tally) is then submitted as the proposal's calldata. Finally, build the execution flow: a successful proposal automatically triggers the execute function, calling the target contract—like a multisig wallet or a custom healthcare data access manager—to transfer funds or update permissions.

For practical testing, start with a fork of the OpenZeppelin Governor contracts and the Semaphore repository. Use a local Hardhat or Foundry environment to simulate the complete flow: 1) Proposal creation, 2) Off-chain vote proof generation and submission, 3) Queueing, and 4) Execution. Thoroughly audit the permissioning logic, especially the function that validates the off-chain proof result on-chain. Consider using a relayer to pay gas fees for users submitting proofs, ensuring a seamless experience.

The future of DAO tooling is moving toward more sophisticated privacy-preserving primitives. Explore zkSNARK-based voting systems like MACI (Minimal Anti-Collusion Infrastructure) for enhanced coercion-resistance, or state channels for near-instant, micro-governance decisions. As layer-2 scaling solutions mature, the cost of on-chain execution will decrease, but the need for privacy in healthcare contexts will remain paramount. Your implementation should be designed to adapt to these evolving technologies.

Further resources are essential for successful deployment. Review the official documentation for OpenZeppelin Governor, Semaphore, and EIP-4824 for DAO standardization. Engage with the community on forums like the Ethereum Research forum and consider a professional audit from firms specializing in zero-knowledge cryptography and governance systems before a mainnet launch.