How to Architect a Privacy-Preserving Betting Protocol

A privacy-preserving prediction market allows users to bet on future events without revealing their position, stake, or trading history on-chain. Traditional markets like Augur or Polymarket operate transparently, exposing user activity to front-running and social bias. To achieve privacy, the protocol must cryptographically hide three key data points: the event outcome a user is betting on, the amount staked, and the user's identity. This requires a shift from account-based models to note-based or commitment-based systems, similar to those used in private payment protocols like Zcash or Aztec.

The core architectural component is a commitment scheme, such as a Pedersen Commitment. When a user creates a bet, they generate a cryptographic commitment that binds their choice and amount to a secret random value, called a nullifier. This commitment is published to the blockchain, appearing as random data. To later settle the bet and claim winnings, the user must provide a zero-knowledge proof (ZKP). This proof, generated using circuits in frameworks like Circom or Halo2, verifies that: 1) the user knows the secret nullifier for a valid, winning commitment, 2) the bet was placed before the event resolution, and 3) the same commitment is not being spent twice, without revealing any underlying details.

A critical challenge is preventing double-spending of the same bet commitment. This is solved using the nullifier. Each commitment is linked to a unique nullifier, which is revealed only when the bet is settled. The protocol maintains a public list of spent nullifiers on-chain. The ZKP must demonstrate that the nullifier for the current settlement is not in this list, ensuring each winning bet is paid out exactly once. The Tornado Cash pool contract is a canonical example of this nullifier-set pattern for private transactions.

For the market to function, an oracle must resolve the real-world event. However, feeding a public result into a private system can leak information. Solutions include using zero-knowledge oracles like API3's Airnode with ZK proofs or threshold signature schemes (TSS) where a decentralized committee signs the outcome. The signed result is then used as a public input to the ZK circuit, allowing only users with commitments for the correct outcome to generate a valid proof for settlement, while keeping all losing bets permanently hidden.

From an implementation perspective, you would write a circuit defining the betting logic. For example, a Circom circuit would have private inputs (nullifier secret, bet choice, amount) and public inputs (commitment, result, nullifier set root). It would output the commitment and a nullifier hash. A Solidity verifier contract, auto-generated from this circuit, would check the ZKP and the oracle's signed result before transferring funds from a liquidity pool to the user. The entire architecture ensures data availability (commitments are on-chain) with data confidentiality (their meaning is hidden).

Key considerations for developers include managing the liquidity pool that backs the bets, designing a front-end that can generate ZK proofs client-side using SnarkJS or similar, and ensuring gas costs for proof verification are sustainable. Privacy inherently requires more complex state management than transparent systems, but frameworks like Noir or zkSync's ZK Stack are making this increasingly accessible. The end result is a trust-minimized platform where users can speculate without fear of their strategy being copied or their beliefs being exposed.

Before writing any code, you must define the core architectural components. A robust privacy-preserving betting protocol typically consists of three layers: a settlement layer (like Ethereum or Arbitrum) for finality and value transfer, a privacy layer (such as Aztec or Zcash) for confidential transactions, and an oracle network (like Chainlink or API3) for providing verifiable, real-world event outcomes. The interaction between these layers determines the protocol's security, scalability, and user experience. Your first design decision is choosing between a monolithic application-specific chain or a modular approach using existing L1/L2 infrastructure.

The core cryptographic primitive for privacy is zero-knowledge proofs (ZKPs). Specifically, you will use zk-SNARKs or zk-STARKs to allow users to prove they have placed a valid bet—meeting criteria like sufficient balance and correct odds—without revealing the bet amount, selected outcome, or their identity on-chain. This requires designing a custom circuit. For example, a circuit could take private inputs (user's secret, bet details) and public inputs (event ID, total pool size) to output a commitment hash, which is posted to the blockchain. Libraries like circom or halo2 are essential tools for this development.

Managing funds securely is critical. You must architect a non-custodial pooled liquidity model using smart contracts. When users place private bets, they lock funds in a shielded pool. The contract logic must ensure that: 1) payouts are mathematically correct based on the oracle-attested outcome, 2) only users with valid ZK proofs can claim winnings, and 3) the house fee (if any) is transparently deducted. Avoid storing sensitive user data on-chain; instead, store only commitments and nullifiers to prevent double-spending. Use established patterns like the UTXO model or Merkle trees for managing anonymous state.

Integrating a decentralized oracle is a major security consideration. The oracle's role is to attest to the outcome of a real-world event (e.g., a sports match result) and make it available to your settlement contract. You must design a cryptographic attestation flow where the oracle's signed data is the sole trigger for unlocking the prize pool. To prevent manipulation, use a consensus of multiple oracle nodes or a commit-reveal scheme. Your smart contract should include a dispute period where users can challenge an incorrect result using their ZK proof as evidence of having a stake in the correct outcome.

Finally, consider the user experience and regulatory landscape. Users need a client-side prover to generate ZK proofs locally, which requires computational resources. You may need to provide a web-based prover or leverage hardware acceleration. Furthermore, while transactions are private, architect for selective disclosure—allowing users to generate proof of their betting history for tax or audit purposes without revealing all activity. Always consult legal experts, as privacy features intersect with financial regulations like AML/KYC in many jurisdictions. Start with a testnet implementation using tools like Hardhat or Foundry to simulate the entire flow.

A privacy-preserving betting protocol's architecture separates the public state of the system from the private state of user bets. The public, on-chain layer manages the betting pool's liquidity, resolves outcomes via a trusted oracle, and enforces payouts. This is typically implemented as a set of smart contracts on a blockchain like Ethereum, Arbitrum, or Polygon. The private, off-chain layer is where users generate and manage their bets. Here, cryptographic primitives like zero-knowledge proofs (ZKPs) are used to create commitments that prove a bet is valid—e.g., within odds limits and properly funded—without revealing the specific selection or amount to the network until settlement.

The core technical challenge is enabling the public contract to verify private actions. This is achieved through a commit-reveal scheme augmented with ZKPs. A user first submits a cryptographic hash (a commitment) of their bet data to the contract, locking their funds. Later, after the event outcome is known, they submit a ZK-SNARK proof. This proof convinces the verifier contract of two things: 1) the revealed bet matches the original commitment, and 2) the bet is a winner according to the settled odds. The contract can then execute the payout without ever learning the loser's bet details, preserving privacy and reducing on-chain data bloat.

For the resolution layer, integrating a decentralized oracle like Chainlink is critical. The architecture must designate a specific, immutable data feed (e.g., sports_data_eth_usd) as the single source of truth for event outcomes. The settlement smart contract should be permissionless, allowing anyone to trigger the payout phase once the oracle reports a result. This design prevents censorship and ensures protocol neutrality. It's essential to implement a robust dispute period or challenge mechanism, often using optimistic rollup concepts, where claims can be contested if a user provides a fraud proof.

Key off-chain components include a client-side SDK and a relayer network. The SDK, built with libraries like snarkjs and circom, handles ZKP generation and wallet interactions. Since generating ZKPs can be computationally intensive, the architecture should allow users to offload this to their own device or a trusted service. A permissionless relayer network can then broadcast the resulting transactions to the blockchain, abstracting gas fees and improving UX. This separation ensures the core protocol remains trust-minimized while maintaining accessibility.

Finally, the architecture must account for economic security and liquidity. A common model is a peer-to-pool system, where liquidity providers deposit funds into a shared contract to back potential winnings. The contract's logic uses a constant product formula (like Uniswap v2) or a parimutuel system to dynamically calculate odds and payout ratios. This design eliminates counterparty risk and creates a liquid market for any bet. Monitoring and upgradeability are also crucial; consider using a proxy pattern for contracts and a decentralized multisig for governance to manage parameter updates without introducing centralization risks.

A commitment scheme is a two-phase cryptographic primitive: Commit and Reveal. In the Commit phase, a user generates a secret value (e.g., a bet on 'Heads' or a specific number), mixes it with a random nonce (a salt), and produces a commitment hash. This hash is published to the blockchain. Crucially, the hash reveals nothing about the underlying secret due to the cryptographic properties of the hashing function. The random nonce is essential to prevent brute-force attacks where an attacker could guess common inputs.

The Reveal phase occurs later, after all bets are placed or a game round concludes. To reveal, the user broadcasts the original secret and the nonce. Anyone can verify the commitment by hashing the revealed pair and checking it matches the originally published hash. This binding property ensures the user cannot change their secret after committing, while the hiding property keeps it secret until reveal. In a betting context, this prevents front-running and ensures bets are locked in before an outcome is known.

For on-chain implementation, we use a hash function like keccak256. A typical Solidity struct for a commitment might be:

solidityCopy
struct Commitment {
    bytes32 hashedChoice;
    uint256 nonce;
    address better;
    bool revealed;
}

The commitment function would be keccak256(abi.encodePacked(secretChoice, nonce, better)). The inclusion of the better's address prevents replay attacks across different users or rounds.

A critical design decision is the commit-reveal timing. The protocol must define a clear sequence: a commit phase where commitments are accepted, followed by a reveal phase where secrets are disclosed. Bets are only valid if both a valid commit and a subsequent timely reveal are submitted. This scheme forms the trustless backbone for private actions in decentralized applications, extending beyond betting to voting and sealed-bid auctions.

The enclave's primary function is to act as a verifiable black box. It receives encrypted user inputs—such as bets and random seeds—performs the core game logic and random number generation (RNG) in complete isolation, and outputs only the encrypted results and cryptographic proofs. This design ensures that the game's critical state (e.g., the secret random seed determining an outcome) is never exposed on-chain or to the operator, preventing front-running and manipulation. The enclave's code, or attestation, is publicly verifiable, allowing anyone to confirm it's running the intended, unmodified software.

Architecturally, the enclave interfaces with two systems. First, it connects to the blockchain via an on-chain verifier contract. This contract validates the enclave's attestation and the cryptographic proofs (like Intel SGX's RA-TLS attestation or a zk-SNARK) accompanying its results. Second, it communicates with users and the operator through a secure, off-chain key management service. This service facilitates the exchange of encrypted messages and manages the session keys used for end-to-end encryption between users and the enclave, ensuring inputs remain confidential.

A critical design choice is the source of entropy for the RNG. A naive approach using only an enclave-generated seed is vulnerable to pre-computation attacks if the seed is predictable. The recommended method combines multiple entropy sources in a commit-reveal scheme: the enclave's internal RNG, a user-supplied seed (committed before the game starts), and a future blockchain value (like a block hash). The enclave hashes these together to produce the final, unpredictable random number. This process must be reproducibly verifiable; the proof must allow the verifier contract to recalculate the same result given the revealed inputs.

For development, frameworks like the Open Enclave SDK or Intel SGX SDK are used. The core game logic is written in a memory-safe language like Rust and compiled for the TEE platform. The code must be deterministic to ensure verifiable reproducibility. All external calls (e.g., for the block hash) must be made via OCALLs (outside calls) and their results fed back into the enclave. The final step is generating a Measurement or MRENCLAVE value—a cryptographic hash of the compiled enclave—which is hardcoded into the verifier contract as the authorized code identity.

The main trade-off with a TEE-based design, compared to a fully on-chain, verifiable system like a zk-rollup, is the trust assumption in the hardware manufacturer and the absence of public verifiability for the computation itself. While the proof confirms the code ran correctly on genuine hardware, it does not allow independent re-execution of the logic. However, for complex game logic where generating a zero-knowledge proof is computationally prohibitive, a TEE offers a practical alternative with strong confidentiality and acceptable trust boundaries for many applications.

In a privacy-preserving betting protocol, the resolution and payout phase is the most critical trust point. Unlike public protocols where an oracle's result is transparent, here the outcome must be cryptographically proven to be correct without revealing the underlying event data. The architecture typically relies on a decentralized network of oracle operators or a threshold signature scheme (TSS) to produce a signed attestation of the result. This attestation, not the raw data, is submitted on-chain. For example, a TSS group of 7-of-11 operators would collaboratively sign a message like "Event_ID_XYZ: Winner=Team_A", and only the resulting signature is published.

The smart contract must be designed to verify this attestation and map it to the correct conditional logic for payouts. This involves storing commitment hashes of all possible market outcomes during market creation. Upon resolution, the contract checks that the submitted attestation's message hash matches one of the pre-committed outcomes. A zk-SNARK or similar zero-knowledge proof can be used here to enhance privacy further, proving the attestation is valid for some committed outcome without revealing which one, though this adds computational overhead. The contract's resolution function should be permissionless, allowing anyone to submit a valid attestation and trigger the payout state transition.

Once the outcome is verified on-chain, the protocol must execute privacy-preserving payouts. If the system uses stealth addresses or shielded pools (like zk-SNARK-based anonymity sets), the contract cannot directly iterate over public winner addresses. Instead, it typically unlocks funds into a claimable state. Winners must then submit a zero-knowledge proof demonstrating that their private betting credential is linked to a winning outcome, without revealing which specific bet slip it corresponds to. They can then withdraw their funds to a fresh stealth address. This mechanism, similar to Zcash's shielded transactions, ensures the transaction graph between bet placement and payout is broken.

A significant challenge is handling the liquidity for these private payouts. The protocol must ensure the prize pool—often held in a shielded pool or a specific vault—has sufficient funds and that its internal accounting remains consistent. This requires a commitment tree (like a Merkle tree) to track the pool's state. Each deposit or winning claim updates this tree with new commitments. The contract verifies proofs against the root of this tree. Auditing overall solvency without compromising privacy can be achieved using techniques like balance proofs or range proofs to show the total value of commitments equals the vault's actual holdings.

Finally, the protocol must have a clear dispute and fallback mechanism. If the oracle network fails to produce an attestation within a timeout period, the contract should allow a fallback resolution, such as refunding all bets, which requires securely unlocking the entire pool. Additionally, a challenge period after an attestation submission allows other oracle nodes to submit a fraud proof if they detect collusion or incorrect data. Designing these economic and cryptographic safeguards is essential for maintaining the system's integrity when the core event data remains private.