Private Markets

strong opinions,
quietly held

Privacy on prediction markets — without revealing your identity, your size, or your conviction. Place leveraged bets on Polymarket where no single party along the way has enough information to attribute the trade.

Private Markets: What is it?

Today, betting on a prediction market means publishing your conviction. Your wallet shows the position. Your size is visible. Your timing is recorded. If your information is sensitive — professionally, contractually, or politically — that visibility is the cost of participating.

This protocol removes that cost. The user funds an established privacy pool on Ethereum mainnet. They express a leveraged bid through an encrypted intent layer that splits the order randomly across multiple independent providers — including all Polymarket users who simply want their positions kept private. Each provider sees only a fragment, never the whole. The position opens on Polymarket through a non-custodial vault. No single party — including the operator of any individual component — has enough information to attribute the trade.

The user's identity is broken from their funds by Privacy Pools. The bid contents are broken from any single provider by encrypted random-fragment routing. The on-chain footprint is broken from the user by a protocol-controlled vault. Three independent privacy layers, composed.

  1. FundsPrivacy Pools breaks the link between your wallet and the protocol vault. Your deposit is visible; what happens after is cryptographically detached.
  2. IntentClient-side encryption plus random fragment splitting breaks the link between any single party and the bid. The bid is encrypted on your device; the router relays opaque ciphertext; each provider sees only a fragment.
  3. PositionThe on-chain vault, not your address, holds the trade. Polymarket sees one address opening many positions; not yours.

Who this is for

All Polymarket users

Anyone who'd rather their positions and timing weren't a public broadcast. Privacy as the default.

Information traders

Anyone whose conviction would let market prices update if it didn't blow their identity to do so.

Working professionals

Lawyers, journalists, analysts, government employees who want their personal market views kept personal.

Hedge funds & desks

Trading firms whose strategies leak through observable positions. Front-running risk vanishes when positions aren't attributable.

Citizens of restrictive regimes

People in jurisdictions where holding a position on the wrong outcome is itself a risk worth not taking.

How it works

Six steps, end to end. A user signs once; everything else happens automatically across infrastructure designed to forget who they are.

01 👤 Fund Pool User deposits to Privacy Pool on mainnet
02 🔒 Encrypt & Split Browser encrypts bid, splits into random fragments
03 🌐 Route mev-commit p2p relays opaque ciphertext
04 🛡️ Decrypt in TEE Each provider's enclave reads only its fragment
05 🏦 Open Position Vault on Polygon opens trade on Polymarket
06 💰 Settle P&L returns to user-controlled fresh address

→ steps 02–04 are where privacy is built; steps 01, 05, 06 are public on-chain events with no link to the user

The user funds an instance of Privacy Pools on Ethereum mainnet — the same architecture the Ethereum Foundation integrated into its Kohaku wallet, designed to keep illicit funds out by screening every deposit against an Association Set.

To express a bid, the user's interface encrypts the bid locally on their device, randomly splitting the order into fragments addressed to multiple independent providers. Each fragment is encrypted to its provider's public key. The encrypted envelope is handed to a routing service running on the mev-commit network, which forwards opaque ciphertext to each provider. The router cannot read anything; it is a relay, not a custodian of intent.

Each provider's trusted execution environment decrypts only its own fragment, opens that fragment of the leveraged position on Polymarket through a shared non-custodial vault. No single provider sees the whole order. Random per-bid fragmentation means a given provider sees a sequence of unrelated fragments over time and cannot stitch them together — strictly stronger than any "winning provider takes the whole bid" model. Provider fees are paid from vault P&L distribution at settlement to per-bid fresh stealth addresses, so payments never cluster across bids.

When the user wants out — to close a position before resolution, or to claim P&L after — the same loop runs in reverse. The user signs an encrypted close intent, providers' TEEs decrypt and sign attested close instructions, the vault redeems on Polymarket and distributes proceeds to a fresh address the user controls. The user can then pull funds back to L1 like any normal exit.

Who sees what

Privacy is precise. It's worth being clear about what each party knows.

partywhat they see
Public chain observer A user funded a privacy pool. The pool released funds to a vault. The vault opened a Polymarket position. No link between user and position.
Polymarket A protocol vault opened a position. Cannot see the underlying users.
Any single provider (in TEE) A random fragment of one bid. Cannot infer the full size, the full bid, or the user. Memory sealed; no logs retained outside the enclave.
Subpoena to a provider "Our TEE service helped execute a fragment of an aggregate trade." The TEE has erased the linkage; the company never had it.
Intent router operator Opaque ciphertext + user IP addresses + timestamps. Cannot decrypt. Cannot read bids. Knows that some IP submitted a bid at time T, never what was bet on. v1: IP logs discarded after 30 days. v1.5: multiple parallel routers operated by different parties; no single operator has the full picture.
Privacy pool / mainnet Public deposit and withdrawal events. No off-chain data; no operator-held linkage. The deposit step is visible; what happens after is cryptographically detached.
Compliance ASP Whether each deposit's source is clean. Not which user did what afterward.
User Their own deposit, full bid, position, and outcome.
on the deposit being public

The deposit step itself is visible on-chain — every privacy pool has this property by construction. It says "this user funded a privacy pool," not "this user bet on Polymarket." The privacy comes from breaking the link between deposit and what happens afterward — and that link is broken cryptographically.

Building blocks

This protocol composes existing infrastructure rather than reinventing it. Each component is already proven in production.

0xbow · Privacy Pools + ASP Primev · intent transport + provider Amplifi · TEE leverage execution + provider Other provider(s) · TEE provider Polymarket · settlement venue

The privacy pool — Privacy Pools on mainnet — is OSS, audited, and live with USDC support. The encrypted intent transport runs over mev-commit's existing p2p network. The execution providers each operate TEE infrastructure today. The settlement venue — Polymarket — is the deepest prediction-market liquidity on the planet. The vault — a small smart contract on Polygon — is the only piece that's purpose-built. Provider fees are paid from vault P&L distribution at settlement to per-bid stealth addresses, so payments don't cluster across bids.

System components

Each box is an environment. Each arrow shows what crosses between them — and what doesn't.

SYSTEM COMPONENTS · WHAT CROSSES BETWEEN ENVIRONMENTS USER DEVICE · browser wallet · proof generation random fragment splitting per-fragment encryption to provider keys runs locally · sees everything · trusted by user ETHEREUM L1 · mainnet Privacy Pools (0xbow) · USDC ASP screening · existing anonymity set deposit · ZK withdrawal funds layer · public & immutable deposit + ZK proof INTENT ROUTER · mev-commit p2p network receives envelope of pre-encrypted fragments forwards opaque ciphertext to each provider structurally cannot decrypt — like a CDN CANNOT DECRYPT CANNOT READ BIDS encrypted envelope PROVIDER A · TEE amplifi decrypts fragment 1 opens partial position sees: 23% of order cannot infer total PROVIDER B · TEE primev decrypts fragment 2 opens partial position sees: 31% of order cannot infer total PROVIDER C · TEE other provider(s) decrypts fragment 3 opens partial position sees: 46% of order cannot infer total PROTOCOL VAULT · Polygon · non-custodial aggregates fragment positions · holds Polymarket trade of record settles P&L · returns to user-controlled fresh address smart contract · no operator market sees: vault opened a position. that's all.
system components — what crosses between environments

mev-commit as the encrypted intent layer

The honest reason to use mev-commit is not strategic alignment but practical reuse. mev-commit ships, as production infrastructure, exactly the primitives this protocol needs for an encrypted intent layer between bidders and a chosen set of providers. Each row below is something we'd otherwise have to build from scratch.

primitive with mev-commit without
P2P transport between bidder and providers ✓ libp2p with Noise transport encryption build: HTTPS + auth + retry per provider
Multi-recipient encrypted-key broadcast ✓ ECIES-to-each-provider, in production build: client-side multi-recipient ECIES
Bidder node binary that handles dispatch ✓ runs today, accepts opaque payloads build: dispatch service + provider connections
Provider node binary with custom plugin point ✓ standard binary, BidProcessor extension build: TEE adapter per provider from scratch
On-chain provider registry with public keys ✓ existing registry; anyone can register build: custom registry contract + governance
Provider whitelist mechanism ✓ built into bidder node build: client-side whitelist enforcement
Operating network with established providers ✓ existing testnet + mainnet build: bootstrap a network from zero

Each row above is concrete engineering work avoided. The aggregate is several months of infrastructure that we don't write because Primev already shipped it. That's why the protocol uses mev-commit — not because Primev is the org behind this initiative, but because mev-commit is built for exactly this pattern of "encrypted intent from a bidder to a chosen set of providers" and we'd be reinventing it otherwise.

What we don't use from mev-commit: the on-chain settlement layer (no preconfirmation commitments are written), validator-opt-in mechanisms, or the bid-decay auction model. The protocol uses mev-commit's intent transport and provider directory; the trade itself settles on Polygon via the protocol vault.

Status & roadmap

Phase 0 — Quiet launch

Three providers from day one. Privacy pool live on mainnet. Intent layer routing through mev-commit. Single market venue (Polymarket). Limited liquidity, low activity, weaker anonymity in absolute terms — accepted knowingly by early users as the cost of being early.

Phase 1 — Organic growth

Leverage as the bootstrap appeal. The leverage product pulls in users who care about returns; the privacy layer is the bonus that draws those who care about both. Anonymity-set depth in the pool grows with adoption.

Phase 2 — Mature

More providers, more markets, multiple fallback intent routers, native wallet integrations (Kohaku and others). Random splitting across many providers approaches genuine k-anonymity in the strong sense.

Why this beats doing it yourself

Anyone could already use Privacy Pools or Tornado Cash to obscure the funding source of a Polymarket bet. So why build something new? Because the funding source isn't the only leak — the position is, and so is the size.

diy: privacy pool → polymarket

  • Pool breaks the link to your funding wallet ✓
  • Your fresh address still publicly holds the position. When you eventually cash out, that address is the lookup key.
  • Position size = withdrawal size. Pattern-matches to your deposit easily in a small pool.
  • No leverage. Your bet is capped at your capital.
  • Insider investigations focus on the on-chain holder of the position. That's still you.

this protocol

  • Pool breaks the link to your funding wallet ✓
  • The position is held by a non-custodial vault, aggregating bids across many users. Your address never appears anywhere near it.
  • Position size ≠ deposit size. Leverage decouples them. Random fragment splitting decouples them again — no one party sees full size.
  • Up to provider leverage limits. Your bet is capped by conviction, not capital.
  • Insider investigations land on a smart contract whose providers each saw only a fragment of an aggregate trade.

Trust assumptions

Three real questions that any privacy system has to answer honestly.

What's cryptographic

What's trusted

What's still observable, statistically

Private Markets · private leveraged execution for prediction markets