This document specifies the Anchor Interface of the Open Cryptographic Provenance Protocol for AI System Outputs (OCPP-AI). The Anchor Interface is the abstract specification of the properties any acceptable cryptographic anchor MUST satisfy when used to publish Merkle roots of OCPP-AI receipt batches to a public, immutable data structure for the purpose of providing tamper-evident provenance evidence to EU AI Act Article 50 supervisory authorities, EU AI Act notified bodies, courts of Member States, and natural persons exercising rights under the Regulation.
The interface is deliberately substrate-agnostic. The protocol does not mandate a specific anchoring substrate. It mandates the properties that any acceptable substrate must satisfy. This separation of interface from implementation is essential for three reasons:
This document does not specify a particular substrate. Sections 3 and 4 describe two conforming reference implementations.
A cryptographic anchor substrate is OCPP-AI conformant if and only if it satisfies all of the properties described in Sections 2.1 through 2.8. Compliance is binary; partial compliance is non-compliance.
The substrate MUST provide a cryptographic guarantee that, once an anchor record is published, no party — including the substrate operator, any state actor with jurisdictional authority over the substrate operator, and any coalition of computational resources operating within the substrate's design parameters — can alter, remove, or substitute the published anchor record without producing a publicly observable inconsistency detectable by an independent verifier without privileged access.
An anchor substrate that relies on the cooperation of any identified operator to maintain immutability is non-conformant. An anchor substrate that relies on the absence of an adversary controlling a defined threshold of the substrate's consensus apparatus is conformant if and only if that threshold is publicly documented, currently above the level of any known coalition, and operationally evidenced by the substrate's continuous operation through historical adversarial events.
Any natural or legal person with internet access MUST be able to verify the presence and content of any published anchor record without identifying themselves to the substrate operator, without holding credentials issued by the substrate operator, and without entering into any agreement with the substrate operator.
Verification MUST be possible using only publicly available client software and the published anchor reference.
The substrate's continued operation MUST NOT depend on the consent, license, or non-interference of any single sovereign state, single municipal jurisdiction, or single private legal entity. The substrate MUST be operationally distributed across at least three independent jurisdictions, where independence is evidenced by the absence of mutual extradition treaties enabling unilateral compulsion of substrate operation between any two of the three.
This property is satisfied by substrates operated as voluntary multi-jurisdictional public infrastructure (Bitcoin, EBSI consortium nodes operating under Member State authority). It is not satisfied by substrates operated under the licensing authority of a single regulatory regime.
The substrate MUST have demonstrated continuous operational availability for a period of not less than thirty-six (36) months prior to the date of any anchor publication, with no period of substrate-wide unavailability exceeding seventy-two (72) hours during that period.
This property exists to exclude substrates of unproven operational characteristics from carrying long-term regulatory evidence. The threshold is reviewed at each revision of this specification.
Given an anchor reference produced at the time of anchor publication, any independent verifier MUST be able to deterministically resolve the anchor record content and the substrate position (block height, sequence number, or equivalent) at which it was published. Two independent verifiers performing this resolution MUST produce byte-identical anchor record content and substrate position.
The substrate MUST accept a fixed-length anchor payload conforming to the OCPP-AI Anchor Payload Format defined in Section 2.7. Substrates that require variable-length payloads or impose payload format constraints incompatible with the OCPP-AI Anchor Payload Format are non-conformant.
The anchor payload is a fixed 36-byte structure:
┌──────────────────────────────────┬──────────────────────────────────────┐ │ MAGIC (4 bytes) │ MERKLE ROOT (32 bytes) │ │ ASCII "LPR1" — 0x4C 0x50 0x52 0x31 │ SHA-256 root of receipt batch │ └──────────────────────────────────┴──────────────────────────────────────┘
The MAGIC prefix "LPR1" (0x4C 0x50 0x52 0x31) MUST be present in the first four bytes. The MERKLE ROOT is the SHA-256 (RFC 6234) root of the canonical CBOR (RFC 8949 deterministic encoding subset) representation of the OCPP-AI receipt batch, computed per RFC 6962 (Certificate Transparency Merkle tree construction).
The fixed 36-byte length is preserved across substrate implementations to ensure that an anchor record produced under one conforming substrate can be machine-distinguished from records produced under non-OCPP-AI uses of the same substrate, and to bound the maximum information content of any anchor record at the substrate layer to preclude PII leakage into the anchor.
The anchor payload format defined in Section 2.7 MUST NOT permit the publication of personal data as defined in GDPR Article 4(1) within the anchor record. Compliance with this property is structural: the 32-byte SHA-256 Merkle root carries cryptographically no recoverable information about the underlying receipt content absent access to the full receipt batch, and receipt-level GDPR Article 17 erasure of an individual receipt does not invalidate the anchor for other receipts in the same batch.
This property is binding on the protocol layer. Substrate operators MUST NOT relax this requirement.
The reference implementation of the OCPP-AI Anchor Interface uses the Bitcoin mainnet (network magic bytes 0xF9 0xBE 0xB4 0xD9) as the anchor substrate, publishing anchor payloads via the OP_RETURN script opcode (BIP 0011, BIP 0027, Bitcoin Core consensus rules).
| Property | Status | Evidence |
|---|---|---|
| I-1 Immutability | SATISFIED | Bitcoin's continuous operation since 3 January 2009; reorganization depth bounded; adversarial economic cost of altering historical anchors exceeds practical thresholds by orders of magnitude. |
| I-2 Public verifiability without authentication | SATISFIED | Any internet-connected party may query any of approximately fifteen thousand publicly operated Bitcoin full nodes for the content of any OP_RETURN record. |
| I-3 Jurisdictional neutrality | SATISFIED | Bitcoin nodes operate in over one hundred fifty jurisdictions including all Member States. Mining operations are distributed across jurisdictions with no mutual extradition coalition controlling consensus majority. |
| I-4 Demonstrated durability | SATISFIED | Continuous operational availability since 3 January 2009 with no substrate-wide unavailability event exceeding seventy-two hours in the protocol's history. |
| I-5 Deterministic anchor resolution | SATISFIED | An anchor reference of the form {txid, vout} resolves deterministically to the byte-identical anchor record content at the byte-identical block height across all Bitcoin Core conformant verifiers. |
| I-6 Bounded anchor payload format | SATISFIED | OP_RETURN admits payloads up to 80 bytes; the 36-byte OCPP-AI anchor payload fits within this bound. |
| I-7 Anchor payload format | SATISFIED | The OCPP-AI 36-byte payload is published verbatim as the OP_RETURN data field; no substrate-specific transformation is applied. |
| I-8 GDPR Article 17 compatibility | SATISFIED | The 32-byte SHA-256 Merkle root within the OP_RETURN payload contains no personally identifiable information; receipt-level erasure remains possible at the receipt store layer without affecting the anchor. |
Bitcoin OP_RETURN anchoring is suitable for cross-border, cross-jurisdiction Article 50 evidence where the use case prioritizes maximum operational durability, jurisdictional neutrality, and independence from any single state's regulatory authority. Examples include AI-generated content syndicated across multiple Member States, AI system outputs subject to potential cross-border enforcement coordination among national competent authorities, and Article 50 evidence intended to remain verifiable across multi-decade time horizons.
The reference implementation maintained by LedgerProof Foundation operates at an aggregation cadence of one anchor per ten-minute Bitcoin block window, achieving an effective anchor amortization of approximately one anchor record per several thousand receipts at production volumes.
The European Blockchain Services Infrastructure (EBSI), operated by the European Commission and the European Blockchain Partnership Member States, is identified by this specification as the primary enterprise-government alternative anchor substrate conforming to the OCPP-AI Anchor Interface.
EBSI operates as a permissioned blockchain network with consensus nodes operated by Member State governments. As of the date of this specification, EBSI conformance with the OCPP-AI Anchor Interface has been evaluated as follows:
| Property | Status | Notes |
|---|---|---|
| I-1 Immutability | SATISFIED with conditions | EBSI consensus is Byzantine-fault-tolerant across Member State operator nodes. Immutability is conditional on the absence of a coalition controlling more than one-third of consensus nodes. This threshold is publicly documented in EBSI governance documents and currently exceeds any plausible coalition size. |
| I-2 Public verifiability without authentication | SATISFIED for verifier role | EBSI verifier nodes accept anonymous read queries for published anchor records. Write access (anchor publication) requires accreditation; this asymmetry is consistent with the Anchor Interface requirement that verification specifically be unauthenticated. |
| I-3 Jurisdictional neutrality | SATISFIED at Union level | EBSI nodes are operated across all participating Member States and the Commission. No single Member State or non-EU jurisdiction can compel substrate operation. The substrate is sovereign to the Union as a whole; this is the design intent and is appropriate for Article 50 evidence produced by deployers under EU jurisdictional reach. |
| I-4 Demonstrated durability | UNDER EVALUATION | EBSI's continuous operational record from initial production deployment to date is approaching the 36-month threshold. The Foundation will publish updated conformance assessment when this threshold is met. |
| I-5 Deterministic anchor resolution | SATISFIED | EBSI's block structure provides deterministic resolution of published records by reference. |
| I-6 Bounded anchor payload format | SATISFIED | EBSI smart contracts admit fixed-length byte payloads compatible with the 36-byte OCPP-AI anchor payload format. |
| I-7 Anchor payload format | SATISFIED | The OCPP-AI 36-byte payload format is published verbatim via an EBSI smart contract conforming to a published interface specification (forthcoming Annex B to this document). |
| I-8 GDPR Article 17 compatibility | SATISFIED | The 32-byte SHA-256 Merkle root contains no personally identifiable information; the GDPR posture is identical to the Bitcoin OP_RETURN reference implementation. |
EBSI anchoring is suitable for Article 50 evidence where the use case requires Union-sovereign verification, where the deployer is a public-sector entity or operates under a regulatory regime requiring EU-controlled infrastructure, or where Member State competent authorities have indicated a preference for EU-operated anchor substrates in their supervisory practice.
The Foundation will publish a reference EBSI smart contract for OCPP-AI anchor publication as Annex B to this document at the time the I-4 conformance threshold is met.
This specification permits and RECOMMENDS dual-anchor publication: the same receipt batch Merkle root MAY be published as anchor records to both Bitcoin OP_RETURN and EBSI in parallel. Verifiers MAY accept evidence from either anchor; verifiers operated by EU institutions, Member State competent authorities, or notified bodies MAY require evidence from the EBSI anchor as a matter of supervisory policy, while verifiers operated by parties outside the EU regulatory perimeter MAY accept the Bitcoin OP_RETURN anchor.
Dual anchoring is the recommended configuration for deployers subject to EU AI Act Article 50 obligations whose AI system outputs are syndicated across both EU and non-EU jurisdictions, as it satisfies both sovereign verification preferences without requiring the deployer to commit to a single substrate choice.
The Anchor Interface is explicitly designed to admit additional substrate implementations. Candidate substrates submitted to the Foundation for conformance evaluation are assessed against Sections 2.1 through 2.8 according to a published evaluation procedure. Substrates that satisfy all properties are added to the registry of conforming substrates published at https://spec.ledgerproofhq.io/conforming-substrates.
Substrates that may be evaluated for future inclusion include national-sovereign distributed ledgers operated by individual Member States or the Union, post-quantum-resistant anchor substrates anticipated by OCPP-AI v2.0, and emerging permissionless substrates demonstrating sufficient operational durability.
In the event that a conforming anchor substrate ceases to satisfy any property in Sections 2.1 through 2.8, the Foundation will publish a security advisory and update the registry of conforming substrates. Previously-anchored receipts whose anchor records are published to a now-non-conforming substrate remain verifiable using historical substrate state where the historical state itself is still recoverable; this is the case for Bitcoin OP_RETURN historical records regardless of any future Bitcoin substrate state changes.
Where dual anchoring is in use, the same 32-byte Merkle root MUST be published to both substrates. A verifier that observes inconsistent Merkle roots for the same nominal batch identifier across the two anchors MUST treat the receipt batch as unverified and report the inconsistency.
Receipt-level erasure under GDPR Article 17 is performed at the receipt store layer, not at the anchor layer. The anchor is unaffected by receipt erasure; the receipt erasure invalidates the Merkle proof for the specific receipt but does not invalidate proofs for the remaining receipts in the same batch. This separation is essential for GDPR compliance and is a normative architectural commitment of OCPP-AI.
Normative references:
Informative references:
draft-dawkins-scitt-ai-article50-00 — A SCITT Profile for EU AI Act Article 50 Transparency Receipts (IETF SCITT Working Group)