> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sesameterminal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 0013. The Deposit Wallet's working balance: $50 for live verification, then $100k–$500k

# 0013. The Deposit Wallet's working balance: $50 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](0012-session-key-scope.md) 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 $100k 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.**

| Field | Entry |
| - | - |
| Cap confirmed or changed to | |
| Date (UTC) | |
| Confirmed by | |

### Stage 2: normal operation

* Working balance: **$100k 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](0012-session-key-scope.md#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](../runbooks/session-key-setup.md#6-revocation)).

Stage 2 decision: **pending the user; to be raised when all phases are complete.**

| Field | Entry |
| - | - |
| Gate 5 option recorded in ADR 0012 (1 or 2) | |
| Working balance | |
| Date (UTC) | |
| Accepted by | |

## 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.
* $50 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.