Sandbox

The hosted sandbox reserves an isolated application ownership boundary on Sepolia for:

• an application deployment namespace
• test-wallet role assignments
• quota-controlled test-token faucet access
• reset controls scoped to the owning application

Reset requests are asynchronous and fail closed in private preview. The API records the owning application, moves the sandbox to resetting, and emits a transactional request event. The private-preview worker revalidates the committed PostgreSQL event and application ownership before completing the application-scoped metadata fixture reset and emitting sandbox.reset.completed.

Sandbox admission and faucet claims are separate, wallet-session-bound requests:

• POST /v1/sandbox/admissions admits the current wallet as the owner of one Asset Manager entity in the isolated sandbox authority realm.
• POST /v1/sandbox/faucet-claims is available only to that finalized admission wallet and only for the configured sandbox test token within its application quota.

Torq does not give the customer an admission voucher or any other reusable authorization proof. Instead, a dedicated AWS KMS secp256k1 relayer can call only two bytecode-attested sandbox contracts: the admission controller and test-token faucet. It has no generic transaction endpoint, no customer signer material, no production key access, and no authority over the active V2 Sepolia release.

The API reports this lifecycle only from canonical PostgreSQL state:

requested → submitted → mined → indexed → persisted_visible → final_success

submitted is not success. The sandbox onchain projector decodes the expected contract event from the Sepolia receipt, persists it, and then emits the final canonical lifecycle events. Application owners use their own wallets to assign test-wallet roles within their own admitted entity through the ordinary scoped-authority path.

These onchain sandbox paths are available only to approved Developer Preview applications. The isolated Sepolia contracts, bytecode attestations, relayer funding, and end-to-end sandbox proof are governed separately from the active V2 release. They never fall back to that release.

Sandbox access is not public self-service. Production credentials and approved-role scopes require Torq approval.

Hosted preview sandbox lifecycle

1. An approved preview invitation creates one test organization and its first application.
2. The bootstrap response returns test credentials once. Store the secret server-side and bind the publishable key to the approved origin.
3. GET /v1/sandbox reports the application-owned Sepolia sandbox state. Continue only when its status is ready.
4. Create a wallet session, then request a sandbox admission for the current wallet. Wait for the canonical admission lifecycle to reach final_success before attempting a faucet claim.
5. Use the ordinary scoped-authority workflow for any role assignment or financial action. Every action still requires its own role and freshness preflight.
6. Request POST /v1/sandbox/reset from your server when you need a fresh application-scoped sandbox-data reset; observe sandbox.reset.completed before continuing.

The application, organization, Sepolia chain, sandbox realm, quotas, and outbox events are all part of the persisted application boundary. A reset never resets the shared active-V2 release, another application's records, or a customer's wallet.

Deterministic data boundary

The current hosted worker persists the standard fixture-set selector and deterministic sandbox control state. It does not yet expose an API contract for named seeded markets, vaults, positions, or balances. Do not hard-code fixture IDs, infer a pre-seeded market, or represent the fixture selector as a capital-ready market dataset.

Use canonical collection reads after ready and after every reset. A richer published fixture catalog will be documented only when those concrete canonical records and their reset behavior are part of the API contract.