> **Publication safety update (2026-08-31):** Full Git-history bundles, bundle fragments, and environment-revealing raw logs are withheld from the public site pending a minimal exact-commit snapshot and completed secret/path review. Existing source/evidence identities remain historical references, not downloadable release approval. # Vaultfire V3 x402 Future Deployment Requirements **Status:** Deployment requirements for a future release **Audience:** Partner engineering, security, infrastructure, governance, legal, and operations teams **Last updated:** 2026-08-30 **Current production state:** V3 source-only and disabled; V2 remains the live payment surface ## Purpose and release boundary This document defines the conditions that must be satisfied before a Vaultfire V3 x402 service can accept production payments. It is a deployment and acceptance checklist, not authorization to deploy. The reviewed V3 source is frozen at: - **Tag:** `v3-source-2026-08-27` - **Tag object:** `d9757c125d547968f80d4c61bea08f6638b33dd6` - **Commit:** `bf4b97f65b7032c778d137bb52a432afc4615b51` - **Tree:** `a1fd90c26ae676c87a10e7d3e614e84961b2990c` - **Frozen `v3-src` subtree:** `0a521a25501cd9fe6a74401c99fde450128b22c9` The deterministic tests and portable verifier are a separate immutable tooling release: - **Tooling tag:** `v3-tooling-2026-08-30-r2` - **Tooling tag object:** `49b520805f543d72dcaae6d285fade0ec0fc4025` - **Tooling commit:** `241ce24db4c1417acbf936c5b412352531aba2f1` - **Tooling tree:** `4486751cce5bcf3dfdbd34d124d72384916f77e0` The secret-free logs and checksums are retained by a separate evidence publication: - **Evidence tag:** `v3-evidence-2026-08-30-r3` - **Evidence tag object:** `6f39cb9428e1f265164736812e02fd84a42152eb` - **Evidence commit:** `1be0f7e791ffc4ea68bb35228bc8fcac0ff302da` - **Evidence tree:** `e401714961b852aeb54cdf0b2ef62e615ae9e0b7` - **Evidence release:** https://theloopbreaker.com/v3/releases/v3-production-evidence-2026-08-30-r3/ - **SHA-256 manifest:** https://theloopbreaker.com/v3/releases/v3-production-evidence-2026-08-30-r3/SHA256SUMS - **Complete Git bundle reconstruction:** https://theloopbreaker.com/v3/releases/v3-production-evidence-2026-08-30-r3/tooling/README.md These identities are intentionally separate. The frozen tag identifies reviewed V3 source bytes, the tooling tag identifies the code actually used for the retained tests, the evidence tag identifies the published logs and checksums, and the production release record identifies the website deployment that serves the public handoff. The current public V3 API contains 20 route identities. Deployment- and payment-dependent routes intentionally return `503 v3_x402_release_gate_closed`; the historical partnership-bond write route returns `503 v3_x402_route_permanently_retired`. These responses are safety controls and must not be bypassed through environment-only changes. Vaultfire protocol V3 and x402 payment protocol version 2 are separate version lines. A future Vaultfire V3 payment service is expected to use x402 v2 wire semantics unless a separately reviewed release explicitly changes that decision. ## Required deployment profile The initial production profile must be narrow, reviewable, and fail closed: - **Payment chain:** Base only, CAIP-2 network `eip155:8453`. - **Payment asset:** Native Base USDC with six decimals and a deployment-manifest-pinned contract address. - **Payment scheme:** x402 v2 `exact`. - **Resource identity:** Absolute HTTPS URL plus canonical HTTP method. - **Payee:** A named, approved treasury or payment-receiving account. The deployer must not remain the production payee. - **Facilitator:** A specifically approved facilitator endpoint with pinned environment and ownership. - **Protocol scope:** Only routes listed in an approved, checksummed route registry. - **Partner scope:** Initially limited to the explicitly approved partner and use case. - **V2 boundary:** Existing V2 routes, contracts, receipts, and payment behavior remain unchanged unless a separate compatibility release authorizes a migration. - **Solana boundary:** No Solana x402 payment claim or cross-chain settlement is permitted in the Base-first release. Changing the network, asset, scheme, facilitator, payee, pricing, or route set creates a new deployment candidate and requires new review evidence. ## Source and build integrity Before configuration or deployment: - [ ] Clone the canonical repository recursively from GitLawb. - [ ] Resolve and record the exact tag object, commit, and tree. - [ ] Verify the frozen source archive and every entry in its SHA-256 manifest. - [ ] Reproduce the build under the documented Node 20 environment. - [ ] Confirm there are no uncommitted source changes. - [ ] Generate software bills of materials and dependency-lock digests. - [ ] Scan the candidate for secrets, private keys, payment signatures, credentials, and unexpected binaries. - [ ] Produce deterministic build artifacts and record their hashes. - [ ] Bind every generated artifact to a deployment-candidate ID. Any code change requires a new source tag, commit, tree, audit delta, test run, evidence directory, and approval. The frozen tag must never be moved. ## Contract deployment and governance No production x402 activation may precede an approved V3 contract deployment: - [ ] Complete an independent human security audit of the exact deployment candidate. - [ ] Resolve all Critical and High findings; formally disposition lower-severity findings. - [ ] Rehearse the exact deployment on Base Sepolia. - [ ] Verify chain ID, compiler settings, constructor arguments, bytecode, ownership, roles, and caps. - [ ] Assign governance to the approved multisig rather than an externally owned deployer account. - [ ] Finalize the intended 3-of-5 signer set and 24-hour administrative timelock. - [ ] Assign a separate pause-only guardian that is not a multisig signer. - [ ] Verify that deployment and write controls default to disabled. - [ ] Verify allowlists and caps against the approved machine-readable deployment manifest. - [ ] Confirm withdrawals and terminal exits remain available under pause according to their documented rules. - [ ] Publish verified addresses and bytecode identities without publishing private operational material. The initial Base pilot must not silently add reward programs, cross-chain value movement, unsupported modules, or broader public write access. ## Route registry and API activation Every payable resource must be generated from one canonical registry. For each route, the approved record must include: - Stable route ID and protocol version. - Canonical HTTP method. - Exact absolute HTTPS resource URL. - Input and output JSON Schemas. - Atomic price and human-readable display price. - `eip155:8453` network identifier. - Base USDC asset address and decimals. - Approved payee. - x402 v2 `exact` scheme. - Facilitator and timeout policy. - Required confirmation or finality policy. - Authentication and authorization policy independent of payment. - Data classification, retention, and logging policy. - Owner, support contact, rate limits, and service objective. The OpenAPI document, x402 discovery document, SDK route definitions, production manifest, health response, public documentation, and implementation must be generated from or validated against that same registry. Activation must remain impossible while any route has an unknown method, relative or ambiguous resource, unresolved schema, placeholder address, zero address, unsupported payment option, or missing approval. ## Payment verification and replay protection Every payment authorization, payment ID, receipt, retry, and reconciliation record must be bound to all of: - Canonical HTTP method. - Exact absolute resource URL. - Network and chain ID. - Asset contract. - Atomic amount. - Payee. - Authorization identity and validity window. - Nonce or equivalent uniqueness value. - Required confirmation depth or finality rule. A valid payment for one resource must never unlock another resource, including a same-price route. The verifier must reject mismatches before delivering paid content. Required adversarial tests include: - Same price, different route. - Same path, different HTTP method. - Same route, different query or canonical resource. - Different network, asset, amount, or payee. - Reused authorization, nonce, transaction, or receipt. - Expired and not-yet-valid authorization. - Malformed, duplicated, or noncanonical fields. - Concurrent settlement attempts. - Stale lease and attempt-token races. - Reorged or insufficiently confirmed transfer. ## Settlement idempotency and recovery The production store must be durable and shared across instances. Process memory is not an acceptable fallback. Before settlement, the service must atomically create: - A non-expiring pending-recovery barrier. - Payment, authorization, and nonce reservations. - A short-lived settlement lease. - A unique attempt token for compare-and-delete protection. - The complete canonical request/payment binding. After a facilitator reports successful settlement: - The payment must never be settled again merely because receipt persistence failed. - The pending-recovery barrier must remain until reconciliation reaches a terminal, verified state. - The service must fail closed with a stable recovery status while access cannot safely be restored. - A bounded reconciliation write may restore the settled receipt without re-verifying or re-settling. - Recovery must validate the original method, resource, network, asset, amount, and payee. - Stale attempts must not release or overwrite a newer attempt. - A structured operational alert must be emitted without exposing credentials, payment signatures, raw authorization data, or restricted receipt fields. Recovery acceptance evidence must prove one facilitator settlement call, restored access after reconciliation, rejection of cross-resource replay, safe failure while unresolved, and successful alert delivery. ## Receipt privacy and retention Receipt identifiers act as capability-like locators and require sufficient cryptographic randomness. Callers must not be allowed to select weak or personally identifying identifiers. Public receipt responses may expose only the fields approved by the receipt schema. They must never expose authorization IDs, payment IDs, signatures, payment headers, request bodies, Redis credentials, private keys, or audit-history payloads. Production requirements: - [ ] Edge rate limiting against receipt enumeration. - [ ] Documented retention period for receipts and replay reservations. - [ ] Data minimization and deletion policy for off-chain operational data. - [ ] No PII or free-form sensitive narratives in on-chain commitments. - [ ] Redacted audit events containing only approved identifiers, states, sequence numbers, and short integrity-digest prefixes. - [ ] Privacy and legal review of public-chain correlation risks. ## Secrets and infrastructure Production secrets must be stored in an approved secret manager and scoped by environment: - Facilitator credentials. - Redis or durable-store credentials. - RPC credentials. - Alerting and incident-management credentials. - Deployment automation credentials. No secret may appear in source, build output, logs, evidence bundles, client JavaScript, OpenAPI documents, discovery documents, health responses, or error payloads. Infrastructure must provide: - Multi-instance-safe durable storage. - TLS-only connections and authentication. - Least-privilege service identities. - Credential rotation and revocation procedures. - Primary and fallback Base RPC providers. - Bounded timeouts, retries, and circuit breakers. - Rate limiting and abuse controls. - Immutable deployment logs and trace correlation without sensitive payload logging. - Backup, restore, and data-corruption procedures. ## Monitoring and incident response The following signals must be observable before launch: - Challenge issuance, verification, settlement, receipt persistence, and reconciliation outcomes. - Settlement latency and facilitator error rate. - Duplicate authorization, nonce, payment, transaction, and receipt attempts. - Binding mismatches and cross-resource replay attempts. - Pending-recovery age and backlog. - Redis availability and conditional-write failures. - RPC disagreement, reorg, and insufficient-finality events. - Paid-response delivery failures after settlement. - Route-level 402, 4xx, 5xx, and CORS behavior. - Configuration drift between the registry and public truth surfaces. Alerts must have named owners, tested channels, severity thresholds, escalation paths, and runbook links. The team must complete a rehearsal covering facilitator success followed by receipt-store failure, RPC failure, Redis failure, stale lease recovery, credential compromise, guardian pause, and public status communication. ## Test and evidence gates The final candidate must pass from a fresh recursive clone in an isolated environment: - [ ] Frozen-source checksum and archive verification. - [ ] All contract, invariant, property, selector, authorization, and compatibility tests. - [ ] All SDK tests with outbound network access blocked. - [ ] All no-wallet sandbox tests. - [ ] V3 route contract and fail-closed tests. - [ ] x402 schema, OpenAPI, registry, discovery, CORS, and challenge tests. - [ ] Method/resource/network/asset/amount/payee replay tests. - [ ] Settlement persistence-failure and reconciliation tests. - [ ] Base Sepolia end-to-end tests with real deployment evidence. - [ ] Load, concurrency, rate-limit, and recovery tests. - [ ] Security scans and external audit closure. Retain commands, versions, exit codes, durations, raw logs, machine-readable results, and SHA-256 checksums. Evidence must contain no payment signature, private key, seed phrase, Redis credential, facilitator credential, or restricted receipt payload. Static validation is not proof of a live payment. Before claiming a production route is live, retain route-specific evidence for a real 402 challenge, approved authorization, successful settlement, exact Base USDC transfer, paid response, stored receipt, retry behavior, and later reconciliation. Bazaar validation or metadata generation alone does not prove indexing. ## Launch sequence ### Candidate preparation 1. Select the exact source tag and create a checksummed deployment candidate. 2. Complete independent audit and remediation. 3. Finalize route registry, pricing, payee, facilitator, governance, data policy, and partner scope. 4. Produce a signed approval manifest outside the public repository. ### Base Sepolia rehearsal 1. Deploy with production-equivalent roles and disabled writes. 2. Verify addresses, bytecode, constructor arguments, and role assignments. 3. Exercise challenge, payment, settlement, receipt, replay, reconciliation, pause, and recovery paths. 4. Rehearse rollback and incident response. 5. Record independent acceptance and evidence hashes. ### Capped Base activation 1. Deploy the exact approved contracts and verify them. 2. Configure production infrastructure while keeping discovery and writes disabled. 3. Run read-only smoke tests and configuration-drift checks. 4. Enable one allowlisted partner and the minimum approved route set through governance. 5. Execute a capped real-payment canary with explicit human approval. 6. Verify settlement, receipt, finality, paid response, alerting, accounting, and rollback behavior. 7. Publish the exact release record and update public status only after evidence passes. ### Expansion Expand routes, partners, limits, networks, assets, or modules only through a new candidate, risk review, evidence set, and governance approval. ## Rollback and halt conditions Immediately disable new challenges and writes when any of the following occurs: - Payment binding or replay-control failure. - Double settlement or unexplained duplicate facilitator call. - Assets-to-liabilities invariant failure. - Receipt corruption or inability to reconcile a successful settlement. - Base reorg beyond the accepted finality policy. - RPC providers disagree or all approved providers are unavailable beyond threshold. - Redis or durable-store integrity failure. - Payee, facilitator, route-registry, or pricing drift. - Critical or High security finding. - Credential or governance-key compromise. - Monitoring or alert-delivery failure during the pilot. Pausing must not erase recovery state or block permitted withdrawals and terminal exits. Resume requires documented root cause, remediation, clean reconciliation, renewed evidence, and governance approval. ## Production approval record The final go-live record must identify: - Source tag object, commit, and tree. - Deployment-candidate ID and build hashes. - Contract addresses, bytecodes, constructors, and verification links. - Governance, guardian, payee, facilitator, network, asset, pricing, and route registry. - Audit report and finding disposition. - Sepolia rehearsal evidence. - Test and checksum manifests. - Monitoring and incident-rehearsal evidence. - Legal, privacy, commercial, and partner acceptance. - Activation proposal and human approval. - Production deployment ID and rollback reference. V3 x402 may be described as live only after every required field is non-placeholder, independently verifiable, and bound to the deployed candidate. ## Current gap summary The implementation and evidence provide a strong future deployment foundation, but the following remain external gates: independent human V3 audit, final governance identities, Base Sepolia deployment rehearsal, production contract deployment, production facilitator/payee/store configuration, monitored live-payment canary, legal and privacy approval, partner acceptance, and governance-authorized activation.