Proposals Regarding Vesting Lifecycle #540
Replies: 6 comments 5 replies
-
|
Per the TWG discussion today - chiming in with some scenarios where we've seen amendments to vesting schedules taking place:
Regarding the latter scenario, one thing that comes to mind is whether capturing events in which options that will never vest could be "returned" to the available option count (for lack of a better description) is something we would want OCF to account for? e.g. Conditional/milestone-based vesting where the condition has failed to be met. |
Beta Was this translation helpful? Give feedback.
-
|
The latter scenario is addressed in the current schema by creating a vesting condition with a See example here. |
Beta Was this translation helpful? Give feedback.
-
|
Next steps from 2024-11-07 Technical Working Group Meeting
|
Beta Was this translation helpful? Give feedback.
-
|
Updated version posted 2024-11-18 |
Beta Was this translation helpful? Give feedback.
-
|
Revised 2024-11-19 to remove internal links, as those apparently are not supported in github discussions. |
Beta Was this translation helpful? Give feedback.
-
|
Two additional thoughts: Tie-breaks for EARLIER_OF relationships. I was a bit hasty to say we should entirely abandon the priority of vesting conditions in the Priority of |
Beta Was this translation helpful? Give feedback.
-
|
@MattCantor Still digesting after a few reads :) but it is making sense to me. I am currently thinking about this in three layers.
You have presented several use cases for vesting in your discussion:
Is this list an accurate read-back of your discussion? If so, do these use cases capture the "common real world" entirely and do we need all of them to capture the "common real world"?
Does this list capture them all and which ones of them are dependent on others? (i.e. which are alternatives and which are dependencies?) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Arthur. Here's the tldr summary of what's being proposed. None of them are contingent on the others. Proposals that require changing the schemaA. Introduce additional trigger types to indicate EARLIER_OF and LATER_OF relationships.
B. Add an optional C. Replace the
Proposals that do not require changing the schemaA. Allow vesting terms that can only be fully vested via an acceleration transaction. Provide a validation warning in these cases, rather than throwing a validation error. B. When both C. When both For Future ConsiderationA. Allow a Change Event to trigger a vesting condition, such as in the case of double-trigger acceleration. |
Beta Was this translation helpful? Give feedback.
-
|
Here's how I'd categorize the various kinds of vesting terms referenced above. Most common
The first three would utilize the EARLIER_OF relationship. However, they would be achievable under the current schema by utilizing the existing constraint that only one sibling node may enter the execution path, based on the ordering of the Two-tier vesting would also rely on enforcing a rule that whenever we create a vesting installment:
This rule is required for two-tier vesting regardless of whether the proposals above are adopted. Less common
The first would utilize the EARLIER_OF relationship. However, it would be achievable under the current schema with significant attention to the set-up and a lot of duplicated nodes. The second would utilize both the EARLIER_OF and LATER_OF relationships. However, it would be achievable under the current schema with significant attention to the set-up and a lot of duplicated nodes. Alternatively both could be achieved with indeterminate vesting terms and relying on an acceleration transaction. |
Beta Was this translation helpful? Give feedback.
-
|
An implementation of the vesting model with the EARLIER_OF and LATER_OF relationships is available in this branch of the OCF-Tools repository |
Beta Was this translation helpful? Give feedback.
-
|
The proposals in this discussion have been included in issues #542, #539, and #514. |
Beta Was this translation helpful? Give feedback.
-
This document provides a deep dive into the vesting model (v.1.2.0).
We begin with an inventory of the files, transactions, objects, types, and enums that are included in the vesting model.
Then we analyze the vesting model and attempt to articulate the assumptions on which it is based and describe certain of its characteristics.
Finally we consolidate various proposals to modify the schema as it pertains to the vesting model.
The first proposal represents a significant change to the workings of the model. So it should be read as a "softer" proposal than the ones that follow.
My hope is that even if we do not adopt the first proposal, others may benefit from the deep dive regardless and that certain sections may serve as the basis for additional documentation.
Inventory
The following files, transactions, objects, types, and enums are included in the vesting model (v.1.2.0):
Files
OCF_TRANSACTIONS_FILEOCF_VESTING_TERMS_FILETransactions
TX_EQUITY_COMPENSATION_ISSUANCETX_STOCK_ISSUANCETX_EQUITY_COMPENSATION_ACCEPTANCETX_VESTING_STARTTX_VESTING_EVENTTX_VESTING_ACCELERATIONTX_EQUITY_COMPENSATION_CANCELLATIONObjects
VestingTermsTypes
VestingVestingConditionVestingConditionPortionVestingEventTriggerVestingPeriodInDaysVestingPeriodInMonthsVestingScheduleAbsoluteTriggerVestingScheduleRelativeTriggerVestingStartTriggerEnums
AllocationTypeCompensationTypeOptionTypeVestingDayOfMonthVestingTriggerTypeDesign Overview
Vesting Terms
The vesting model is intended to support arbitrarily-complex trees of dependent vesting conditions that can mix time-based and event-based vesting.
Vesting information is stored in
VestingTermsobjects, each of which expresses the vesting terms for an equity award as a graph ofVestingConditions.Each
VestingCondition(node) in the graph specifies theVestingTrigger(edge) for entering that condition, upon which someVestingConditionPortionorquantityof the associated equity award vests.Each
VestingConditionalso then lists all possible subsequent conditions in thenext_condition_idsfield. An empty array in thenext_condition_idsfield indicates a terminal node in the graph and the end of vesting.A
TX_EQUITY_COMPENSATION_ISSUANCEtransaction is associated with aVestingTermsobject via the transaction'svesting_terms_id.VestingTermsobjects are generally more verbose thanTX_EQUITY_COMPENSATION_ISSUANCEtransactions. Therefore, we prioritize the re-use ofVestingTermsobjects where possible, even if this requires more transactions to be recorded.Vesting Triggers
There are four types of
VestingTriggers:VestingStartTrigger. Describes the vesting condition that sets a vesting schedule in motion, via the recording of a transaction.
VestingConditionin aVestingTermsobject to facilitate re-use of theVestingTermsobject for multiple equity awards. For instance, an array of vesting conditions that describes a 4-year monthly vesting schedule can be used for multiple awards if the vesting start date is triggered "from the outside" via recording a transaction.VestingEventTrigger. Describes a vesting condition satisfied when a particular unscheduled event occurs. Functionally equivalent to the
VestingStartTrigger, but semantically implies unscheduled event-based vesting, such as the achievement of a performance goal.VestingScheduleRelativeTrigger. Describes a vesting condition satisfied when another vesting condition is satisfied, or when a period of time has elapsed since that vesting condition was satisfied. See further discussion below.
VestingScheduleAbsoluteTrigger. Describes a vesting condition satisfied on an absolute date. This type of trigger does not require a transaction to be recorded. Instead this trigger is satisfied implicitly via the passage of time.
VestingScheduleAbsoluteTriggeris used as the initialVestingConditionin aVestingTermsobject, then the vesting schedule would be set in motion implicitly via the passage of time, rather than requiring a separate transaction to be recorded. However, theVestingTermsobject would not be reusable for an equity award with a different vesting start date.Assumptions
The discussion that follows is based on the following assumptions:
Each graph of
VestingConditionsis required to be directed and acyclic. Below we discuss whether we permit multiple root nodes, and whether branches are allowed to converge.A vesting condition is considered to be within the execution path of the vesting graph if and only if that vesting condition's trigger has been satisfied.
The vesting conditions in a
next_condition_idsarray are evaluated in the order in which they appear in the array, and the execution path will follow only one of the vesting conditions in the array. If a vesting condition's trigger is satisfied, any subsequent vesting conditions in the array will not be analyzed. See example two here.Vesting schedules are ultimately ordered chronologically, with a monotonic progress of time.
Validation and Pathfinding
We further assume that that we will require two traversals in order to create the vesting graph and then determine the execution path through it.
First Traversal
The first traversal will create the vesting graph and validate that it is directed and acyclic. This traversal should be uncoupled with business logic, as it pertains solely to the structure of the vesting graph.
Second Traversal
The second traversal determines determines which nodes are included in the execution path as a result of their triggers having been satisfied, whether as a result of a transaction being recorded or implicitly via the passage of time.
Creating a Vesting Schedule
When vesting condition is included in the execution path as a result its trigger having been satisfied, a vesting installment is created, consisting of an amount of shares that vest as of a specific date.
The vesting schedule of a security is the collection of all vesting installments that have been created.
Creating a Vesting Schedule Via Vesting Conditions
The approach described above constructs the vesting graph from vesting conditions, with the vesting triggers acting as rules for determining how vesting installments should be created.
Normal Case
When utilizing this approach, the vesting date of each vesting installment is determined based on the vesting trigger that was utilized:
VestingStartTrigger, the vesting date is the date of theTX_VESTING_STARTtransaction,VestingEventTrigger, the vesting date is the date of theTX_VESTING_EVENTtransaction,VestingScheduleAbsoluteTrigger, the vesting date is date provided in thedatefield of the trigger object.The amount of vested shares is determined from the
portionorquantityfield of the applicable vesting condition.Special Case - Vesting Schedule Relative Trigger
Overview
The
VestingScheduleRelativeTriggeris a special case which signifies a vesting condition that is not triggered by the recording of a transaction or implicitly via the passage of time.Instead, this trigger is utilized when the vesting date is intended to be determined relative to another vesting condition in the execution path.
It may also be utilized to create a collection of vesting installments under the hood, which would be onerous to create by hand and would likely not be re-usable for other securities.
Utilization
The trigger's
relative_to_condition_idfield indicates the "earlier" vesting condition that is being "referred back to".The trigger must include one of two types of
periodobjects - one of which designates a monthly cadence, and the other of which designates a daily cadence.Each
periodobject includes fields fortype,lengthandoccurrences. Aday_of_monthfield is also included to determine the vesting dates, in the case of a monthly- or yearly-based periodic vesting schedule.The
lengthfield designates the duration of the monthly or daily cadence, in the form of an integer which may be zero. Theoccurrencesfield designates the quantity of installments to be created under the hood, in the form of an integer one or greater.A
lengthof zero would indicate a vesting condition with the same vesting date as the "related" vesting condition referenced in therelative_to_condition_idfield.When
lengthandoccurrencesare both greater than one, a periodic vesting schedule is created under the hood.Since the duration of the monthly or daily cadence is designated by the
lengthfield and does not change, this creates a periodic vesting schedule with an equal number of shares vesting in each installment, other that to the extent required to take into account rounding of partial shares as indicated by theallocation_typefield in theVestingTermsobject.For example, the following
periodobject would produce a 4-year monthly vesting schedule with equal amounts vesting in each installment, other than to the extent required to take into account rounding:{ "length": 1, "type": "MONTHS", "occurrences": "48", "day_of_month": "VESTING_START_DAY_OR_LAST_DAY_OF_MONTH" }If the vesting condition referred to in the
relative_to_condition_idfield is not in the execution graph, then no vesting installments should be created under the hood. See the Two Tier Vesting example below.Below we discuss methods for implementing a cliff vesting date with this sort of periodic time-based vesting.
Creating a Vesting Schedule Imperatively
The model alternatively supports creating a vesting schedule imperatively, by providing an array of objects each consisting of an amount of shares vesting and a specific vesting date. Each of these objects is referred to in the schema as a
Vesting.{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://schema.opencaptablecoalition.com/v/1.2.0/types/Vesting.schema.json", "title": "Type - Vesting", "description": "Describes an exact vesting date and amount", "type": "object", "properties": { "date": { "description": "Date the vesting occurred or will occur", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/Date.schema.json" }, "amount": { "description": "Quantity of shares which vested or will vest", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/Numeric.schema.json" } }, "required": ["date", "amount"], "additionalProperties": false, "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/v1.2.0/schema/types/Vesting.schema.json" }REQUIREDREQUIREDExamples
Event Based Vesting with Expiration
This example shows event based vesting with an expiration date.
The event condition and the expiration condition are siblings nodes in the vesting graph, and they are processed in the second traversal based on their order in the
next_condition_idsarray of the vesting start condition.As noted above, the execution path may only follow one sibling node. In this way the sibling nodes behave as mutually exclusive nodes in an XOR relationship.
The ordering of the conditions in the
next_condition_idsis crucial. Since the expiration condition is a leaf node with 0 shares vesting, if its condition is satisfied then the execution path will terminate at that node.The only way for any shares to vest in this example is for the expiration trigger to not be satisfied, so that the event condition can be triggered. Any
TX_VESTING_EVENTtransaction recorded after the expiration condition has been triggered will be ignored.graph Start[ Vesting Start --- quantity: 0 ] Expiration[ Relative Expiration --- quantity: 0 ] QualifyingSale[ Event Condition --- portion: 1/1 ] Start -- First Priority --> Expiration Start -- Second Priority --> QualifyingSaleTwo Independent Events With Expiration Dates
Consider a security with two independent event-based vesting conditions, and each event has its own expiration date. For instance, 1/4 of the shares vest whenever event A is achieved, and the remaining 3/4 of the shares vest whenever event B is achieved.
A vesting installment should be created whenever the trigger for condition A or condition B is satisfied, and each is independent of the other. Both should be allowed to enter the execution path, even if they occur on different dates.
The way to approach this is to define all possible permutations and then ensure there is a branch that addresses each. In other words,
in this scenario we are forced into an imperative paradigm.
For this example, we'll assume the expiration date for event A is before the expiration date for event B.
At first glance it may appear that there are 8 permutations:
However, we know that A cannot occur or expire after B has expired.
Therefore there are only 7 permutations:
This requires care to set up correctly, and a lot of nodes.
graph %% nodes start[ Vesting Start --- quantity: 0 ] %% A expires Aexpires[ Event A Expiration --- quantity: 0 ] Aexpires_Bexpires[ Event B Expiration --- quantity: 0 ] Aexpires_Boccurs[ Event B --- portion: 3/4 ] %% A occurs first Afirst_Aoccurs[ Event A --- portion: 1/4 ] Afirst_Bexpires[ Event B Expiration --- quantity: 0 ] Afirst_Boccurs[ Event B --- portion: 3/4 ] %% B expires Bexpires[ Event B Expiration --- quantity: 0 ] %% B occurs first Bfirst_Boccurs[ Event B --- portion: 3/4 ] Bfirst_Aexpires[ Event A Expiration --- quantity: 0 ] Bfirst_Aoccurs[ Event A --- portion: 1/4 ] %% arrows %% first priority start -- First Priority --> Aexpires Aexpires -- First Priority --> Aexpires_Bexpires Aexpires -- Second Priority --> Aexpires_Boccurs %% second priority start -- Second Priority --> Afirst_Aoccurs Afirst_Aoccurs -- First Priority --> Afirst_Bexpires Afirst_Aoccurs -- Second Priority --> Afirst_Boccurs %% third priority start -- Third Priority --> Bexpires %% fourth priority start -- Fourth Priority --> Bfirst_Boccurs Bfirst_Boccurs -- First Priority --> Bfirst_Aexpires Bfirst_Boccurs -- Second Priority --> Bfirst_AoccursOne may suggest that these two vesting conditions could in principal be separated into separate securities. But it would be unfortunate if we had to impose this real world constraint.
Interdependent Events with Expiration Dates
Consider the same security as above, except that vesting only occurs once the outcome of both events has been resolved. 1/4 of the shares will vest if event A is achieved, and the remaining 3/4 of the shares will vest if event B is achieved.
But vesting will not occur until it is known whether both events have been achieved or will expire, and we don't know which of event A or B will occur first.
This example utilizes the same vesting graph as the example above, except that we must ensure that the proper number of shares vest in the terminal node of each branch.
graph %% nodes start[ Vesting Start --- quantity: 0 ] %% A expires Aexpires[ Event A Expiration --- quantity: 0 ] Aexpires_Bexpires[ Event B Expiration --- quantity: 0 ] Aexpires_Boccurs[ Event B --- portion: 3/4 ] %% A occurs first Afirst_Aoccurs[ Event A --- quantity: 0 ] Afirst_Bexpires[ Event B Expiration --- portion: 1/4 ] Afirst_Boccurs[ Event B --- portion: 1/1 ] %% B expires Bexpires[ Event B Expiration --- quantity: 0 ] %% B occurs first Bfirst_Boccurs[ Event B --- quantity: 0 ] Bfirst_Aexpires[ Event A Expiration --- portion: 3/4 ] Bfirst_Aoccurs[ Event A --- portion: 1/1 ] %% arrows %% first priority start -- First Priority --> Aexpires Aexpires -- First Priority --> Aexpires_Bexpires Aexpires -- Second Priority --> Aexpires_Boccurs %% second priority start -- Second Priority --> Afirst_Aoccurs Afirst_Aoccurs -- First Priority --> Afirst_Bexpires Afirst_Aoccurs -- Second Priority --> Afirst_Boccurs %% third priority start -- Third Priority --> Bexpires %% fourth priority start -- Fourth Priority --> Bfirst_Boccurs Bfirst_Boccurs -- First Priority --> Bfirst_Aexpires Bfirst_Boccurs -- Second Priority --> Bfirst_AoccursPeriodic Vesting with a Cliff
A periodic vesting schedule with a cliff is created with:
VestingScheduleRelativeTriggerthat refers back to the vesting start condition, andVestingScheduleRelativeTriggerthat refers back to the cliff condition.See example here.
The periodic vesting condition is displayed in the graph below as a stack in order to convey that it utilizes the
periodobject to create a collection of vesting installments.The blue arrows in the graph below only indicate the vesting condition's
relative_to_condition_id, and do not constitute cycles in the vesting graph.Presumably we also enforce a constraint that the vesting condition referenced in
relative_to_condition_idmust be in the execution path?graph Start[ Vesting Start --- quantity: 0 ] Cliff[ Cliff --- portion: 12/48 ] Periodic@{ shape: docs, label: "Periodic Vesting<br>---</br>portion: 1/48"} Start --> Cliff --> Periodic Cliff -. relative to .-> Start Periodic -. relative to .-> Cliff linkStyle 2,3 stroke:#1E90ff, color:#1E90ff{ "id": "4yr-1yr-cliff-schedule", "object_type": "VESTING_TERMS", "name": "Four Year / One Year Cliff", "description": "25% of the total number of shares shall vest on the one-year anniversary of this Agreement, and an additional 1/48th of the total number of Shares shall then vest on the corresponding day of each month thereafter, until all of the Shares have been released on the fourth anniversary of this Agreement.", "allocation_type": "CUMULATIVE_ROUNDING", "vesting_conditions": [ { "id": "vesting-start", "quantity": "0", "trigger": { "type": "VESTING_START_DATE" }, "next_condition_ids": [ "cliff" ] }, { "id": "cliff", "description": "25% payout at 1 year", "portion": { "numerator": "12", "denominator": "48" }, "trigger": { "type": "VESTING_SCHEDULE_RELATIVE", "period": { "length": 12, "type": "MONTHS", "occurrences": 1, "day_of_month": "VESTING_START_DAY_OR_LAST_DAY_OF_MONTH" }, "relative_to_condition_id": "vesting-start" }, "next_condition_ids": [ "monthly-thereafter" ] }, { "id": "monthly-thereafter", "description": "1/48th payout each month thereafter", "portion": { "numerator": "1", "denominator": "48" }, "trigger": { "type": "VESTING_SCHEDULE_RELATIVE", "period": { "length": 1, "type": "MONTHS", "occurrences": 36, "day_of_month": "VESTING_START_DAY_OR_LAST_DAY_OF_MONTH" }, "relative_to_condition_id": "cliff" }, "next_condition_ids": [] } ] }Both the cliff and the periodic vesting condition utilize the
allocation_typefrom theVestingTermsobject that contains this array of vesting conditions.However, this runs into a problem with certain allocation types, as discussed in OCF Issue #514.
Consider a grant of 125 options that is intended to vest over 10 periodic installments, with an allocation type of
CUMULATIVE_ROUND_DOWNand a cliff at the 5th installment.How does the periodic vesting condition that follows the cliff know that there a cumulative remainder of 0.5 shares after the cliff installment?
We propose a way to handle this below.
Two Tier Vesting
Consider a security with time-based vesting schedule where an event serves as the vesting commencement date, and the event may expire before it occurs.
This is straight forward to implement under the vesting model.
graph %% nodes start[ Vesting Start --- quantity: 0 ] expiration[ Event Expiration --- quantity: 0 ] event[ Event Condition --- quantity: 0 ] periodic@{ shape: docs, label: "Periodic Vesting<br>---</br>portion: 1/48"} start -- First Priority --> expiration start -- Second Priority --> event event --> periodic periodic -. refers to .- event linkStyle 3 stroke:#1E90ff, color:#1E90ffNow instead consider a security where the event is a vesting condition, but the periodic vesting refers back to the start date.
This is an example of "two-tier" vesting, which is a common approach for private company restricted stock units.
Overview of Two Tier Resting
A two-tier RSU vests based on two requirements: a time-based requirement and an event-based requirement, both of which must be achieved in order for the shares to vest.
The event-based requirement is typically a "liquidity event", meaning a change in control or IPO. The event-based requirement typically has an expiration date, after which it can no longer be achieved (typically 7 years from the grant date).
If the liquidity event is achieved before the end of the time-based vesting schedule, then the RSU vests at the time of the liquidity event to the extent that the time-based vesting requirement has been satisfied. The RSU then continues to vest after the liquidity event in accordance with the remainder of the time-based vesting schedule.
If the liquidity event is achieved after the end of the time-based vesting schedule, then the RSU vests in full upon th eachievement of the liquidity event.
If the liquidity event is not achieved, then the RSU never vests.
The Liquidity Event Behaves as a Cliff
The liquidity event conceptually behaves as a cliff, because the periodic vesting does not start until the later of the liquidity event and the vesting start date of the periodic vesting schedule. Except unlike a standard cliff, it is based on an unscheduled event, rather than on a certain vesting installment or date.
Note that if the time-based vesting schedule has its own cliff, then the RSU first vests at the later of the liquidity event and the cliff installment.
Vesting Graph
This utilizes the same vesting graph as described above, except that the periodic vesting schedule refers back to the vesting start condition,
rather than to the event condition.
Recall that in the case of time-based vesting with a
VestingScheduleRelativeTrigger, theperiodobject creates a collection of vesting installments under the hood.How would we ensure that that the liquidity event behaves as a cliff for the periodic vesting schedule?
Perhaps it would be reasonable to introduce additional business logic such that:
the vesting date cannot be earlier than the date of any ancestor node in the execution path, and
This would have the effect treating the event condition as a cliff for the periodic vesting condition that follows.
graph %% nodes start[ Vesting Start --- quantity: 0 ] expiration[ Event Expiration --- quantity: 0 ] event[ Event Condition --- quantity: 0 ] periodic@{ shape: docs, label: "Periodic Vesting<br>---</br>portion: 1/48"} start -- First Priority --> expiration start -- Second Priority --> event event --> periodic periodic -. refers to .- start linkStyle 3 stroke:#1E90ff, color:#1E90ffObservations regarding sibling nodes
The vesting model assumes all siblings are EARLIER_OF
As shown above, the vesting model forces all sibling nodes into an XOR relationship,
by way of the assumption that sibling nodes will be evaluated in the order in which they appear in the parent node's
next_condition_idsarray, and the execution path will only follow the vesting condition that occurs first in time.This has the effect of creating an EARLIER_OF relationship between sibling nodes.
Creating AND relationships is complex
Since sibling nodes are in an EARLIER_OF relationship, creating an AND relationship requires care and familiarity with the workings of the model, because each possible permutation of the events must be enumerated explicitly.
AND relationships are synonymous with LATER_OF
We may also observe that in the case of a security that vests based on a requirement that more than one vesting condition occurs,
the vesting installment cannot be created until the "later of" the dates that the vesting conditions are achieved.
Likewise, in the case of a security that vests based on the later of two vesting conditions, each vesting condition must "wait and see" what happens with the other.
Therefore LATER_OF vesting behaves as an AND logical relationship.
The amount that vests may be determined by various methods
The LATER_OF distinction implies a focus on the date of the vesting installment. But what about the the amount that vests?
In most cases of an AND relationship, either:
the amount that vests is determined by aggregating the amounts from the sibling nodes, or
one of the sibling nodes operates only with respect to the date dimension and does not contribute to the amount vested.
Interdependent events is an example of the former.
As shown in the Independent Events With Expiration Dates example above, we aggregated the amounts in the terminal node of the execution path. But other methods are common, such as determining the amount that vests based on the greater of, lesser of, average, or other methodology.
Two-tier vesting is an example of the latter. The liquidity event condition acts as a cliff (delays the ultimate vesting date), but does not influence the quantity of shares that vest.
Independent events are forced to be modeled as AND relationships
Given that the vesting model forces all sibling nodes into an XOR relationship, independent events must be modeled as an AND relationship, with the permutations of the two independent events enumerated explicitly, as shown above.
We discuss proposals to address these observations below.
Vesting Schedule Generator
Before moving on to the proposals, we summarize the business logic required in the second traversal of the vesting graph in order to create the vesting installments that comprise a vesting schedule.
Identify the root nodes of the graph (if more than one root node is permitted).
Traverse the vesting conditions from [each] root note in order to create the vesting graph and validate that it is directed and acyclical.
Traverse the graph from [each] root node a second time to determine which vesting conditions are in the execution path, based on whether the vesting condition's trigger has been satisfied.
If two vesting conditions are sibling nodes, enforce the constraint that only one sibling node will enter the execution path, based on which vesting condition is achieved first.
If the vesting condition utilizes a
VestingScheduleRelativeTriggerto create a periodic time-based vesting schedule:use the
periodobject to create a collection of vesting installments under the hood, so long as the vesting condition referenced inrelative_to_condition_idis in the execution path.If the period time-based vesting schedule utilizes a cliff, implement the cliff when recording the vesting installments.
Create a vesting installment for each vesting condition in the execution path. Ensure that the vesting date occurs no later than the date of any ancestor node, and accumulate any shares that would have vested on an earlier vesting date.
Proposals
EARLIER_OF and LATER_OF Relationships
As seen above, creating AND logic within the current model is complex and requires familiarity with how the ordering of the vesting conditions in the
next_condition_idsarray impacts the second traversal.Similarly, creating expiration dates via leaf nodes with 0 quantity of vesting shares relies on business logic to enforce the constraint that only one sibling node will be included in the execution path, based on whichever occurs first in time.
Perhaps we could facilitate both of these while making the business logic we are relying on more explicit.
Enum - Vesting Trigger Type
Current Implementation
{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://raw.githubusercontent.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/main/schema/enums/VestingTriggerType.schema.json", "title": "Enum - Vesting Trigger Type", "description": "Enumeration of vesting trigger types", "type": "string", "enum": [ "VESTING_START_DATE", "VESTING_SCHEDULE_ABSOLUTE", "VESTING_SCHEDULE_RELATIVE", "VESTING_EVENT" ], "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/main/schema/enums/VestingTriggerType.schema.json" }Proposed Implementation
Add
VESTING_RELATIONSHIP_LATER_OFandVESTING_RELATIONSHIP_EARLIER_OFtheenumfield.Enum - Later Of Calculation Type
Proposed Implementation
{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://raw.githubusercontent.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/main/schema/enums/LaterOfCalculationType.schema.json", "title": "Enum - Later Of Calculation Type", "description": "Enumeration of methods for determining the amount of shares vesting for a vesting condition with a `VESTING_LATER_OF` trigger, based on the amounts vested from the input conditions.", "type": "string", "enum": [ "SUM", "MAX", "MIN", "MEAN", "MODE" ], "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/main/schema/enums/LaterOfCalculationType.schema.json" }LATER_OF Vesting Trigger Type
Proposed Implementation
{ "$schema": "https://json-schema.org/draft-07/schema", "$id": "https://raw.githubusercontent.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCT/main/schema/types/vesting/VestingLaterOfTrigger.schema.json", "description": "Describes a vesting condition satisfied only if *all* vesting conditions referred to in `input_condition_ids` are also satisfied.", "type": "object", "allOf": [ { "$ref": "https://raw.githubusercontent.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/main/schema/primitives/types/vesting/VestingConditionTrigger.schema.json" } ], "properties": { "type": { "const": "VESTING_RELATIONSHIP_LATER_OF" }, "input_condition_ids": { "description": "The conditions that all must be satisfied for this vesting condition to be satisfied.", "type": "array", "items": { "type": "string" }, "uniqueItems": true }, "calculation_type": { "description": "Method for determining the amount of shares vesting for this vesting condition, based on the amounts vested from the input conditions.", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/enums/QuantityTreatment.schema.json" } }, "required": ["input_condition_ids", "calculation_type"], "additionalProperties": false, "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/main/schema/types/vesting/VestingLaterOfTrigger.schema.json" }VESTING_RELATIONSHIP_LATER_OFREQUIREDSTRING]REQUIREDEnum - Quantity TreatmentONE OF:
- SUM
- MIN
- MAX
- MEAN
- MODE
REQUIREDEARLIER_OF Vesting Trigger Type
Proposed Implementation
{ "$schema": "https://json-schema.org/draft-07/schema", "$id": "https://raw.githubusercontent.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCT/main/schema/types/vesting/VestingEarlierOfTrigger.schema.json", "description": "Describes a vesting condition that selects one of the vesting conditions referred to in `input_conditions_id`, based on the first to occur in time.", "type": "object", "allOf": [ { "$ref": "https://raw.githubusercontent.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/main/schema/primitives/types/vesting/VestingConditionTrigger.schema.json" } ], "properties": { "type": { "const": "VESTING_RELATIONSHIP_EARLIER_OF" }, "input_condition_ids": { "description": "The conditions from which the first to occur in time will be selected by this vesting condition.", "type": "array", "items": { "type": "string", }, "uniqueItems": true }, }, "required": ["input_condition_ids"], "additionalProperties": false, "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/main/schema/types/vesting/VestingEarlierOfTrigger.schema.json" }VESTING_RELATIONSHIP_EARLIER_OFREQUIREDSTRING]REQUIREDExamples
In this section we provide examples of common vesting terms utilizing this proposal.
All of the examples below make use of the following
TX_EQUITY_COMPENSATION_ISSUANCEtransaction:Event Based Vesting With Expiration
Using an EARLIER_OF relationship makes transparent that business logic will be used to ensure that only one of the sibling nodes will enter the execution path.
graph %% Nodes start[Vesting Start] event[ Event Condition --- portion: 1/1 ] expiration[ Event Expiration --- portion: 0/1 ] EARLIER_OF{{ EARLIER Of --- Event Condition Event Expiration }} start --> event event -. refers to .-> start start --> expiration event --> EARLIER_OF expiration --> EARLIER_OF linkStyle 1 stroke:#1E90ff, color:#1E90ffTwo Independent Events with Expiration Dates
We are no longer required to explicitly enumerate all possible permutations, thereby facilitating a more declarative paradigm.
We also save the need for duplicate versions of the same vesting condition, at the cost of creating two new vesting conditions to represent the relationships.
Each EARLIER_OF relationship selects a vesting condition to include in the execution path.
By allowing more than one sibling node to be included in the execution path, we can simply allow a vesting installment to be created once the relationship is resolved.
graph %% nodes start[ Vesting Start --- quantity: 0 ] eventA[ Event A --- portion: 1/4 ] eventB[ Event B --- portion: 3/4 ] eventB_expiration[ Event B Expiration --- quantity: 0 ] eventA_expiration[ Event A Expiration --- quantity: 0 ] %% relationships EARLIER_OF_A{{ EARLIER OF --- Event A Event A Expiration }} EARLIER_OF_B{{ EARLIER OF --- Event B Event B Expiration }} start --> eventA start --> eventA_expiration eventA_expiration -. refers to .-> start start --> eventB start --> eventB_expiration eventB_expiration -. refers to .-> start eventA --> EARLIER_OF_A eventA_expiration --> EARLIER_OF_A eventB --> EARLIER_OF_B eventB_expiration --> EARLIER_OF_B linkStyle 2,5 stroke:#1E90ff, color:#1E90ffInterdependent Events with Expiration Dates
In the case of interdependent events where only a single vesting installment is intended, we utilize the vesting graph from the example above with an additional LATER_OF relationship.
We ensure that the correct number of shares vest in the final installment by utilizing the
calculation_typefield.graph %% nodes start[ Vesting Start --- quantity: 0 ] eventA[ Event A --- portion: 1/4 ] eventB[ Event B --- portion: 3/4 ] eventB_expiration[ Event B Expiration --- quantity: 0 ] eventA_expiration[ Event A Expiration --- quantity: 0 ] %% relationships EARLIER_OF_A{{ EARLIER OF A & EXPIRATION --- Event A Event A Expiration }} EARLIER_OF_B{{ EARLIER OF B & EXPIRATION --- Event B Event B Expiration }} LATER_OF_A&B{{ LATER OF A & B -- EARLIER OF A & EXPIRATION EARLIER OF B & EXPIRATION --- calculation_type: SUM }} start --> eventA start --> eventA_expiration start --> eventB start --> eventB_expiration eventA --> EARLIER_OF_A eventA_expiration --> EARLIER_OF_A eventB --> EARLIER_OF_B eventB_expiration --> EARLIER_OF_B EARLIER_OF_A --> LATER_OF_A&B EARLIER_OF_B --> LATER_OF_A&BTwo-Tier Vesting
This is essentially the same pattern as the Two Tier Vesting example above, other than the EARLIER_OF relationship to signal the business logic used for the liquidity condition and its expiration. The event condition includes a reference to the relative condition, in order to indicate how the execution path should proceed in the event the event condition occurs first.
This would rely on the business logic rule described above to ensure that the liquidity event operates as a cliff for the periodic vesting schedule.
graph %% nodes start[Vesting Start Date] liquidity[ Liquidity Condition --- quantity: 0 ] expiration[ Liquidity Expiration --- quantity: 0 ] periodic@{ shape: docs, label: "Periodic Vesting<br>---</br>portion: 1/48"} %% relationships EARLIER_OF_EVENT{{ EARLIER OF LIQUIDITY & EXPIRATION -- Liquidity Condition Liqudity Expiration }} start --> expiration expiration -. refers to .-> start start --> liquidity periodic -. refers to .-> start liquidity --> EARLIER_OF_EVENT liquidity --> periodic expiration --> EARLIER_OF_EVENT EARLIER_OF_EVENT --> periodic linkStyle 1,3 stroke:#1E90ff, color:#1E90ffIndeterminate Vesting Terms
There are some vesting terms that we will not be able to describe as a vesting graph, such as vesting contingent on the achievement of a performance goal, where the amount of vested shares depends on the degree to which the goal is achieved.
For instance, consider a restricted stock unit over 2X shares, where X shares vest if the company achieves $Y of revenue, all 2X shares vest if the company achieves $2Y of revenue, and in the case of revenue between $Y and $2Y, the number of shares that vest is determined by interpolating between the two thresholds.
Given the that any quantity of shares between X and 2X may ultimately vest (or 0 shares), it would be unmagageable to encode all possible outcomes in a
VestingTermsobject.Should we include a way to indicate that the intent is to create indeterminate vesting terms?
For instance, to create the vesting terms above we could require only an initial vesting condition with a
VestingStartTrigger, followed by a vesting condition with an e.g.,VESTING_SCHEDULE_INDETERMINATEtrigger. This would semantically indicate that the vesting schedule is intentionally leaving some shares that can only be vested via an acceleration transaction.If a
VESTING_SCHEDULE_INDETERMINATEtrigger isn't provided, then we'd throw a validation error if a vesting graph does not include any execution paths that would result in all shares vesting.Or alternatively we could allow vesting terms that can only be fully vested via an acceleration transaction, without requiring any indication that it was intentional, and instead of throwing a validation error we could provide a validation warning.
Handling Employment Terminations
The vesting model tacitly assumes we are concerned with service-based vesting.
Continued employment is therefore an implicit vesting condition within each
VestingTermsobject. Utilizing the framework described above, every vesting condition is in an implicit EARLIER_OF relationship an employment termination event.Cliff
As discussed in the Periodic Vesting With a Cliff example above, the exact number of shares that should vest on a cliff requires first applying the
VestingScheduleRelativeTriggerwith the relevantAllocationTypefrom theVestingTerms, in order to determine the number of shares that would have vested on each installment prior to and including the cliff installment, as well as any fractional shares remaining after the cliff installment.However, the current implementation of
VestingConditionsinstead assumes that we will resolve theVestingStartTrigger, then move to the cliff condition, and then to theVestingScheduleRelativeTrigger.Vesting Period Primitive Type
Current Implementation
{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/types/vesting/VestingPeriod.schema.json", "title": "Primitive - Vesting Period Type", "description": "Abstract type describing the fields common to all periods of time (e.g. 3 months, 365 days) for use in Vesting Terms", "type": "object", "properties": { "length": { "description": "The quantity of `type` units of time; e.g. for 3 months, this would be `3`; for 30 days, this would be `30`", "type": "integer", "minimum": 0 }, "type": { "description": "The unit of time for the period, e.g. `MONTHS` or `DAYS`", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/enums/PeriodType.schema.json" }, "occurrences": { "description": "The number of times this vesting period triggers. If vesting occurs monthly for 36 months, for example, this would be `36`", "type": "integer", "minimum": 1 } }, "required": ["length", "type", "occurrences"], "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/v1.2.0/schema/primitives/types/vesting/VestingPeriod.schema.json" }INTEGERtypeunits of time; e.g. for 3 months, this would be3; for 30 days, this would be30REQUIREDEnum - Period TypeDescription: Enumeration of time period types
ONE OF:
• DAYS
• MONTHS
• YEARS
MONTHSorDAYSREQUIREDINTEGER36REQUIREDProposed Implementation
Add the following optional field to the
propertiesobject:INTEGERExample
The classic 4-year monthly vesting schedule with a 1-year cliff is created with:
VestingStartTriggerVestingScheduleRelativeTrigger, andTX_VESTING_STARTtransaction to set the vesting schedule in motion.A cliff is added to the period vesting schedule by designating a
cliff_installmentin theperiodobject of theVestingScheduleRelativeTrigger.The
vesting_schedule_generatorutility inOCF-Toolscalculates the periodic time-based vesting schedule, but accrues and aggregates the amounts that vests on each installment until it reaches thecliff_installment.graph TD InstallmentCheck[Are there any remaining installments?] InstallmentCheck -- Yes --> CliffCheck[Have we reached the cliff?] CliffCheck -- No --> IncrementInstallment[Increment Installment] --> InstallmentCheck CliffCheck -- Yes --> Record[Create Installment] --> IncrementInstallment InstallmentCheck -- No --> StopAcceleration
As discussed in OCF Issue #538, the current implementation of
TX_VESTING_ACCELERATIONis ambiguous in the case of a partial acceleration.Specifically, if the
quantityis less than the total remaining number of unvested shares, it is unclear which vesting installments the vesting acceleration is intended to apply to.The most typical approach is for a partial vesting acceleration to apply 'pro-rata' across all unvested shares. In other words, the cadence and duration of the vesting schedule remains the same, but the quantity that vests on each remaining installment is reduced proportionally.
But other approaches are available, such as:
We could address this ambiguity as follows:
Current Implementation
{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://schema.opencaptablecoalition.com/v/1.2.0/objects/transactions/vesting/VestingAcceleration.schema.json", "title": "Object - Vesting Acceleration Transaction", "description": "Object describing an acceleration of vesting, in which additional shares vest ahead of the schedule specified in security's vesting terms.", "type": "object", "allOf": [ { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/Object.schema.json" }, { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/transactions/Transaction.schema.json" }, { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/transactions/SecurityTransaction.schema.json" } ], "properties": { "object_type": { "const": "TX_VESTING_ACCELERATION" }, "quantity": { "description": "Number of shares vesting ahead of schedule", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/Numeric.schema.json" }, "reason_text": { "description": "Reason for the acceleration; unstructured text", "type": "string" }, "id": {}, "comments": {}, "date": {}, "security_id": {} }, "additionalProperties": false, "required": ["quantity", "reason_text"], "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/v1.2.0/schema/objects/transactions/vesting/VestingAcceleration.schema.json" }STRINGREQUIREDSTRING]TX_VESTING_ACCELERATIONDefined in [schema/enums/ObjectType]
REQUIREDREQUIREDSTRINGidfield which identifies the issuance transaction object itself. All future transactions on the security (e.g. acceptance, transfer, cancel, etc.) must reference thissecurity_idto qualify which security the transaction applies to.REQUIREDREQUIREDSTRINGREQUIREDEnum - Allotment_Type
Proposed Implementation
{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://schema.opencaptablecoalition.com/v/1.2.0/enums/AllotmentType.schema.json", "title": "Enum - Allotment Type", "description": "Enumeration of allotment types to use as a helper when modifying vesting schedule. `Ascending` applies the acceleration to the shares that would have vested first in time. `Descending` applies the acceleration to the shares that would have vested last in time. `Prorata` applies the acceleration proportionally across the remaining vesting installments", "type": "string", "enum": ["Ascending", "Descending", "Prorata"], "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/v1.2.0/schema/enums/AllotmentType.schema.json" }TX_Vesting_Accceleration
Proposed Implementation
{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://schema.opencaptablecoalition.com/v/1.2.0/objects/transactions/vesting/VestingAcceleration.schema.json", "title": "Object - Vesting Acceleration Transaction", "description": "Object describing an acceleration of vesting, in which additional shares vest ahead of the schedule specified in security's vesting terms.", "type": "object", "allOf": [ { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/Object.schema.json" }, { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/transactions/Transaction.schema.json" }, { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/transactions/SecurityTransaction.schema.json" } ], "properties": { "object_type": { "const": "TX_VESTING_ACCELERATION" }, "quantity": { "description": "If provided, the number of shares vesting ahead of schedule. If none of `quantity` or `portion` are provided, then all of the remaining unvested shares are assumed to be accelerated.", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/Numeric.schema.json" }, "portion": { "description": "If provided, the fractional part of the _whole_ security that is vesting ahead of schedule, e.g. 25:100 for 25%. Use `quantity` for a fixed vesting amount. If none of `quantity` or `portion` are provided, then all of the remaining unvested shares are assumed to be accelerated.", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/vesting/VestingConditionPortion.schema.json" }, "reason_text": { "description": "Reason for the acceleration; unstructured text", "type": "string" }, "id": {}, "comments": {}, "date": {}, "security_id": {}, "vestings": { "title": "Equity Compensation Issuance - Vestings Array", "description": "If provided, the list of exact vesting dates and amounts for this security. Takes precedence over `vesting_terms_id` and `allotment_type`. If none of `vesting_terms_id`, `vestings` or `allotment_type` are present, then the security is fully vested on issuance.", "type": "array", "minItems": 1, "items": { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/Vesting.schema.json" } }, "vesting_terms_id": { "description": "If provided, the identifier of the VestingTerms to which this security is subject. Takes precedence over `allotment_type. If none of `vesting_terms_id`, `vestings` or `allotment_type` are present, then the security is fully vested on issuance.", "type": "string" }, "allotment_type": { "description": "If provided, an allotment type to use as a helper when modifying a vesting schedule. If none of `vestings`, `vesting_terms_id` or `allotment` are present, then the security is treated as fully vested.", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/enums/AllotmentType.schema.json", } } "additionalProperties": false, "required": ["reason_text"], "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/v1.2.0/schema/objects/transactions/vesting/VestingAcceleration.schema.json" }STRINGREQUIREDSTRING]TX_VESTING_ACCELERATIONDefined in [schema/enums/ObjectType]
REQUIREDREQUIREDSTRINGidfield which identifies the issuance transaction object itself. All future transactions on the security (e.g. acceptance, transfer, cancel, etc.) must reference thissecurity_idto qualify which security the transaction applies to.REQUIREDportion. If none ofquantityorportionare provided, then all of the remaining unvested shares are assumed to be accelerated.quantityfor a fixed vesting amount. If none ofquantityorportionare provided, then all of the remaining unvested shares are assumed to be accelerated.STRINGREQUIREDvesting_terms_idandallotment_type. If none ofvesting_terms_id,vestingsorallotment_typeare present, then the security is fully vested on issuance.STRINGallotment_type. If none ofvesting_terms_id,vestingsorallotment_type` are present, then the security is fully vested on issuance.Enum - Allotment TypeDescription: Enumeration of allotment types to use as a helper when modifying vesting schedule.
Ascendingapplies the acceleration to the shares that would have vested first in time.Descendingapplies the acceleration to the shares that would have vested last in time.Prorataapplies the acceleration proportionally across the remaining vesting installmentsvestings,vesting_terms_idorallotmentare present, then the security is treated as fully vested.Vesting Schedule Modification
When vesting schedules are modified, changes can be made to the frequency, cadence, and duration of the schedule. As discussed in OCF Issue #539, I don't think there is currently any way to modify a vesting schedule.
But isn't modification to a vesting schedule a superset of a vesting acceleration?
In which case, the changes proposed in the Acceleration Proposal above could be expanded to facilitate any type of vesting schedule modification, by removing the
quantityandportionfields from the transaction object and replacing theallotment_typefield with aVestingAccelerationtype as follows:Enum - Allotment_Type
Proposed Implementation
{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://schema.opencaptablecoalition.com/v/1.2.0/enums/AllotmentType.schema.json", "title": "Enum - Allotment Type", "description": "Enumeration of allotment types to use as a helper when accelerating a vesting schedule. `Ascending` applies the acceleration to the shares that would have vested first in time. `Descending` applies the acceleration to the shares that would have vested last in time. `Prorata` applies the acceleration pro rata across the remaining vesting installments", "type": "string", "enum": ["Ascending", "Descending", "Prorata"], "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/v1.2.0/schema/enums/AllotmentType.schema.json" }VestingAcceleration Type
Proposed Implementation
{ "$schema": "https://json-schema.org/draft-07/schema", "$id": "https://schema.opencaptablecoalition.com/v/1.2.0/types/vesting/VestingAcceleration.schema.json", "title": "Type - Vesting Acceleration", "description": "Describes the terms of a vesting schedule modification that accelerates unvested shares.", "type": "object", "properties": { "id": { "description": "Reference identifier for this vesting acceleration", "type": "string", "minLength": 1 }, "quantity": { "description": "If provided, the number of shares vesting ahead of schedule. If none of `quantity` or `portion` are provided, then all of the remaining unvested shares are assumed to be accelerated.", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/Numeric.schema.json" }, "portion": { "description": "If provided, the fractional part of the _whole_ security that is vesting ahead of schedule, e.g. 25:100 for 25%. Use `quantity` for a fixed vesting amount. If none of `quantity` or `portion` are provided, then all of the remaining unvested shares are assumed to be accelerated.", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/vesting/VestingConditionPortion.schema.json" }, "allotment_type": { "description": "If provided, an allotment type to use as a helper when modifying a vesting schedule. If none of `quantity` or `portion` are provided, then all of the remaining unvested shares are assumed to be accelerated.", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/enums/AllotmentType.schema.json", } } }STRINGREQUIREDquantityfor a fixed vesting amount. If none ofquantityorportionare provided, then all of the remaining unvested shares are assumed to be accelerated.Enum - Allotment TypeDescription: Enumeration of allotment types to use as a helper when modifying vesting schedule.
Ascendingapplies the acceleration to the shares that would have vested first in time.Descendingapplies the acceleration to the shares that would have vested last in time.Prorataapplies the acceleration proportionally across the remaining vesting installmentsquantityorportionare provided, then all of the remaining unvested shares are assumed to be accelerated.TX_Vesting_Modification Transaction
Proposed Implementation
{ "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://schema.opencaptablecoalition.com/v/1.2.0/objects/transactions/vesting/VestingModification.schema.json", "title": "Object - Vesting Modification Transaction", "description": "Object describing a modification of vesting terms, which may include a full or partial vesting of shares ahead of the schedule specified in security's vesting terms.", "type": "object", "allOf": [ { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/Object.schema.json" }, { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/transactions/Transaction.schema.json" }, { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/primitives/objects/transactions/SecurityTransaction.schema.json" } ], "properties": { "object_type": { "const": "TX_VESTING_MODIFICATION" }, "reason_text": { "description": "Reason for the acceleration; unstructured text", "type": "string" }, "id": {}, "comments": {}, "date": {}, "security_id": {}, "vestings": { "title": "Equity Compensation Issuance - Vestings Array", "description": "If provided, the list of exact vesting dates and amounts for this security. Takes precedence over `vesting_terms_id` and `allotment_type`. If none of `vesting_terms_id`, `vestings` or `allotment_type` are present, then the security is fully vested on issuance.", "type": "array", "minItems": 1, "items": { "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/Vesting.schema.json" } }, "vesting_terms_id": { "description": "If provided, the identifier of the VestingTerms to which this security is subject. Takes precedence over `allotment_type. If none of `vesting_terms_id`, `vestings` or `allotment_type` are present, then the security is fully vested on issuance.", "type": "string" }, "vesting_acceleration": { "description": "If provided, describes the terms of a vesting schedule modification that accelerates unvested shares. If none of `vestings`, `vesting_terms_id` or `vesting_acceleration` are present, then the security is treated as fully vested as a result of this vesting schedule modification.", "$ref": "https://schema.opencaptablecoalition.com/v/1.2.0/types/vesting/VestingAcceleration.schema.json", } } "additionalProperties": false, "required": ["reason_text"], "$comment": "Copyright © 2024 Open Cap Table Coalition (https://opencaptablecoalition.com) / Original File: https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/tree/v1.2.0/schema/objects/transactions/vesting/VestingModification.schema.json" }STRINGREQUIREDSTRING]TX_VESTING_MODIFICATIONDefined in [schema/enums/ObjectType]
REQUIREDREQUIREDSTRINGidfield which identifies the issuance transaction object itself. All future transactions on the security (e.g. acceptance, transfer, cancel, etc.) must reference thissecurity_idto qualify which security the transaction applies to.REQUIREDSTRINGREQUIREDvesting_terms_idandallotment_type. If none ofvesting_terms_id,vestingsorallotment_typeare present, then the security is fully vested on issuance.STRINGallotment_type. If none ofvesting_terms_id,vestingsorallotment_type` are present, then the security is fully vested on issuance.vestings,vesting_terms_idorvesting_accelerationare present, then the security is treated as fully vested as a result of this vesting schedule modification.Cancellation
The
TX_EQUITY_COMPENSATION_CANCELLATIONtransaction avoids the issue described above regarding theTX_VESTING_ACCELERATIONtransaction by assuming that in the case of a partial cancellation there will be anothersecurity_idthat holds the remaining balance.If this assumption is acceptable, then no changes would be proposed for the
TX_EQUITY_COMPENSATION_CANCELLATIONtransaction.Beta Was this translation helpful? Give feedback.
All reactions