Yogen: A Privacy-Preserving Prediction Market on Canton Network

00 Abstract

Prediction markets turn collective opinion into probability estimates for real-world events. They've proven more accurate than polls, pundits, and most forecasting models. But existing platforms force users into a brutal tradeoff: either accept a centralized operator who can censor markets and freeze funds, or use a public blockchain where every trade is visible, front-runnable, and expensive.

Yogen takes a different path. Built on Canton Network with Daml smart contracts, Yogen delivers a fully decentralized prediction market with privacy-preserving transactions, sub-second finality, and zero MEV exposure. Users trade binary outcome shares through a Constant Product Market Maker (CPMM), with prices determined algorithmically and settlement handled trustlessly through on-chain escrow.

This paper describes Yogen's architecture, its AMM mechanism, the oracle resolution system, the security model validated through formal audit, and the Canton Network integration that makes it all possible without the tradeoffs that plague Ethereum-based alternatives.

01 Introduction & Motivation

1.1 The Case for Prediction Markets

Prediction markets aggregate dispersed information into a single price signal. When a "Will BTC exceed $100K by March?" contract trades at $0.72, the market collectively assigns a 72% probability to that outcome. Research from the University of Iowa's Electronic Markets and studies by Arrow et al. (2008) consistently show these mechanisms outperform expert forecasts across domains—elections, economic indicators, sporting events, and technology adoption timelines.

1.2 What's Wrong with Current Platforms

Centralized platforms like Kalshi and (the old) Polymarket operate under regulatory constraints that limit market creation, require KYC for every user, and maintain full custody of funds. They work, but they're gatekept.

Decentralized alternatives on Ethereum solve the custody problem but introduce new ones:

• MEV extraction. Miners and validators can see pending trades and front-run them. On prediction markets, this means someone can see your large buy order, purchase shares ahead of you, and sell into your trade at a profit.
• Public order books. Every position is visible on-chain. Sophisticated actors can model your portfolio and trade against you.
• Gas costs. A $10 bet that costs $8 in gas fees doesn't make sense for anyone.
• Slow finality. Ethereum's 12-second block times (longer for true finality) create uncertainty windows where the market state is ambiguous.

1.3 Yogen's Approach

Yogen eliminates these tradeoffs by building on Canton Network—a privacy-first, enterprise-grade distributed ledger where only counterparties see transaction details. There's no public mempool to front-run, no gas auction to win, and finality happens in under a second.

The platform uses virtual currency (Canton Coin, or CC) distributed through a faucet, lowering the barrier to entry to zero. Users get 1000 CC on signup and can start trading immediately. No wallet setup, no token purchase, no friction.

02 Platform Architecture

2.1 System Overview

2.2 Technology Stack

2.3 Data Flow

A typical trade flows through the system:

1. User selects a market and outcome (YES or NO)
2. Client calculates expected shares and price impact via AMM formula
3. Trade request hits the API layer with slippage protection parameters
4. Tokens are locked in on-chain escrow via Daml TokenEscrow contract
5. AMM pool state updates atomically
6. Position is recorded in Supabase with real-time notification to the client
7. On market resolution, the settlement engine processes payouts through TokenEscrow.ReleaseWithPayout

03 Market Mechanism

3.1 Constant Product Market Maker (CPMM)

Yogen uses a Constant Product Market Maker, the same core model that powers Uniswap and other leading DEX protocols. Each binary market maintains two liquidity pools: one for YES shares and one for NO shares.

Where k remains constant (before fees) across all trades. This guarantees that the market always has liquidity—there's never a situation where a user can't buy or sell.

3.2 Pool Initialization

Every new market is seeded with 1000 CC of virtual liquidity, split evenly:

This gives an initial price of 0.50 for both outcomes (50/50 probability), which is the maximum-entropy starting point when no information favors either side.

3.3 Price Calculation

The price of an outcome share reflects the current pool ratio. Following the corrected formula from the security audit (finding L3):

Note that P(YES) + P(NO) = 1 always holds, which is a necessary property for a coherent probability market.

3.4 Buy Formula

When a user buys shares on a given side, the platform applies a 2% fee first, then calculates shares received:

Where sidePool is the pool corresponding to the outcome being purchased, otherPool is the opposing pool, and shares is the number of outcome shares the user receives.

Larger trades move the price more—a 10 CC bet in a 1000 CC pool barely shifts the price, but a 500 CC bet shifts it dramatically. This is natural slippage, and it's a feature: it makes price manipulation expensive.

3.5 Sell Formula

The 2% fee is applied to the proceeds. Selling also experiences slippage—dumping a large position yields progressively worse prices per share.

3.6 Worked Example

Consider a market "Will ETH hit $5000 by March?" with current pools:

yes_pool = 400, no_pool = 600
P(YES) = 600 / 1000 = 0.60
P(NO)  = 400 / 1000 = 0.40

Alice wants to buy 100 CC worth of YES shares:

fee            = 100 × 0.02 = 2 CC
amountAfterFee = 98 CC

shares = 98 × 600 / (400 + 98)
       = 58,800 / 498
       ≈ 118.07 YES shares

Alice now holds 118.07 YES shares at an effective cost of ~0.83 CC each. If the market resolves YES, each share pays out proportionally from the losing pool.

3.7 Fee Structure

The 2% fee serves two purposes:

1. Pool sustainability. Fees accrue to the liquidity pool, gradually increasing k and deepening liquidity over time.
2. Manipulation resistance. Any attempt to manipulate the price requires paying fees on every trade, making sustained manipulation expensive.

04 Canton Network Integration

4.1 Why Not Ethereum?

This isn't an anti-Ethereum stance—it's an engineering decision. For prediction markets specifically, Canton solves problems that Ethereum architecturally can't:

4.2 Canton's Privacy Model

Canton uses a sub-transaction privacy model. When Alice buys YES shares from the AMM:

• Alice sees her trade details
• The AMM contract sees the pool state change
• Nobody else sees anything

There's no public mempool. There's no block explorer showing every trade. Other users see the result (updated prices) but not who traded or how much.

4.3 MEV Elimination

Miner Extractable Value (MEV) is impossible on Canton because there's no public transaction ordering step. On Ethereum, validators choose which transactions to include and in what order—creating opportunities for sandwich attacks, front-running, and back-running.

Canton's consensus processes transactions through a sequencing layer that doesn't expose pending transactions to third parties. You can't front-run what you can't see.

For prediction markets, this matters enormously. Imagine a whale placing a $50,000 bet on a political outcome. On Ethereum, bots would see this pending transaction, buy ahead of it, and extract value. On Canton, the trade executes privately and atomically.

4.4 Daml Smart Contracts

Daml is a purpose-built smart contract language created by Digital Asset. It compiles to a formally verified execution model (Daml-LF) and prevents entire classes of vulnerabilities by construction:

• No reentrancy. Daml's execution model is strictly sequential within a transaction. The reentrancy attacks that drained The DAO ($60M) are structurally impossible.
• No integer overflow. Daml uses arbitrary-precision integers. The overflow bugs that have caused millions in losses on EVM chains don't exist.
• Dual signatory enforcement. Every contract action requires explicit authorization from all signatories. You can't forge someone else's signature.

4.5 Enterprise Ecosystem

Canton Network's participant list includes Goldman Sachs, BNY Mellon, BNP Paribas, Broadridge, and others. This means the network has enterprise-grade infrastructure, SLAs, and regulatory engagement that pure crypto chains don't. For Yogen, this translates to a path toward regulated prediction markets without rebuilding the infrastructure layer.

05 Smart Contract Architecture

5.1 Token Module

The token system uses three core contracts:

TokenAccount holds a user's CC balance. Requires dual signatories (issuer + owner), meaning neither the platform nor the user can unilaterally move funds.

template TokenAccount
  with
    issuer  : Party
    owner   : Party
    balance : Decimal
  where
    signatory issuer, owner

TokenEscrow locks tokens for active bets. When a user places a trade, their CC moves from TokenAccount into TokenEscrow. The tokens can't be spent, withdrawn, or moved until the market resolves.

TokenAccountFactory manages token creation with a supply cap, preventing inflation and ensuring total CC in circulation never exceeds the defined ceiling.

5.2 BetProposal Pattern

Trades follow a propose-accept pattern with built-in protections:

1. User creates a BetProposal specifying the market, side, amount, and maxPrice (slippage tolerance)
2. The system validates that the current price doesn't exceed maxPrice
3. Tokens are locked in escrow as proof of funds
4. The AMM processes the trade atomically
5. If the price moved beyond maxPrice between proposal and execution, the trade is rejected and escrow is released

5.3 PayoutPool

The PayoutPool contract manages post-resolution distribution: collects all escrowed tokens from a resolved market, calculates proportional payouts to winning positions, processes withdrawal requests through TokenEscrow.ReleaseWithPayout, and enforces the conservation invariant.

06 Oracle Resolution System

6.1 Multi-Source Architecture

Yogen doesn't trust any single data source. The oracle resolution engine queries multiple independent sources and requires consensus before resolving a market:

6.2 Confirmation Policy

A single data point isn't enough. The oracle requires multiple consecutive confirmations from the same source before triggering resolution. This guards against API glitches, flash crashes that reverse quickly, and temporary data feed disruptions.

For price-based conditions (e.g., "BTC above $100K"), the oracle checks whether the condition holds across several polling intervals. Only after N consecutive confirmations does it mark the market as resolved.

6.3 Condition Types

The oracle supports a composable set of condition primitives:

• price_above(asset, threshold) — Asset price exceeds threshold
• price_below(asset, threshold) — Asset price falls below threshold
• team_wins(team, game) — Sports team wins specific game
• value_above(indicator, threshold) — Economic indicator exceeds threshold
• fear_extreme_greed — Fear & Greed index enters extreme greed zone (>75)
• Custom conditions via API endpoint

6.4 Rate Limiting & Resilience

Each data source has independent rate limits configured to respect upstream API constraints. The oracle engine staggers requests and implements exponential backoff on failures. Rate limit state is persisted in PostgreSQL so it survives serverless cold starts—a detail that matters when your infrastructure is Vercel functions that can spin down between requests.

6.5 Manual Resolution

Admin-created markets support manual resolution as a fallback. This covers edge cases that automated oracles can't handle—"Will Congress pass bill X?" or "Will company Y launch product Z?" An admin with authenticated session access can trigger resolution with appropriate documentation.

07 Security Model

7.1 Audit Findings & Mitigations

Yogen underwent a security review that identified and addressed several vulnerability classes:

• L3 — AMM Price Formula Correction. The original price formula used sidePool / totalPool, which inverted the price relationship. The corrected formula noPool / totalPool for YES price properly reflects supply-demand dynamics. Caught before mainnet deployment.
• Division-by-Zero Guards. All pool arithmetic includes explicit guards against zero-pool states.
• Supply Cap Enforcement. The TokenAccountFactory enforces a hard cap on total CC in circulation.

7.2 Dual Signatory Pattern

Every token operation requires both the issuer and the owner to sign:

• The platform can't steal user funds (needs user's signature)
• Users can't mint tokens (need platform's signature)
• Both parties must agree on every state transition

This eliminates admin key compromises, rug pulls, and unauthorized transfers—exploits that have collectively cost billions on other chains.

7.3 Escrow Pattern

All bets are fully collateralized through the escrow pattern:

1. User's tokens move from TokenAccount → TokenEscrow before the trade executes
2. Escrowed tokens are immovable until market resolution
3. On resolution, escrow releases to winners via ReleaseWithPayout

There's never a moment where a bet exists without backing funds. The system can't become insolvent.

7.4 Application Security

• Row-Level Security (RLS) on all Supabase tables. Users can only read/write their own data.
• Rate limiting via PostgreSQL. Persists across serverless cold starts.
• Admin authentication with timing-safe string comparison, preventing timing attacks.
• Client-side wallet storage. Private keys never touch the server.

08 Token Economics

8.1 Canton Coin (CC)

CC is Yogen's virtual currency—a unit of account within the prediction market ecosystem.

8.2 Why Virtual Currency?

1. Zero barrier to entry. No credit card, no crypto purchase, no bank transfer. Sign up, get 1000 CC, start trading.
2. Regulatory clarity. Virtual currencies for prediction avoid the securities classification debates that plague token-based markets.
3. Focus on forecasting. When the stakes aren't financial, users trade on their actual beliefs rather than risk tolerance. This can produce better probability estimates.
4. Path to real value. Canton's regulatory-friendly design means Yogen can transition to real-value markets when the regulatory framework permits it.

8.3 Fee Distribution

The 2% trading fee flows into the PayoutPool system and is used for liquidity pool deepening (increasing k), platform operation costs, and future liquidity provider incentives.

09 Wallet Architecture

9.1 Embedded Wallet

The default experience uses an embedded wallet that removes all friction from onboarding:

• Auto-created on signup with a yogen_xxx identifier
• Private key material stored client-side (never sent to server)
• No seed phrases to back up (for the virtual currency context)
• Transactions signed locally in the browser

9.2 Zoro Wallet (Self-Custody)

For users who want full control, Yogen integrates the Zoro SDK:

• Self-custody wallet with Canton-native party ID
• QR code connection flow (scan to link)
• User controls their own signing keys
• Canton party identity maps directly to Daml contract signatories

9.3 Future Integrations

Planned wallet integrations include Dfns (MPC key management), C8 Enterprise Wallet (institutional custody), and 5N Loop (Canton-native). Each follows the same interface: the wallet signs transactions locally, the platform never holds keys.

10 Settlement & Payout

10.1 Resolution Flow

When a market's condition is met (oracle confirms or admin resolves), the market status transitions from active → resolved, the winning outcome is recorded on-chain, and the settlement engine activates.

10.2 Payout Calculation

Winners receive proportional payouts from the total pool minus the 2% protocol fee:

The conservation invariant ensures:

No payout can exceed what's actually in the pool. This is enforced at both the application layer and the smart contract layer.

10.3 Position Lifecycle

10.4 On-Chain Settlement

Fund movement happens through Canton atomically:

1. TokenEscrow contracts for winning positions execute ReleaseWithPayout
2. CC transfers from the escrow pool to winners' TokenAccount contracts
3. Both the issuer and owner sign the release (dual signatory)
4. Losing positions' escrowed tokens are redistributed to the payout pool

The entire settlement is atomic—either all payouts process or none do. No partial settlement state.

11 Roadmap

12 Conclusion

Prediction markets work. The research is clear, the track record is strong, and the demand is obvious. What's been missing is infrastructure that doesn't force users to choose between centralized convenience and decentralized sovereignty—or between privacy and transparency.

Yogen doesn't split that difference. It removes the tradeoff entirely. Canton Network provides the privacy, finality, and safety guarantees that prediction markets need. Daml prevents the smart contract bugs that have cost the broader crypto ecosystem billions. The CPMM mechanism provides continuous liquidity with well-understood mathematical properties. And the multi-source oracle system ensures markets resolve based on verified real-world outcomes, not a single point of failure.

The platform is live. The contracts are audited. The math checks out.

Trade what you know at yogenmarket.com.