Build with what
exists today.

01 / GET STARTED

Run the sandbox

Requires Node.js 24 or later. Use a local checkout; the in-memory fixture resets when its server stops.

npm ci
npm run sandbox

Then open http://127.0.0.1:3000/app. The process binds to loopback. Do not expose it through a tunnel or deploy it. Use only the fixed personas and TEST-USD fixture.

1. As the buyer, create a protected test payment to the seeded merchant.
2. Inspect the provider pool's available and reserved coverage.
3. As the merchant, inspect the credit and optionally transfer test balance to the simulated external account.
4. As the buyer, open a non-delivery claim. Assign triage and two independent test reviewers.
5. Use explicit local clock controls to pass decision and appeal windows; inspect the refund and reconciliation report.

Not production authentication: browser personas are fixed sandbox identities with short-lived local sessions. There are no user accounts or persistent sessions.

02 / PAYMENT LIFECYCLE

Payment and coverage are distinct

A payment is not treated as protected until the required reservation and simulated settlement transitions succeed. The browser does not implement these financial rules.

03 / PROVIDER POOLS

Coverage in the local fixture

The seeded pool is an in-memory test fixture. Total coverage is available plus reserved ledger coverage. Reserving eligible coverage reduces the available amount; this is not a custody account or external deposit.

The app exposes no pool funding, policy-editing or withdrawal operation. Provider onboarding and pool discovery are not implemented. The opt-in vault fixture is separate from the default browser simulation.

04 / DISPUTES & REFUNDS

A test claim is not a chargeback

The local flow models a non-delivery claim, role-scoped triage, two independent reviewer votes, an appeal period and a protocol refund from the reserved pool to the original buyer. A merchant account is not debited by this refund.

“Chargeback” is not a card-network or bank reversal here. Clock controls are explicit simulation actions. Reconciliation is read-only and never repairs state.

05 / LEDGER & RECONCILIATION

Evidence, not an assurance

The local SQLite ledger records sandbox balance movements and idempotent operation evidence. Reconciliation compares available local protocol, ledger and pool projections; it cannot prove custody, external settlement, blockchain finality or solvency.

Status values are PASS, WARNING, FAIL and NOT_VERIFIABLE. A finding is surfaced for an operator; no automatic financial correction is performed.

06 / API REFERENCE

Use the implemented contract

Mutations require a valid session, object/role authorization and an Idempotency-Key. Identical retries return the stored result; a changed payload under the same key is rejected. Sandbox bootstrap and clock routes are harness-only and absent from the ordinary API server.

No generated SDK or public API service is available.

07 / LOCAL EVM

The local protection lifecycle

The opt-in Hardhat/Mock-USDC fixture connects the role-checked API, SQLite and vault through payment, dispute and confirmed pool refund or release. It also tests signed recovery after uncertainty or reorgs. No verified Base Sepolia deployment is recorded.

08 / SECURITY & TRUST

Prototype boundaries are explicit

No independent audit, certification, production monitoring, provider settlement or real-funds controls are claimed. Local tests and dependency checks do not certify the system as safe for real assets. Keep the harness on loopback.

09 / IMPLEMENTATION & ROADMAP

Gates A through G

Gates B and C are accepted locally. Gate C verifies the durable API/outbox-to-vault lifecycle and signed operator recovery. Gate D has started with read-only wallet connection and testnet readiness. Transaction signing, verified deployment and actual Base Sepolia receipts remain pending. Browser payments stay simulated.