How to Handle Convertibles that Convert Pre and Post Money?

[JSv4]

Per Issue #56, importing comments / suggestions to our static Google Doc into GitHub for discussion

@ashawber asks how to deal with Convertibles that have a blend of post and pre-money convnersions?

We’ve actually seen a blend of pre-money and post-money, where up to a certain amount of Convertibles are included in the pre-money and the rest in the post-money.

[JSv4]

@ashawber, can you share any examples of the language or specific conversion mechanisms you've seen?

I wonder if the solution here is to two separate convertibles objects in OCF (with the different security_id fields for OCF purposes but the same custom_id for human readable purposes - e.g. CN-1) - for each part of the convertible's instrument terms? One would be pre-money and the other post-money.

[ashawber]

Here's an example of the definition of Company Capitalization which splits it between pre-money and post-money. This language is based on YC post-money SAFE (emphasis added).

“Company Capitalization” is calculated as of immediately prior to the Equity Financing and (without double-counting, in each case calculated on an as-converted to Common Stock basis):
• Includes all shares of Capital Stock issued and outstanding;
• Includes all Converting Securities_, except to the extent the original purchase amounts of such Converting Securities exceeds $2,000,000_;
• Includes all (i) issued and outstanding Options and (ii) Promised Options; and
• Includes the Unissued Option Pool, except that any increase to the Unissued Option Pool in connection with the Equity Financing shall only be included to the extent that the number of Promised Options exceeds the Unissued Option Pool prior to such increase.

[ashawber]

This is currently a very uncommon formulation, but it might come more into favor once more founders realize how bad post-money SAFEs can be for them.

[JSv4]

@ashawber, thanks again for raising this.

I've been kicking this around with a couple colleagues, and it seems like there's two fixes here. We're still workshopping these, but I wanted to toss them out to see if you or anyone else had other ideas. I'm sure there are other fixes too, so please let me know if you see another angle or approach we're missing.

1. Perhaps the more elegant and expressive approach is to define some kind of data structure that captures what securities should be included in the denominator of the PPS calculation when calculating the conversion ratio / price. On a related note, perhaps coming up with some kind of standardized formula for how that conversion price is calculated - which would then transparently let you clearly define and tweak all of its respective variables, such as the valuation cap, total capitalization for the purposes of conversion, etc. - would cover almost every case we'd run into. I think this approach could work really well conceptually but, I don't think the required information is commonly captured in a way that all of the vendors can easily export (I will bring this up in the TWG meeting though - perhaps I am wrong). Even if the data is available, however, at this stage in the release cycle, my sense is this would be a fairly large change to solve a corner case. I'm inclined to look at creating something like this for our next major release if we have interest in it but to avoid it for now.

2. The more expedient solution would be to add another conversion enum in addition to PRE-MONEY and POST-MONEY. We could have a CUSTOM conversion type. In the conversion event, we could add a new, required data field for CUSTOM conversions setting forth a manual conversion amount and a required conversion explanation field. This does lose structured data, to the extent it's captured in the exporting system and discarded, but it has the benefit of being much easier to add to the OCF spec for the public release and not needing a lot of data that is probably not commonly captured at the moment.

Either way, you are correct that we need a way to support things that are a little more off the wall. For now, I think option 2 gets us most of the way there with very little additional data required.

Thoughts?

[pavitrabhalla]

I do think that the correct approach long-term is to come up with a data structure (as suggested in #1 by @JSv4) that captures which securities are included in the company capitalization, instead of just saying pre-money or post-money. That would prevent us from having to change the data structure each time a new flavor of the SAFE is introduced.

However, that doesn’t solve the edge case raised by @ashawber here, which is about putting a condition on when converting securities should be included in the capitalization calculation. To account for this edge case, I second @JSv4's #2 suggestion above.

I recently saw a Post Money SAFE where converting securities were included in the company capitalization during a funding round, but not included in case of a liquidation event. @JSv4 's suggestion #2 would help account for such cases as well.

My recommendation would be to do both #1 and #2.

#1 helps create a robust data structure, which is more explicit and less dependent on assumptions about what a pre-money vs post-money should include. Whereas #2 solves the edge case raised in this discussion.

[JSv4]

Great points @pavitrabhalla.

I have some further thoughts on how to do # 1 above, but, before diving into that, wanted to get your thoughts on sequencing.

Since we're (a) driving towards release, (b) don't fully know how to do # 1 and (c) can solve for the most significant problem of having the proper conversion amount with proposal # 2, I would say that we should implement # 2 immediately and pursue # 1 in earnest as part of the next release. Do you agree, or do you think we need both features now to make OCF successful?

As for how to do #1, I was thinking there are a couple things that are relevant for each Convertible:

1. We need to specify the inputs required for the conversion calculation - for example, as discussed above, which securities to include to derive the pre and money capitalization amounts. To the extent an input data field is not available in the OCF spec, we either need to add it or that particular convertible type needs to fall back to a custom conversion type that is not fully structured and makes use of the CUSTOM conversion event (see 2.b below). Some conversion schemes, like the $2M cap Andy flagged, may never be able to be easily structured unless they become so common it justifies creating a new, enumerated Convertible type (see 2 below).
2. For each type of convertible, we could also specify the commonly understood calculation for conversion, so, for clarity, anyone could understand how the OCF inputs spec'd above are used to determine a conversion amount. This would increase transparency and help ensure everyone is handling conventions like PRE, POST, MFN SAFE, etc. the same way. It would also make it clearer when you need a custom type and can't rely on an enumerated type.
   a. I think it actually might make sense to create specific types for each commonly-spec'd convertible with this defined (e.g. PRE-MONEY SAFE, POST-MONEY SAFE, MFN SAFE, Convertible Note, etc.). As the market evolves and new, common convertibles are created, we can add new types. Supporting one data structure to cover all possibilities strikes me as extremely complex.
   b. At any point, a not-yet-supported or bespoke convertible can be added as a generic convertible type with a required CUSTOM conversion.

Still thinking through all of this, so please definitely consider this half baked at best.

[JSv4]

This has been converted to an issue, but please continue discussions in the thread above to better resolve the proper approach to move this forward.