Conformance
“OCP-conformant” means something verifiable.
Every question is written to be decidable by running a test rather than by forming an opinion, so an implementer establishes conformance without asking anyone. Conformance today is self-attested against the Appendix A coverage map; no executable suite is published yet. Objective tests are what let a specification be implemented by parties who did not write it.
Appendix A.4
Conformance questions
The properties in A.2 are what every runtime must preserve. The questions below are how an implementation demonstrates that: each is written to be decidable by running a test rather than by forming an opinion. An implementation is OCP-conformant for a given specification version when every applicable question is answered yes against that version’s semantics, and an implementer can construct those tests and attest to the result without asking anyone.
What does not exist yet is a published conformance suite — versioned fixtures, golden manifests, behavioural vectors and a harness — that would make two implementers’ attestations comparable and let a third party re-run them. Producing it is open work (Request for Builders, Foundations).
A no on any of 1–16 is not conformant; a no on 17 or 18 is conformant for recording but not for operation, and cannot hold a production register.
Question 7 is required for a runtime holding a register subject to supervision, which is every US securityholder register; a runtime that fails it may be conformant for research or for records outside that perimeter, and is not suitable for a regulated deployment.
Status of the suite
An implementer measures itself against Appendix A.2 and the A.4 coverage map and says so. There is no published executable suite yet, no registry of conformant implementations, no certification body and no third-party attestation: a standard with a conformance claim and no runnable suite is a standard on its honour. That gap is open work (Request for Builders) as much as governance. The coverage map was written so a third party can eventually decide each question without a relationship to the authors; publishing the suite and getting a second implementation through it is what makes the claim checkable; a registry is what makes it durable.
Appendix A.2
What every runtime must preserve
- The OCF data model
- Every reference object and transaction type, with all fields preserved — except that identifying fields may be held by reference rather than by value where the runtime’s visibility model requires it. This is the one permitted departure from carrying every OCF field literally onchain, and it is stated as an explicit exception rather than left to be discovered.
- The role split
- System operator, issuer, stakeholder — with both the operator and the issuer as signatories on every object.
- Atomic batching
- A batch commits entirely or not at all.
- Balance integrity
- No accepted write may leave any security overdrawn, evaluated against the whole register and under the least favourable ordering of same-dated events. OCF carries no intra-day sequencing, so where several events share a date the runtime evaluates them in the order that produces the lowest possible balance — reverse splits, retirements, reductions, then forward splits — and accepts the batch only if every possible ordering is valid.
- Determinism
- The same log yields the same positions.
- Scoped supervisory visibility
- A supervisory authority can be granted read-only visibility into a defined scope of records — a whole register, one issuer’s cap table, or a named subset — continuously and in real time, without those records becoming visible publicly or to unrelated parties on the network, and without the grant’s continued operation depending on the operator. The mechanism is the runtime’s; the capability is required.
- Round-trip extractability
- The OCF manifest can be extracted and used to rebuild the register on any other conformant runtime.
What varies, and is not a protocol concern
The concrete on-ledger primitives; the privacy mechanism; the signing and authorization mechanics; and the performance, cost and finality characteristics.
Appendix A.1
How ledger models map to the specification
OCP does not specify a single implementation that runs unchanged everywhere, because ledger models differ in ways that require different implementation patterns to satisfy the same behaviour.
Contract-based
Canton, and UTXO-derived chains. State is held in discrete contracts or outputs that transactions consume and re-create. In the reference implementation the cap-table contract is consumed and re-created by each update, with each OCF object materialized as its own contract beneath it. Atomic batching is natural: the batch is one exercise that either commits or fails.
Account-based
EVM chains, Solana. State is held in mutable records keyed to accounts and modified in place. An OCP implementation would hold the register in a contract or set of contracts whose state is updated by typed batch transactions. Atomicity maps to a single transaction that reverts entirely on failure.
Privacy-augmented
FHE-enabled EVM. Account-based at the storage layer, with selected fields encrypted so that only authorized parties can compute over them. Identifying and sensitive fields are held encrypted; the protocol semantics are unchanged.
The highest-value open work
Producing the conformance suite — reference fixtures, golden OCF manifests, behavioural test vectors — is what makes multi-runtime parity a testable claim rather than an assertion. It is what allows an implementer to demonstrate conformance without asking anyone’s permission. See items 1–4 →
Governance
Why a data standard does not need this and an implementation specification does
OCF is maintained by the Open Cap Table Coalition and that arrangement works: the data model is genuinely shared, no single member controls it, and a member who leaves takes nothing with them. An onchain extension needs the same properties and three more.
A conformance regime
So that “OCP-conformant” means something verifiable rather than self-declared. Conformance today is self-attested — an implementer measures itself against A.2 and the A.4 coverage map and says so. There is no published executable suite yet.
Clear IP terms
So an implementer’s counsel can approve building on it without negotiating. The specification, reference implementation and SDK are open source and published.
A change process
With more than one implementer at the table, so the specification evolves toward what implementers need rather than toward what any one operator has already built.
The specification is versioned as an artifact separate from any implementation of it. Whether the onchain extension is governed by the Coalition itself or by a neutral vehicle established for the purpose is a decision for implementers and members collectively, and the specification does not presume it.