Most SAFT problems do not show up on signing day. They hit during close, when legal says “future tokens,” finance sees a liability, and the subledger shows nothing yet.
In Web3 accounting, SAFT accounting gets messy because the paper may look simple while the settlement terms are not. If we also issued token warrants or token purchase rights, one bad call can distort dilution, liabilities, and later token delivery. The fix starts with the contract, then flows into the ledger.
The label on the document is not the accounting answer
A SAFT is a funding contract, not the token itself. That sounds obvious, but teams still book the instrument as if the token already exists. That is where trouble starts.
The SEC’s March 2026 guidance reinforced a point founders need to respect: a SAFT sale is a securities transaction when we sign it, even if token delivery happens later. That matters for disclosures, exemptions, and how we think about the issuer’s obligation. It also matches the practical distinction laid out in this founder’s guide to token warrants, SAFEs, and SAFTs.
A SAFT is a contract about a future token, not the token sitting in treasury today.
Token warrants and token purchase rights can look similar on a cap table, yet their accounting can diverge fast. A warrant may give the investor optionality at a set price. A purchase right may be prepaid, milestone-based, or contingent on token generation. Some rights settle in tokens only. Others include cash settlement, discounts, MFN clauses, or variable token counts. Those terms drive the book answer.
That is why GAAP crypto accounting starts with a term-by-term memo. We ask what we owe, when we owe it, and whether the outcome changes with token price, financing terms, or a launch event. If settlement is variable or cash can creep in, liability treatment becomes much more likely. If the right is tightly drafted and fixed, the analysis may be narrower, but we still do not assume an equity answer because the document says “SAFT.”
Where SAFT accounting usually lands under GAAP and IFRS
US GAAP does not give us a clean SAFT chapter. So we work through the existing literature, usually starting with obligation, settlement mechanics, and embedded derivative features. For founders, the practical point is simple: ASU 2023-08 does not solve SAFT accounting. That rule applies to qualifying digital assets we actually hold, not automatically to contracts for future delivery.
This quick screen is a useful starting point:
| Instrument | First question we ask | Common issuer outcome |
|---|---|---|
| SAFT | Do we owe a variable amount of tokens, cash, or both? | Often liability-style accounting, sometimes with fair value remeasurement |
| Token warrant | Is exercise fixed, and is settlement strictly in tokens? | Often fair value analysis, with derivative concerns if terms are variable |
| Token purchase right | Is it prepaid, optional, or contingent on launch milestones? | Could be a deposit, liability, or derivative-like instrument |
The table is only a first pass. The real work is in the clauses.
If we are the issuer, fair value can become a live issue long before token launch. If we are the investor, the mirror problem appears on the asset side because there may be no active market for the unissued token claim. That is one reason SAFTs are painful in both crypto financial reporting and audit prep.
Under IFRS, the answer can also move. This overview of IFRS treatment of SAFT notes shows why IFRS digital asset reporting may split the contract from the future token economics in a different way than US GAAP. We should not assume our US memo travels cleanly into a foreign reporting pack.
Once the token is delivered, ASU 2023-08 can matter a lot more. For qualifying native assets, fair value and disclosures kick in. FASB also discussed expanded guidance in April 2026 around wrapped tokens and transfer disclosures, which is why our post-delivery close should line up with an ASU 2023-08 crypto disclosure checklist.
Close problems usually start after signing, not before
The ugly part is operational. We may sign a SAFT in one quarter, launch on Ethereum months later, deliver some investor tokens on Arbitrum, move treasury to Base, and later send part to Coinbase or Kraken. If Cryptio, Tres Finance, CoinTracker, or QuickBooks Online do not map those steps correctly, the accounting breaks even if the memo is fine.
We have seen the same pattern more than once. A client bridged ETH from Arbitrum to Base, wrapped part of it for a Uniswap deployment, and the subledger treated the receipt as fresh income. That is not an edge case anymore. It is normal on-chain reconciliation work. The same controls support Web3 accounting, DeFi accounting, digital asset accounting, blockchain accounting, and day-to-day crypto bookkeeping. They also keep multi-chain reconciliation, cross-chain accounting, DEX reconciliation, L2 accounting, staking accounting, airdrop accounting, token accounting, stablecoin accounting, and crypto treasury reconciliation from drifting apart.
For operators, that becomes the backbone of crypto subledger management, crypto startup accounting, Web3 bookkeeping, token project bookkeeping, crypto bookkeeping for startups, and reliable close files. If the issuer also moves customer funds, money transmitter accounting, MTL accounting, MSB accounting, stablecoin treasury management, and crypto accounting for money transmitters add another layer because FinCEN rules and state MTL obligations require a clean line between company assets and customer obligations. Funds on the buy side face the same pressure in crypto fund accounting.
After launch, founders ask about how to account for staking rewards and DeFi yield farming accounting. Those questions are real, but they sit on top of the original SAFT lot schedule. If delivery settles into wrapped or bridged assets, we also need a policy for wrapped token accounting under ASU 2023-08. The same close stack often needs wallet reconciliation services, crypto controller services, or fractional CFO crypto support.
A solid cryptocurrency accounting firm should connect the legal doc, the cap table, the token ledger, and the general ledger. If we are still searching for a “rypto accountant” after the first failed close, we waited too long.
SAFT accounting gets hard when we confuse fundraising paperwork with token ledger reality. The clean answer comes from contract terms, settlement mechanics, and disciplined close controls after token generation.
If we need help cleaning up SAFTs, token warrants, or purchase rights before the next audit or raise, we can book a free consultation with the Web3 crypto accounting team.
