Accounting for Restricted Token Awards in the CELO ReleaseGold() Contract

Mackenzie Patel
Mackenzie Patel
save time
September 28, 2024

Related articles

Browse all articles

Accounting for Restricted Token Awards in the CELO ReleaseGold() Contract

September 28, 2024
Technical Accounting

Token compensation is a well-known and effective recruiting strategy for crypto startups. After all, you never know when a coin will moon and leapfrog from $.0001/token to $1 - a massive increase for founders and early investors/employees with a meaningful allocation. Token comp has been analogized to ”traditional” equity compensation such as stock options, restricted stock units and restricted stock awards. These instruments are staples in the tech industry, with equity compensation forming a decent chunk of the total payment package. With crypto compensation, however, the rules of the game are totally different.

First of all, tokens are not equity and do not confer ownership rights over a legal entity to the token holder. The token likely serves a function in a new protocol or application, but it doesn't convert to equity or guarantee anything (i.e. it’s a utility token). Second, the world of crypto securities is fuzzy and not well-defined yet. Token compensation may fall under securities rules, so it’s imperative that companies wishing to pay employees in tokens understand what they’re getting into. The documentation around these arrangements is complex and requires sound legal advice. There’s two types of token comp we’ll be diving into for this article:

  • Restricted Token Units (RTUs)
    • Similar to an RSU (restricted stock unit)
    • It’s a promise to pay a unit of crypto in the future, pending certain conditions being met
  • Restricted Token Awards (RTAs)
    • Similar to an RSA (restricted stock award)
    • Employee gets stock/tokens up front, but they are locked/vesting for a period of time

The difference between the two is subtle, but paramount, since it affects the available tax treatments for the compensation (more on this later). The key takeaway is that with RTUs, there is no property up-front - it’s a promise the employer makes to the employee to give them something in the future. With RTAs, the employee gets the total property/tokens up front, but they are subject to time-based restrictions. A typical vesting schedule for both token and equity compensation is:

  • 4 year vesting period
  • 1 year cliff - employee has to stay for at least one year, or they forfeit their entire allocation
    • Typically 25% of the total compensation vests on the 1 year work anniversary
  • Remaining allocation vests linearly each month until the 4 years is served (after which, the employee is entitled to 100% of the comp)

The incentives are aligned so the employees stick around for at least 365 days and ideally for 4 years to claim their bag. The taxation around these arrangements is a hot topic, and I’ve been to several parties in San Francisco where the conversation revolves around startup equity taxes (for real). There’s a small provision in the tax code called 83(b), and it’s game-changing for founders, investors and early employees who are looking to minimize taxes.

What is the 83(b) election?

Going back all the way to 1969, Section 83 of the tax code has been saving startup founders and employees lots of money in taxes. Under this provision, taxpayers who receive restricted stock (or other property) as part of their total compensation can elect to be taxed at the fair market value of this “other compensation” at grant date, not at vesting date. So if an employee is granted restricted stock, they can pay ordinary income tax using this formula: 

Total units of restricted stock granted * fair market value at grant date * ordinary tax

This provision is advantageous if the taxpayer expects the grant to appreciate over time. They’re saving taxes because no ordinary income tax is assessed as the grant vests if the 83(b) election is taken (there’s only capital gains/losses when the award is disposed of).

Taxpayers have to be quick though: the 83(b) election must be filed within 30 days of receiving the stock grant. It’s also incredibly archaic. Taxpayers have to fill out a physical form (example below) and mail it to the IRS, and it’s encouraged to use certified mail for record keeping purposes (in case the IRS, you know, loses your mailed form). It’s also advised to include a self-addressed, stamped envelope for the IRS to return a date-stamped copy, although you’re not guaranteed to receive a response.

If this election is filed properly, the employee includes the FMV (fair market value) of the grant on their W-2 and the employer can take a deduction equal to the FMV of the compensation. No further action is required by the employee as their grant vests and no other deductions can be taken by the employer related to the grant.

There’s a few nuances with Section 83(b) though:

  • It only applies to property that has actually been received by the taxpayer. It doesn’t apply to instruments like restricted token units (RTUs) or restricted stock units (RSUs) since the employee doesn’t actually possess the property yet. The company is simply promising to pay them in the future. By contrast, 83(b) applies to restricted token awards (RTAs) and restricted stock awards (RSAs), since the employee technically owns the property - it’s just subject to vesting.
  • If the employee leaves before vesting is completed, they forfeit the unvested award and cannot receive a tax refund for the taxes paid on unvested compensation. It’s a risk that’s undertaken when filing the 83(b), which is irreversible.

83(b) is so potent though because startup shares or tokens are usually worth very little (at least compared to the potential value of the company). The risk is manageable since the founder/employee is paying taxes on a small base up-front, potentially saving them millions of dollars if their company succeeds. If the shares are sold in the future, capital gains tax kicks in at 15% or 20% (long term capital gains rate), which is more favorable than the highest ordinary tax bracket of 37%.

What if the 83(b) election isn’t made?

If the taxpayer doesn’t file an 83(b) election, they are subject to ordinary income tax as their award vests over time (taxable income = # of units vested * fair market value at time of vest). Vesting could occur monthly, daily or yearly, and the fair value of this compensation is reported on the employee’s W-2 (with the offsetting deduction available to the employer).

This method requires more tracking on the accountant’s part and can potentially be disastrous from a tax perspective. If the stock value moons, then the employee is footing a huge tax bill that could’ve been avoided if they paid tax up front. The employee is also subject to capital gains tax when the stock is sold (although capital gains would be lower since the employee has a higher tax basis in the property).

If you’d like to dive deeper, here’s an example spreadsheet I created that looks at the US tax implications for employers & employees if the 83(b) election isn’t taken. As I mentioned, this methodology gets messy because the employer has to withhold tokens (and subsequently convert them to USD) to cover the payroll tax liability as the token compensation vests. And since crypto prices are so volatile, the total tokens withheld can change period-to-period to cover the liability owed. Yeesh!

Enter CELO and the ReleaseGold() Contract

My deep dive into the 83(b) election and token compensation started because I learned about the ReleaseGold() Contract on the Celo blockchain. According to Celo’s documentation, “ReleaseGold is a smart contract that enables CELO to be released programmatically to a beneficiary over a period of time.” It’s perfect for token-based compensation that, if deployed correctly, is eligible for the 83(b) election. The ReleaseGold() contract is flexible, and several parameters can be set by the developer:

  • Beneficiary - address that will receive the CELO over time
  • ReleaseOwner - admin of the specific deployment of the ReleaseGold() contract
  • ReleasePeriod - the frequency (in seconds) at which CELO is released (i.e. every day, week, month, three months)
  • amountReleasedPerPeriod - the amount of CELO to be released/vested each period
  • numReleasePeriods - the number of periods the CELO is released over
  • releaseCliff - time at which the cliff expires (typically one year, in seconds)

Once the contract is deployed, the CELO can either be unreleased (not vested) or released (vested). A great feature is that all CELO is available to be staked, even if it can’t be withdrawn yet, if the correct setting is enabled in the contract.

I was fascinated by this contract and the inherent tax advantage that comes with it - so naturally, I convinced my fiance, Nikhil, to tinker with the ReleaseGold() code and deploy my own personal contract! He spent several hours on a Friday night hacking away on Github, typing furiously on his command line, and downloading the entire Celo blockchain locally (what you apparently have to do for this contract to work). Nikhil finally published his first contract and I enthusiastically deposited 100 CELO into the contract from Valora, a mobile Celo app…only to discover a few minutes later that there was a bug in his code, and the 100 CELO was lost forever. 🐛 Such are the joys of crypto!

He eventually pinged me this updated contract address: 0x7ED15Bed1442Df48825657F4E0f8d6DF6113877A, and I sent 20 CELO into it (I learned my lesson after sending 100 CELO).

The tricky part about these contracts is that you can’t actually read any contract details via the block explorer, https://celoscan.io/ (like how you could on Etherscan). If you head to the “Contract” tab on the address above, gobbledigook is spit out:

I haven’t found a way to directly decompile this bytecode on Celoscan, so I had to ask my friends at Valora how to decode these contracts. Luckily, the Celo team built a Vercel front-end that displays pertinent information about live ReleaseGold() contracts - you can search by contract address here: https://celo-data.vercel.app/releasegold

When Nikhil’s contract is input into Vercel, this screen appears:

Relevant data points include:

  • Total balance of CELO in the contract (what the total restricted token award would be)
  • Total Withdrawn - amount of released (vested) CELO withdrawn to the beneficiary address
  • Released Amount - vested CELO (eligible to be withdrawn)
  • Release schedule information such as Release Start, Release Cliff, Release Period, # of Release Periods and Amount Released Per Period

It’s not clear what Distributed Balance means, but I could tell this contract wasn’t deployed correctly either since nothing had been released (even though the cliff was reached). Either way, we had a thrilling and nerdy Friday night. 🤓

To see an example of a ReleaseGold() Contract that was deployed correctly (and how to navigate information on the Vercel app), check out our video here:

Resting and Vesting 😎

In my opinion, time-restricted compensation is one of the great financial innovations of our day. It not only incentivizes founders and early employees to think long-term, but it also comes with a convenient tax break that celebrates success, instead of punishing it. We know this is a complex topic, so if you have any questions on this, feel free to reach out!

Additional Resources:

Mackenzie Patel

Related Content

BACK TO BLOGBACK TO BLOG