Stock Plan size

[kedder]

Currently the Stock Plan object defines current_shares_reserved field described as:

The number of shares currently approved. The original number of shares can be determined from the event log.

Consider keeping the original number of reserved shares instead of current amount (current_shares_reserved). The value of current_shares_reserved is not static and will potentially change every day, even if no changes to captable are made (due to option expiration, forfeitures, etc). Also the value depends on the current date - it will basically be valid only on the day the OCF file is generated. OTOH, the original number of reserved shares is static and does not depend on the current date. The current_shares_reserved may be reconstructed from the transaction log instead.

[JSv4]

Hi, @kedder, thanks for all of the thoughtful comments. The Technical Working Group was chatting through some of these earlier today. You raised some great points. Really appreciate the engagement.

On this point, you're correct that you'll lose historical shares reserved amounts. When scoping out the initial release, we decided to limit the scope of the event-driven architecture by focusing only on events directly affecting security objects and necessary for a valid cap table ledger (e.g. events affecting Stock, Plan Securities, Warrants and Convertibles).

As part of the next major release after our first public release, we plan to include a change log to capture all changes to any valid OCF object - including stock plans and, implicitly, the shares reserved. There is some minor loss of fidelity not having that at launch, but we made the call it wouldn't create any major issues losing some of this historical data, and we'd rather solve this problem all at once for all objects rather than create specialized fields or objects for certain object field histories.

Hope this helps and please do follow-up if you think there's a real need for this at launch (e.g. is this is a must have for you guys @ Shoobx or merely a nice to have?)

[kedder]

hi @JSv4 . I'm not completely sure I've got my point through, so I'll give a practical example:

Let's say today is 2022-03-02 and there is an ISO grant of 2000 options that expires on 2022-03-03. Let's say the company originally reserved 10000 common shares for the stock plan.

When we generate OCF today, we'll get a Stock Plan with current_shares_reserved == 8000, which is correct. However, if we look at the generated OCF tomorrow, the value of current_shares_reserved will be wrong, because options have expired, returned to the plan and the current_shares_reserved should be 10000. So, the such generated OCF will only be valid for one single day, which is not ideal.

That said, I'm not sure I understand the semantics behind current_shares_reserved correctly. Is this number supposed to include shares, that have been already issued from the plan or only "reserved and still available for issuance"?

At Shoobx we are storing "initial pool size" as a primary data and deriving "still available for issuance" from various transactions (issuance, forfeiture, repurchase, etc). It is not that important how what values we will have in OCF as long as it is possible to unambiguously derive the initial reserved pool size from the transactions.

[JSv4]

Hi @kedder, in your example, that current_shares_reserved field is meant to be 10,000 in both cases. It's meant to indicate the shares reserved under the plan, not the amount remaining in the pool. Perhaps we need to tweak the description and naming.

The amount of options issued and outstanding vs the shares remaining in the pool is meant to be determined by traversing the event stack to see what's been issued vs cancelled vs exercised, etc.. We've discussed releasing some utilities to let people quickly parse an OCF and determine aggregate statistics like the current size of the pool (8,000 in your example on 3-02-2022), but we're focused on getting the format finished first.

Tweaking your example a little bit, the current_shares_reserved field does get out of date if the size of the pool is changed by the Board. If you have 10K shares reserved on 3-02 and then, on the next day, another 2,000 shares are reserved to cover new option issuances on 3-03, the current_shares_reserved field in the export from 3-02 would obviously be inaccurate. You'd also be missing the new issuances in the old event stacks too, however, so you'd need to export a new OCF on 3-03 anyway. The 3-03 file would have an accurate current_shares_reserved field as of the effective date of the pool increase, but you would be missing the history of the pool changes. Like I said, we want to have change logs for the entire OCF file in the next major release. Rather than create a non-transaction event type just for the pool changes, we feel people can live without the pool history in the interim until we have a general-purpose change log for non-transactions.

Hopefully this is clearer? Any thoughts on the wisdom of not having an event for option pool size changes?

[kedder]

@JSv4, this makes sense, thanks for clarification! I agree - some clarifications in naming and description might help with avoiding the confusion.

As for pool size changes - yes, I realize it is not part of the spec yet (as well as grant size/price/vesting/etc changes). I think it makes sense to omit that for the first release - the format still allows to accurately capture captable from the generation date onwards.

[JSv4]

Answer: we're going to improve the description of the current_shares_reserved field in the schema.