Skip to main content
POST
Move the caller to the generation-2 vault (vault roadmap part 2)

Authorizations

X-Api-Key
string
header
required

Partner / integrator key — format ps_live_<keyId>_<secret>. Partner keys are issued by PredictStreet; a user can also create keys bound to their own wallet from their account settings in the web app. Never ship to a browser. multi_wallet partners must additionally send X-User-Wallet: 0x<40-hex> on every authenticated request to declare the acting wallet. See the API keys guide for scope taxonomy, partner kinds, rate limits, and rotation procedure.

Headers

X-User-Wallet
string

Required for multi_wallet partners on every authenticated request; ignored for single_wallet. Declares the acting end-user wallet for this request — drives KYC checks, balances/positions/orders attribution, rate-limit buckets, and audit. Lower-cased server-side. Missing on a multi_wallet key → 401 api_key_user_wallet_required; malformed → 401 api_key_user_wallet_invalid. The on-chain CTFExchange/Vault contracts still verify EIP-712 signer ↔ vault binding, so loosening API-layer attribution is safe by construction.

Pattern: ^0x[a-fA-F0-9]{40}$
Example:

"0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb3"

Response

The generation-2 vault is the active vault.

walletAddress
string
required

Authenticated wallet (lowercase 0x-hex).

vaultAddress
string | null
required

Per-user vault contract address; null until the vault is deployed.

deployed
boolean
required

true once VaultFactory.vaultOf(wallet) has been on-chain confirmed.

status
enum<string>
required

Vault lifecycle (RND-312): not_created = no vault and no deploy in flight (the first deposit or POST /api/me/vault creates it); deploying = poll; ready = vaultAddress usable; failed = the last deploy job failed; a new one starts on the next POST /api/me/vault (or funding) after a cooldown — the 409 carries retryAfterSec. Authoritative; deployed + deployStatus stay for existing clients.

Available options:
not_created,
deploying,
ready,
failed
generation
enum<integer>
required

Contract generation of the active vault (the one deposits and trading go to). 1 = original factory, 2 = post-audit factory (the beacon proxy). Always equals vaults.find(v => v.active).generation. Defaults to 1 before any vault exists.

Available options:
1,
2
targetGeneration
enum<integer>
required

The generation a new deploy / activation targets (from the rollout). 1 while generation 2 is not rolled out to this wallet; 2 once the wallet is in the rollout. When generation is 1 and targetGeneration is 2, POST /api/me/vault/upgrade migrates the account.

Available options:
1,
2
vaults
object[]
required

Every vault the authenticated wallet holds, ordered by generation ASC (generation 1 first). After POST /api/me/vault/upgrade the user holds TWO vaults: the generation-1 vault stays here with active: false (it trades legacy markets and keeps its positions / USDC until moved or withdrawn), and the generation-2 vault has active: true. Empty array before any vault exists.

enqueued
boolean
required

true when THIS call queued the deploy job; false when it already existed or the vault was ready.

upgradeActivated
boolean
required

true when THIS call activated the generation-2 vault (the active vault moved); false otherwise.

deployStatus
enum<string>

Status of the platform's automatic vault deployment: not_started (no deploy job; also shown for vaults that existed before auto-deploy — check deployed), pending / building / submitted (in progress), confirmed (deployed and vaultAddress set), skipped_existing (vault already existed), failed_permanent (deployment failed; contact support).

Available options:
not_started,
pending,
building,
submitted,
confirmed,
skipped_existing,
failed_permanent
deployTxHash
string | null

Tx hash of the VaultFactory deploy call once submitted; null until then.

deployRequestedAt
string<date-time> | null

When the deploy job was enqueued.

deployConfirmedAt
string<date-time> | null

When the deploy was confirmed on-chain.

retryAfterSec
integer

For failed: seconds until a POST /api/me/vault (or a funding path) starts a new deploy; 0 otherwise.

upgrade
object | null

Vault roadmap part 2: present while the account is eligible for generation 2 and has not finished the migration in upgrade; only POST /api/me/vault/upgrade moves them to generation 2. A user with generation: 2 already has upgrade: null. Lifecycle of the generation-2 vault — the migration the FE prompts and POST /api/me/vault/upgrade runs. vaultAddress / status above keep describing the ACTIVE vault (deposits and trading go there until the upgrade is activated). Null otherwise (target 1, no vault yet, or already generation 2).