# BAVAI Operator Specification

**Protocol surface for batching, indexing, audit feeds, flag publication, and verification.**

*Version 1.0 — Developer Preview — May 2026*

> **Core invariant.** Per-commitment production cost is positive and scales linearly with volume up to operational constants, under a stated, adversary-favourable threat model. The architectural contribution is cost preservation and attribution: production cost paid by a holder persists as attributable scarcity across every system that recognises the commitment. See *Orange Anchor White Paper v2.3* for the full argument.

> **Status — Developer Preview.** v1.0 of this specification is published as a *Developer Preview*: the **protocol surface** — wire formats, anchor reference construction, BAVAI key/value layout, inclusion verification, flag and audit record formats — is stable and suitable for integrator review and protocol implementation. The **construction internals** referenced in §7.4 (proof_internals slot layout, full construction verification algorithm, reference test vectors) are deferred to the forthcoming Orange Anchor reference implementation. A verifier built strictly from this document supports *inclusion verification* in full; *construction verification* requires the reference implementation. This boundary is deliberate (see *Reference implementation dependency* below) and is the reason for the Developer Preview classification.

> **Verification scope at a glance.**  
> • **Inclusion verification** — fully specified by this document. A verifier can confirm against the Bitcoin chain alone that an envelope's anchor reference is committed in a specific batch.  
> • **Construction verification** — protocol surface specified here (§7.4); algorithm and test vectors live in the reference implementation. Verifiers requiring construction-quality assurance MUST either run the reference implementation against a verification package or consume an audit score from a trusted operator (§6.3).

---

## Value Proposition

Orange Anchor lets any platform attach cost-backed digital collateral to
existing accounts and verify it against the Bitcoin chain. *Cost-backed*
here means the collateral commitment represents a sunk commitment of computational and
physical resources by the holder's device — not a monetary payment. This
document specifies the protocol surface — how operators publish commitments
to the chain, what artefacts verifiers consume, and the algorithm for
verifying those artefacts — that makes the ecosystem composable. The
architecture is trustless by default and opt-in by composition: a verifier
may operate against the Bitcoin chain alone, opt in to convenience services
from one or more operators, or combine opt-ins under a policy of their own
choosing. Operator services accelerate and curate access to commitments but
cannot substitute for them.

---

## About This Document

This document specifies the protocol surfaces operator services and verifier
implementations interoperate over in the Orange Anchor ecosystem. It is the
protocol-level companion to the *Orange Anchor White Paper v2.3* §5, *BACC
v1.9* §3–§4, and the *Orange Anchor Integration Brief v2.2*.

*Scope.* The batching surfaces (§3) assume the Orange Anchor construction
as defined in BACC. The attribution index and BAVAI surfaces (§5–§8) are
construction-agnostic and may be applied to other constructions of the BACC
pattern.

The audience is implementers — operator services, verifier libraries,
platform integrators, and audit service builders. The document is structured
so each numbered claim conveys a normative or architectural property on its
own; supporting prose develops the property without changing it.

*Status.* v1.0 is a *Developer Preview* (see status callout above) accompanying the release of the white paper, BACC, integration brief, and interaction patterns specification. The specification defers byte-level construction internals to the reference implementation; the *Orange Anchor Technical Paper* (forthcoming) may, in time, provide formal security analysis and parameter calibration justification but is not required for the protocol surface to be stable. Subsequent revisions will be driven by real implementer and deployment feedback.

*Reference implementation dependency.* This specification defines the
protocol surface — what gets published, what gets verified, what
authenticates what. The internal structure of `proof_internals` slots
(§7.4), the construction verification algorithm, and reference test vectors
are specified exclusively by the reference implementation. A verifier
implementer building from this document alone cannot complete a trustless
construction verifier; the reference implementation source is authoritative
ground truth for the construction-internal layer. This boundary is
deliberate: the protocol surface is stable; the construction calibration is
iterative, and locking it in prose would couple two layers that benefit
from independent evolution.

*Conformance language.* Within normative claims, MUST, MUST NOT, SHOULD,
SHOULD NOT, and MAY are used per RFC 2119. Architectural claims that
describe properties of the protocol rather than implementer obligations do
not use these terms.

*Notation.* Byte sequences are written as hexadecimal where bytes are
specified literally and as named field references otherwise. Concatenation
is written with `‖`. `SHA256` denotes single SHA-256. `HASH160` denotes
RIPEMD160(SHA256(·)).

*How to read this document.* Operator implementers should focus on §3, §5,
§6, §9, and Appendix C.1 / C.3. Verifier and integrator implementers should
focus on §4, §7, §8, and Appendix C.2. Cryptographic and security reviewers
should focus on §3, §7, §8.4, and §10. All readers benefit from §1's framing
and Appendix D's diagram for orientation.

---

## 1. Scope and Position

**1.1 — This document specifies how operators publish to the chain and to
off-chain feeds, how operators identify themselves, what artefacts verifiers
consume, and the algorithm for verifying those artefacts.**

The construction is specified in *BACC v1.9* and, at byte level, in the
reference implementation. Integration paths for platforms are specified in
the *Orange Anchor Integration Brief v2.2*.

**1.2 — The protocol's foundational property is that verification depends
only on the Bitcoin chain and the artefacts the verifier holds; operators
are convenience services, never trust dependencies.**

This property is load-bearing for everything that follows. Every operator
failure mode (offline, slow, malicious, misconfigured) is bounded to service
quality, never to proof validity. Every opt-in described in §7 preserves the
verifier's ability to fall back to the chain alone. A reader encountering
any later requirement should interpret it under this constraint: the
protocol surface specified here cannot place trust in any party other than
the Bitcoin chain itself.

**1.3 — The specification covers four operator surfaces — batching,
indexing, audit feeds, flag publication — and the verification surface that
consumes their outputs.**

**1.4 — The specification is an open practice: any party may operate any
service; no operator is privileged; no licenses or delegations are
required.**

Operator reputation accumulates through the verifier feeds that consume
operator outputs, not through the protocol.

**1.5 — Bitcoin anchors all commitments without intermediation; operator
services accelerate and curate access to those commitments but cannot
substitute for them.**

This is what makes opt-in composition (§7.1.3) safe at every level the
verifier chooses: even a verifier consuming every operator output at face
value retains the Bitcoin chain as the ultimate authority on what was
committed and when.

---

## 2. Terminology

**2.1 — *Operator.*** A service implementing one or more of the four
protocol surfaces specified in §6.

**2.2 — *Producer.*** The holder of an Orange Anchor collateral commitment.

**2.3 — *Verifier.*** A party consuming proofs, scores, or flags to make
recognition or trust decisions.

**2.4 — *Anchor transaction.*** A Bitcoin transaction recording a commitment
relevant to one or more Orange Anchor proofs.

**2.5 — *Batch root.*** A 32-byte SHA256 Merkle root committed in a single
Bitcoin transaction that aggregates many anchor references.

**2.6 — *Batch transaction.*** The Bitcoin transaction containing the
`OP_RETURN` output that publishes a batch root.

**2.7 — *Anchor reference.*** The canonical 32-byte identifier of an Orange
Anchor proof, defined in §4.

**2.8 — *Inclusion proof.*** A Merkle authentication path demonstrating
that an anchor reference is included as a leaf under a given batch root.

**2.9 — *Portable proof envelope.*** The canonical export format carrying
the data required for on-chain inclusion verification (§7.3).

**2.10 — *Verification package.*** The canonical bundle carrying the data
required for full trustless construction verification (§7.4).

**2.11 — *Signed record.*** A signed structured record used for audit feeds,
flags, and counter-statements (§7.5).

**2.12 — *Operator short ID.*** The 6-byte truncation of `HASH160` of an
operator's public key, used as a soft attribution hint in on-chain
commitments.

**2.13 — *Portable index.*** The operator-published off-chain artefact
listing the leaves of a batch and the operator's signature over the batch
root (§6.1.4).

*Canonical terminology — envelope formats, commitment types, and
verification vocabulary — follows the* Orange Anchor Lexicon v2.7. *Where
this specification uses a term defined there, the Lexicon definition is
authoritative.*

---

## 3. Locked Design Decisions

**3.1 — The following decisions are locked at v1.0 and may be revised only
by major-version revision of this specification.**

| # | Decision | Locked value |
|---|---|---|
| 1 | On-chain commitment | `OP_RETURN` with `OAV1` namespace prefix |
| 2 | Batch magic prefix | ASCII `OAV1BAT` (7 bytes: `0x4f 0x41 0x56 0x31 0x42 0x41 0x54`) |
| 3 | Flag magic prefix | ASCII `OAV1FLG` (7 bytes: `0x4f 0x41 0x56 0x31 0x46 0x4c 0x47`) |
| 4 | Operator short ID | First 6 bytes of `HASH160(operator_pubkey)` |
| 5 | Anchor reference | `SHA256(start_anchor_txid ‖ end_anchor_txid)` |
| 6 | Signature scheme | secp256k1 Schnorr per BIP340 |
| 7 | Inclusion proof | Native Bitcoin Merkle path (double-SHA256, Bitcoin convention) |
| 8 | Wire encoding | Canonical JSON per RFC 8785 for all signed and verification artefacts |
| 9 | Hash function | SHA256 throughout; HASH160 for operator short ID derivation only |
| 10 | Flag context identifier | Per-publisher URI namespace |

**3.2 — The `OAV1BAT` and `OAV1FLG` prefixes are scanning tags, not
authenticators.**

Any party may publish an `OP_RETURN` containing the prefix. Authenticity is
established by the operator's Schnorr signature in the portable index
(§6.1.4) or by the publisher's signature on a signed record (§7.5), never
by the on-chain prefix.

**3.3 — Magic prefix rationale.** The prefix discharges one function:
filtering Orange Anchor commitments from broader `OP_RETURN` traffic. The
form `OA` (Orange Anchor), `V1` (protocol version), three-byte type
discriminator is self-documenting and version-explicit. Future protocol
versions update the version segment under §10.4.

---

## 4. Anchor Reference Canonical Form

**4.1 — The canonical anchor reference of an Orange Anchor proof is:**

```
anchor_reference = SHA256(start_anchor_txid ‖ end_anchor_txid)
```

where `start_anchor_txid` and `end_anchor_txid` are the 32-byte
little-endian Bitcoin transaction IDs of the proof's start and end anchor
transactions, concatenated in that order.

**4.2 — The anchor reference is 32 bytes and is the canonical leaf value
committed in batch Merkle trees (§6.1.2).**

**4.3 — A proof has a canonical anchor reference only after its end-anchor
transaction has been submitted; incomplete proofs are outside the
protocol's identity space.**

---

## 5. Operator Identity

**5.1 — An operator's protocol identity is a single secp256k1 BIP340 x-only
public key (32 bytes), referred to as the *operator public key*.**

**5.2 — Verifiers MUST authenticate operators against the full 32-byte
operator public key via Schnorr signature verification; the 6-byte operator
short ID is a scanning hint only and MUST NOT be used as the basis for any
trust decision.**

The operator short ID is derived as the first 6 bytes of
`HASH160(operator_pubkey)`. The 6-byte space (~280 trillion distinct
values) is collision-resistant for any plausible operator population, but
verifier implementations confirm operator identity through the full public
key on every verification path.

**5.3 — An operator MAY publish multiple keypairs and operate multiple
short IDs concurrently; verifiers consume each as a distinct operator
identity. Reputation accumulates per public key.**

**5.4 — Operator key compromise is recovered by retiring the compromised
key and publishing a new one; existing batches signed by the compromised
key remain on-chain and remain verifiable, but their operator trust must be
re-evaluated by verifiers.**

The protocol provides no mechanism for revoking past signatures.

---

## 6. The Four Operator Surfaces

### 6.1 Batching Surface

**6.1.1 — A batch operator MUST publish each batch by submitting a Bitcoin
transaction containing exactly one `OP_RETURN` output structured as
specified in §6.1.2.**

**6.1.2 — The `OP_RETURN` payload MUST be exactly 45 bytes:**

```
+----------------+--------------------+------------------+
|  magic prefix  |    batch root      | operator short ID|
|    7 bytes     |     32 bytes       |     6 bytes      |
+----------------+--------------------+------------------+
|    OAV1BAT     | SHA256 Merkle root | HASH160(opkey)   |
|                |                    |   first 6 bytes  |
+----------------+--------------------+------------------+
```

The full Bitcoin script is `OP_RETURN <push 45 bytes>` at 47 bytes
scriptPubKey, well within Bitcoin's 80-byte standard `OP_RETURN` limit.

**6.1.3 — The batch Merkle tree is constructed over anchor references as
leaves using Bitcoin's canonical Merkle construction: double-SHA256
internal nodes (`SHA256(SHA256(left ‖ right))`); odd levels duplicate the
last node before pairing.**

**6.1.4 — Batch operators MUST publish a *portable index* alongside each
batch containing the batch root, the batch transaction ID, the operator
public key, the BIP340 Schnorr signature over `batch_root ‖ batch_txid`,
the ordered leaf list, and the tree depth.**

The portable index allows third parties to independently reconstruct the
Merkle tree, verify any inclusion proof, and verify operator authorship.

**6.1.5 — Verifiers holding the portable index can reconstruct any
inclusion path from the leaf list and verify proofs without requiring
inclusion paths to be carried with each proof; verifiers without the
portable index require the proof's portable proof envelope (§7.3) for
inclusion verification.**

**6.1.6 — Batch operators MAY operate at any scale, batching cadence, or
fee-amortisation ratio; producers MAY use any operator, multiple operators,
or self-anchor.**

**6.1.7 — Batch operators MUST publish inclusion proofs to producers within
a bounded time of confirming the batch root; the bound is a deployment
parameter agreed between operator and producer, not a protocol-level
deadline.**

### 6.2 Indexing Surface

**6.2.1 — An indexing operator maintains queryable mappings between
holders, proofs, and the on-chain locations of their anchors.**

**6.2.2 — Indexing operators serve discovery; verification of any returned
proof is performed against the Bitcoin chain via the portable proof
envelope (§7.3), not against the indexer.**

**6.2.3 — Indexing operators MAY index against any combination of holder
public keys, anchor references, batch roots, batch txids, bracket
intervals, or other operator-defined keys; the protocol does not specify
the index schema.**

**6.2.4 — Indexing operators MUST NOT modify the proof transcript, anchor
references, or inclusion proofs in any way that would change verification
outcomes.**

### 6.3 Audit Feed Surface

**6.3.1 — An audit operator publishes structured analyses over proofs —
scores, coherence assessments, anomaly findings — using the common signed
record format (§7.5).**

**6.3.2 — Audit feed methodologies MUST be publicly specified at a
methodology URI of the form:**

```
methodology_uri = "https://" operator_domain "/methodology/" name "/v" version
```

Closed scoring methodologies are outside this specification's scope.

**6.3.3 — Operators MAY publish multiple audit feeds under different
methodologies and MAY revise methodologies over versioned URIs.**

**6.3.4 — Audit feed delivery transports are operator decisions; the
signed record format is normative.**

**6.3.5 — The candidate denomination unit BARU (Bitcoin-Anchored Resource
Unit), defined in the *Orange Anchor Lexicon v2.7* §5b, MAY be used
as the expression of audit feed scores; the unit is a deployment
convention, not a protocol commitment.**

### 6.4 Flag Publication Surface

**6.4.1 — A flag is a signed observation against a proof's anchor reference
asserting the holder has acted maliciously under a stated context.**

**6.4.2 — Flags MAY be published on-chain or through operator feeds; both
channels use the common signed record format (§7.5) with the same
signature scheme.**

**6.4.3 — On-chain flags are encoded as a Bitcoin transaction containing
exactly one `OP_RETURN` output with the following 71-byte payload:**

```
+----------------+--------------------+------------------+
|  magic prefix  |  anchor reference  | flag context hash|
|    7 bytes     |     32 bytes       |     32 bytes     |
+----------------+--------------------+------------------+
|    OAV1FLG     |  flagged proof's   | SHA256 of flag   |
|                |   anchor reference |  signed record   |
+----------------+--------------------+------------------+
```

**6.4.4 — Off-chain flags are published as standalone signed records
(§7.5) distributed through any operator feed or publisher channel; their
verification does not require a corresponding on-chain transaction.**

**6.4.5 — Flag context identifiers are per-publisher URIs:**

```
flag_context_uri = "https://" publisher_domain "/flag-context/" name
```

A publisher's flag context taxonomy is the publisher's own surface;
verifiers interpret each publisher's contexts under their own policy.

**6.4.5.1 — Canonical seed taxonomy (RECOMMENDED).** To support
cross-operator policy composition, publishers SHOULD use the following
canonical seed values for `name` where applicable:

```
spam | fraud | abuse | csam | coordinated_inauthentic |
policy_violation | other
```

Publishers MAY extend the taxonomy with publisher-specific names; verifiers
MAY map publisher-specific names onto the canonical seed taxonomy under
their own policy. The canonical seed is a coordination convenience, not a
protocol-level commitment.

**6.4.6 — Flags are reputationally weighted; the protocol does not assign
weight, and verifiers compose flag streams under their own weighting
policy.**

**6.4.7 — Holders MAY publish counter-statements signed with their Orange
Anchor key; counter-statements use the signed record format (§7.5) and
reference the disputed flag by the flag record's SHA256 hash.**

The protocol does not adjudicate disputes. Both flag and counter-statement
stand on the public record, signed by their respective parties.

**6.4.8 — Flag-spam handling (RECOMMENDED verifier policy).** Because
any commitment holder may publish a flag, naive equal-weight aggregation
is vulnerable to *cheap-flagging* attacks in which a low-cost commitment
floods the index with flags against a high-cost target. Verifiers SHOULD:

- Weight each flag by the **production cost** of the publishing commitment
  (proxied by burn duration, BARU score, or operator-supplied cost estimate
  per §6.3) rather than treating flags as equally weighted records.
- Apply per-publisher **rate limits** per epoch (e.g. at most *k* flags per
  publisher per anchor-reference target per 24h) when computing aggregate
  flag pressure.
- Apply a **BARU floor** below which publisher flags are ignored or
  down-weighted to zero.
- Treat self-flagging (flag publisher == flag target) as policy-invalid
  unless explicitly admitted by the verifier's policy.

These are RECOMMENDED defaults; verifiers MAY substitute alternative
policies under §6.4.6. Operators publishing flag feeds SHOULD expose the
fields necessary to apply this policy (publisher anchor reference,
publisher cost estimate or BARU score, publish timestamp).

**6.4.9 — Multi-flagger key extension.** Where the BAVAI flag-lookup key
(*BAVAI Reference v1.0* §6.4) would collide because multiple flaggers
publish against the same target anchor reference, operators MUST extend
the key with a 6-byte flagger short-id derived from the flagger's anchor
reference:

```
KEY_EXTENDED = flag_indicator (1 byte)
            || target_anchor_reference (32 bytes)
            || flagger_short_id (6 bytes)
```

where `flagger_short_id = first 6 bytes of SHA256(flagger_anchor_reference)`.
The 6-byte short-id provides a collision resistance margin sufficient for
tens of millions of distinct flaggers per target while keeping the key
short. Verifiers iterate over all extended keys sharing the
`flag_indicator || target_anchor_reference` 33-byte prefix to enumerate
all flags against a target. Operators MAY index this prefix to accelerate
the enumeration.

### 6.5 Operator Discovery (Out of Scope at v1.0)

**6.5.1 —** Operator discovery — how a verifier finds the set of operators
it may opt into — is **out of scope** for v1.0. v1.0 assumes operators are
known to verifiers out-of-band (configuration, organisational policy,
bilateral arrangement, or hard-coded defaults shipped by a verifier
library).

**6.5.2 —** A future revision of this specification may introduce a
discovery mechanism (e.g. a well-known endpoint, a published registry
signed by a known root, or a DNS-based scheme). Until then, verifier
implementations SHOULD document their default operator set and the
provenance of that set in their user-facing acceptance policy.

**6.5.3 —** Because verification by the Bitcoin chain alone is always
available (§7.1.1), no verifier is forced to discover any operator in
order to verify. Operator discovery is a convenience surface, not a
dependency.

---

## 7. Verification

### 7.1 Verification Framing

**7.1.1 — Orange Anchor verification is trustless by default. Operators
and auditors are opt-in conveniences for verifiers who want to amortise
the work or consume curated quality signals — never required, never
gating.**

A verifier holding a portable proof envelope (§7.3) and a verification
package (§7.4) can verify any proof against the Bitcoin chain alone, with
no operator or auditor participation.

**7.1.2 — Two distinct verification operations are supported.**

*Inclusion verification* answers "is this proof committed on-chain in a
specific batch?" It requires the anchor reference, the batch transaction
ID, and the Merkle inclusion path. A Merkle root is a one-way commitment;
given only the root and a leaf, a verifier cannot determine whether the
leaf is in the tree, so the inclusion path is structurally required for
verification against the chain alone.

*Construction verification* answers "is this proof's internal cryptographic
structure valid against its raw inputs?" It requires the verification
package (§7.4) and the verification algorithm specified in the reference
implementation.

A verifier may perform either operation independently or both together.

**7.1.3 — Verifiers MAY compose opt-ins flexibly: trust one operator for
batching convenience, consume audit feeds from several auditors, fall back
to trustless verification when the stakes warrant. The protocol does not
impose a verification posture.**

**7.1.4 — A common composability pattern is *multi-auditor voting*: a
verifier consumes audit scores from multiple independent auditors and
takes a median, threshold-agreement, or weighted aggregate as input to
their recognition decision. The protocol enables the pattern; it does not
specify it.**

**7.1.5 — A new auditor service bootstraps by taking the open-source
verification toolchain, adding a scoring methodology, publishing the
methodology URI per §6.3.2, and beginning to publish signed audit records
per §7.5. There is no protocol-level barrier to becoming an auditor; the
open-source baseline is what makes the auditor market open.**

### 7.2 Wire Encoding

**7.2.1 — All verification artefacts (portable proof envelope, verification
package, signed records) are encoded as canonical JSON per RFC 8785.**

JSON is chosen for transparency, debuggability, and uniformity; the
canonicalisation rules of RFC 8785 ensure hash-stability for signed
records.

**7.2.2 — Field ordering, number formatting, string escaping, and
whitespace follow RFC 8785 normatively.**

### 7.3 Portable Proof Envelope

**7.3.1 — The portable proof envelope is the canonical export format
carrying the data required for inclusion verification.**

A verifier holding an envelope and access to the Bitcoin chain can confirm
the proof is committed on-chain in a specific batch without contacting any
operator.

**7.3.2 — The portable proof envelope contains:**

| Field | Form | Definition |
|---|---|---|
| `envelope_version` | string | `"1.0"` for this specification |
| `anchor_reference` | hex string (32 bytes) | Per §4 |
| `start_anchor_txid` | hex string (32 bytes) | Bitcoin txid of start anchor |
| `end_anchor_txid` | hex string (32 bytes) | Bitcoin txid of end anchor |
| `batch_txid` | hex string (32 bytes) | Bitcoin txid of the batch transaction |
| `inclusion_proof` | array of objects | Merkle path; each entry `{direction, sibling}` per §7.3.3 |
| `operator_pubkey` | hex string (32 bytes), optional | BIP340 x-only public key of the batching operator |
| `operator_signature` | hex string (64 bytes), optional | BIP340 Schnorr signature over `batch_root ‖ batch_txid` |

**7.3.3 — Inclusion proof entries are objects of the form
`{"direction": "left"|"right", "sibling": "<hex>"}`.**

`"left"` means the sibling is the left node; `"right"` means the sibling
is the right node.

**7.3.4 — A verifier processes a portable proof envelope as follows:**

1. Fetch the Bitcoin transaction identified by `batch_txid`.
2. Confirm the transaction contains exactly one `OP_RETURN` output with a
   payload of exactly 45 bytes beginning with `OAV1BAT`.
3. Extract the 32-byte batch root from bytes 7–38.
4. Apply the inclusion proof: starting with `anchor_reference`, for each
   entry, if `direction = "left"` compute
   `SHA256(SHA256(sibling ‖ current))`; if `direction = "right"` compute
   `SHA256(SHA256(current ‖ sibling))`. After processing all entries, the
   result MUST equal the batch root.
5. (Optional) If the optional operator fields are present, verify the
   Schnorr signature against `batch_root ‖ batch_txid` and confirm
   `HASH160(operator_pubkey)[0..6]` matches the on-chain operator short
   ID.

If steps 1–4 succeed, the proof is committed on-chain. Step 5 attributes
the batch to a specific operator.

### 7.4 Verification Package

**7.4.1 — The verification package is the canonical bundle carrying the
data required for full trustless construction verification.**

A verifier holding a verification package and access to the Bitcoin chain
can confirm the proof's internal cryptographic structure is valid against
its raw inputs, without operator or auditor participation.

**7.4.2 — The verification package wraps a portable proof envelope (§7.3)
and adds a `proof_internals` slot:**

```json
{
  "package_version": "1.0",
  "portable_proof_envelope": { ... },
  "proof_internals": {
    "manifest": { ... },
    "vdf_chain": { ... },
    "memory_hard_checkpoints": { ... },
    "block_hash_injections": [ ... ],
    "channel_data": { ... },
    "thermal_power_telemetry": { ... },
    "final_transcript": { ... }
  }
}
```

**7.4.3 — The reference implementation is the complete and authoritative
specification for all `proof_internals` slot contents and verification
logic at MVP.**

The slot names enumerated in §7.4.2 are the protocol-level commitments;
their internal structure, exact JSON shape, field definitions, encodings,
and the verification algorithm that consumes them are specified by the
reference implementation source code. Implementations conform by matching
reference implementation behaviour. Future revisions of this specification
may include detailed wire-level slot specification if implementer
experience indicates a need.

**7.4.4 — A verifier processes a verification package as follows:**

1. Verify the embedded portable proof envelope per §7.3.4.
2. Run the construction verification algorithm provided by the reference
   implementation against the `proof_internals` data.
3. The verification result is the conjunction of the two outcomes.

**7.4.5 — Verification packages MAY be distributed by any channel:
directly from the holder, from a public registry, via Nostr or similar
gossip transport, or hosted by an operator. The protocol specifies what
the package is and how it is verified, not how it is delivered.**

### 7.5 Signed Records

**7.5.1 — Audit feed records, off-chain flags, and counter-statements all
use the common signed record format specified in this section.**

**7.5.2 — A signed record is a canonical JSON object containing:**

| Field | Form | Definition |
|---|---|---|
| `record_version` | string | `"1.0"` for this specification |
| `record_type` | string | `"audit"`, `"flag"`, or `"counter_statement"` |
| `publisher_pubkey` | hex string (32 bytes) | BIP340 x-only public key |
| `subject_anchor_reference` | hex string (32 bytes) | Anchor reference of the proof being assessed, flagged, or whose flag is being disputed |
| `context_uri` | string | Methodology URI for `audit`; flag context URI for `flag`; SHA256 hex of disputed flag record for `counter_statement` |
| `body` | object | Record-type-specific payload (per §7.5.3) |
| `signature` | hex string (64 bytes) | BIP340 Schnorr signature over `SHA256(canonical_json(record_without_signature))` |

**7.5.3 — Record body fields:**

- **audit:** `{ "score": number, "methodology_version": string, "supplementary": object (optional) }`
- **flag:** `{ "observed_at": ISO8601 string, "rationale": string, "evidence_refs": array (optional) }`
- **counter_statement:** `{ "disputed_flag_hash": hex string, "response": string }`

**7.5.4 — A verifier validating a signed record:**

1. Removes the `signature` field and computes the canonical JSON encoding
   of the remainder per RFC 8785.
2. Computes SHA256 of that encoding.
3. Verifies the BIP340 Schnorr signature against the SHA256 hash and the
   `publisher_pubkey`.
4. Confirms `record_version` and `record_type` are recognised.
5. For counter-statements, confirms the disputed flag hash references a
   flag the verifier is aware of (or treats the counter-statement as
   referring to an unknown flag).

### 7.6 Worked Examples

**7.6.1 — Inclusion verification (envelope-only).**

A platform receives a portable proof envelope from a user binding their
proof to a platform account. The platform fetches the batch transaction at
`batch_txid`, confirms the `OP_RETURN` payload begins with `OAV1BAT` and
extracts the 32-byte batch root, walks the inclusion proof from
`anchor_reference` upward to confirm it equals the batch root, and records
the binding on the user's account. The platform required no operator
service.

**7.6.2 — Full trustless verification (envelope + package).**

A high-stakes verifier requires construction-level confidence and refuses
to trust any operator. The verifier obtains a verification package from
the holder, performs inclusion verification per §7.6.1 using the embedded
envelope, and runs the open-source construction verification tool against
the `proof_internals` data. The verifier accepts the proof only if both
succeed. The verifier required no operator service.

**7.6.3 — Operator opt-in (portable index).**

A verifier subscribed to an operator's portable index wishes to verify a
proof referenced by anchor reference alone. The verifier looks up the
anchor reference in the operator's leaf list, reconstructs the inclusion
path per §6.1.3, confirms the reconstructed root matches the batch root
and appears on-chain at the recorded `batch_txid`, and verifies the
operator's BIP340 signature over `batch_root ‖ batch_txid`. The verifier
traded operator subscription cost for envelope-distribution cost.

**7.6.4 — Multi-auditor composition.**

A platform consumes audit scores from three independent auditors A, B,
and C operating under different methodologies. For a candidate proof the
platform receives:

| Auditor | Methodology | Score (BARU) |
|---|---|---|
| A | Coherence-focused | 720 |
| B | Bracket-and-density | 700 |
| C | Channel-anomaly | 1,100 |

The platform applies a composition policy of its own choosing — for
example, taking the median (720 BARU) to bound any single auditor's
influence to one-third regardless of reputation; applying reputation
weights for a weighted average; or requiring threshold agreement above a
floor. Substantial disagreement (auditor C diverging by ~60% here) is
itself a signal, and the platform may flag the proof for review, request
a fourth auditor, or apply more conservative composition until agreement
converges.

The platform's trust commitment is to *each auditor publishing what they
say they publish* — verified by the BIP340 signature on each audit record
(§7.5) — not to *any auditor's score being correct in absolute terms*.
The protocol enables these composition patterns; the platform's policy
specifies them.

---

## 8. Operator Trust Properties

**8.1 — No operator is privileged in the protocol; verifiers compose
results across operators under their own policy. The protocol provides no
operator registry, no certification, and no trust hierarchy.**

**8.2 — Operator failure modes are bounded: an offline, slow, malicious,
or misconfigured operator can fail to deliver a service or deliver false
service, but cannot affect the validity of any proof, flag, or score that
verifiers can verify against the Bitcoin chain.**

A batching operator that disappears does not invalidate batched proofs
(verifiers fall back to portable proof envelopes). An indexing operator
that returns wrong results does not invalidate the proofs it indexes
(each returned proof is verified independently). An audit operator that
publishes wrong scores does not invalidate proofs whose construction is
independently verifiable. A flag publisher that publishes false flags is
identifiable by signature and weighted accordingly.

**8.3 — A verifier with no operator trust can still operate against the
Bitcoin chain alone using portable proof envelopes (§7.3) and verification
packages (§7.4); operator services provide convenience and amortisation,
never gating.**

### 8.4 Threat Model

**8.4.1 — Threats addressed by this specification:**

- *Operator misrepresentation.* Detected by inclusion verification
  (§7.3.4) failing.
- *Construction tampering.* Detected by construction verification
  (§7.4.4) failing against the reference implementation.
- *Forged or unsigned flags.* Flags require a publisher signature;
  unsigned or mis-signed flags are rejected.
- *Single-operator manipulation.* Bounded by the trustless-default
  framing (§7.1.1) and optionally further by composability patterns
  (§7.6.4).

**8.4.2 — Threats partially addressed; deployment-layer mitigations
apply:**

- *Operator feed spam and denial-of-service.* The protocol does not
  specify rate limits; operators apply endpoint protection per §9.5.
- *False but signed flags.* The protocol records signatures and bindings
  but does not adjudicate truth; verifiers compose multiple flag
  publishers under their own weighting policy (§6.4.6) to bound any one
  publisher's influence.
- *Audit methodology gaming.* Bounded by multi-auditor composition
  (§7.6.4); single-auditor verifiers carry the methodology-gaming risk
  directly.

**8.4.3 — Threats explicitly out of scope:**

- *Operator key compromise.* Recovered by §5.4 key rotation; past batches
  signed by the compromised key remain on-chain. Verifiers re-evaluate
  trust per public key.
- *Producer key compromise.* The producer's key management is the
  producer's responsibility. A compromised producer key allows new
  bindings under that proof's identity but does not retroactively alter
  the proof or its on-chain commitment.
- *Bitcoin chain reorganisation.* Verifiers select confirmation depth per
  their own policy; this specification does not impose a minimum.
- *Replay of signed records across contexts.* Signed records are bound to
  `subject_anchor_reference` and `context_uri`, constraining replay to
  records the publisher would have signed anyway. Explicit replay
  protection is flagged as a v1.1 hardening item (§11.1).

---

## 9. Operational Guidance

**9.1 — Batch operators SHOULD implement RBF-aware batch transaction
submission, allowing fee-bumping under congestion without invalidating
producer-held inclusion paths.**

A batch root is the protocol's commitment; RBF replacement of the
containing transaction changes the txid but not the root. Operators that
publish updated `batch_txid` references after RBF replacement preserve
verifier inclusion paths under both pre-RBF and post-RBF txids.

**9.2 — Indexing operators SHOULD support query patterns matching observed
verifier needs: by holder pubkey, by anchor reference, by batch root, and
by bracket interval. The exact query interface (REST, GraphQL, RPC) is
operator choice.**

**9.3 — Audit operators SHOULD publish methodology revisions under stable
versioned URIs and retain prior versions; verifiers consuming historical
scores require the methodology that produced them to remain resolvable.**

**9.4 — Flag publishers SHOULD distinguish their flag context taxonomy at
URI level and publish human-readable definitions at the URI; verifiers
weighting flags require the context to be interpretable.**

### 9.5 Endpoint Protection

**9.5.1 — Operators SHOULD protect public endpoints (audit feeds, indexer
queries, portable index downloads, flag distribution) against spam and
denial-of-service exposure. The protocol does not prescribe a strategy;
several are viable and may be combined. Strategy choice and parameter
calibration are operator deployment-layer decisions, not protocol-level
requirements.**

*Deployment considerations — strategies operators MAY deploy:*

- *Transport-layer rate limiting.* Per-IP rate limits applied at a CDN,
  reverse proxy, or in the operator service. Effective for casual abuse;
  complicated by NAT and CGNAT for very large client populations.
- *Client proof-of-work challenges (hashcash-style).* The endpoint
  requires a small proof-of-work alongside each request, calibrated so
  that legitimate clients pay a bounded latency cost (e.g., a few seconds
  per request) and bulk abusers pay multiplicatively. Architecturally
  coherent with the Orange Anchor cost-backed model and operationally
  simple at scale. Operators calibrate PoW difficulty against observed
  traffic and client device capability; difficulty SHOULD be adjustable
  without protocol revision. On low-power devices the latency floor may
  be higher than on desktops.
- *Authenticated client tokens.* Clients identify themselves via API
  keys, account-bound tokens, or Lightning-paid access tokens. Effective
  for known-client populations; adds onboarding friction for casual
  verifiers.
- *Combinations.* Operators may compose strategies — for example,
  unauthenticated clients face PoW challenges; authenticated clients face
  per-token rate limits.

---

## 10. Versioning and Compatibility

**10.1 — Protocol revisions are versioned independently of the
construction; revisions to operator surfaces or verification artefacts do
not require revision of the construction.**

**10.2 — Forward-compatible additions (new optional fields, new record
types) MAY be introduced within the current version. Verifiers MUST
tolerate unknown optional fields without error.**

**10.3 — Backward-incompatible changes require a new version and are
introduced only by major-version revision.**

**10.4 — Magic prefixes for new on-chain commitment types use the `OAV1`
namespace with a three-byte type discriminator; `OAV1BAT` (batch) and
`OAV1FLG` (flag) are allocated; other discriminators within the `OAV1`
namespace are reserved. Future protocol versions update the version
segment (`OAV2BAT`, etc.).**

---

## 11. Open Items

**11.1 — Items deferred from v1.0:**

- Detailed wire-level specification of `proof_internals` slot contents
  (currently specified by the reference implementation).
- Conformance profiles formalising operator declarations of which
  surfaces they implement (Appendix B forward reference).
- Multi-signature operator keys for high-value batch attribution.
- OpenTimestamps-compatible secondary on-chain attestation as deployment
  convenience.
- Methodology specification format for audit feeds.
- Explicit replay protection (timestamps or sequence numbers) for signed
  records — deferred as v1.1 hardening per §8.4.3.
- Endpoint-protection strategy guidance with calibration recommendations,
  pending operational experience under §9.5.

**11.2 — These items are MVP-deferred, not architecturally undefined;
they will be addressed in subsequent revisions if implementer experience
or deployment demand indicates a need.**

---

## Appendix A — Companion Documents

This specification sits within the Orange Anchor document suite:

- *Orange Anchor White Paper v2.3* — architectural pattern, cost-backed digital
  scarcity, generality argument.
- *BACC v1.9* — construction philosophy,
  calibration rationale, ecosystem dynamics.
- *Orange Anchor Integration Brief v2.2* — platform value, integration paths,
  user experience.
- *Orange Anchor Reference Implementation* — Android application,
  verification library, diagnostic tooling, and the authoritative source
  for `proof_internals` slot contents and verification algorithm details.
- *Orange Anchor Technical Paper* (forthcoming) — formal security
  analysis, parameter calibration justification, threat-landscape
  snapshot. Not required for MVP release.
- *Integrator Quick Start* (forthcoming, separate companion) — short
  on-ramp document for platform engineering leads, pointing into this
  specification for detail.

---

## Appendix B — Conformance Profiles (Forward Reference)

**B.1 — Conformance profiles are deferred to a post-MVP revision.**

A future revision will define conformance profiles for the four operator
surfaces, allowing operators to declare which surfaces they implement and
at what conformance level. Example profiles: batching-only operator,
indexing-and-audit operator, flag-publisher operator.

---

## Appendix C — Implementation Checklist

The reference implementation is the authoritative behavioural source.

### C.1 Batching operator implementer

1. BIP340 x-only secp256k1 keypair; secure the secret key.
2. `OP_RETURN` payload construction per §6.1.2.
3. Bitcoin canonical Merkle tree per §6.1.3.
4. Batch transaction submission with RBF policy per §9.1.
5. Portable index publication per §6.1.4 with operator Schnorr signature.
6. Inclusion proof delivery per §6.1.7.
7. Endpoint protection per §9.5.

### C.2 Verifier implementer

1. Bitcoin chain access (full node, light client, or trusted API).
2. Portable proof envelope ingestion and JSON parsing per RFC 8785.
3. On-chain `OP_RETURN` parsing and prefix validation per §7.3.4.
4. Merkle inclusion proof verification per §7.3.4.
5. BIP340 Schnorr signature verification (libsecp256k1 or equivalent).
6. Signed record validation per §7.5.4.
7. Optionally: open-source construction verification tool for full
   trustless verification per §7.4.

### C.3 Auditor implementer (additional items beyond C.2)

1. Methodology specification at a stable methodology URI per §6.3.2.
2. Scoring against the published methodology.
3. Signed audit record generation per §7.5.2.
4. Feed publication via chosen transport per §6.3.4 with endpoint
   protection per §9.5.

---

## Appendix D — Surfaces and Verification Paths

```
                        ┌────────────┐
                        │  PRODUCER  │
                        │  (holder)  │
                        └─────┬──────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
   ┌─────────┐           ┌─────────┐           ┌─────────┐
   │ batch   │           │  audit  │           │  flag   │
   │  via    │           │ submit  │           │ submit  │
   │operator │           │         │           │         │
   └────┬────┘           └────┬────┘           └────┬────┘
        │                     │                     │
        ▼                     ▼                     ▼
  ┌───────────────────────────────────────────────────────┐
  │                  OPERATOR LAYER                       │
  │  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐       │
  │  │Batching│  │Indexing│  │ Audit  │  │  Flag  │       │
  │  │ §6.1   │  │ §6.2   │  │ §6.3   │  │ §6.4   │       │
  │  └───┬────┘  └───┬────┘  └───┬────┘  └───┬────┘       │
  └──────┼───────────┼───────────┼───────────┼────────────┘
         │           │           │           │
         ▼           ▼           ▼           ▼
  ┌───────────────────────────────────────────────────────┐
  │                 BITCOIN CHAIN                         │
  │     anchors • batch roots • on-chain flags            │
  └─────────────────────┬─────────────────────────────────┘
                        │
                        ▼
                  ┌──────────────┐
                  │   VERIFIER   │
                  └──────────────┘

  Two verification paths
  ─────────────────────────────────────────────────────────
  TRUSTLESS DEFAULT (§7.1.1)
    portable proof envelope (§7.3)  → Bitcoin chain only
    verification package (§7.4)     → chain + reference impl
    no operator dependency

  OPT-IN COMPOSABLE (§7.1.3)
    portable index from batching operator (§6.1.4)
    audit scores from one or more auditors (§6.3)
    flags from one or more publishers (§6.4)
    verifier composes opt-ins per own policy (§7.6.4)
```

---

*Orange Anchor Operator Specification v1.0 — Release Candidate. Issued
alongside the Orange Anchor White Paper v2.3, BACC v1.9, Orange Anchor
Integration Brief v2.2, and the Orange Anchor Reference Implementation
as the MVP release set. Implementer feedback during MVP deployment will
inform the v1.1 revision cycle.*