Skip to content

OCF Architecture#

OCF is designed to be extremely expressive and extensible. Pay particular attention to vesting and conversion, which have both been designed to support the types of complex, bespoke vesting and conversion conditions commonly found on attorney-drafted options and convertibles yet are (today) challenging to model in a structured format

Event-Driven#

OCF is powered by an event-driven architecture. All Stocks, Plan Securities, Warrants and Convertibles have object-specific events that are added to an event "stack" to represent the history of that security. These events describe the relevant data needed to describe key events such as issuances, transfers, conversions, etc. You can see a full list of event transactions supported in our transactions schemas folder.

Here's an example of how an event stack would work to track the lifecycle of a single issuance of preferred stock:

Conversions#

The conversion of one OCF security into another is modeled using three key concepts which describe how, when and into what a convertible security converts into:

  1. Conversion Right: what can the security convert into?
  2. Conversion Trigger: when and under what conditions does the Conversion Right come into effect?
  3. Conversion Mechanism: how is the coversion amount calculated?

We use the same design patterns for convertible stock (e.g. preferred stock converting into common), warrants (which don't "convert" but can be "exercised") and convertible securities (e.g. notes).

Let's illustrate the design pattern using a convertible note as an example:

And here's what some sample data looks like in practice:

Lossless Vesting#

Our vesting data model supports arbitrarily-complex trees of dependent vesting conditions that can mix time-based and event-based vesting (e.g. vesting over time and "milestone" vesting, in any execution order with any desired dependencies). We are working on more comprehensive documentation for these concepts. In the meantime, please review the vesting terms object (essentially a "vesting schedule"). the vesting OCF Types in /schema/types/vesting, and the vesting events in /schema/objects/transactions/vesting (which are used to indicate when a given vesting schedule starts for a given security and when a milestone-based condition is satisfied).

You can see example vesting schedules in our samples.

Stay tuned for expanded documentation!

OCF File Type#

OCF is a multi-file format designed to make it easy to split, compress or stream company capitalization tables. A valid OCF cap table is made up of JSON objects that match the schemas available in our repo in the schemas folder.

OCF objects are grouped and stored in eight file types (defined in our file schemas folder.

There are currently 9 file types that make up a cap table:

  1. A Manifest File - The manifest holds basic issuer information and references to the instances of the other 7 file types needed to represent a company's capitalization history.
  2. Stakeholders File(s) - One or more files listing all stakeholders of the Company. Stakeholder types are enumerated in our standard, and we welcome comments on how to categorize stakeholders.
  3. Stock Classes File(s) - One or more files listing all classes / series of stock issued by the issuer.
  4. Stock Legend Templates File(s) - One or more files storing the legends used by the issuer.
  5. Stock Plans File(s) - One or more files storing the issuer's stock plans and related information.
  6. Transactions File(s) - One or more files storing the transactions for the issuers. Any of our transaction event objects are supported.
  7. Valuations File(s) - One or more files storing valuations for the issuer.
  8. Vesting Terms File(s) - One or more files storing vesting schedules used by the issuer.
  9. Financings File(s) - One or more files storing the issuer's financing events.

At the moment, we recommend combining all of these files into a single compressed file with a *.ocf.zip extension:

We are working on sample tooling to interact with compressed *.ocf.zip files.

You can also break out the various OCF Types and OCF Objects and make those available separately via API or other, suitable mechanism. The key part of OCF is the data structure, not the container itself, though, to ensure complete cap table integrity, a full cap table export is recommended.