Implementations

One specification, three layers.

The protocol defines the objects and the rules. A runtime enforces them and guarantees atomicity and visibility. The libraries make both usable without re-implementing either.

Structure

What each layer is responsible for

Protocol

The OCF objects and transactions, the rules governing their lifecycle, and the authorization model that decides who may write and who may read. Runtime-agnostic: it describes behaviour, not storage. Versioned as an artifact separate from any implementation of it.

Runtime

An implementation of that protocol on a specific distributed network. Different ledger models require different implementation patterns to satisfy the same specification, which is why conformance is defined behaviourally rather than by a single codebase.

Libraries

The typed interfaces that read and write the protocol. Identity, authentication and disclosure are provided by the underlying network, so OCP defines no identity layer, session layer or replication protocol of its own.

Runtimes

Runtime status and disclosure profiles

OCP is chain-agnostic by construction. The data model, the authorization semantics and the derivation rules are identical across runtimes; what differs is how a given network realizes visibility, signing and atomicity. The runtime follows the disclosure profile of the register it would hold — not the issuer’s listing status.

A new runtime becomes OCP-conformant by answering yes to every applicable question in the Appendix A coverage map. There is no certifier and nothing to apply for; conformance today is self-attested, and no executable suite is published yet. The conformance questions →

Reference implementation

DAML on the Canton Network

The reference runtime defines four primitives. OcpFactory is one shared contract per network deployment, signed by the system operator, which registers issuer parties. IssuerAuthorization is the proof of that registration, exchangeable by the issuer for the right to create a cap table and withdrawable by the operator. Issuer and CapTable are created together, the latter holding typed index maps, not balances. UpdateCapTable is the single choice through which all subsequent state changes flow.

Every contract in that structure — the cap table and each of the fifty-odd OCF entity templates — carries both the issuer and the system operator as signatories. The transfer agent’s authority is not an assertion made in an accompanying document; it is present cryptographically on every record in the register.

Operators

Who runs OCP today

OCP is most valuable when many transfer agents run it, each as system operator for the issuers it administers. A transfer agent adopting it runs its own registers under its own accountability and gains interoperability with every other operator implementing the same specification — without a membership, a central operator, or a dependency on any other participant’s continued operation.