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. Each fragment opens a position on Polymarket through a vault owned by one of the user's stealth addresses — one vault per fragment, each with a single beneficial owner. 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 stealth-address derivation — each vault is owned by a fresh stealth address with no on-chain link to the user's funding wallet. Three independent privacy layers, composed.
- FundsPrivacy Pools breaks the link between your wallet and any vault that holds your position. Your deposit is visible; what happens after is cryptographically detached.
- 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.
- IdentityStealth-address derivation breaks the link between your wallet and any vault that holds your position. Polymarket sees a fresh stealth-address-owned vault per fragment, with no on-chain link to you or to each other.
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.
→ 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 decrypts only its own fragment and relays the user-signed instruction to that fragment's stealth-address-owned vault on Polygon. No single provider sees the whole order. Random per-bid fragmentation, drawn from a fixed set of fragment-size buckets, 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 out at settlement to per-bid fresh stealth addresses, so payments never cluster across bids.
Each fragment lands in a vault owned by one of the user's stealth addresses. A user fragments their own order across multiple of their own stealth addresses, so no single provider sees full size and no vault holds positions on behalf of more than one beneficial owner. The protocol does not pool positions across users. Per-fragment jitter and bucketed sizes prevent stitching fragments back together by timing or size.
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 relay the signed close instructions, each vault redeems on Polymarket under its stealth-address owner's signature, and proceeds settle 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.
| party | what 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 stealth-address-owned vault opened a position. Each vault has a single beneficial owner; the owner is a stealth address with no on-chain link to the user's funding wallet or to other vaults the same user controls. |
| Any single provider | A random fragment of one bid. Cannot infer the full size, the full bid, or the user. The fragment alone — bucket-aligned size, one slice of an N-way split — is structurally insufficient to deanonymize. |
| Subpoena to a provider | "Our service relayed one signed fragment of a user's order." The provider held one slice and never signed anything itself. They never had the linkage between user, full size, or final position. |
| 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. |
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.
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 run mev-commit's standard provider node binary with a custom plugin — no enclave or specialized hardware. The settlement venue — Polymarket — is the deepest prediction-market liquidity on the planet. The vault — a smart contract on Polygon — is the only piece that's purpose-built; each vault is owned by a user-derived stealth address (single beneficial owner per vault) and authenticates instructions via the owner's signature. Provider fees are paid out at settlement to per-bid stealth addresses, so payments don't cluster across bids.
Leverage on positions is sourced permissionlessly by the vault from external borrow venues — Amplifi in v1, with the borrow integration designed to be swappable as additional venues come online. The leverage venue is plugged into the vault, not into the provider critical path: providers execute, the vault borrows.
System components
Each box is an environment. Each arrow shows what crosses between them — and what doesn't.
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: provider integration framework 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; trades themselves settle on Polygon via stealth-address-owned vaults.
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 ✓
- Positions are held in stealth-address-owned vaults, one per fragment, each with a single beneficial owner. The vault is unlinkable to your funding wallet via stealth-address derivation.
- Position size ≠ deposit size. Leverage decouples them. Random fragment splitting decouples them again — no one party sees full size.
- Up to venue leverage limits. Your bet is capped by conviction, not capital.
- Insider investigations land on a stealth address whose only on-chain footprint is one fragment of one user's order. The link back to the user is cryptographically broken at the funding step.
Trust assumptions
Three real questions that any privacy system has to answer honestly.
What's cryptographic
- The link between your deposit and any later withdrawal from the privacy pool. Zero-knowledge proof; not invertible.
- Each fragment is encrypted to its recipient provider's public key (ECIES). The router and the bidder node relay opaque ciphertext and cannot decrypt anything.
- The vault authenticates fragment instructions via on-chain provider signatures. Allowlist is public via mev-commit's ProviderRegistry; an attacker without a registered key cannot direct vault funds.
What's structural
Privacy in this system is not a single trick. It is the composition of several primitives, each of which alone is insufficient and which together make per-user attribution structurally hard.
- Stealth-address-owned vaults. Each vault has exactly one beneficial owner — a stealth address derived per-fragment from the user's key. Positions never pool across users. The protocol does not custody.
- Provider non-custody. Providers relay user-signed fragment instructions; vaults validate signatures from their stealth-address owners; providers never hold signing authority over any vault.
- Random fragment splitting across N stealth addresses, each routed through a different provider. A user fragments their own order; no single provider sees full size.
- Bucketed fragment sizes. Fragments are drawn from a fixed bucket set, so an observer cannot fingerprint individual bids by their characteristic sizes.
- Per-fragment jitter. Random delay before each provider relays its fragment, so fragments of one bid do not arrive in a tight time correlation.
- Stealth payouts. Provider fees and user P&L go to per-bid fresh addresses; payments do not cluster across bids.
What's trusted
- The Association Set Provider — to honestly screen out illicit sources at deposit time. 0xbow runs the production ASP; methodology is public.
- The intent router for liveness, and for abstracting user IPs from providers. The router operator (Primev in v1) can observe user IP addresses and bid timestamps over time — never bid contents, which are encrypted to provider keys before leaving the device. Subpoena to the operator returns "this IP submitted bids at these times," not what was bet on. v1 commitment: IP logs are discarded after 30 days. v1.5 adds multiple parallel routers operated by different parties.
- The router as a jurisdiction filter. v1 routes are IP-screened against restricted-jurisdiction and sanctioned-region lists; the router does not knowingly relay for users in geo-blocked jurisdictions. This is operational, not cryptographic — it does not legitimize a user's own representation choices, but it ensures the relay infrastructure is not knowingly serving prohibited traffic.
- That a provider operator can read the fragments routed to them. They learn one fragment, which is the same information any on-chain observer recovers from the corresponding stealth-owned vault. That fragment alone — bucket-aligned size, one slice of an N-way split — is structurally insufficient to deanonymize a user.
- That a strict majority of providers is not colluding on a given bid. Collusion across all N providers on one bid would let the colluding set reconstruct that bid's fragments. Growing N reduces this risk.
What's still observable, statistically
- Anonymity-set depth in the privacy pool. A small pool gives weaker privacy.
- Per-vault positions are visible on-chain. Each stealth-owned vault's positions are public under its stealth address; what's hidden is the link to the user's funding wallet and to any other vaults the user controls.
- Single-active-user case. If only one user is bidding on a particular market at a particular time, fragment count and timing alone may narrow attribution despite stealth-address unlinkability. Mitigates with adoption.