Stock Class required field questions

[pjohnmeyer]

https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/blob/main/schema/objects/StockClass.schema.json lists required fields that we propose should not be.

1. par_value : Some jurisdictions allow issuance of stock with no par value. On one hand that could be interpreted to be 0, but that's not really what "no par value" says to me. In my mind it's like the difference between null and 0 -- subtle but real. I propose we make it optional.

2. votes_per_share : While relevant and interesting information, it is not necessary to understand the distribution of equity in a cap table. I propose we make it optional or remove it.

3. price_per_share : Common Stock classes probably do not have a price per share unless there has been a valuation; price_per_share is already present in valuation objects, but there may not be any valuations yet. This field should be optional across the board, or optional for COMMON stock.

[JSv4]

I asked some of our KM folks for feedback on this. Will add their responses here later this coming week.

[JSv4]

@pjohnmeyer, here's our thoughts from the Gunderson side:

1. par_value: Agree this could be optional - while there is a technical distinction between zero and null, particularly from an engineering perspective, but, practically, we'd see zero as saying “no par value” (like saying “zero par value”). All that said, making the field optional seems to clear up any ambiguity.
2. votes_per_share: Strongly object to removing this - particularly from the perspective of folks who actually use these systems (perhaps less relevant purely from the vendor side). Cap tables aren’t just for ownership, but also for tracking control, which includes voting. Having this would also be extremely useful in enabling users/service providers/viewers to help people with closings, as they'll need to tracking voting thresholds.
3. price_per_share: Agree this could be optional

[pjohnmeyer]

@JSv4 thanks. On par_value, it's important that we indicate that null explicitly means value is not present, so implementers do not interpret its absence as "zero".

With that said, do you still feel the field can be optional?

Regardless of your answer, I think we have enough info to work this as an issue.

[JSv4]

Changes incorporated via PR #178