Crypto wallet + P2P escrow

Cambridge TCG is building a non-custodial wallet-link seam and an escrow integration contract. Crypto checkout is not live. No real-value token, deployed Cambridge escrow contract, or production release/refund path exists in this version.

Current substrate. The only named environment is eip155:84532 (Base Sepolia) with Circle test USDC at 0x036CbD53842c5426634e7929541eC2318f3dCF7e. Circle states that this testnet token has no financial value. Checkout and value transfer remain disabled.

What linking a wallet proves

A fresh EIP-4361 signature can prove that the signed-in Cambridge account controlled the stated wallet when it answered the one-use challenge. It does not prove legal identity, source of funds, beneficial ownership of every wallet asset, KYC or sanctions status, or future ability to pay. Cambridge never asks for a seed phrase or private key.

Each challenge lasts five minutes, is bound to the exact Cambridge database session and canonical site origin, and can be consumed once. Issuance is serialized and capped at 20 challenges per account in a rolling hour; reaching the cap creates no new challenge and returns a retry-later error.

Before any message proof, local signature work or RPC call, PostgreSQL atomically reserves an attempt using its post-lock clock. Failed proofs still consume one of five attempts per challenge and 40 per account in a rolling hour. A deployment-edge limiter is still required before any production rollout so abusive traffic is rejected before application or database work.

EOA signatures are checked locally. After local failure, an explicitly configured HTTPS RPC (HTTP only on localhost) must report Base Sepolia chain ID 84532. Cambridge sends only the public address to classify deployed code; the exact message and signature go to that RPC only for deployed code or a locally recognized ERC-6492 proof. A remote endpoint is unusable unless its public provider name and HTTPS privacy link are configured and shown beside the linking action; the endpoint itself and any credential remain server-only.

Revocation in this testnet version marks the current registry link revoked and retains that history. It does not cancel a challenge that was already issued or whose signature is being verified; that proof can create a fresh link until the signed five-minute expiry. Production payment use therefore requires a shared per-address generation or epoch so a completed revoke also makes every older proof stale.

Turning off new wallet-link issuance does not disable revocation. A signed-in participant can still revoke their own existing link while the canonical origin and registry remain available.

Why a transaction hash is not payment

A browser can report a hash for a transaction that later reverts, lands on the wrong chain, transfers the wrong token or amount, pays the wrong contract, is replaced, or is removed by a reorganisation. The settlement contract therefore keeps these states separate:

1. prepared
2. authorization_pending
3. submitted
4. submission_unknown
5. observed_unfinalized
6. reconciling
7. funded_final
8. funding_review
9. shipped
10. shipping_review
11. inspection
12. inspection_review
13. releasable
14. release_review
15. released

Only exact, independently observed, successful and finalized evidence may advance reconciling to funded_final. Release is later still: the physical card must pass the agreed shipping and inspection window with no blocking dispute, return, reversal or fraud hold.

A submitted transaction can time out locally and still land later, so submitted cannot become terminal failed just because an observer has not found it yet. Ambiguous broadcast or temporarily missing evidence moves to the recoverable submission_unknown state. Observation continues from there; only independent evidence can move it forward. Pre-funding uncertainty cannot enter a fulfilment review state.

Holds after funding are phase-specific: funding_review,shipping_review, inspection_review, andrelease_review. This preserves what has actually happened: every possible path to released must pass funded_final → shipped → inspection → releasable first.

The exact reconciliation

The fixed quote and observed event must agree on every field:

• chain ID and exact token contract;
• escrow contract and integer atomic amount;
• non-empty bounded opaque trade reference, payer and beneficiary;
• positive settlement generation and exact 32-byte terms digest;
• fixed expiry and observed block-inclusion time no later than it;
• successful receipt, explicit finality and a non-removed log;
• unique event identity: chain + transaction hash + log index.

Wrong-chain or late deposits go to reconciliation; they do not silently unlock shipping. Overpayment does not authorize a larger trade. Underpayment is not partial success.

Who is allowed to say what

The adapter is deliberately split into prepare → authorize → submit → observe → reconcile → adjust → dispute.A wallet may authorize; an RPC or provider may observe; the reconciliation command may compare evidence; the physical-goods workflow may declare a release eligible. No single browser callback owns all four claims.

What must happen before production

• Port a one-rail, commit-before-provider payment reservation and repair the existing Stripe refund/cancellation/payout races first.
• Obtain UK legal/compliance advice for the exact custody, P2P, stablecoin, financial promotion, Travel Rule, sanctions and payment-services flow.
• Confirm provider and seller eligibility; independently audit any settlement contract, roles, emergency powers, refund paths and upgrade policy.
• Test replay, concurrent payment, expiry, late deposit, replacement, reorg, duplicate event, refund, dispute and double-release paths before any capped pilot.

The full engineering record is public in docs/decisions/2026-08-23-crypto-wallet-and-escrow-boundary.md. Related platform rules: escrow routing, trade completion, and payout hold.

Change history

• v1 — 2026-08-23. Base Sepolia wallet proof and provider-neutral no-value escrow boundary; checkout withheld.