# Solidity Protection Vault

**Status: LOCAL EVM.** The default browser sandbox still uses simulated settlement. The opt-in Gate C fixture links the role-checked HTTP API, SQLite/outbox and actual Hardhat/Mock-USDC transactions through payment, dispute, final refund/denial and expiry release. It uses local test signers; browser wallet integration belongs to Gate D.

## Local verification

From the repository root:

```powershell
npm run solidity:compile
npm run solidity:test
```

Tests use local mock tokens. A local compile/test result is not a deployment, an external token integration, a security audit or proof of testnet behavior.

## Deployment status and boundaries

No verified Base Sepolia vault address, token address or transaction receipt is recorded. Do not infer deployment from a deploy script, successful compilation or Hardhat test. The browser supports explicit read-only wallet connection and Base Sepolia switching; transaction signing and contract reads remain pending. See [Gate D progress](../BACKSTOP-GATE-D-PROGRESS.md) for the read-only deployment preflight.

The vault has its own role and accounting rules in [`contracts/USDCProtectionVault.sol`](../contracts/USDCProtectionVault.sol). The relay applies financial state only after matching confirmed chain receipts. Lifecycle reconciliation remains read-only. Uncertain/reorged operations require exact observed evidence and two independent operator signatures; no money balance is automatically repaired. See [Gate C acceptance](../BACKSTOP-GATE-C-ACCEPTANCE.md) and the [operator guide](local-vault-operations.md).

## Run the linked local payment demo

```powershell
npm.cmd run relay:demo
```

This creates an ephemeral local chain-31337 fixture with a file-backed SQLite database. The buyer accepts terms containing the trusted vault/token/address binding, authorizes the payment, and the backend reserves local coverage. A separate worker consumes the matching outbox event and submits the combined merchant-payment/reserve transaction. A submission acknowledgement does not credit the local merchant ledger.

The demo uses seven separate worker processes and API/database restarts. It confirms the payment, lets the merchant spend the tokens, opens a confirmed dispute, obtains two independent review votes, observes the appeal deadline and confirms a pool-funded refund. Every financial posting and final job completion commit together. It prints the receipt references and read-only reconciliation result. One TEST-USD cent maps to 10,000 six-decimal mock-token units; the ledger is mirror accounting, not a second transfer or real USDC.

The fixture is cleaned up afterward; re-running creates a new isolated scenario. The normal `/app` preview remains a separate simulation. Browser wallet signing belongs to the later wallet/testnet integration. The fixture's loopback RPC bridge and unlocked accounts are test infrastructure, not a public deployment setup.

The API's `execution` field distinguishes payment, dispute and final-transition evidence, including pending and manual-review states. Consult a fresh `GET /v1/payments/{id}` rather than an old idempotent POST response. Only the scoped pool operator may request the combined local/vault reconciliation report.

No private key or mainnet access is required for these local tests. No real funds should be used.