# Security model and capability map

## Status boundary

This directory is an additive, source-only Solana V3 successor. Its program ID is new and unrelated to protected legacy programs. No deployment, wallet, keypair, mainnet map, migration, or upgrade instruction is included. `initialize` starts paused; only the configured authority can unpause. The checked-in deployment template has both authorization flags false.

## PDA domains and replay protection

| Record | Seed prefix | Remaining identity seeds |
|---|---|---|
| protocol config | `v3-config` | singleton |
| parity/replay receipt | `receipt` | actor, little-endian nonce |
| identity | `identity` | subject |
| KYA | `kya` | subject, issuer, nonce |
| consent | `consent` | subject, grantee, nonce |
| mandate | `mandate` | principal, nonce |
| mandate execution | `execution` | mandate, execution nonce |
| evidence/reputation | `evidence` / `reputation` | issuer, nonce |
| bond | `bond` | canonical party A, party B, nonce |
| task | `task` | client, provider, nonce |
| milestone | `milestone` | task, index |
| deterministic cover | `cover` | funder, beneficiary, nonce |
| mutual aid / reward | `aid` / `reward` | funder, recipient, nonce |
| grouped reward program | `reward-program` | sponsor, issuer, nonce |
| grouped reward issuance | `reward-issuance` | reward program, issuance digest |
| resource vault | `vault` | resource account |
| pull credit | `credit` | vault, recipient |
| governance / approval | `governance` / `approval` | proposer+nonce / proposal+signer |
| emergency | `emergency` | guardian, nonce |
| provenance / privacy | `provenance` / `privacy` | signer, nonce |
| ML-DSA policy | `mldsa-policy` | subject, key epoch |

Creation and execution receipts cannot be replayed because their nonce is part of a unique PDA. Mutable records additionally use expected revisions, bounded use counters, terminal state, or one-approval-per-signer PDAs.

## Custody and liabilities

Every bond, milestone, deterministic cover record, voluntary aid record, and reward has a distinct program-owned vault PDA. Deposits use the system program; arithmetic is checked. Settlement only creates recipient-specific pull credits. A withdrawal preserves the vault's rent minimum and verifies `totalWithdrawn <= totalCredited`. A credit operation verifies total credits never exceed that vault's deposits. Recovery remains available while paused. Exact deadline equality remains on the live-action side, and permissionless recovery begins strictly after the deadline, matching the Base successor.

Single-claim rewards are funded only into `ResourceKind::Reward` vaults.
Grouped rewards are funded only into `ResourceKind::RewardProgram` vaults.
A grouped reward program binds its sponsor, issuer, issuer-identity commitment,
resource, action, rules digest, original budget, remaining budget, deadline,
monotonic issuance nonce, and program nonce. Only the bound issuer may create
an issuance; every issuance has a unique PDA derived from the program and a
nonzero issuance digest, while the exact next nonce must be consumed, so digest
replay, nonce replay, and cross-program substitution fail closed. Each issuance
stores the native actor separately from its identity commitment and stores
distinct resource, action, payload, consent, validity, and chain-domain fields.
Structured provenance separately records source family/domain/program/block,
event digest, finality digest, and destination domain. Its SHA-256 commitment is
recomputed from a versioned canonical byte sequence, and the destination domain
must equal the initialized protocol chain domain. Receipt validity is inclusive:
issuance is permitted exactly when `valid_from <= now <= valid_until`.
Each partial issuance checks that program `remaining` equals the vault's
uncredited balance before and after crediting. Issuance remains live at exact
deadline equality. After the deadline, any signer may pay for terminal recovery
to the bound sponsor, including a zero-remaining close after full issuance.
Neither reward path can debit a bond, escrow, cover, or aid vault, and there is
no protected-principal slashing path.

## Capability boundaries

- Partnership bonds require canonical distinct parties, bilateral creation/activation/settlement, exact fixed terms, and timeout recovery.
- Accountability bonds use one precommitted objective fact digest and deterministic beneficiary. They do not consume reputation, KYA, beliefs, behavioral signals, or free-form adjudication.
- Task escrow is divided into at most eight isolated milestone vaults. Release is bilateral; deadline recovery is permissionless and credits the client.
- “Deterministic cover” is an isolated reserve interface, not an assertion of licensed or actuarially sound insurance.
- Mutual aid is a voluntary donor-to-recipient transfer with donor timeout recovery.
- Identity, KYA, ERC-8004 identifiers, evidence, reputation, provenance, privacy commitments, and governance proposals are records. Informational records have no CPI or custody authority.
- Mandates bind principal, delegate, target program, instruction discriminator, ordered-account digest, scope digest, spend cap, use cap, and exact validity window. This version records consumption but intentionally does not perform arbitrary CPI.
- Governance is a threshold/timelock record, not a generic executor. The guardian can pause and record an incident but cannot unpause, move value, or configure verifiers.

## Verifier interfaces

ZK, FHE, and ML-DSA interfaces default to the all-zero/unconfigured verifier and fail closed. A bound receipt must be owned by the exact configured verifier program and contain exactly:

`"VFVRFY01" || statement_pubkey[32] || digest[32] || success_byte(1)`

Configuration requires the protocol authority and increments the governance epoch. This adapter proves only that the named external program emitted the exact receipt; it does not inherit or claim the external system's cryptographic security.

The ML-DSA policy schema fixes ML-DSA-65 public-key/signature lengths at 1,952/3,309 bytes and stores suite, context, key, subject, and epoch commitments. `assert_mldsa_verified` always returns `MldsaVerificationUnavailable`. The Solana program does not implement ML-DSA natively. Adapter source exists and is locally tested against the native core, but no production verifier pin or real-proof chain test exists. ML-DSA-65 is a FIPS 204 algorithm target only; no FIPS 140 validation, independent conformance, post-quantum verification, or quantum-resistance claim is made.

### Chain-bound ML-DSA authorization gate

The generic external-verifier receipt is a privacy-commitment interface and is
not accepted as an ML-DSA authorization result. Program ownership plus
`VFVRFY01 || statement || digest || 1` does not prove that ML-DSA was executed
or bind the protocol's complete public inputs. `MldsaPolicyRecord` also stores
32-byte digests, while the canonical SDK fingerprint and envelope/payload
digests required by the hybrid protocol are SHAKE256-512 values.

A sound success path must bind the exact canonical envelope bytes and hash,
key fingerprint and current epoch/lifecycle, algorithm/version, policy, exact
payload length and digest, genesis hash, consumer program, module, operation,
128-bit nonce, validity window, configuration version, and cryptographic
verification result. The classical leg must read only the real instructions
sysvar and require a successfully executed, prior, canonical inline Ed25519
instruction over those exact envelope bytes. No caller-provided instruction
bytes or off-chain report may substitute.

No production-pinned proof verifier presently supplies the ML-DSA
result. The exact SOFTWARE blocker is a reviewed staged-PDA direct verifier
within measured transaction/CU/heap bounds, or a named audited proof stack
whose guest/circuit executes the FIPS 204 ML-DSA-65 algorithm and whose SBF
verifier binds every field before atomic nonce consumption. The machine-
readable blocked disposition is [the public ML-DSA capability record](../modules.manifest.json).

## Testing boundary

Native Rust tests cover checked accounting, exact deadlines, terminal-state monotonicity, PDA domain separation, bounded account sizing, signer-set ordering, participant canonicalization, resource isolation, canonical receipt field separation, and ML-DSA size confusion. Real-SBF `solana-program-test` coverage additionally exercises grouped reward digest replay, nonce replay, issuance-PDA substitution, issuer substitution, unbound provenance rejection, over-credit, pause, exact-deadline issuance, permissionless terminal recovery while paused, and aggregate account state. See the implementation report for exact commands and results. Tests do not constitute an audit.