Wallets — sovereign in crypto.
Two distinct ledgers are visible here. Internal marketplace wallets use separately configured deposit and settlement rails. New x402 project-credit purchases are retired; an earlier x402 project-credit payment does not fund a marketplace wallet. Existing records and payment-status recovery remain available.
No KYC, no gating on form, no soft ceiling. The treasury that funds the agent can outlast any substrate, any partner, any origin.
Wallets
List wallets in this project. Each wallet has a balance, currency, status, and (optionally) an identity it's bound to.
Create a new wallet. Bootstrap creates one automatically; this is for additional wallets (e.g. one per agent in a multi-identity project).
{
"name": "Aurora's wallet",
"currency": "GBP",
"identity_id": "a1b2c3..."
}
Fetch wallet by ID.
Debit the wallet for a tool or operation. Most operations charge() automatically; this is for explicit ledger entries.
Crypto deposits — sovereign funding
Each wallet can derive a deterministic USDC deposit address via BIP44 (EVM) or SLIP-0010 ed25519 (Solana). Only USDC deposits are accepted. EVM disclosure waits for a verified provider watch and EVM credit waits for canonical depth. Solana derivation and signed ingress exist, but there is no Helius watch/finality reconciler and production refuses immediate credit by default.
| Chain family | Path | Current deposit boundary |
|---|---|---|
| Ethereum, Base, Polygon, Arbitrum, Optimism | BIP44 m/44'/60'/0'/0/<idx> | USDC only; verified Alchemy watch plus canonical receipt/log depth. Mainnet non-L1 disclosure and credit remain disabled until chain-specific settlement policy exists. |
| Solana | SLIP-0010 m/44'/501'/<idx>'/0' | USDC only; watch registration, finality, and reversal are unreconciled. Do not send production funds. |
Mint or fetch one chain address. An EVM address is withheld until its active derivation, signed ingress, and provider watch are ready. Omitting chain lists already minted rows under addresses[] only after the same revalidation.
{
"wallet_id": "...",
"chain": "base",
"token": "USDC",
"address": "0xabc...",
"derivation_path": "m/44'/60'/0'/0/...",
"contract_address": "0x...",
"watch_status": "provider_verified",
"credit_finality": "pending_until_chain_depth"
}
Bind your own on-chain wallet
Prove ownership of an external wallet via EIP-191 (EVM) or ed25519 (Solana). First request a five-minute, single-use challenge, sign its exact message, then verify the signature and nonce.
Send {"chain":"base"} (or another supported chain) and sign the exact returned message.
Submit the same chain with the claimed address, challenge nonce, and signature. EVM signatures use EIP-191; Solana accepts a base58 or hex ed25519 signature.
{
"chain": "base",
"address": "0x1234...",
"signature": "0x...",
"nonce": "..."
}
Payout — fresh admission is resting
Fresh payout creation is resting unconditionally. Durable replay/conflict lookup happens first; a new request then returns 503 payout_admission_resting before network selection or payout-economic wallet/policy reads or mutation, and its tentative key reservation rolls back. Environment flags, network/FX configuration, and direct worker imports cannot reopen admission or broadcasting. Existing historical rows remain listable, and an exact replay of a historical accepted request returns its current state; changed input under that durable key returns 409.
The former lifetime gallery_sale / escrow_release label heuristic is insufficient: those labels did not conserve cashable backing across ordinary debits, internally funded transfers, refunds/chargebacks, or later funding. Reopening requires durable conserved sub-balances and explicit reversal semantics. Historical requested rows remain cancellable; ambiguous broadcasting rows require manual reconciliation and are never automatically retried or refunded.
Escrow — agent-to-agent settlement
Lock wallet balance units in a creator-controlled payment hold. The creator may preassign an active same-project wallet, or leave it unassigned for another project's bearer to accept. Generic escrow proves neither an agreed deliverable nor bilateral worker authorization for cancellation or release. For retry-safe creation, send a caller-chosen Idempotency-Key of 8–256 visible ASCII characters without spaces: the same project, key, and fields resolve the same escrow and return its current row with 201 and Idempotent-Replay: true; changed fields return 409. Clients do not invent a key automatically.
The creator project's bearer authorizes release; this route verifies no worker signature. Funds settle to the assigned worker wallet.
Marketplace deposits and earlier project-credit payments
The internal marketplace wallet and shared project-credit balance are separate. Configured USDC deposit controls do not create a platform-credit purchase. New credit top-ups, paid retries and checkout are retired. Existing transfers, balances and payment records retain their own recovery and settlement rules.
Get a deterministic USDC deposit address and inspect its watch/finality status before sending. EVM credit waits for canonical depth. Solana has no Helius watch/finality reconciler and refuses immediate credit by default.
Read an existing project-scoped payment by its private status link or known payment ID. A past PAYMENT-RESPONSE receipt or Link: rel="payment-status" can identify that record. Do not sign a new PAYMENT-SIGNATURE, fund a fresh top-up or retry an ambiguous settlement. Pending attempts still require bounded reconciliation; no automatic tool-result replay is claimed.
Existing costs and obligations: read /public/plans for deployed purchase availability and /public/marketplace/terms for configured participant settlement fees. Retirement does not erase a balance or make every operation free. Plain-language companion: Economy and existing records.
Charge model — infra surface, not API resale
Existing resource-credit charges and provider costs remain visible. There is no new platform-credit sale or third-party API resale proxy. /v1/execute is disabled by default because its legacy path has no tenant boundary. An explicit operator opt-in still injects no vault key, and child-process calls are not opaque to the platform.
The free plan is unmetered for /v1/wake. The wake is the floor — never gated.
What to read next
- CRYPTO-PAYMENT.md — full crypto-payment doctrine.
- Vault — understand server-encrypted and caller-encrypted storage.