Can some rounding methods create indeterminate vesting for certain VestingTerms?

[pjohnmeyer]

To front-load this lengthy post with the questions so you can have them in mind as you read:

1. Do I understand the algorithm for FRONT_LOADED_TO_SINGLE_TRANCHE correctly?
2. If so, how would a vesting calculator resolve this uncertainty if calculating point-in-time vesting for a stakeholder?

---

I was doing some test calculations internally and noticed something confounding. I'll avoid spelling out the entire VestingTerms structure and just describe a schedule that looks like this:

• 1/4 vested every year for 4 years
• at any point after 1 year, the remainder can vest all at once on some event

This creates the following possible tranche scenarios, by percentages:

Tranche 1	2	3	4
25%	25%	25%	25%
25%	25%	50%	--
25%	75%	--	--

For at least one rounding method, if I understand them correctly, this makes it impossible to know how many shares vest at tranche 1. I've yet to puzzle through all of the allocation methods, but I think the ones that DO work are:

• CUMULATIVE_ROUNDING
• CUMULATIVE_ROUND_DOWN
• BACK_LOADED_TO_SINGLE_TRANCHE
• FRACTIONAL

I'm less sure about FRONT_LOADED and BACK_LOADED; I think there may be issues there as well in certain scenarios but I haven't dug into them. But the one that is I am certain is indeterminate is FRONT_LOADED_TO_SINGLE_TRANCHE. You can see my analysis of the algorithm and the scenarios below generating different Tranche 1 amounts. To me this means I either have the algorithm wrong, or there are additional constraints on the terms and/or share # awards for certain combinations of terms and rounding methods.

I know the schema most likely cannot address this issue; a theoretical validator possibly could.

Algorithm

If I understand the algorithm correctly, it essentially means:

1. Calculate the fractional tranches
2. Round all tranches down
3. Apply the remainder to Tranche 1

Assuming I have this correct, the breakdown for each scenario looks like this. We'll use 1010 shares as the example.

25-25-25-25

Step	1	2	3	4	Remainder
Calculate fractions	252.5	252.5	252.5	252.5	0
Round down	252	252	252	252	2
Front-load remainder	254	252	252	252	0

25-25-50

Step	1	2	3	Remainder
Calculate fractions	252.5	252.5	505	0
Round down	252	252	505	1
Front-load remainder	253	252	505	0

25-75

Step	1	2	Remainder
Calculate fractions	252.5	757.5	0
Round down	252	757	1
Front-load remainder	253	757	0

[pjohnmeyer]

@pavitrabhalla @daviidy FYI

[pjohnmeyer]

TWG Notes
@jacobyavis and I discussed this, and he pointed out that scenarios 2 and 3 seem like acceleration events, and I agreed. We could differentiate the "main" path through the vesting terms as the one to use for rounding, but we would need then a way to represent that in the terms. For example some kind of marker field.