Skip to main content
PolyShield
POLYGON MAINNET · BETA
ProductHow It WorksDocsBlogRoadmap
Launch App
Docs menu · Security
Getting started
OverviewThe basicsQuickstartFAQ
Core concepts
The privacy modelZero-knowledge proofsSpending notesThe Merkle tree & nullifiers
Architecture
System overviewVault contractZK circuitsOff-chain services
Security
Threat modelTrust assumptionsBackup & recoveryFees
Reference
Glossary
SECURITY

Threat model

The adversary PolyShield is built against: a network observer with full on-chain visibility trying to link a depositor address to a specific Polymarket bet.

Mitigated

  • Identifying who placed an order — every order comes from the vault's single shared EOA.
  • Linking a nullifier to a depositor — N = Poseidon2(secret, nonce) is not derivable without the secret, and excludes balance and owner.
  • The relay or signing layer learning who bet — they only see proofs and public inputs.
  • Forged deposit balance, double-spend, fee under-payment, forged attestation, inflated credit, redirected withdrawal — all blocked on-chain, regardless of who sends the transaction.
  • A malicious backend index — serves only public data; worst case is incomplete recovery, never theft or de-anonymization.

Not mitigated (by design)

  • That a wallet used PolyShield — the deposit is public.
  • The deposit amount — an ERC-20 transfer amount is on-chain.
  • Calling a spend function from your own wallet — that self-de-anonymizes. The frontend never does this; it's a client discipline.