Ova Protocol — v0.6 Specification Amendment

Document version: v0.3 Status: MERGE-READY — apply to OVA_PROTOCOL_SPEC_V2.md, output OVA_PROTOCOL_SPEC_V3.md Verified against: live spec V2 (Downloads, Mac Mini) = Forge DB copy (engagement 2795063c, review #2 "ready", 2026-03-09). Confirmed identical; Forge not ahead. Sources: CR-01…06; Verification Part II; CC pre-repair report (June 11, 2026) Date: June 11, 2026

Changes from v0.2

1. Dependency citations corrected against verbatim live-spec rows. v0.2 cited dependencies by remembered meaning; the CC report exposed three mismatches:

• REQ-028 is decoy ordering (pseudorandom permutation), not decrypt-and-discard. Decrypt-and-discard is REQ-025. REQ-072's dep corrected.
• REQ-030 is chain-seed secrecy, not rekeying. Rekeying is REQ-016 (re-derivation on every state write, type-identical). REQ-069's dep corrected; REQ-074's deps redone.
• REQ-010 is schema forward-compatibility, not the schema definition (REQ-001). REQ-070's dep corrected, and a forward-compat interaction noted in its description.

1. Placement: new Cycle 8. All eight rows append as ### Cycle 8: Toccata Alignment and Behavioral Uniformity (v0.6) under Phase 4, after Cycle 7 (which ends at REQ-068, line 268). This keeps every existing cycle's contiguous REQ range untouched. Fallback if Forge requires the 7-cycle structure: append to Cycle 7's table and update its total line instead.
2. No supersessions. The vProg grep shows 22 REQ rows using "vProg" as terminology, none whose meaning dies with the vProgs deferral. Section D is now a reword-in-place terminology pass plus an amendment-flag refresh, not supersession.
3. Duplication guard added for REQ-076 vs existing REQ-025/REQ-038 (which already cover rejection-response content and byte length). REQ-076 is scoped strictly to the status/error-code surface.
4. Date June 11; AC convention confirmed against the live file (additive margin for adversarial accuracy per REQ-065; chi-squared p<0.05 reserved for distribution-uniformity per REQ-024 — this batch uses only the former).

Section A — New requirement rows (final)

Append as:

### Cycle 8: Toccata Alignment and Behavioral Uniformity (1.9 build days)

| REQ-NNN | Description | Est | Deps | Acceptance Criteria | |---------|-------------|-----|------|---------------------| | REQ-069 | Egg state transitions MUST NOT be linkable through KIP-20 covenant lineage. Each egg state update produces an on-chain object whose covenant lineage identifier has no derivable relationship to the lineage identifier of the prior state of that egg. | 0.3 | REQ-016 | Given 1000 sequences of 5 successive state updates to the same egg, an adversary with full on-chain read access and all covenant lineage data identifies which objects belong to the same egg with accuracy not exceeding the random-guess baseline + 0.02. | | REQ-070 | Within a given schema version, real, chaff, and nest eggs MUST share a single byte-length-identical structure layout at every serialization boundary. Egg type MUST NOT be represented by any variant-tagged serialization construct (enum, tagged union, or discriminated variant) in any serialized form. Forward-compatible extension fields (REQ-010) MUST be applied uniformly across all three types so length identity within a schema version is preserved. | 0.2 | REQ-001, REQ-010 | A byte-level inspection of 1000 serialized eggs of one schema version (mixed types, equal counts) finds all records byte-length identical, and a static analysis of the serialization code path finds zero enum or tagged-union types crossing a serialization boundary. | | REQ-071 | The traffic-analysis adversary model MUST be defined as an observer of the Ova partition specifically, with full visibility of partition activity timing and volume, and zero visibility of egg type, authorized content, or requester identity. | 0.2 | None | The adversary model section enumerates the observer's visible inputs (partition activity, timing, volume) and explicitly lists egg type, authorized content, and requester identity as not visible. A reviewer confirms each item is classified. | | REQ-072 | Decoy rejection (decrypt-and-discard) and routine nest maintenance operations MUST be performed outside the proven state transition, UNLESS a cited formal verification result requires inclusion to preserve a stated indistinguishability property. Any inclusion MUST cite the requiring proof by Part number. | 0.3 | REQ-021, REQ-025 | A trace of 1000 decoy rejection operations records zero decoy rejections included in a proven state transition, OR every included decoy rejection is annotated with a verification Part citation. A run with no citations and any included decoy rejection fails. | | REQ-073 | Proof system selection MUST be recorded per deployment as a non-normative implementation decision with written rationale, including trusted-setup status and mainnet-availability status of the chosen system at time of selection. | 0.1 | None | A deployment record exists containing the selected proof system name, its trusted-setup status, and its mainnet-availability status. A deployment record missing any of the three fields fails. | | REQ-074 | The egg interrogation handler MUST execute in time independent of egg type. Interrogation of a real, chaff, or nest egg MUST be indistinguishable by wall-clock timing. | 0.3 | REQ-025 | Over 10,000 interrogations per type under fixed load, a per-type timing classifier achieves accuracy not exceeding 0.5 + 0.02. | | REQ-075 | Decoy rejection MUST NOT produce any on-chain artifact (transaction shape, address-touch pattern, or fee signature) that differs from the on-chain footprint of a real-egg interrogation of equivalent position. | 0.3 | REQ-072, REQ-021 | An adversary with full on-chain read access, given 1000 interrogations of mixed real/decoy targets, classifies decoy vs real by on-chain artifact alone with accuracy not exceeding 0.5 + 0.02. | | REQ-076 | The interrogation status surface MUST present a type-independent set of status and error codes. No observable status or error code MUST correlate with egg type. This requirement covers the status/error-code channel only; response content and response byte length are covered by REQ-025 and REQ-038 respectively. | 0.2 | REQ-025, REQ-038 | Over 10,000 interrogations per type, a classifier given only the observed status/error values achieves per-type accuracy not exceeding 0.5 + 0.02, and the set of distinct status values observed is identical across types. |

Cycle total line to append: Cycle 8 total: 1.9 build days | 8 requirements (REQ-069 – REQ-076)

Section B — Scope prose amendment

Replace the platform sentences at lines 46 and 52 (Scope) with:

> The Ova Protocol is a decentralized access control protocol implemented as a standalone based ZK application on the Kaspa blockDAG, using the Toccata primitives: KIP-16 ZK verification opcodes, KIP-17 covenant opcodes, KIP-20 covenant identifiers (subject to REQ-069), and KIP-21 partitioned sequencing. Ova executes its access-control logic off-chain, inherits transaction ordering from Kaspa Layer 1 consensus, and posts compact zero-knowledge proofs that Layer 1 verifies. Synchronously composable verifiable programs (vProgs) are recorded as a possible future migration target and are not a dependency of this specification. > > Under KIP-21 partitioned sequencing, the existence and volume of Ova activity within the Ova partition is observable on-chain. Indistinguishability properties apply within the partition — to egg type, authorized content, and requester identity — and never to membership of the partition itself. The traffic-analysis adversary is defined accordingly (REQ-071).

Section C — Constraints prose amendment

Add to Constraints (or Tech Stack if no Constraints section exists; CC confirms which heading the spec uses):

> ZK proof requirements in this specification are defined against an abstract proof interface — statement, witness, public inputs, and verification cost bounds — and no normative requirement binds to a named proof system (Groth16, RISC Zero STARK, or other). Proof system selection is a per-deployment implementation decision, recorded per REQ-073.

Section D — Terminology pass and flag refresh (replaces supersession)

D.1 Terminology reword, meaning preserved, thresholds unchanged. In the 22 REQ rows listed in the CC report (lines 141–268) and the prose/glossary/tech-stack lines (17, 19, 32–33, 46, 52, 72, 77–78, 99, 131, 281–299):

• "vProg" / "Ova vProg" / "Kaspa vProg" (the executing program) → "Ova application" or "based-app runtime" as grammar requires.
• "vProg schema" → "egg record schema".
• "vProg verifier" → "L1 proof verifier (KIP-16)".
• "Kaspa vProgs testnet" → "Kaspa testnet 12 (TN12)".
• Glossary entry "vProg" (line 131): replace with a "Based ZK application" entry; add a note that vProgs (synchronously composable programs) are a future Kaspa stage and a possible migration target, not a dependency.
• Tech Stack (lines 72, 77, 78): Execution Environment → Kaspa based-app runtime (kaspanet/vprogs repository, prototype); Proof Verification → KIP-16 opcodes; Resource Metering → ScopeGas (final pricing implemented, KIP pending — benchmark on TN12).
• Grounding section (281–299): retain Yellow Paper citations as historical grounding; add one line noting the Toccata reframing and its date.

D.2 Amendment-flag refresh (REQ-048, 050, 059, 060, 061). These flags reference the May 5 hard-fork date and pre-Toccata uncertainty. Update flag text only — numeric placeholders stay until TN12/mainnet benchmarks replace them:

• Hard fork: "Toccata, mainnet activation ~June 30, 2026 (rusty-kaspa v2.0.0, DAA score 474,165,565)".
• "L1 ZK Verification Opcode" → "KIP-16 (Groth16 confirmed mainnet; RISC Zero STARK live on TN12, mainnet undecided)".
• "Kaspa vProgs testnet" → "TN12 (full Toccata feature set live now — benchmarks can be gathered before mainnet activation)".

Section E — Glossary additions

Add: covenant lineage; Ova partition; proven state transition; based ZK application; variant-tagged serialization (definitions per amendment v0.1/v0.2, unchanged except REQ references → REQ-069/REQ-071).

Merge procedure (for CC, on the Mac Mini)

1. cp ~/Downloads/OVA_PROTOCOL_SPEC_V2.md ~/Downloads/OVA_PROTOCOL_SPEC_V3.md — never edit V2.
2. Apply Section A: insert Cycle 8 heading, table, and total line after line 270 (Cycle 7 total). Update the Phase 4 heading to "(Cycles 7-8)".
3. Apply Sections B, C, E (prose and glossary).
4. Apply Section D terminology pass and flag refresh. Verify no numeric threshold changed: diff old/new and confirm all digit changes are dates/KIP numbers only.
5. Duplication guard: read REQ-025 and REQ-038 in full; confirm REQ-076 does not restate either (it should cover status/error codes only). If overlap is found, narrow REQ-076 further rather than touching the inducted rows.
6. Run the patcher from the Forge repo: node /Users/dunin7/dunin7-forge/scripts/patch-build-days.js against V3. The live spec uses per-cycle totals (no grand total); the spec passed induction in this format, so the patcher is expected to handle it — if it errors on a missing grand-total line, report the error verbatim, do not hand-add a total.
7. Sanity greps on V3: highest ID = REQ-076; 76 unique contiguous IDs; zero occurrences of "vProg" outside the glossary migration note and grounding history; zero occurrences of "May 5, 2026".
8. Upload V3 to Forge for re-induction (engagement 2795063c). Expect induction to re-review; the new rows were written to its criteria.

Traceability (unchanged from v0.2 except dep corrections)

CR-01→REQ-069 · CR-02→REQ-071+Scope prose · CR-03→REQ-072 · CR-04→REQ-070 · CR-05→REQ-073+Constraints prose · CR-06→Scope prose+Section D · Part II A1→REQ-074 · A3→REQ-075 · A2→REQ-076.

Dependency direction check: all deps are existing IDs (REQ-001, 010, 016, 021, 025, 038) or lower-numbered in-batch (REQ-075→REQ-072). No forward refs, no cycles.

DUNIN7 · Ova Protocol OVA_PROTOCOL_SPEC_V0_6_AMENDMENT — v0.3 (MERGE-READY) — June 11, 2026