2(B) Ordinary Corporate Structure

Disclaimer

Ordinary Corporate Structure

By the time most Crypto businesses start thinking about their ICO, they have already caused all the related IP to be owned by a corporation.  In this case, a plain vanilla ICO causes enormous leakage to the IRS (regardless of whether it's in the form of a straight token sale or a SAFT).  The leakage principally results from the fact that the corporation has a huge slug of income in one year, and won't spend that money for several years.  Under US tax rules, a corporation can take losses from one year and use them to obtain refunds of taxes paid in the previous two years, but taxes paid three or more years ago are lost forever.  

If you assume for example, that the corporation plans to raise $100 million through the ICO and spend $20 million each year thereafter for 5 years, the corporation will come up ~$16 million short -- $16 million that your shareholders might have hoped to receive as a dividend.  That’s because losses from years 4 and 5 can only be carried back two years, and there will be no tax liabilities in those years that can be refunded.  Simplistically, it works out as follows:

                        Income              Expense             Tax (@40%)                   Year End Cash

Year 1:              $100 mm           $20 mm             $32 mm                                    $48 mm

Year 2               $   0                  $20 mm             ($ 8 mm)                       $36 mm

Year 3:              $   0                  $20 mm             ($ 8 mm)                       $24 mm

Year 4               $   0                  $20 mm             $ 0                               $  4 mm

Year 5               $   0                  $ 4 mm             $ 0                               $  0 mm

Clearly, having $84 million to spend is not a bad thing, but $100 million would be better.

DEFERRAL OF INCOME WITH A SAFT

I have heard many people say that they believe a SAFT (“Simple Agreement for Future Tokens”) does not generate taxable income in the year it is issued, but rather in the year it settles, in which case, this problem is reduced.  If in the above example the SAFT is issued before the network goes live and the network goes live in year 3, then all $100 million would be available to the corporation.  I think this is certainly an argument that I would make in filing a corporation’s tax returns, but I also think there are three issues that might be relevant.

            The first issue is that I’m not sure a SAFT should be treated as generating income in the year in which it settles (although there is certainly an argument to that effect).  There are two arguments for deferral: 

           The first argument is that a SAFT is a variable prepaid forward contract, and such contracts should not generate tax until they are closed.  Where the number of Tokens that will be delivered at settlement varies sufficiently (generally around 20%) this is a good argument.  However, where the only variability is the settlement date (i.e., because no one can know the “go-live” date for the network), I am less convinced.  In that case, all economic benefits and burdens of owning the Token (i.e., all benefit from appreciation and all risk from depreciation) has passed to the SAFT buyer and generally that causes a transaction to be taxed as a sale.  Even if the SAFT doesn’t generate immediate tax as a variable prepaid forward, this approach only delays the income to network launch, and if your anticipated expenses will extend more than 3 years after that, you will still have leakage.  I have also heard people argue that lock ups and other restrictions can delay the taxable event, but I have my doubts.  Section 83 (which is not technically applicable here, but covers a similar concept) specifically ignores “lapse restrictions” (restrictions which will lapse with the simple passage of time) and if those principles are applied here, a lock up or other restriction that lapses after a period of years would not effect a deferral of income.

            The other argument in favor of deferral is that a SAFT is an “Open Transaction”, largely because the Tokens don’t exist on the date the SAFT is issued.  I find this argument compelling (at least until network launch), but it concerns me for a different reason.  If the corporation is planning on holding back a portion of its sponsor tokens, I believe this argument presents a risk that the corporation is taxed on the unsold Tokens on the date of network launch – and in that event, the amount of income might be enormous and would not be matched by a receipt of a corresponding amount of Fiat necessary to pay the government.   If your SAFT provides for the delivery of a fixed number of Tokens, I believe the benefit of delaying the recognition of income until network launch is overshadowed by the risk that the IRS tries to tax the corporation based on the value of the Tokens on the network launch date.

            Given that a corporation undertaking an ICO has few tools at its disposal to address the tax leakage, I recommend that the SAFT be structured so that the number of Tokens deliverable to the investor can vary.  For example, assume that investors and the corporation agree that Tokens are worth $0.20 on the SAFT issuance Date.  I would then provide in the SAFT that the Company has to deliver 5 Tokens per dollar invested if the value of Tokens on the settlement date exceeds $0.20/Token and 6 Tokens per dollar invested if the value of the Tokens on the settlement date is less than $0.16 2/3rds/Token (and $1 worth of Tokens if the value is between $0.16 2/3rds and $0.20/Token).
  

DIVIDEND OPTIMIZATION BY EARLY TOKEN DISTRIBUTION

            In some cases, it may be advantageous to distribute Tokens or SAFTs to your shareholders before network launch.  If the corporation above distributed 40% of its Tokens to its shareholders when the IP is still being developed, the total tax leakage would be significantly reduced (although of course the corporation would have less money to spend).   The issue here is that (a) when a corporation distributes property to its shareholders, it has to recognize taxable income as if it had sold that property for its fair market value and (b) if that taxable income exceeds the current year losses, the distribution will be taxable to the investors even if the amount paid is less than the amount invested.  Certainly if the distribution is when the value of the Tokens is low enough those problems can be managed, but getting a reliable appraisal of Token value prior to network launch can be very difficult.  Moreover, if the sponsor hopes to claim that the Tokens are worth $0.01 on day 1 when Tokens are distributed to employees, $0.10 30 days later when Tokens are distributed to investors and then closes a SAFT 30 days later at $1.00 per Token (not to mention closing an ICO at $10/Token), the IRS may argue that subsequent events demonstrate that those values are wrong – the only third party transaction is a SAFT sale at $1.00/Token, and thirty days is not enough time for the Tokens to have appreciated 10x.  (And, the Corporation and its officers may be liable for penalties for failing to withhold on the actual value distributed to the employees.)  Nevertheless, and early Token distribution certainly should be considered.

OTHER STRATEGIES

If it’s too late to distribute Tokens (or you’ve already distributed all you can) and the Company is still likely to be unable to get a refund of all the taxes it has paid regardless of how much it expends, there still may be some useful options.  For example, the Company might enter into a standard tax shelter, like a leveraged lease, which would generate losses in the early years (which could shelter the income from the ICO) offset by income in later years (which would be sheltered by losses in those later years which can't be carried back to the ICO year).  More on this in a future post.

I expect that there are other techniques to address these issues (or there will be as soon as Wall Street starts developing targeted financial products for Token companies), but companies will need to find those techniques and move fast to implement them in the early years.