Skip to main content

An open specification · Stewardship proposed to the Open Cap Table Coalition

GitHub [email protected]
Open Cap Table Protocol
SPEC v1.0 · AUGUST 2026 IN PRODUCTION OPEN SOURCE REFERENCE IMPL. CHAIN-AGNOSTIC

An open specification for the onchain register of record

The Open Cap Table Protocol is the onchain extension of the Open Cap Table Format. Every issuance, transfer, conversion, exercise and vesting event is appended as a typed OCF transaction to an append-only log on a distributed ledger. That log is the issuer’s official register: the book itself, not a copy of one.

One protocol, one data model, for the issuer's register — private or listed. Operated by a party with legal accountability for the record, inside the perimeter securities law already defines.

The register, as read

ocf-event-log append-only
STOCK_ISSUANCE      Alice        100,000   sec-1
STOCK_TRANSFER      Alice → Bob   30,000   sec-1
STOCK_CLASS_SPLIT   2 : 1

Alice’s position is stored nowhere. It is 140,000 — the result of applying those three events. Any entitled party computes the same number, because the events and the rules for applying them are the same for everyone.

Status
In production
on the reference implementation of chapter 7.2
Data model
OCF
strict, no semantic drift, no second format
Perimeter
§ 17A
registered transfer agent as system operator
Runtimes
Any conformant
Canton first, not required

Relationship to the standard

A division of questions

OCF answers

How is ownership represented?

A question about vocabulary, settled by five years of industry work. The Open Cap Table Format is the JSON standard for capitalization data — issuers, stakeholders, stock classes, plans, vesting terms, valuations, documents and the full taxonomy of equity transactions — maintained by the Open Cap Table Coalition, whose members include Gunderson Dettmer, Cooley and Wilson Sonsini, the equity platforms that hold the records, and consumers including Nasdaq Private Market and Morgan Stanley.

OCF specification →

OCP answers

Which record governs?

A question about authority, and it has not been settled at all, which is why every participant still keeps its own book and reconciles afterwards. OCP specifies how a register built on OCF is written, authorized, read and carried between the parties accountable for it.

OCP introduces no second data model. A STOCK_ISSUANCE recorded onchain is the STOCK_ISSUANCE an OCF-aware system reads from a file.

How OCP extends OCF →

What the protocol specifies

Five primitives, and one of them is the whole design

01

The event log is the register

Constitutive, not notificational. There is no offchain master book that the onchain record refers back to, and therefore no pair of records that can drift apart. A shareholding is not a number a system stores and protects: it is the result of applying the events that produced it, and the events are the record.

02

An accountable operator

The system-operator role is held by a registered transfer agent — or by an issuer acting as its own. Both the operator and the issuer are signatories on every object, so the examiner’s question — on whose authority was this recorded — is answerable from the record itself.

03

Deterministic derivation

Two parties applying the same log through the same data model reach the same positions. Determinism is not what makes the record authoritative — legal designation and an accountable keeper are — but it is what makes the record usable as one by parties who did not write it.

04

Controlled visibility

A securityholder file is not a public broadcast. The protocol requires confidentiality; the runtime provides it. Canton’s sub-transaction privacy confines each transaction to the parties involved; FHE-enabled chains compute over encrypted values. No runtime carries identifying information into public visibility.

05

Atomicity

A Series A closing is twenty or thirty typed objects describing one event. UpdateCapTable applies all of it or none of it. Balance integrity is validated against the whole post-batch register, under the least favourable ordering of same-dated events.

SCOPE

A register first, tokens only where useful

Equity is not a bearer instrument. The register carries ownership, because ownership is a legal fact with an accountable keeper. A token is an instrument issued against a position — a credential, a trading handle, collateral — and never the register itself.

Get started

Specification, runtime, libraries

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. All three are published.

Specification

v1.0 STABLE

The Open Cap Table Protocol

Fourteen chapters, the Request for Builders, and the Appendix A coverage map. Versioned as an artifact separate from any implementation of it.

Open source and published.

Read →Download PDF →Conformance →

Reference runtime

IN PRODUCTION

open-captable-protocol-daml

A set of DAML contracts on the Canton Network. Four primitives: OcpFactory, IssuerAuthorization, CapTable, UpdateCapTable.

DAML · open source

GitHub →Runtimes →

Reference SDK

IN PRODUCTION

@open-captable-protocol/canton

Returns OCF-shaped data in TypeScript and submits OCF-shaped writes back, validating against the OCF schema before anything reaches the network.

TypeScript · open source

GitHub →

Implementation status

The balance-integrity guarantees of chapter 8 are live. Positions of record — the published, reservation-aware position view committed atomically with the write — are specified in chapter 3.4 and are part of the open work. A second, independent runtime is the single most valuable contribution available.

Governance

A specification many institutions are asked to implement cannot be governed by one of them

Where the standard sits

OCF is maintained by the Open Cap Table Coalition, a nonprofit whose members include the law firms, equity platforms and market participants who use it. The data model is genuinely shared, no single member controls it, and a member who leaves takes nothing with them.

What the extension needs

The same properties, and three a data standard does not have to solve: a conformance regime, clear intellectual-property terms an implementer’s counsel can approve without negotiating, and a change process with more than one implementer at the table.

Where the work stands

The specification, reference implementation and SDK are open source and published. The specification is versioned separately from any implementation and published at github.com/Open-Cap-Table-Protocol/specs, a home that belongs to no implementer. Conformance today is self-attested: 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, no certification body and no third-party attestation.

A protocol, not a network

A network is something you join: it has a centre, a membership, and an operator who runs the shared infrastructure. A protocol is something you implement. There is no centre and nothing to join. HTTP is a protocol; no one operates the web.

A transfer agent adopting OCP runs its own registers under its own accountability and gains interoperability with every other operator who implements the same specification — without a membership, a central operator, or a dependency on any other participant’s continued operation.

Why this matters beyond the parties involved

Ownership, voting, distributions, disclosure obligations, tax reporting and collateral eligibility all resolve to the question of who holds what, which makes the issuer’s register the foundation the rest of the record system stands on.

A protocol that could only be operated by its author would fail the test the specification sets for infrastructure at that layer, however well it worked.

Get involved

Twenty open pieces of work. No application, no membership, no allocation.

The specification is deliberately narrow: a register an issuer designates, an accountable keeper maintains, and any entitled party can read and recompute. What it opens up is wider, and none of it is claimed.

Item 02 · open source

A second runtime

An independent, conformant implementation on an account-based chain — EVM, Solana, or an FHE-enabled chain — converts chain-agnosticism from a design claim into a demonstrated property.

Good first version — the objects and transactions of chapters 5 and 6, atomic batching, and the balance-integrity validation of chapter 8, decided by the published conformance suite against Appendix A.2 / A.4 coverage.

Item 16 · standards, then code

Interoperation between registers

A transaction whose legs sit on two registers has no defined semantics when one keeper commits and the other does not. Solving this as routing and semantics rather than as membership is the difference between many registers and one system.

Good first version — a two-register transfer protocol, with its commit, rollback and failure semantics specified.

Item 13 · a company

Equity as collateral

Private equity is close to unusable as collateral for informational rather than economic reasons. A register of record answers the first; the reservation field is the primitive an encumbrance would be built on.

Good first version — the lien lifecycle, attach through foreclose, mapped onto OCF objects with the Article 8 and 9 analysis stated.

Foundations

An independent cap-table engine · a formal model of batch validation

The standard

Ownership interests in OCF · governance and voting · equity compensation lifecycle depth · compliance conditions as libraries

Operating a register

Transfer-agent operations · migration from existing platforms · examination tooling · derived disclosure

What it makes possible

The cash leg · venues that settle to the register · cross-register acceptance · holder-side credentials · portable evidence · proofs over a register

The OCF items belong to the Open Cap Table Coalition and should go there. Everything else is ordinary open work: build it, publish it, and tell us where to find it — [email protected].

All twenty →

Authors, first operator and the standard body

Authors · first operator

Fairmint

SEC-registered transfer agent. Employs both specification authors and operates OCP on Canton for the issuers it administers. That deployment is evidence the protocol runs; it is not a definition of the protocol, and nothing in the specification requires an implementer to run Fairmint’s stack.

fairmint.com →

The data standard

Open Cap Table Coalition

Nonprofit maintainer of the Open Cap Table Format. Stewardship of the onchain extension is proposed to the Coalition; the decision belongs to its members and to implementers collectively.

opencaptablecoalition.com →

First runtime

Canton Network

Chosen first because its sub-transaction privacy matches the disclosure profile of a securityholder file without additional machinery. Not required — the runtime is a deployment decision, not a protocol decision.

Canton key concepts →