Backend auto-deploy

​

What triggers it

1. Account creation — single_wallet partners, and multi_wallet partners with requirePerWalletKyc=true. A deploy job is enqueued on the wallet’s first sign-in and again when its KYC is approved, and a catch-up job enqueues one every minute for any account that still has no vault (closed or blocked accounts are skipped). Vault deploy is not gated on KYC — KYC gates deposits and trading. See Partner kinds for the per-flag enforcement matrix.
2. First request auto-onboarding — multi_wallet partners with requirePerWalletKyc=false (KYB-onboarded prime brokerage model). The first authenticated request from the partner key that names a previously-unseen sub-account in X-User-Wallet creates the sub-account and enqueues an auto-deploy job right then — without retail KYC for the sub-account.

​

Sequence

​

Reading deployment status

GET /api/me/vault
X-Api-Key: ps_live_<keyId>_<secret>   # needs `portfolio:read`

{
  "walletAddress":     "0x...",
  "vaultAddress":      "0x...",
  "deployed":          true,
  "deployStatus":      "confirmed",
  "deployTxHash":      "0x...",
  "deployRequestedAt": "2026-04-25T12:34:06.247Z",
  "deployConfirmedAt": "2026-04-25T12:34:15.256Z"
}

​

deployStatus values

​

What stays the same

• The on-chain artefact is identical to a manually-deployed vault — same Vault bytecode, same ABI, same vaultOf(eoa) lookup. The vault address is assigned at deploy time and cannot be computed from your EOA; always read it from vaultOf(eoa) or GET /api/me/vault.
• Vault ownership stays with your associated EOA. The back-office wallet pays gas to deploy but never holds keys to the vault.
• Emergency withdraw, dual-signature withdrawal, splits, merges, and redeems — all unchanged. Auto-deploy only saves the on-chain bootstrap, not custody.
• Order.maker is your vault address; Order.signer is your EOA — the EIP-712 domain and signature flow are identical to manual deploy.

​

What stays your responsibility

• Authorising each deposit. Auto-deploy stops at the vault contract; only the EOA that holds the USDC can move it in — either approve + depositERC20 sent from the EOA (you pay gas), or an EIP-2612 USDC.permit signed by the EOA and submitted to POST /api/deposits/relay (the platform broadcasts it: no gas, no approve). The platform cannot bypass that. See Deposits overview.
• Custody of the EOA private key — never reaches our infrastructure.
• Gas for any vault transaction you broadcast yourself (for example a split / merge / convert you send to the vault directly). Withdrawals are broadcast by the platform, and co-signed split / merge / convert ops can be relayed without gas via POST /api/me/positions/op-submit.

​

Limits initialisation

​

Verifying

// Off-chain: poll until the vault deploys
const r = await fetch(`${BASE}/api/me/vault`, {
  headers: { 'X-Api-Key': process.env.PS_API_KEY! },
});
const v = await r.json();
if (v.deployed) {
  console.log('vault ready:', v.vaultAddress, 'tx:', v.deployTxHash);
}

// Or listen for `vault_created` on the `user_activity` WS channel
// instead of polling. Auto-deploy normally completes within a few
// seconds.

​

What if auto-deploy does not fire

• The wallet has no platform account yet — it has never signed in, or (multi_wallet with requirePerWalletKyc=false) no authenticated request has named it in X-User-Wallet.
• The account is closed or blocked — the catch-up job skips such accounts. Call your integration manager.