Version. v0.2 Date. June 11, 2026 (v0.1: June 9; Decisions 8–11 added June 10–11) Status. Discovery record. Session trajectory preserved for seed extraction and future reconstruction. Source session. Reevaluation of Ova design against the Kaspa Toccata release; production of v0.6 candidate requirements and amendment.
This record preserves not just the decisions reached in this session but the path to them: the prior positions corrected, the alternatives considered and set aside, and the points where something new crystallized. It is the input material for the Ova candidate seed and a reconstruction aid for later review.
It is one session's trajectory. It does not restate the full Ova design — only what moved, and why.
Prior position. The Phase Development Plan and the v1 Forge spec stated the implementation target as "Ova on Kaspa vProgs." Phase 3 was titled "Ova Implementation … on Kaspa vProgs."
Correction. vProgs is not in the Toccata release. Toccata delivers the standalone based-ZK-application model: off-chain execution, ordering inherited from Layer 1, compact proofs verified on-chain. Full vProgs (synchronous composability) is a later roadmap stage, signposted around 2027.
Why the new position is not a compromise. Ova never needed synchronous composability. Tessera consumes Ova at the application layer, in Tessera's own codebase — not through cross-contract calls. The based model also strengthens the security argument: individual hops and decoy rejections happen inside privately proven state, so Layer 1 sees commitments and proofs, not per-hop activity.
Crystallization. Waiting for vProgs would cost roughly a year and buy nothing Ova needs. The based-app model is a better fit, available now on testnet 12. This became candidate requirement CR-06 and the v0.6 Scope amendment.
Prior position. Work was planned around a May 5, 2026 mainnet activation, with Ova Forge work resuming mid-May.
Correction. The date moved from May 5 to a June 5–20 window, then to roughly June 30, 2026 (hardcoded in rusty-kaspa v2.0.0 at DAA score 474,165,565). The slips were to allow the sequencing commitment architecture to be finalized before circuits bind to it.
Consequence. "Resume mid-May" was built on a date that no longer holds. Prototyping does not need to wait for mainnet — testnet 12 already runs the full feature set including the STARK verifier — but hardening and economic benchmarking must wait for activation and final pricing.
Prior position. The horizon tracked "ZK opcode activation" as a single pending dependency.
Correction. KIP-16 ships two verifiers with different consequences:
Crystallization. Because the STARK mainnet decision is outside our control, the spec must not bind to either system. This became CR-05: define an abstract proof interface; record the per-deployment choice with rationale. Practical plan: prototype on RISC Zero now; if STARK reaches mainnet, use it; if not, wrap STARK in a single fixed Groth16 circuit (one ceremony, once, for a wrapper that never changes).
What crystallized (new, not a correction). Two Toccata features that help most applications create new ways an observer could learn things about Ova:
Alternative considered and set aside (CR-01). Rather than breaking lineage entirely, let every egg type carry lineage in an identical pattern so lineage reveals nothing about type. Set aside: lineage would still reveal each egg's update frequency, which is exactly the timing signal Part V treats as dangerous. Breaking lineage entirely is the safer rule.
What crystallized. Under KIP-21, an app pays proving cost proportional to its own activity — but chaff is Ova's own activity. With billions of nest eggs, proving every decoy event would make the cover traffic that protects the system also the thing that bankrupts it.
Position. Decoy rejection and routine nest maintenance stay outside the proven state transition, unless a formal verification result requires inclusion to preserve an indistinguishability property (in which case the requiring proof is cited). Became CR-03 (REQ-072).
Prior position (document v0.1). CR-04's trigger was stated as "Borsh in the vProgs runtime." The Operator challenged this: if vProgs is not the target (Decision 1), why cite it here?
Correction (document v0.2). The rule rests on variant-tagged serialization in general — any format that writes a discriminant marker (Borsh enum index, bincode tag, serde tagged forms, protobuf oneof). Borsh in the based-app runtime is only the immediate instance. Clarified that the kaspanet/vprogs repository is forward-named but serves today's standalone based-app model, which removed the apparent contradiction between CR-04 and CR-06.
Why it matters. The existing v0.5 rule ("no type identifiers in serialized state") was prose a reviewer couldn't mechanically check. CR-04 (REQ-069) makes it checkable: one byte-identical struct for all egg types, no variant-tagged construct at any serialization boundary, type resolved only through key derivation. A single discriminant byte would collapse the Part I indistinguishability argument.
Position reached. The build is not ready to start; the spec is close.
What may proceed now. Specify (cut v0.6 from the CRs); prototype on testnet 12 (egg lifecycle skeleton, first ACL proof circuit in RISC Zero) as throwaway-friendly exploration. Full Phase 3 build is gated behind Parts II–IV and mainnet activation.
The question. What may the Part II interrogating adversary observe? The Operator first chose "match Part I" — a sound instinct that turned out to be impossible to take literally, because Part I's adversary is passive and Part II's is active; four observation channels (response content, timing, errors, on-chain side effects) exist only in the active setting. The Operator then deferred the choice.
Decision (Claude, with Operator's deferral). The strong model: all four channels. Rationale: a proof omitting a real channel moves discovery from proof-time to audit-time; the decoy-cost optimization (REQ-072) is only safe if decoys cast no on-chain shadow, which must be proven, not assumed; and the strong model is the faithful reading of Part I's spirit (strongest adversary for which the property holds). Marked reversible: if an assumption proves uncommittable, drop to a scoped weaker version stated plainly.
Payoff. The strong model surfaced REQ-076 (uniform status signalling) — a genuine discovery no prior CR implied — and converted REQ-072 from a cost decision into a verified security property (REQ-075).
Prior position. The v0.6 amendment (v0.1) numbered new requirements from REQ-068, based on REQ-067 being the highest ID visible in past-conversation search snippets.
Correction. Grep of the live spec on the Mac Mini (June 10): both V1 and V2 top out at REQ-068, 68 contiguous IDs. The amendment's first row collided with an existing requirement. All rows renumbered from REQ-069 (amendment v0.2).
Lesson recorded. Past-conversation snippets are not the source of truth for the live spec; the live file (and Forge's database copy) is. The CC pre-repair brief pattern — verify against the live system before merging — exists because of exactly this failure mode.
Prior position. Amendment v0.2 cited dependencies by remembered meaning: REQ-028 as "decrypt-and-discard," REQ-030 as "rekeying," REQ-010 as "the schema."
Correction (CC report, June 11, verbatim rows). REQ-028 is decoy ordering (pseudorandom permutation); decrypt-and-discard is REQ-025. REQ-030 is chain-seed secrecy; rekeying is REQ-016. REQ-010 is schema forward-compatibility; the schema definition is REQ-001. Amendment v0.3 corrected all affected dependency columns, and REQ-070 gained a clause making forward-compatible extension fields type-uniform (a real interaction the wrong citation had hidden).
Lesson recorded. Citing requirements by remembered meaning is the same failure mode as Decision 9 in a different coat. The brief demanded verbatim rows for this reason; it caught three errors.
Prior position. The amendment planned to supersede vProgs-framed requirements (zero estimate, retain for history).
Correction. The live-file vProg grep (22 REQ rows, plus prose/glossary/tech-stack mentions) showed "vProg" is used as terminology throughout, but no requirement's meaning dies with the vProgs deferral. Supersession was the wrong instrument; amendment v0.3 specifies a terminology pass (vProg → based-app runtime / Ova application, thresholds untouched) plus a refresh of the five stale amendment flags (REQ-048, 050, 059, 060, 061 — May 5 date, pre-KIP-16 wording).
Also learned. The Ova spec passed Forge induction (review #2, verdict "ready," March 9, 2026) — a fact not previously in the working record. The V3 merge will trigger re-induction.
| Artifact | Version | Role | |----------|---------|------| | OVA_V0_6_CANDIDATE_REQUIREMENTS | v0.1 → v0.2 | Six CRs in plain English; v0.2 folded the CR-04 correction | | OVA_PROTOCOL_SPEC_V0_6_AMENDMENT | v0.1 → v0.2 → v0.3 | v0.2: renumbered post-collision, Part II folded in, meta-REQs demoted to prose; v0.3: dependency corrections, Cycle 8 placement, reword-not-supersede, merge procedure | | OVA_VERIFICATION_PART_II_BEHAVIORAL | v0.1 → v0.2 | Part II proof; v0.2 renumbered to final namespace (REQ-074–076) | | ova-candidate-seed | v0.1 → v0.2 | Foundation document; v0.2 resolved the V1-operator commitment | | OVA Discovery Record (this document) | v0.1 → v0.2 | Session trajectory | | CC_BRIEF_OVA_V0_6_PREREPAIR | v0.1 | Live-system verification brief; caught Decisions 9–11's corrections |
ova-record location the Operator establishes.DUNIN7 · Ova Protocol OVA Discovery Record — v0.2 — June 11, 2026