Open agenda

Twenty open pieces of work. None of it requires permission to start.

Non-normative. This section is an implementation agenda, not part of the specification. Nothing in it is required for conformance, nothing in it constrains an implementer, and nothing in it is a commitment by the authors.

OCP specifies a register that an issuer designates, an accountable keeper maintains, and any entitled party can read directly and recompute for itself. That is the whole of the specification, and it is deliberately narrow. What it opens up is wider.

A register kept on any conformant runtime, in any jurisdiction, by any operator willing to be accountable for it. Registers that transact with each other without a central depository standing between them. A position a lender can lend against, because an encumbrance is recorded rather than promised. A holding a stakeholder can prove to a bank without asking an operator for a PDF. An interest recorded under one country’s law that a counterparty under another’s can accept without a phone call and an opinion letter.

None of that requires a change to the protocol. All of it is open, and none of it is claimed.

The list

Each item states the opportunity, why it matters, and what a good first version looks like

Each item states the opportunity, why it matters, what a good first version looks like, and what kind of effort it is — open source, standards work, research, or a company. Some of it is a weekend. Some of it is a company. None of it requires permission to start.

Foundations

OCP makes three checkable claims: it runs on any conformant runtime, its positions can be recomputed by anyone, and no batch can overdraw a position. Each is demonstrated today by one implementation, written by the same people who wrote the specification. A second, independent one turns each claim into a fact — and everything else on this list is easier to build once it is.

1. 01 · open source

   An executable conformance suite

   Appendix A.2 states what every runtime must preserve; A.4 lists the properties a third party must be able to decide yes or no. Eighteen questions are a coverage map, not a battery someone can run. Until versioned fixtures, golden OCF manifests and behavioural vectors exist — with a harness that exercises authorization negatives, batch integrity, extract and rebuild, and the operations tier — “OCP-conformant” remains a self-attestation against a checklist.

   Good first version: a versioned fixture pack and harness that decides A.4 questions 1–13 and 15 for the reference runtime, published next to the specification. Questions 14 and 16 wait on a second engine and a second runtime (Foundations 2–3).

2. 02 · open source

   A second runtime

   OCP has run on Ethereum, Optimism and Base, and the reference implementation today is Canton. An independent, conformant implementation on an account-based chain — EVM, Solana, or an FHE-enabled chain — is the single most valuable contribution available, because it 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.

3. 03 · open source

   An independent cap-table engine

   Determinism is what makes an authoritative record usable by parties who did not write it (chapter 3.1), and it is demonstrated today by one implementation. A second engine, in a different language, that computes positions from an OCF manifest and agrees with the reference implementation across a corpus of fixtures turns that from an assertion into a result.

   Good first version: Python or Go, reading an OCF manifest, producing positions and a fully-diluted table.

4. 04 · research

   A formal model of batch validation

   Chapter 8 requires that no accepted batch leave a security overdrawn, evaluated against the whole register and against every same-date ordering. That property is enforced today by one implementation and by the A.4 coverage map. What is not yet settled in the open is whether the stated adversarial schedule is equivalent to quantifying over all orderings, and whether the fold over OCF lifecycle events matches the informal rule for every transaction type. A machine-checked model of event effects and the validation check, with a proof of the ordering claim for the single-batch case, would give every future runtime a reference to refine against — not a restatement that “reject if overdrawn” preserves non-negativity.

   Good first version: event semantics and the chapter 8 check formalized; ordering equivalence proved for the transaction types in the reference engine.

The standard

OCF is the shared data model (chapter 2), and OCP reaches exactly as far as OCF does. Extending OCF extends everything built on it at once, which makes this the highest-leverage work on the list per line of code. It belongs to the Open Cap Table Coalition, not to any implementer — and for several of these bricks the deepest expertise sits with the firms that already run the plumbing at scale. Contributing a schema costs none of them anything they compete on.

1. 05 · standards work

   Ownership interests in OCF

   The standard covers corporate stock. Limited liability company units, limited partnership interests and profits interests are not yet covered (chapter 5), which leaves the vehicles holding most of the world’s private capital outside the data model. Capital accounts, commitment and drawdown schedules and distribution waterfalls are a substantial piece of standards work with a large constituency and, so far, no one carrying it.

   Good first version: a schema proposal for LLC membership units, submitted to the Coalition.

2. 06 · standards work

   Governance and voting in OCF

   OCF records who holds what, and votes per share is part of a stock class. What it does not yet describe is the exercise of those rights: record dates, notice, proxy appointment and revocation, ballots, quorum and tabulation — and, for private issuers, the written consent that does most of the actual governing, whose validity turns entirely on who held what on a given date and whether a threshold was met. Where the register is constitutive, a record date is a query rather than an extract, and a consent threshold is a computation over the register rather than a lawyer’s reconstruction. This is the brick that turns a register of ownership into one the issuer’s corporate acts can run on.

   Good first version: record date, consent solicitation and threshold computation for an action by written consent under DGCL § 228, expressed as OCF objects.

3. 07 · standards work

   Equity compensation lifecycle depth in OCF

   Stock plans, options, RSUs, vesting terms, early-exercise flags, termination exercise windows, repricings and vesting accelerations are already in the standard. What still varies by platform — and what breaks when a grant moves between systems — is the layer around them: 83(b) elections after early exercise, the ISO limit under IRC § 422(d) and disqualifying dispositions, the change in tax character when a post-termination window is missed or extended, net and cashless exercise and share withholding as first-class exercise mechanics, option exchanges beyond a bare price change, typed multi-trigger acceleration (including double-trigger), and employees who change tax jurisdiction mid-vest. Those are improvements to an existing vocabulary, not a new object family — and they are what decide what a grant is worth and how it is taxed.

   Good first version: exercise mechanics — cash, net, cashless and share withholding — expressed on the exercise transaction so two engines agree on quantity issued, consideration and shares returned to the plan.

4. 08 · open source

   Compliance conditions as libraries

   Chapter 9.1 draws the line between verification, which requires judgment, and evaluation, which is mechanical. Evaluation is the part that can be shared: Rule 144 holding-period expiry, accreditation credentials with expiry, jurisdictional eligibility as a zero-knowledge proof, screening-list conditions, legend-derived transfer rules. Written once and shared, they keep a standard from becoming a set of dialects — and whoever writes the first good one sets the shape the rest adopt.

   Good first version: a single rule, specified precisely enough that two implementations agree on every edge case.

Operating a register

What lets an operator move a real book onto OCP and answer for it. Each of these converts an issuer or a transfer agent from an interested reader into a user.

1. 09 · open source

   Transfer-agent operations on OCP

   The statutory functions a transfer agent performs — annual proxy, dividend and distribution processing, stock splits with fractional resolution, escheatment, lost-securityholder search under 17Ad-17, statement generation, tax reporting under 1099 and K-1 — map onto OCF objects and OCP transactions, and the mapping is there to be written. It is the work that lets an existing transfer agent evaluate OCP against its actual book rather than against a description.

   Good first version: one function, mapped end to end.

2. 10 · open source, or a company

   Migration from existing platforms

   Every issuer adopting OCP arrives from somewhere — a cap-table platform, a transfer agent’s system, a spreadsheet. Importers that produce a validated OCF manifest from those sources, with a reconciliation report showing what could not be mapped and why, remove the single largest practical obstacle to adoption.

   Good first version: one source platform, one honest reconciliation report.

3. 11 · a company

   Examination tooling

   Chapter 10 gives regulators and auditors standing, scoped, real-time visibility through Observer parties. The opening is the interface an examiner would actually use: reconstruct the register as of a date, trace a position to its originating events, diff two points in time, export in a form that goes into a workpaper. Whoever builds it will shape how examining an onchain register is done in practice, though the standard of supervision remains the regulator’s to set.

   Good first version: point-in-time reconstruction with event-level provenance.

4. 12 · open source

   Derived disclosure

   Section 16 filings, Schedule 13D and 13G thresholds, Rule 12g5-1 holder-of-record counts and Form 5500 reporting are all functions of a register. Where the register is a queryable event log, they become computations rather than data-collection exercises.

   Good first version: holder-of-record counts under Rule 12g5-1, computed from an OCF manifest, with the counting rules stated explicitly.

What a register of record makes possible

The work above makes OCP correct and operable. The work below is what a correct, operable register lets other people build — and none of it is a protocol change.

1. 13 · a company

   Equity as collateral

   Private equity is close to unusable as collateral, and the reasons are informational, not economic: a lender cannot verify the position independently, cannot perfect and monitor a security interest cheaply, and cannot predict what enforcement looks like. A register of record answers the first, and the reservation field of chapter 3.4 is the primitive an encumbrance would be built on — recorded against a position rather than asserted in a side letter. The open work sits between the two: how control of an uncertificated security under UCC Article 8, and perfection by control under Article 9, are established against a position on an OCP register; what a control agreement looks like when the issuer’s obligation to follow a secured party’s instructions is a recorded condition rather than a contractual promise; and how foreclosure executes as a transaction. Nothing here inherently requires a token. Solving the control and perfection layer would remove one of the principal structural barriers to lending and other financing against private equity — not all of them, since priority, custody, valuation, concentration and insolvency treatment each remain their own question.

   Good first version: the lien lifecycle — attach, perfect, monitor, release, foreclose — mapped onto OCF objects and OCP transactions, with the Article 8 and 9 analysis stated.

2. 14 · a company

   The cash leg

   OCP settles the security leg atomically (chapter 8). Payment happens elsewhere, which means a transfer that is atomic on the register is still one half of a settlement that is not. Delivery versus payment requires a mechanism that prevents either leg from reaching finality without the other, even where the two systems share no native transaction boundary. Whether the payment leg is a stablecoin, a tokenized deposit or an instant payment rail, the interface is the same problem, and it is open.

   Good first version: one payment rail, one settlement protocol, with the commit and failure semantics of both legs specified.

3. 15 · a company

   Venues that settle to the register

   Chapter 12 covers the register’s own lifecycle operations, not the market that can sit above them. Tender offers, issuer-run liquidity windows and order books all need intake, eligibility evaluation, allocation and settlement that terminate in a register transaction with its conditions evaluated. The design constraint is unusual: the register is where finality of record ownership lives, so a venue is designed backwards from settlement rather than forwards from matching. The broker-dealer and venue-registration analysis is part of this work, not a footnote to it.

   Good first version: an issuer-run liquidity window — intake, eligibility, pro-rata allocation, batch settlement.

4. 16 · standards work, then open source

   Interoperation between registers

   OCP specifies what happens inside one register, kept by one accountable keeper. The world is many registers, across many keepers, runtimes and jurisdictions, and composition across them is achieved today through centralized market infrastructure — principally depositories and the intermediary structure built around them, which immobilize positions and keep entitlements rather than linking issuer registers to one another. Doing it without that layer is, precisely, the architecture the 1969 Rockwell report described and the industry could not then build (chapter 1): settlement as book-entry between the registers themselves rather than against a central vault. Three cases are open. A transaction whose legs sit on two registers — a share exchange in an acquisition, a fund interest and the portfolio company’s stock — has no defined semantics when one keeper commits and the other does not. A stakeholder holding across dozens of registers cannot yet see one position without an intermediary reassembling it. And underneath both sits the resolution problem chapter 14.4 leaves open deliberately: given an issuer, which register governs, and where is it. Solving these 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.

5. 17 · a company

   Cross-register acceptance

   A register is constitutive within one issuer’s designation and one accountable keeper (chapter 11). That says nothing about why a counterparty somewhere else should accept it. Today acceptance is bilateral and manual: a lender, a venue, a receiving transfer agent or a fund’s custodian relies on knowing the keeper, or on counsel’s opinion about a jurisdiction it does not practise in. The opportunity is to let a register publish what a third party needs in order to decide, as verifiable and revocable records rather than PDFs. This is the layer that lets an interest recorded under one country’s law be accepted, pledged or held under another’s.

   Good first version: a machine-readable profile a register publishes at a known location — keeper identity, its registration or licence and the authority that granted it, the jurisdiction whose designation it operates under, its conformance results, and the signature of whoever attests to those facts — plus a verifier a counterparty can run without contacting the keeper. The profile would not establish legal recognition on its own; it exposes the facts a counterparty needs in order to reach that determination without starting from a diligence package.

6. 18 · open source

   Holder-side credentials and interfaces

   A stakeholder should be able to prove control of a position, authorize an instruction, and read their own holdings without depending on any particular operator’s application. Chapter 9.3 specifies the authorization model; the holder-side experience is open, and because it is not naturally any one operator’s work, it is available to anyone.

7. 19 · a company

   Evidence a holder can hand to someone else

   A holder regularly has to show a position to a party with no access to the register — a bank, a counterparty, an employer, a court. Today that is a PDF, and its weight comes from the letterhead on it. A register makes something better possible: a statement whose authenticity the recipient can verify against the register, or against a proof derived from it, that expires, that can be revoked, and that discloses only the fact being asserted rather than the surrounding table.

   Good first version: a signed statement of a single holding, with a verification path the recipient can follow without an account.

8. 20 · research, then open source

   Proofs over a register

   Many of the most valuable facts about a register are answers rather than contents: whether an issuer is under the Rule 12g5-1 holder-of-record threshold, whether a position exceeds what a lender requires, whether every holder in a class is eligible under the exemption relied on. Each is answered today by disclosing the register to whoever is asking. Proving them without disclosing is a well-understood problem in cryptography and an open one here.

   Good first version: one proof — a holder-of-record count below a threshold — with the statement, the circuit and the verification path public.

How to start

There is no application, no membership and no allocation

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.