OVA — candidate seed v0.1

Version. 0.1 Date. 2026-06-22 Status. Candidate seed. Ready for Operator review and induction.

What the work is

OVA is a standalone DUNIN7 product: a topology-hiding predicate authorizer over the Kaspa blockDAG. It answers exactly one question about an access request — granted or rejected — and answers it without revealing who is asking, what they are permitted, which condition was satisfied, or how the governed system is structured.

The unit is the egg: an on-chain object carrying live authorization state (its ACL conditions, state payload, and 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; the interrogation returns the boolean result and nothing more. The egg's ACL conditions and type are never exposed in the return value (REQ-013).

OVA's committed differentiator is that the who-can-reach-what structure stays opaque even to an observer who can read everything — the assume-breach / full-read adversary model. This is the single property that separates OVA from conventional access-control systems, all of which assume a trusted observer of the policy.

Identity correction (preserved, not smoothed). OVA was previously framed as a product for "AI agent identity and authorization." That framing is retired. Grounding against the V3 spec established that OVA contains no agent vocabulary, no notion of principal type, and no identity machinery — it proves predicates over credential sets while remaining deliberately blind to who or what holds them. The prior framing was a label that never matched the built mechanism. The seed fixes OVA as the predicate authorizer the spec describes; "agent identity" is not OVA's work and never was.

Who consumes the work

Consuming applications that need provable, topology-hiding authorization decisions, integrating OVA at the application layer in their own codebases (the based-ZK-application model — off-chain execution, ordering inherited from Kaspa Layer 1, compact proofs verified on-chain).

Named and anticipated consumers:

• GRANTHA — the access-grant model; consumes OVA as its Policy Decision Point, serialising grants as OVA eggs and proving grant satisfaction in-circuit.
• Tessera — consumes OVA at the application layer (named in the spec as a consumer; explicitly not part of OVA).
• Any future application requiring yes/no authorization without a readable permission list or a stealable map of the organisation.

OVA does not distinguish its consumers by the nature of the principals they authorize. A human-holding consumer and an agent-holding consumer produce identical OVA proofs.

Voice

Neutral / decisional. OVA's posture toward its consumers is to return an authorization result — granted or rejected — and nothing else. It does not advise, explain, or expose its reasoning; the deliberate withholding of which condition was satisfied (REQ-041) is constitutive of the product. OVA is a decision surface, not an advisory or descriptive one.

Constraints

Must:

• Return only a boolean authorization result (granted/rejected); the interrogation operation must not expose the egg's ACL conditions or type (REQ-013).
• Keep egg type, authorized content, and requester identity invisible to a full-read adversary (REQ-071); prove condition satisfaction without revealing which condition is satisfied (REQ-041).
• Keep associated eggs unlinkable — in chain lineage, in timing, and in observable activity — so that an observer cannot determine which eggs belong together. This is the load-bearing property; the topology-hiding rests on it. (The Toccata leakage surfaces — covenant lineage KIP-20, partitioned sequencing KIP-21 — are named hazards this constraint exists to defeat.)
• Carry no type identifiers in serialized state: one byte-identical struct for all egg types, type resolved only through key derivation (REQ-069). A single discriminant byte collapses the indistinguishability argument.
• Remain a standalone based-ZK application over Kaspa. Depend only on Kaspa Layer 1 and on FORAY (audit, consumed one-way). Depend on no identity layer — OVA must not reach back to Stele or any principal-identity system.
• Bind to no single ZK proof system; define an abstract proof interface and record the per-deployment verifier choice with rationale (REQ-005 / CR-05).

Must not:

• Must not carry, store, protect, or release a data object. OVA decides; it does not hold and hand out the data it authorizes. A yes/no authorizer that also releases the underlying value becomes a single point that can leak both the decision and the secret. Protecting a data object at rest is a separate concern with its own mechanism, outside OVA. (See "What OVA is not.")
• Must not know or branch on principal nature. OVA reads nothing about whether a requester is human or autonomous; it proves over a credential set. Adding principal-type awareness would create the very leak the topology-hiding exists to prevent.
• Must not prove non-inclusion / non-membership over an open commitment set. OVA's freshness and replay model is nullifier inclusion (REQ-044) plus on-chain state-commitment equality (REQ-020); its set is closed to its own ACL condition model (role / attribute / time — REQ-042). An open arbitrary-commitment set with absence proofs is a different cryptographic system and is not OVA. (See "What OVA is not.")
• Must not make the cover traffic that protects the system also the thing that bankrupts it: decoy rejection and routine nest maintenance stay outside the proven state transition unless a formal verification result requires inclusion (REQ-072).

Success conditions

OVA is complete-and-good when:

• A consuming application can provision an egg with an ACL payload, and a requester can interrogate it and receive a correct granted / rejected result, with the ACL conditions and type never exposed.
• The topology-hiding property holds against a full-read adversary across all four observation channels (response content, timing, errors, on-chain side effects) — proven, not asserted. The verification program is the success measure: Part I (state-at-rest / IND-CPA) complete; Parts II–VII (behavioral indistinguishability and beyond) the remaining bar.
• Eggs associated to one authorization context remain unlinkable in lineage, timing, and activity on live Kaspa mainnet.
• The proof-system choice is recorded per deployment behind a stable abstract interface, so neither a STARK-mainnet decision nor a Groth16 fallback forces a spec change.

This is continuously-maintained correctness: the maintained property is that no spec change, platform change, or consumer integration reintroduces a linkage, a type identifier, or a content/identity leak that the indistinguishability argument forbids.

Initial contributors and agents

• Operator / governing authority: Marvin Percival (DUNIN7).
• Scoping and specification: Claude.ai (scoping, change requests, methodology, handoffs).
• Execution, retrieval, builds: Claude Code (CC) on DUNIN7-M4, against live trees.
• Verification agent (Forge): OVA's spec passed Forge induction (review #2, "ready," 2026-03-09); the V3 merge triggers re-induction. Forge SAE is the induction/verification surface for the spec.

No autonomous agent holds authority over OVA's commitments; the roster names humans-and-tools at creation and evolves through the engagement.

What OVA is not (the fence)

This section exists to protect OVA from well-intentioned expansion by the products that consume it. A seed that only says what a product does leaves the door open for consumers to annex it; OVA's value is its smallness and its blindness, and both are lost by accretion.

• OVA is not a data-object protector. It does not carry a value and release it on proof. If a value (a secret, a key, a protected datum such as an SSN) must be protected at rest and revealed only to an entitled party, that is a separate mechanism with its own seed, built beside OVA — not a feature bolted onto OVA. Such a mechanism may consume OVA's intrinsic unlinkability the way any consumer does; it is not OVA.
• OVA is not an identity system. It is principal-nature-blind by commitment and depends on no identity layer. It does not know human from agent.
• OVA is 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. Properties of the form "prove X is not in the hidden set S" (non-membership, independence-of-roots, personhood-distinctness) are not OVA capabilities and must not be assumed of it.
• OVA is not part of any consuming product. GRANTHA, Tessera, and any future consumer integrate OVA; OVA is standalone.

Future-primitive note (not a commitment). Should a data-object-protection mechanism or an absence-proof capability prove genuinely needed by the broader system, each is a separate product with its own seed, scoped and justified on its own terms — never a stretch of OVA. This note records the boundary without predicting OVA will ever cross it.

Authorisation

Authorized by Marvin Percival, DUNIN7 Operator, 2026-06-22: OVA is a standalone DUNIN7 product — a topology-hiding predicate authorizer over Kaspa. It is not part of any consuming product. The "agent identity and authorization" framing is retired. Data-object protection is out of scope and belongs to a separate mechanism.

Drafter's notes for your review

What was provided vs. drawn from source.

• What the work is, Voice, Constraints, What OVA is not, Authorisation — drawn from this session's settled decisions (drop the agent label; OVA is the yes/no predicate authorizer; data-object protection is a separate mechanism; the explicit fence) plus the CC-grounded V3 spec evidence (REQ-012/013/041/042/044/020/069/071/072, scope and glossary lines).
• Who consumes the work — drawn from the GRANTHA handoff (GRANTHA consumes OVA as PDP) and the V3 spec (Tessera named as consumer, explicitly excluded from OVA).
• Success conditions — drawn from the OVA discovery record (v0.2) Decisions 7 and 8 (specify-yes/build-no; the strong four-channel observation model; the seven-part verification program) and the maturity grounding.
• Initial contributors and agents — drawn from the two-role discipline and the spec's Forge induction history.

Preserved corrections (Discovery-record posture).

• The "agent identity and authorization" → "topology-hiding predicate authorizer" reframing is recorded as a retired prior position, not silently replaced, in What the work is.
• The construction's two wanted-but-refused methods (value-at-endpoint; non-inclusion over open sets) are recorded as explicit refusals in What OVA is not, with their reasons — so the boundary is principled and re-findable, not just absent.

Consistency checks applied.

• Consumer-render alignment: no render-types declared (OVA is a mechanism/protocol, not an artifact-producing engagement), so no consumer-render mismatch. Declared render-types section omitted as not-applicable; flag if you want it present and empty.
• Constraint-voice tension: voice is neutral/decisional and constraints reinforce withholding — consistent, no tension.
• Success-scope: success conditions reference only the authorization mechanism and its verification, which the work commits to — no scope mismatch.
• Version-filename agreement: filename, title, header all v0.1 / v0_1. ✓

Flagged for your decision (not resolved by the skill):

1. No prior OVA seed existed. CC confirmed there is no ova-candidate-seed-* anywhere and the record subtree is "awaiting content." This is genuinely v0.1 — first seed for OVA. (Noting it so the version isn't mistaken for a restart over a higher existing version.)
2. Open spec items inherited, not resolved by the seed: the STARK-vs-Groth16 mainnet decision (REQ-048/050/059/061, [ZK-OPCODE]); the [SCOPEGAS] and [SCALE] flags (REQ-060); mainnet activation (~2026-06-30) post-dating this draft. The seed commits to the abstract-interface posture (bind to neither verifier) rather than to a specific verifier — confirm that's the right level for a seed.
3. Verification maturity: Part I complete, Part II draft, Parts III–VII not present. Success conditions name the full program as the bar; confirm you want the seed to hold OVA to all seven parts as its success measure rather than a reduced set.
4. FORAY dependency version: the spec cites FORAY "consumed as an external dependency at v4.1." Left as-is; flag if the version reference should be generalised.

What was deliberately NOT included.

• The cross-product agent construction (Stele nature property, independence-of-roots, personhood, biometric uniqueness, the SS#-dispersal model) is not in OVA's seed. All of it is consumer-side or separate-mechanism work; putting any of it in OVA's seed would breach the fence this seed exists to build. It belongs in the respective products' seeds or in new seeds, not here.
• Kaspa substrate version specifics (rusty-kaspa v2.0.1, Toccata, testnet 12) are left to the spec, not the seed — the seed commits to "standalone based-ZK application over Kaspa," and the spec carries the version detail.

DUNIN7 · Done In Seven LLC · Miami, Florida OVA — candidate seed — v0.1 — 2026-06-22