Wallet Architecture

Smart (Proxy) Wallet — What & How

What is a “Proxy Wallet” here?

• A non‑custodial smart account (a contract wallet) that belongs to the user but lives on‑chain.
• It uses Account Abstraction (ERC‑4337) so the account can:
• • Bundle multiple actions into one transaction (approve + buy + stake, etc.).
  • Use sponsored gas via a Paymaster (or pay gas in USDC).
  • Use session keys, spending limits, and social recovery.
• It’s called “proxy” because we deploy a lightweight proxy (minimal proxy / EIP‑1167 or upgradeable proxy) that delegates logic to a single implementation contract.
• • This makes deployment cheap (clones) and allows upgrades (with timelock & owner approval)

Ownership model (non‑custodial)

• The smart account is owned by the user’s key:
• • Either EOA (MetaMask/Trust/WalletConnect)
  • Or Magic.link key (MPC, non‑custodial).
• The platform never holds keys. Ownership & recovery modules are on‑chain.

When & how the wallet is created

• On signup, we derive a counterfactual address (via CREATE2) for the user’s smart account—no gas spent yet.
• On the first action (e.g., first trade/deposit), the AccountFactory deploys the proxy at that deterministic address and initializes:
• • Owner(s) (EOA or Magic.link)
  • Modules (session keys, recovery, spending limits)
  • USDC as primary collateral and ERC‑1155 positions as holdings
• We maintain a Registry mapping userId → smartAccountAddress per chain.

Where funds and positions live

• USDC collateral sits inside the user’s proxy wallet or inside the market contract/AMM while a trade is open.
• Market positions are ERC‑1155 tokens minted to the user’s proxy wallet address.
• Selling or winning credits USDC back to the proxy wallet.

Multi‑chain deposits (“Deposities”)

Goal: Let users send supported tokens (e.g., USDC) from several chains and have them available quickly for Polygon trading—without losing control.

Design (hub & spokes):

• Polygon is the hub where markets run and the proxy wallet primarily operates.
• Users may deposit on source chains they already hold assets on (e.g., Ethereum, Arbitrum, Base).
• A DepositRouter (source) contract accepts deposits and uses a Bridge Adapter:
• • USDC: prefer Circle CCTP (burn/mint) for native USDC with minimal liquidity risk.
  • Other tokens: use CCIP / Axelar adapters (configurable).
• On Polygon, a DepositRouter (hub) receives the bridged funds and credits the user’s proxy wallet.

Security & UX:

• Each deposit mints a DepositReceipt (event + id) for traceability.
• Replays are prevented by deposit nonce tracking.
• Timeouts/fallbacks if a bridge is congested.
• Notifications/Webhooks update UI when funds arrive.

Why bundling + paymaster matter

• With ERC‑4337, the user signs a UserOperation that can:
• • Perform multi‑call: approve USDC → buy YES/NO → store receipt.
  • Be sponsored so no MATIC is needed in the user wallet.
  • Optionally pay gas in USDC via a paymaster policy.
• Result: Fast, single‑click trades, fewer signature popups, higher conversion.