Skip to main content

​
0013. The Deposit Wallet’s working balance: 50forliveverification,then50 for live verification, then 100k–$500k

  • Status: Proposed, in two stages.
    • Stage 1: the user must confirm or change the $50 cap before the live run.
    • Stage 2: pending the user; to be raised when all phases are complete.
  • Date: 2026-09-30

​
Context

The Session Key lives on the app host. ADR 0012 found that the wallet contract does not limit it to trading: if it leaks, what protects the funds is Polymarket’s relayer policy, which is not public. Even a key limited to trading can lose the balance by trading against an attacker’s orders (threat T36). Gate item 6 (security finding P3-01, F5a) asks for the user’s cap on what the Deposit Wallet holds. The user trades with a bankroll of 100kto100k to 500k, so a $50 cap cannot be the operating balance. The decision is split into two stages.

​
Decision

​
Stage 1: live verification

  • Cap: $50 in pUSD held in the Deposit Wallet during live verification and afterwards, until stage 2 is accepted.
  • Positions count toward the cap at cost: cash plus the cost of open positions stays at or below $50. The rest of the user’s funds stay outside the Deposit Wallet.
  • The user tops the wallet up by hand from outside the app. The app has no deposit or transfer feature and gets none (CLAUDE.md).
  • The live run does not start until the user has confirmed or changed this amount in writing, in this record, and stage 1 is Accepted. On the day of the run, the live-verification runbook checks the balance before arming (prerequisite P4, pre-flight PF2).
  • The cap holds for as long as the Session Key is authorised. If the wallet goes above it before stage 2 is accepted, the key is revoked.
Stage 1 decision: pending the user.

​
Stage 2: normal operation

  • Working balance: 100kto100k to 500k in pUSD in the Deposit Wallet, the amount set by the user in this record.
  • The Session Key is not trade-only on-chain (ADR 0012). Unless gate item 5 is closed by a Polymarket statement or the owner’s relayer test (ADR 0012 Gate 5 decision, options 1 and 2), a leaked key can move the whole working balance out of the wallet.
  • Stage 2 therefore requires the gate 5 decision first, and only options 1 or 2 qualify. Option 3 (accepted risk) covers the stage 1 run only.
  • Even with gate 5 closed, a leaked key can trade the whole working balance away to an attacker’s orders (threat T36). The app’s risk limits and foreign-activity detection do not stop a key used outside the app; revoking the key does (Session Key setup §6).
Stage 2 decision: pending the user; to be raised when all phases are complete.

​
Consequences

  • Under stage 1, the most a leaked Session Key can lose is about $50 plus any gain on open positions, whichever of ADR 0012’s cases applies.
  • Under stage 2, a leaked key can lose the whole working balance by trading, and by transfer as well if the relayer accepts a session-signed transfer.
  • 50coversthelive−verificationrunbookatminimumsizes(itsprerequisiteP4asksforabout50 covers the live-verification runbook at minimum sizes (its prerequisite P4 asks for about 20 to $50).
  • The app does not enforce either stage; each is an operating rule. For the run, max_position_notional ($8, runbook §1.1) keeps each position well below the stage 1 cap. max_daily_notional counts turnover, not holdings, so it may exceed the cap.
  • The app’s default risk limits are sized for stage 2. The runbook lowers the settings and their RISK_CEILING_* values for the stage 1 run.
  • Moving to stage 2 is a deliberate step: the gate 5 decision in ADR 0012, then the stage 2 entry in this record.