# Vaultfire Solana Mainnet Readiness — Source-Only Handoff

**Historical readiness handoff baseline:** checked-in source at public Vaultfire
commit `cf1975db9ff12b946695069e42059eed25b3ae3f`. The separate V3 internal
security-audit/remediation baseline is
`fbedf828be39aaaf5d74aa6cb4085d783d28a683`, recorded in
[`V3_SECURITY_RELEASE.json`](./V3_SECURITY_RELEASE.json). Neither record is a
deployment, payment, partner-approval, or operational-evidence report.

The machine-readable gates are
[`MAINNET_READINESS.json`](./MAINNET_READINESS.json) and
[`V3_SECURITY_RELEASE.json`](./V3_SECURITY_RELEASE.json). Run
`npm run test:readiness` before merging any Solana readiness change. The test
deliberately fails if source metadata is relabeled as deployment or settlement
evidence.

## Decision

| Dimension | Source-only status | What it does **not** prove |
| --- | --- | --- |
| Vaultfire V3 Solana program | **Not deployed** | A `mainnet` Anchor configuration entry, a program keypair, a local-validator result, or an ID in documentation is not mainnet deployment evidence. |
| x402 USDC settlement | **Configured, unverified** | A 402 option, USDC mint constant, `payTo` default, or verifier code is not a settled mainnet payment. |
| Trust/indexing lanes | **Inventory only** | The eight documented routes are not proven live by this checkout. They are passive/read or receive-only lanes, never proof of a native program. |
| Future partner program | **Optional, not ready** | No partner approval, independent audit, program ID, deployment transaction, or custody plan is recorded here. |
| V3 alpha hardening | **Blocked** | The internal AI-assisted review remediates selected source findings but does not replace independent human audit, reproducible SBF validation, or uncapped-value approval. |

The canonical Solana mainnet identifier for this handoff is
`solana:mainnet`. The website x402 implementation currently uses `solana` as
an x402 network-selection alias; it must not be presented as a substitute for
the canonical identifier.

## Existing source inventory

### Native program source

`programs/` contains fifteen Anchor Rust programs and `tests/e2e_functional.ts`
contains a recorded local-validator functional suite. `Anchor.toml` is
intentionally local-validator-only. The historical program identifiers in
[`PROGRAM_IDS.md`](./PROGRAM_IDS.md) are local deployment identifiers, not
mainnet claims.

### x402 USDC metadata

The website source supplies a Solana SPL-USDC option through:

- `repos/theloopbreaker-site/app/api/x402/trust/_lib/verify-solana.ts`:
  source constant for the mint and an RPC URL fallback.
- `repos/theloopbreaker-site/app/api/x402/trust/_lib/verify-payment.ts`:
  `PAY_TO_SOL` environment default and the advertised payment option.
- `repos/theloopbreaker-site/app/api/x402/trust/_lib/with-x402-multinet.ts`:
  x402 challenge construction, Bazaar metadata, and logging behavior.

The values are recorded in the JSON gate solely to track their source
provenance. They must not be copied into a partner announcement, deployment
manifest, or settlement receipt without independent validation.

### Discovery and Bazaar

The PR7 generated route registry is a separate V2/V3 API artifact. In the
integrated source it contains 29 resources with a canonical Solana payment
option and `metadata-configured-unverified` metadata. That is source configuration for
Solana x402 USDC settlement, not a published discovery capture, facilitator
confirmation, or a production settlement receipt. Generated metadata, a 402
challenge, and a production settlement receipt are three different things; no
independent discovery capture or receipt is included here.

### Documented read-only/indexing lanes

`CONTRACTS.md` names these eight passive lanes:

1. `GET /api/solana/health`
2. `GET /api/solana/scan`
3. `GET /api/solana/program-scan`
4. `GET /api/solana/agents`
5. `GET /api/solana/receipt`
6. `GET /api/solana/bonds/map`
7. `GET /api/solana/index`
8. `POST /api/solana/webhook` (receive-only ingress)

This source checkout does not contain `app/api/solana/` route implementations.
The documented Alchemy RPC, Alchemy webhook/HMAC, Upstash KV, and hourly-cron
claims are operational dependencies requiring their own evidence. None grants
signing authority or creates a native Vaultfire program.

## Partner-led launch handoff

Only an approved deployment partner may move the optional-program gate. The
partner must supply every item below, then an accountable Vaultfire reviewer
must attach it to the release record.

1. **Authority:** written approval, partner legal entity, accountable signer,
   exact program scope, and confirmation that the deployment is optional and
   separate from existing EVM contracts.
2. **Build and audit:** pinned source commit, reproducible build instructions
   and digest, independent audit report, findings/remediation disposition, and
   explicit approval of all upgrade paths.
3. **Deployment evidence:** the exact program ID, mainnet deployment
   transaction signature, RPC-account capture proving executable state and
   program owner, and a bytecode comparison against the approved build.
4. **Custody and operations:** upgrade-authority custody/threshold plan,
   emergency pause or incident procedure, monitoring ownership, webhook HMAC
   secret-management evidence, indexer/reorg handling, and rollback plan.
5. **x402 settlement (if offered):** documented owner acceptance for `payTo`,
   independently checked mint provenance, a controlled successful settlement
   receipt, challenge/receipt capture, replay/expiry evidence, and
   reconciliation owner.
6. **Publication:** only after all gates pass may a release record name the
   program, call settlement live, or associate a partner deployment with
   Vaultfire V3.

If any field is missing, retain `not_deployed`, `configured_unverified`, or
`not_ready` as applicable. Do not infer approval from a wallet, code comment,
or metadata file.
