The Web3 Fundraising Instrument Stack: SAFE + Token Right, and Its Consequences

Founders ask "SAFE or SAFT or warrant?" as if the answer is one instrument. In practice a Web3 raise is usually a stack: a SAFE for equity plus a token warrant or side letter for token upside. The stack has dual-ledger cap-table, accounting and securities consequences, and each leg is its own counsel question. This is the cornerstone view tying the instruments together — hedged, because every leg is fact-specific.

TL;DR

• A Web3 raise is usually not one instrument but a stack: SAFE (equity) + token warrant/side letter (token upside).
• Each leg is a separate question — distinct securities classification, accounting, and cap-table consequence.
• Dual-ledger dilution: SAFE dilutes equity; token right dilutes the token ledger — model both together (see token cap-table management).
• Accounting differs per leg — scope/treatment settled framework by framework with your accountant.
• No single correct stack — jurisdiction-, structure- and fact-specific; the SAFT route carries the heaviest securities risk.
• Design with securities counsel + accountant, each leg on its own facts — not legal/accounting advice.

The stack, not the instrument

The common pattern:

The investor holds both future equity and a token right. "Stack" is the point: a Web3 raise is usually a combination, and the combination's legs have separate consequences. (A SAFT is a different, single-instrument route — and the highest securities risk.)

Each leg is its own question

The equity leg (SAFE) and the token leg (warrant/side letter) are distinct instruments with:

• distinct securities classification — economic-reality-tested, fact by fact;
• distinct accounting treatment — scope settled per framework;
• distinct cap-table effects — on two different ledgers.

A conclusion about one leg does not carry to the other. Bundling them in analysis is a common error — see the instrument comparison.

Cap-table consequence (dual ledger)

The SAFE dilutes the equity ledger on conversion; the token warrant/side letter dilutes the token ledger when it resolves. One raise touches both ledgers, so the fully diluted picture must be modelled across equity and tokens together — modelling only the equity side understates the true dilution. This is exactly why token cap-table management treats both ledgers as one combined picture.

Accounting consequence (per leg)

Each leg is recognised under the framework appropriate to it once scope is settled — equity-settled share-based payment vs other treatments for the equity side, and the separate question of how token grants/instruments are accounted for (see token vesting & cliff accounting and token compensation accounting). The stack does not share one accounting answer; each leg's scope and treatment is determined with your accountant, framework by framework.

There is no default stack to copy

The right combination depends on jurisdiction, structure, token plan and investor base, and each leg's securities treatment is fact-specific and economic-reality-tested. The stack is a common pattern, not a template. The defensible approach is to design it with securities counsel and your accountant, each leg on its own facts.

Practical guidance

1. Plan the raise as a stack — equity leg + token leg — not one instrument.
2. Analyse each leg separately — securities, accounting, cap-table — no cross-carry.
3. Model dual-ledger dilution — SAFE (equity) + token right (token) together.
4. Settle accounting scope per leg with your accountant — framework by framework.
5. Treat the SAFT route distinctly — single-instrument, heaviest securities risk.
6. Design with securities counsel + accountant — fact- and jurisdiction-specific; not legal/accounting advice.

How vendor tools handle the stack

Pulley models token and equity cap tables together (with custodian integration); Carta models the equity side broadly. They represent the stack's legs and dilution across ledgers and provide an audit trail. Confirm the tool models both legs and your specific terms — it does not determine securities classification or accounting scope, which stay counsel and accountant determinations.

How Wag3s helps

Wag3s HR records the stack's instrument data — SAFE conversion terms, token-warrant/side-letter terms, grant and vesting schedules — as structured, auditable inputs feeding dual-ledger cap-table and equity-/token-compensation reporting, while the securities and accounting treatment of each leg stays counsel- and accountant-confirmed. See the HR product page.

Further reading

• SAFE vs SAFT vs Token Warrant
• Post-Money SAFE Explained
• SAFT Securities Risk
• Token Warrant vs Token Side Letter
• Token Cap-Table Management
• Web3 Employee Token Grant Structuring

Sources

• Common Web3 raise = a stack, not one instrument — typically a SAFE (equity) plus a token warrant or (some non-US) token side letter for token upside; the SAFT is a distinct single-instrument route with the heaviest securities risk
• Each leg is distinct — separate securities classification (economic-reality-tested), separate accounting treatment (scope per framework), separate cap-table effect (two ledgers); a conclusion on one leg does not carry to the other
• Dual-ledger dilution — SAFE dilutes equity, token right dilutes the token ledger; one raise touches both, so fully diluted modelling must span both ledgers
• No single correct stack — jurisdiction-, structure- and fact-specific; design with securities counsel and accountant, each leg on its own facts — not legal/accounting advice