Ova Protocol — v0.6 Specification Amendment

Document version: v0.2 Status: DRAFT — for induction pre-flight Amends: OVA_PROTOCOL_SPEC_V2.md (live file, Mac Mini M4, ~/Downloads) Sources: OVA_V0_6_CANDIDATE_REQUIREMENTS-v0_2.html (CR-01…CR-06); OVA_VERIFICATION_PART_II_BEHAVIORAL-v0_1.md (Part II findings) Date: June 10, 2026

Changes from v0.1

Renumbered after collision confirmation. The live spec (V1 and V2 both) tops out at REQ-068 — confirmed by grep on the Mac Mini, June 10. v0.1's rows started at REQ-068 and collided. All rows renumbered; new IDs begin at REQ-069.
Part II requirements folded in. Verification Part II (Behavioral) generated three normative requirements; they join this batch so induction sees one settled set.
Two meta-requirements demoted to prose. v0.1's REQ-070 ("the specification MUST state…") and REQ-073 ("no requirement MUST bind to a proof system") constrained the document, not the system — induction Necessity risk. Their content moves to prose amendments (Sections B and C below); their testable siblings remain as REQ rows.
One statistical convention. All adversarial ACs use the live spec's REQ-065 margin style (classifier accuracy ≤ baseline + 0.02). Part II's p-value phrasing replaced.
Dates corrected to June 10, 2026.

Remaining pre-flight items (run on the live file before merge)

Confirm Forge's database copy of the Ova spec matches OVA_PROTOCOL_SPEC_V2.md (Downloads is upload staging; SAE remediation could have moved the Forge copy ahead). If Forge is ahead, export and merge against that.
Paste cited dependency rows verbatim (REQ-010, 016, 021, 028, 030) and confirm each still means what this amendment cites.
Grep vProg in the live file to fix the exact supersession target IDs (Section D).
Identify the receiving cycle for the new rows; new rows go at the end of that cycle's table.
Run node /Users/dunin7/dunin7-forge/scripts/patch-build-days.js last; never hand-set totals.

Section A — New requirement rows (REQ-069 … REQ-076)

Security

| 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, REQ-030 | 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 | At every serialization boundary, real, chaff, and nest eggs MUST share a single byte-length-identical structure layout. Egg type MUST NOT be represented by any variant-tagged serialization construct (enum, tagged union, or discriminated variant) at any serialization boundary. | 0.2 | REQ-010 | A byte-level inspection of 1000 serialized eggs (mixed types, equal counts) finds all serialized records of identical byte length, and a static analysis of the serialization code path finds zero enum or tagged-union types crossing a serialization boundary. |

Privacy / Observability

| REQ-NNN | Description | Est | Deps | Acceptance Criteria | |---------|-------------|-----|------|---------------------| | 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. |

Performance / Cost

| REQ-NNN | Description | Est | Deps | Acceptance Criteria | |---------|-------------|-----|------|---------------------| | 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-028 | 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. |

Proof system

| REQ-NNN | Description | Est | Deps | Acceptance Criteria | |---------|-------------|-----|------|---------------------| | 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. |

Behavioral uniformity (from Verification Part II)

| REQ-NNN | Description | Est | Deps | Acceptance Criteria | |---------|-------------|-----|------|---------------------| | 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-010, REQ-030 | 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 outcomes. No observable status or error code MUST correlate with egg type. | 0.2 | REQ-010 | 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. |

Total added: 1.9 build days (provisional — patcher authoritative).

Section B — Scope prose amendment (CR-06 + observability statement)

Replacement text for the ## Scope platform paragraph:

> 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).

The second paragraph carries former v0.1 REQ-070's content as scope prose, where the Necessity category expects document-level statements to live.

Section C — Constraints prose amendment (proof-system abstraction)

Add to the ## Constraints section:

> 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.

This carries former v0.1 REQ-073's content as a constraint, keeping the testable deployment-record requirement (now REQ-073 in this batch) as the REQ row.

Section D — Supersession instructions

Targets to be fixed by the live-file vProg grep (pre-flight item above). Expected, subject to confirmation:

Any REQ row stating the implementation target as "Kaspa vProgs" — reword to "Ova based-app runtime," preserving numeric thresholds unchanged.
The vProg schema requirement for the three egg types — superseded by REQ-070 plus the Section B scope amendment; the indistinguishability intent is preserved, only the platform framing changes.
Supersession follows the Forge convention: estimate zeroed, row retained for history, never renumbered or reused.

Section E — Glossary additions

Unchanged from v0.1 except the REQ reference updates: covenant lineage, Ova partition, proven state transition, based ZK application, variant-tagged serialization. Definitions as in v0.1.

Traceability

| Source | Becomes | Note | |--------|---------|------| | CR-01 (lineage) | REQ-069 | | | CR-02 (observability) | REQ-071 + Section B prose | statement demoted to prose; adversary model kept as REQ | | CR-03 (decoy cost) | REQ-072 | | | CR-04 (no enums) | REQ-070 | | | CR-05 (proof-system agnostic) | REQ-073 + Section C prose | interface abstraction demoted to prose; deployment record kept as REQ | | CR-06 (based app) | Section B prose + Section D supersessions | | | Part II A1 (constant time) | REQ-074 | | | Part II A3 (side effects) | REQ-075 | security face of REQ-072 | | Part II A2 (status surface) | REQ-076 | genuine Part II discovery |

Renumbering map (v0.1 → v0.2)

| v0.1 | v0.2 | | v0.1 | v0.2 | |------|------|-|------|------| | REQ-068 | REQ-069 | | REQ-072 | REQ-072 | | REQ-069 | REQ-070 | | REQ-073 | → Section C prose | | REQ-070 | → Section B prose | | REQ-074 | REQ-073 | | REQ-071 | REQ-071 | | Part II 075/076/077 | REQ-074/075/076 |

Dependency direction check: all cited dependencies are existing spec IDs (REQ-010, 016, 021, 028, 030) or lower-numbered rows within this batch (REQ-075 → REQ-072). No forward references, no cycles.

DUNIN7 · Ova Protocol OVA_PROTOCOL_SPEC_V0_6_AMENDMENT — v0.2 (DRAFT) — June 10, 2026