OVA — Project Handoff — v0.1

Version. 0.1 Date. 2026-06-22 Author. Marvin Percival (DUNIN7 Operator) with Claude.ai. Purpose. Cold-start orientation for the OVA project. Written to be read by a fresh OVA chat with empty project memory. It carries inline — because a fresh chat may not reach loomworks-record (Cloudflare Access) — what OVA is, its as-specified state, what this originating session settled, the corrections preserved, the open items, and the boundary with the products that consume OVA. Read this first. Status. Founding orientation. Markdown primary (technical/internal). Self-contained by design. Travels with. ova-candidate-seed-v0_1.md (the seed this handoff delivers — read it second).

Plain-language summary

OVA is a standalone DUNIN7 product: a topology-hiding predicate authorizer over the Kaspa blockDAG. It answers one question about an access request — granted or rejected — and reveals nothing else: not who asked, not what they're permitted, not which rule they satisfied, not how the organisation is structured. Its differentiator is that the who-can-reach-what structure stays hidden even from an observer who can read everything on-chain. This session produced OVA's first seed (there was none before), fixed OVA's identity as the predicate authorizer its V3 spec actually describes, retired an earlier "agent identity and authorization" mislabel, and built an explicit fence around what OVA is not — so the products that consume OVA can't slowly stretch it into something leaky. The seed is ready for Operator review and induction; several spec-level items remain open (verifier choice, verification-program completion, mainnet timing) and are named below.

Part 1 — The OVA seed (what OVA is committed to)

The commitment frame. When proposed work conflicts with what this names, raise it before proceeding. The authoritative statement is ova-candidate-seed-v0_1.md; this part summarises it.

What OVA is

A standalone topology-hiding predicate authorizer over Kaspa. The unit is the egg: an on-chain object carrying live authorization state (ACL conditions, state payload, chain linkage — encrypted under the egg key), living among indistinguishable decoys. A requester proves in zero knowledge that their credential set satisfies at least one of an egg's ACL conditions; interrogation returns granted / rejected and nothing more. The ACL conditions and egg type are never exposed in the return value (REQ-013).

What OVA does — and the boundary it draws

OVA decides: granted or rejected. It does not carry, store, protect, or release the data it authorizes — interrogation withholds the payload (REQ-013). It does not know or branch on whether a requester is human or autonomous — it is principal-nature-blind (REQ-071). It does not prove non-inclusion over an open set — its freshness/replay model is nullifier inclusion (REQ-044) plus on-chain state-commitment equality (REQ-020), and its condition set is closed to its own ACL model (role / attribute / time — REQ-042).

The differentiator (the spine)

The who-can-reach-what structure stays opaque to a full-read / assume-breach adversary. This single property separates OVA from every conventional access-control system, all of which assume a trusted observer of the policy. The topology-hiding rests on unlinkability — associated eggs must stay unlinkable in chain lineage, timing, and observable activity. The Toccata leakage surfaces (covenant lineage KIP-20; partitioned sequencing KIP-21) are named hazards this property exists to defeat.

Dependency direction (confirmed)

OVA is standalone over Kaspa. It depends only on Kaspa Layer 1 and on FORAY (audit, consumed one-way). It depends on no identity layer — it does not reach back to Stele or any principal-identity system. Consumers (GRANTHA, Tessera, future applications) integrate OVA at the application layer; OVA is not part of any of them.

What OVA is NOT (the fence — load-bearing)

This is the part that protects OVA from well-intentioned expansion by its consumers. OVA's value is its smallness and its blindness; both are lost by accretion.

• Not a data-object protector. It does not carry a value and release it on proof. Protecting a value at rest (a secret, a key, an SSN) and revealing it only to an entitled party is a separate mechanism with its own seed, built beside OVA. Such a mechanism may consume OVA's unlinkability the way any consumer does — it is not OVA.
• Not an identity system. Principal-nature-blind by commitment; depends on no identity layer.
• Not a non-inclusion prover over open sets. Its set is closed to its ACL model; its freshness is inclusion-and-equality, not absence-proof. Statements of the form "prove X is not in hidden set S" (non-membership, independence-of-roots, personhood-distinctness) are not OVA capabilities and must not be assumed of it.
• Not part of any consuming product.

Future-primitive note (not a commitment). Should a data-object-protection mechanism or an absence-proof capability prove genuinely needed, each is a separate product with its own seed — never a stretch of OVA.

Part 2 — As-specified state (the floor; confirmed against the V3 spec)

Grounded by CC against the live artifacts this session (read-only). The OVA spec lives at ~/Downloads/OVA_PROTOCOL_SPEC_V3.md; the record subtree loomworks-record/protocols/ova/README.md is still "awaiting content" (spec not yet staged to the record).

• Spec version. V3, Toccata-aligned, v0.6 amendment (v0.3) applied. Header: "Induction-ready … submitted for Forge re-induction." 70 of 76 requirements induction-ready; 6 requirements behind 3 open flags (below).
• Implementation model. Standalone based-ZK application on Kaspa (off-chain execution, ordering inherited from Layer 1, compact proofs verified on-chain). Not vProgs — vProgs is a later roadmap stage (~2027) OVA never needed. The kaspanet/vprogs repo is forward-named but serves today's based-app model.
• The egg. Carries ACL conditions + state payload + chain linkage, encrypted under the egg key (Glossary). Real eggs live among indistinguishable decoys (nest eggs).
• Provisioning / interrogation. Provision accepts egg_id + ACL payload, encrypts, writes state_ciphertext (REQ-012). Interrogation returns granted/rejected, withholds ACL and type (REQ-013).
• ZK condition model. Three fixed ACL condition types: role membership, attribute value, time range (REQ-042). Proves the credential set satisfies at least one condition without revealing which (REQ-041). Private inputs: requester credential set + egg ACL; public: state commitment + nullifier.
• Freshness / replay. Nullifier (32-byte, derived from egg ID + requester pubkey + block height) stored on-chain after a successful grant; resubmission of the same nullifier is rejected (REQ-044). Stale-state proofs (one write behind) rejected by state-commitment equality (REQ-020).
• Revocation. Publishes a nullification commitment, transitions egg to revoked state (REQ-014). (Inclusion of a commitment — not a non-revocation/absence proof.)
• Serialization indistinguishability. One byte-identical struct for all egg types; no variant-tagged construct at any serialization boundary; type resolved only through key derivation (REQ-069).
• Decoy cost. Decoy rejection and routine nest maintenance stay outside the proven state transition unless a verification result requires inclusion (REQ-072).
• Adversary model. Full-read: zero visibility of egg type, authorized content, or requester identity (REQ-071). Strong four-channel observation model for behavioral proofs (response content, timing, errors, on-chain side effects).
• Proof system. Bind to neither verifier; abstract proof interface, per-deployment choice recorded (CR-05). Groth16 confirmed for mainnet (trusted setup per circuit); RISC Zero STARK transparent, live on TN12, mainnet undecided.
• Dependencies. Kaspa L1 + FORAY (audit, v4.1, one-way). No identity dependency. Tessera named only as an excluded consumer.

Part 3 — What this session settled (the decisions delivered into the project)

1. OVA has a seed now — its first. CC confirmed no ova-candidate-seed-* existed anywhere prior. ova-candidate-seed-v0_1.md is genuinely v0.1, not a restart over a higher version.
2. The agent label is retired. OVA was previously framed as "AI agent identity and authorization." Grounding established the V3 spec contains zero agent vocabulary, no principal-type notion, no identity machinery. The seed fixes OVA as the predicate authorizer the spec describes. The prior framing was a label that never matched the build. (Recorded as a correction in the seed's What the work is, not silently dropped.)
3. OVA is principal-nature-blind, confirmed against the spec (REQ-071, scope). Not an assumption — a verified-adjacent commitment.
4. Dependency arrow confirmed. OVA → {Kaspa L1, FORAY}. No identity dependency. Consistent with the cross-product spine (a substrate depends on nothing below it; identity must not depend on OVA, and OVA does not reach back to identity).
5. Data-object protection is out of scope — a separate mechanism. The seed fences it explicitly. (Origin below, Part 4.)
6. Two consumer-wanted methods are refused as not-OVA: value-at-endpoint (payload release on proof) and non-inclusion over an open commitment set. Both recorded with reasons in the seed's fence.

Part 4 — Corrections preserved (what was considered and ruled out, and why)

This handoff originated in a cross-product scoping session (held in the Stele project) about agent identity and authorization across Stele, OVA, and GRANTHA. That investigation is not OVA's work — but it pressure-tested OVA hard and produced the boundary findings the seed's fence encodes. Preserved here so the OVA project does not re-litigate them or get tempted to annex them.

• "Value-at-endpoint" (an OVA egg carrying a value and releasing it to a prover). Considered as a possible OVA capability; the originating chat reasoned on it for some time. Ruled out: not in the V3 spec (interrogation withholds the payload, REQ-013), and against OVA's grain — a yes/no authorizer that also releases the underlying value becomes a single point that can leak both the decision and the secret. → Separate mechanism, if ever.
• "Non-inclusion over a committed hidden set." A cross-product construction tried to reduce four problems (revocation freshness, independence-of-roots, personhood-distinctness, biometric-uniqueness) to one primitive — non-inclusion over hidden state — and assumed OVA provided it. Ruled out: OVA does the opposite shape (nullifier inclusion + state-commitment equality), and its set is closed to the ACL model. The reduction was shape-matching across an incompatible set type. → Not an OVA capability; do not assume it.
• The SS#-dispersal idea (protect a data object by splitting it into pieces dispersed unlinkably among millions of eggs). A genuinely sound intuition — its security is the absence of linkage plus the absence of a confirmation oracle (an attacker can't tell which eggs associate, nor confirm a reconstruction). But this is data-object protection, a different job from authorization. It would consume OVA's intrinsic unlinkability; it is not an OVA feature. → This is the concrete origin of the seed's "separate mechanism" fence (Part 3 item 5).
• The mislabel's root cause. The "agent identity" drift was possible precisely because OVA had no seed to hold the line. The seed closes that vacuum.

(The agent-side construction — Stele's principal-nature property, independence-of-roots, personhood/biometric uniqueness — remains live work, but it belongs to the cross-product thread and the consuming products' seeds, not to OVA. It appears here only as the boundary that produced OVA's fence.)

Part 5 — Open items (carried forward; not resolved by the seed)

In rough priority:

1. The verifier decision — STARK vs Groth16. Inherited and unresolved. Rigid policy favours Groth16 (trusted setup per circuit); expressive/iterating policy favours RISC Zero STARK (transparent, no ceremony) — but STARK's mainnet status is undecided. The seed commits to the abstract-interface posture (bind to neither; record per deployment), deliberately leaving the choice to deployment time. Practical plan from the discovery record: prototype on RISC Zero now; if STARK reaches mainnet, use it; else wrap STARK in a single fixed Groth16 circuit (one ceremony, once, for a wrapper that never changes).
2. Open spec flags (6 reqs, 3 flags): [ZK-OPCODE] REQ-048/050/059/061 (Groth16-confirmed / STARK-undecided wording, placeholder latencies); [SCOPEGAS] REQ-060; [SCALE] REQ-060 (1,000,000-egg population threshold, unresolved). Pending post-mainnet data.
3. Mainnet activation (~2026-06-30). Hardcoded in rusty-kaspa v2.0.0 at DAA score 474,165,565. The V3 spec carries no post-activation confirmation; pricing (ScopeGas benchmarks) and the STARK decision wait on it. This handoff predates activation.
4. Verification program — 1 of 7 complete. Part I (state-at-rest / IND-CPA) complete. Part II (behavioral indistinguishability) in draft (v0.2, 2026-06-11). Parts III–VII not present. The seed names the full seven-part program as the success measure — confirm at induction whether that's the intended bar.
5. Re-induction. The V3 merge triggers Forge re-induction (the spec previously passed induction review #2, "ready," 2026-03-09).
6. Records home. The spec lives only in ~/Downloads/; protocols/ova/README.md is "awaiting content." Establishing OVA's canonical record home (and whether an ova-record exists separate from loomworks-record) is an early OVA-project decision. The seed should be staged (see action path).

Part 6 — The boundary with the consuming products

OVA is consumed by GRANTHA (as its Policy Decision Point — grants serialised as OVA eggs, proven in-circuit), by Tessera (application-layer, explicitly not part of OVA), and by future applications. The dependency direction is inward: consumers call OVA; OVA never calls a consumer, and never reaches up into identity.

The fence is the boundary convention. A consumer asking OVA to grow a capability (carry a value, prove an absence, learn a principal's nature) is asking OVA to breach its own spine. The seed's What OVA is not section exists to refuse these by default. When a consumer's need is real, the answer is a separate mechanism with its own seed that consumes OVA's intrinsic properties — not a new OVA feature. GRANTHA in particular will press on this (it consumes all of OVA, Stele, FORAY); hold the line the same way for every consumer.

First-read rotation for a new OVA chat

1. This handoff (carries the as-specified state, the settled decisions, the corrections, the open items, the boundary).
2. ova-candidate-seed-v0_1.md (the authoritative commitment frame — review for induction).
3. OVA_PROTOCOL_SPEC_V3.md (the detailed as-specified mechanism; from ~/Downloads/ until staged to the record).
4. OVA_DISCOVERY_RECORD-v0_2.md (the v0.6-amendment trajectory — Decisions 1–11, the source of the open items).

When in doubt about an as-specified fact, do not guess — have CC ground it against the live spec.

Disciplines (carry into every OVA chat)

• Corrections-preserved documentation. Name the prior position, the finding, the resolution. (This handoff and the seed are built that way.)
• Inspect/ground-first. Ground against the live spec before architectural claims; past-conversation snippets are not the source of truth for the live file (the REQ-068 collision and the dependency-citation errors in the discovery record are the standing lessons).
• Verify before propagating. Re-check a fact carried from a screenshot or earlier turn against current state; name its source.
• Two-role discipline, fresh chat per role. Claude.ai = scoping, seeds, methodology, handoffs. CC on DUNIN7-M4 = execution, retrieval, builds, grounding. CC retrieves what Claude.ai cannot reach.
• Versioned artifacts. name-v0_1.ext, underscores; version in filename and at the top of the document; filename and title agree; never restart at v0.1 over a higher existing version.
• Skill-first for deliverables. candidate-seed for seed work; forge-spec for REQ-NNN spec content.

Action path (what the Operator does next)

The seed and this handoff are produced in the Stele-project chat's outputs. Their canonical home is the record, which Claude.ai cannot reach — CC stages.

Paste to CC on DUNIN7-M4:

Stage the OVA seed and handoff to the record. Halt before push.

1. Operator will place these in ~/Downloads/ from Claude.ai outputs:
     ova-candidate-seed-v0_1.md
     ova-project-handoff-v0_1.md
2. Stage both to the record:
     loomworks-record/candidate-seeds/ova/ova-candidate-seed-v0_1.md
     loomworks-record/candidate-seeds/ova/ova-project-handoff-v0_1.md
   (create candidate-seeds/ova/ if it does not exist)
3. Explicit-path add only — git add [each exact path]. Never -A.
4. Commit: "Add OVA candidate seed v0.1 + project handoff v0.1 (first seed; agent label retired)"
5. Halt before push. Report staged state for Operator confirmation.

Do not touch protocols/ova/README.md ("awaiting content") in this commit — separate thread.

Then, in the OVA project: start a fresh chat, upload this handoff and the seed, and the project is oriented.

DUNIN7 · Done In Seven LLC · Miami, Florida OVA — Project Handoff — v0.1 — 2026-06-22 Travels with: ova-candidate-seed-v0_1.md