Skip to main content

Is the new post-money SAFE mathematically sound?

Y-Combinator published a new set of documents for their SAFE, short for "Simple Agreement for Future Equity". The new version takes the document from a pre-money investment to a post-money investment. But for those of you that know neither versions, a SAFE is a legal document signed by the SAFE investor and a startup, so that the startup gets cash to build their product and the investor gets equity in the company. How much equity the SAFE investor gets is not spelled out in numbers but in the form of a set of equations that should compute this number at a later stage. "Later" usually means at the next funding round called Series A, where a larger investor injects more cash into an already working prototype of the product. At the point of Series A, it is much more clear on how the product performs and whether there is a market. The Series A investment usually happens a year after the SAFE investment. The assumption here is that it is fair to both the startup and the SAFE investor to derive the number of SAFE shares only when more information is available. Otherwise, the agreement would have to be based on a lot of guesswork, and if the guess is off by a lot, the startup might have sold their great idea for nothing, or the investor might have bought something worthless.

There are more terms and eventualities defined in the SAFE document, e.g. what happens when the company goes bankrupt before Series A or gets acquired before Series A. Also the document talks about things like Post-Money valuation Cap, and unless you are the startup or the SAFE investor mentioned above, you don't really need to know them to appreciate this blog post. Let's look at the intended case, where a SAFE investors signs the agreement with a startup that later raises a Series A round. This event is defined in the document as Equity Financing event and it has the following implications:

(a) Equity Financing. If there is an Equity Financing before the termination of this Safe, on the initial closing of such Equity Financing, this Safe will automatically convert into the greater of: (1) the number of shares of Standard Preferred Stock equal to the Purchase Amount divided by the lowest price per share of the Standard Preferred Stock; or (2) the number of shares of Safe Preferred Stock equal to the Purchase Amount divided by the Safe Price.

So the SAFE investor gets a bunch of shares, and the document says that he gets the great of two numbers. So,

# You will see later, why I am using 
# the assignment operator ← instead of =
SafeShares ← MAX(

This expression refers to three terms: PurchaseAmount, LowestStandardPreferredStockPrice and SafePrice. The first is a constant, the second is the share price the Series A investor pays, which is negotiated and derived at independently outside of this agreement, so we treat it as constant as well. The term SafePrice however is also something that we have to compute. We find how to derive it in the Section 2 of the SAFE Agreement, titled 'Definitions':

“Safe Price” means the price per share equal to the Post-Money Valuation Cap divided by the Company Capitalization.

To compute the safe price, we need the Post-Money Valuation Cap and the Company Capitalization. So,

SafePrice ← PostMoneyCap/CompCap

PostMoneyCap is a constant, but CompCap requires another computation. Section 2 also defines:

“Company Capitalization” is calculated as of immediately prior to the Equity Financing and (without double-counting):
  • Includes all shares of Capital Stock issued and outstanding;
  • Includes all Converting Securities;
  • Includes all (i) issued and outstanding Options and (ii) Promised Options;
  • Includes the Unissued Option Pool; and
  • Excludes, notwithstanding the foregoing, any increases to the Unissued Option Pool (except to the extent necessary to cover Promised Options that exceed the Unissued Option Pool) in connection with the Equity Financing.

So it's a bunch of numbers that we add together, and at the end we arrive at the total number of stocks that company will have after Series A closes.

CompCap ← 
  CapitalStock + 
  ConvertingSecurities + 

Again, we need to look at the definitions of all the terms to do that computation. Most of them are straight forward, but the "Converting Securities" definition is particularly interesting. It is:

“Converting Securities” includes this Safe and other convertible securities issued by the Company, including but not limited to: (i) other Safes; (ii) convertible promissory notes and other convertible debt instruments; and (iii) convertible securities that have the right to convert into shares of Capital Stock.

Let's assume for simplicity that we only have on SAFE agreement and no others. Then we have:

ConvertingSecurities ← SafeShares

Notice the SafeShares is the same as we had it in the beginning of this post. Remember that we ended up here, because we wanted to compute SafeShares, and to do so we find that we need SafeShares! This legal document contains cyclic definitions!

It's an equation system

So instead of viewing those definitions as a way of deriving the defined from some other numbers, we have to view it as an equation system. While the previous version of the SAFE agreement -- the pre-money one -- also set something like goals, the description of those goals were at the same time a way of computing the numbers for said goals. This new post-money version of the SAFE just sets goals leaving the method of computation undefined.

To make things more complicated, it is possible to hand out multiple SAFE agreements, and now you have a lot of interplay between all those agreements. Here is the full equation system:

SafeShares[i] = 

SafePrice[i] = PostMoneyCap[i]/CompCap

CompCap = CapitalStock + 
  ConvertingSecurities + 

ConvertingSecurities = 
  SafeShares[1] + 
  SafeShares[2] + 
  ... + 
See that all SafeShare equations depend on ConvertingSecurities which in turn depends on all SafeShares.

The most naive way of dealing with this is to set random starting values for SafeShare variables and then iterating on the computation using the definitions as computations. If we are lucky the whole thing converges to a stable solution. For this particular equation set, I found this to be the case most often. I made an interactive calculator for this to verify my gut feeling, and also to be able to play around with scenarios, so I can find the one that would be favourable to me. The box below is powered by CodePen, so go and inspect the code if you like.

See the Pen SAFE funding analyser by clefru (@clefru) on CodePen.

However, a word of warning: At the first glance, it is unclear if this equation system has more than one solution. It is far from obvious what the interplay between all SAFE agreements implicates mathematically. If there are multiple solutions, then it is also unclear who's job it is to give the canonical set of numbers. What if one party doesn't like the set of numbers and takes to court?

The model however has interesting properties, and I assume that YC chose it because of that: Each SAFE investor can compute the minimum amount of ownership received by dividing the PostMoneyCap in his contract by his PurchaseAmount. E.g. a 500k$ investment with a 2M$ post-money cap yields at least 25% of ownership after Series A. Well, and with this minimum guarantee of ownership implied by the equation set is exactly where the problem starts. Take a guaranteed 25% SAFE investment as implied by the numbers above and make 5 investors sign 5 deals. Then you have promised in total 125% ownership to your investors. To the equation set above this means that there is no fixed-point in when iterating on the numbers, and that the shares received for each SAFE holder go to infinity, while the SafePrice converges to 0. What are the legal implications of that? YC has yet to publish a user guide for those new agreements. In the meantime, check your numbers with the SAFE calculator above for sanity. Also do so in your best interest, if you are a founder, as you want to know your dilution when handing out term sheets.


Popular posts from this blog

Liskell standalone

Some time has passed since I last blogged about Liskell. It is not dead nor have I changed my mind that Haskell needs a proper meta-programming facility not to mention a better syntax.Liskell was a branch of GHC once. Now it sits on top of the GHC API, or I should rather say sneaks behind its back as it creates its own API as the original one is not suitable for the stunts I'm interested in. If Liskell sticks with GHC as its soil, I will definitely send patches upstream to refine the GHC API in the areas where it needs more flexibility for Liskell. However for the moment, my main target was to get something out that compiles with a stable version of GHC.You can grab it with the usual: darcs get This version has been tested with ghc 6.10.1 and should install like: ./Setup.lhs configure ./Setup.lhs build ./Setup.lhs install cd LskPrelude make install-inplace Optionally you can run make tests in the testsuite subdirectory. Thanks to community.haskell…

XMonad GridSelect

Personally, I not just need a window manager, I need a focus manager. I tend to think of windows as TODO items, and as there are many TODOs in life there are many windows on my workspaces. Usually a fraction of that can't be closed or worked on immediately, so they linger around on my desktop, cluttering my workspace.I used to use the Tabbed layout. But Tabbed isn't the answer when you are a guy who reports bugs such as "XMonad 0.6 with Tabbed dies when firefox-session-restore slams 40 windows at once on the desktop". In other words, I use a lot of windows. The workspaces concept isn't particularly useful to me either. My mind just doesn't work with mental boxes. So the result is, that I have too few workspaces with too much windows on them, so that Tabbed has trouble displaying useful window titles, and navigating through them is slow and cumbersome (mostly because tab switching generates a lot of useless X Expose events).GridSelect is my answer to that. It…