[Enhancement]: Resolve ambiguity in Vesting Acceleration Transaction for partial accelerations

[MattCantor]

Moved to Discussion #540

---

Description of Enhancement :

Why is this Needed?

The Vesting Acceleration Transaction includes a date field and a numeric quantity field, along with an unstructured field for comments.

In the case of a partial acceleration, it is ambiguous whether the acceleration should apply to:

• the shares that would otherwise vest soonest (i.e., acccelerate some shares, toll vesting for a period, then continue vesting)
• the shares that would otherwise vest last (i.e., accelerate some shares, then truncate the vesting schedule)
• pro-rata across all remaining shares (i.e., accelerate some shares and reduce the amount that would vest on all future vesting dates)
• or something else.

Pro-rata is the most common, but we see the other approaches as well.

Possible Approaches

One alternative would be to require a vestings field such as found in the Equity Compensation Issuance Transaction to provide the exact vesting dates and amounts for the vesting schedule that should apply following the partial acceleration.

Or perhaps a field with e.g. enum ApplyToFirst, ApplyToLast, ApplyProRata, and an optional vestings field that takes precedence if it is provided.

[MattCantor]

Conceptually, the reason for the ambiguity is that the schema currently assumes that a vesting event always applies to the "next" installment in the vesting schedule.

That assumption holds for a relative vesting schedule. That's just normal time based vesting.

But it doesn't always hold for an acceleration event. It's appropriate to ask which installment in the vesting schedule the acceleration applies to.

We define vesting schedules in the schema imperatively. Even in the case where an array of vestings is provided, we do not provide an id for each vesting event.

This means we cannot designate the installment in the vesting schedule that the acceleration should apply to. Instead we need to define a new vesting schedule imperatively again.

[MattCantor]

Incorporated into #539