JSv4
commented
1 year ago We probably should add more events for things that are relevant in audit logs or cap table outputs (OCX). Question then is what falls under that? A change like modifying votes-per-share probably is significant (and is not captured)
Do we want to do this on a field-by-field basis with separate events, or do we have some more general purpose change event for these kinds of changes - e.g. where the new Stock Class object is nested on the event so you can back out the changes? A benefit of the latter approach is we don't need to keep creating new objects. Downside is it's much harder to quickly see nature of a change (but not that hard programmatically).
ryansdwilson
jacobyavis
Description of Enhancement :
Example of what we need here
You have a startup that raises money with a Preferred. Then they have another round and want to change the original preferred to Preferred Seed.
Another example was Cayman Shares where you might want to or need to change the votes per share of a given class of stock.
In both cases, we don't have a way to handle this that would preserve the change history. When we released v1, we targeted equity transactions for inclusion in the event log. All other changes to object attributes would just be a moment in time, and, if you want to see an earlier version, to the extent you have earlier OCF files, you'd look at an earlier version and the relevant object id and back out the changes.
Why is this Needed?
We may want to keep this in the event log so it's clear what happened to effect a change (or to even make it clear there was a change)
Anything else we need to know?
Whether or not it's significant enough to keep track of these changes / histories is debatable. Open to including it, but these were not deemed important enough to be included in v1.0.0 event log.