Skip to main content

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

GitHub spec@opencaptableprotocol.org
Open Cap Table Protocol

OCF and OCP

A division of questions.

OCF standardized the language of ownership. The industry is now assembling around that standard. OCP proposes the missing protocol for making that record authoritative and executable — offered to the standard rather than built beside it.

OCF answers

How is ownership represented?

A question about vocabulary. Settled by five years of industry work.

OCP answers

Which record governs?

A question about authority. Not settled at all — which is why every participant still keeps its own book and reconciles afterwards.

The standard

What the Open Cap Table Format is

OCF is the JSON data standard for capitalization data: issuers, stakeholders, stock classes, stock plans, vesting terms, valuations, documents, and the full taxonomy of equity transactions — issuances, transfers, conversions, exercises, repurchases, adjustments and vesting events. It is maintained by the Open Cap Table Coalition, a nonprofit whose members include most of the leading US securities law firms and the major equity platforms.

Its value is that one set of field definitions is shared by parties who otherwise share nothing. Counsel verifying a cap table before a financing reads the same objects the issuer’s platform wrote. A company moving between providers carries its record across intact instead of re-keying it. An auditor examining the capitalization examines the record itself, not a report about it. Before OCF, each of those parties worked from a different rendering of the same facts, and the differences between renderings were the work.

Who defines it

Law firms that paper these transactions — including Gunderson Dettmer, Cooley and Wilson Sonsini — alongside the equity platforms that hold the records.

Who consumes it

Secondary-market and infrastructure participants including Nasdaq Private Market and Morgan Stanley. Membership is now widening to depositories, transfer agents and exchanges.

Why that matters

A standard implementable by both incumbent market infrastructure and newer participants is the only kind that ends the reconciliation problem rather than relocating it.

OCF specification on GitHub →

The gap

What OCF does not specify

OCF settled how capitalization data is represented and who agrees on the representation. What it does not specify is how a register built on that data is written, authorized, read, and carried between the parties accountable for it.

Without that, every implementer builds its own answer, and the reconciliation problem the standard was created to end reappears one layer down. This is not a technology problem, and has not been one for some time. It is a missing-protocol problem in a precise sense: the components exist, and what is absent is the agreement on how they compose.

Who may write, and on whose authority
OCP: a system operator held by a registered transfer agent, signatory alongside the issuer on every object. The examiner’s question — on whose authority was this recorded — is answerable from the record itself.
Whether the onchain record is the book or a copy of it
OCP: the event log is the register. There is no offchain master book behind it, and therefore no pair of records that can drift apart.
What happens when half a closing lands
OCP: atomic batching. Twenty or thirty typed objects describing one round commit together or not at all, validated against the whole post-batch state of the register.
Who may read which field
OCP: visibility is required by the protocol and provided by the runtime — sub-transaction privacy on Canton, encryption on FHE-enabled chains, and no identifying information in public visibility on any runtime.
How a register moves to another operator
OCP: succession in four specified steps — extraction as an OCF manifest, verification by recomputation, re-establishment of grants, and continuity of the log across the seam.

The constraint

OCP introduces no second data model

Every object on the OCP ledger carries the same object_type discriminant, the same field names and the same validation semantics as the corresponding OCF JSON document. A STOCK_ISSUANCE recorded onchain is the STOCK_ISSUANCE an OCF-aware system reads from a file. The data model that counsel defined and the Coalition standardized is the data model OCP enforces in code.

OCP today is a strict implementation of OCF for the ownership record, with no semantic drift; a reader of the OCP event log is reading OCF. That constraint is deliberate and load-bearing, because it is what prevents an onchain register from becoming a vendor format by accretion.

In the vocabulary of recent SEC staff guidance, an OCP-recorded cap table is the issuer’s master securityholder file maintained onchain: the cap-table industry and the regulatory regime are describing the same record from two directions.

The consequence for an issuer

An issuer adopting OCP acquires an onchain register without acquiring a dependency. Its record remains readable by any OCF-compliant system, movable to any other, and reconstructible from the log by anyone entitled to read it. Migration between providers is an exchange of OCF, not of a proprietary export.

Portability here is a property of the protocol, not a commitment by an operator, and it holds even where an operator would prefer otherwise.

The consequence for the market

Every party that touches an issuer’s capitalization — counsel, auditors, transfer agents, broker-dealers, custodians, depositories, exchanges — can read the same book, in a format they already know, without any of them owning it.

The reason to build a register on a public standard is not interoperability between vendors. It is that market infrastructure at this layer should be common property, and OCF is the only candidate the industry has already agreed on.

Open work

Extending OCF extends everything built on it

OCP reaches exactly as far as OCF does, which makes standards work the highest-leverage contribution available. These items belong to the Open Cap Table Coalition, not to any implementer.

04

Ownership interests

LLC membership units, limited partnership interests and profits interests are not yet covered, which leaves the vehicles holding most of the world’s private capital outside the data model.

05

Governance and voting

Record dates, notice, proxy appointment, ballots, quorum and tabulation — and the written consent that does most of the actual governing at private issuers.

06

Equity compensation lifecycle

83(b) elections, the ISO limit, post-termination exercise windows, net exercise, withholding, repricings, acceleration, mid-vest jurisdiction changes.

All twenty →

Questions

Direct answers

Is OCP a competing format to OCF?
No. It is a strict implementation of OCF for the ownership record, with no semantic drift. A reader of the OCP event log is reading OCF.
Do I need OCP to use OCF?
No. OCF is a data standard usable entirely offchain, and most of its users do exactly that. OCP is for the case where the record itself should be the live, shared book rather than a file exchanged between systems.
Does OCP change any OCF field definitions?
No. Fields are preserved as specified. The one permitted departure is that a runtime whose visibility model cannot hold an identifying field in the clear may hold it by reference — stated as an explicit exception in Appendix A.
Who governs the onchain extension?
Undecided, deliberately. The authors intend to bring the specification to the Open Cap Table Coalition and seek its stewardship. Whether it is governed by the Coalition itself or by a neutral vehicle is a decision for implementers and members collectively.