Web3 Employee Token Grant Structuring: Allocation, Vesting, Lockups

A token grant is not a number you airdrop — it is a designed instrument. Get the vesting, the lockup, or the tax-timing lever wrong and you create accounting noise, a retention failure, or a tax bill on tokens that never vested. This guide is the levers, each an adviser question.

TL;DR

• Four levers: allocation, vesting schedule, lockup (separate from vesting), early-tax election (US 83(b)-type — not universal).
• Lockup ≠ vesting — vesting is the earning condition; lockup is a transfer restriction that can run beyond vesting.
• An 83(b)-type election is US-specific, strict-deadline, risky — not a universal mechanism; jurisdiction-specific.
• Structure drives accounting — schedule = recognition profile (IFRS 2 over service period; graded = sub-awards).
• Every lever has jurisdiction-specific legal/tax/dilution consequences; special regimes (FR BSPCE) differ.
• An advised design, not a cross-jurisdiction template.

The four levers

Each interacts with accounting (IFRS 2 vs IAS 19, recognition over the service period) and jurisdiction-specific tax. They are design choices with consequences, not boilerplate.

Lockup is not vesting

• Vesting = the earning condition (service/performance) determining entitlement.
• Lockup = a transfer restriction preventing sale/movement for a period, which can run separately from and beyond vesting.

A token can be vested but still locked. Conflating them mis-states the accounting recognition and the holder's actual liquidity, and the tax point may turn on one or the other depending on the jurisdiction. Design and track them as distinct.

The 83(b)-type election: US-specific, not universal

An 83(b)-type election is a US tax-code concept: a recipient may elect to be taxed at grant on the value then, rather than at vest, within a strict deadline, for certain restricted-property awards. It is US-specific, with strict conditions and real risk — you pay tax up front on possibly illiquid property that may never vest. It must not be presented as a universal mechanism; other jurisdictions have their own, different rules or none. Treat any early-election decision as jurisdiction-specific and adviser-confirmed — this is the YMYL caution of this article.

Structure drives the accounting

The schedule drives recognition: an equity-settled IFRS 2 award is expensed over the service period at grant-date fair value; graded vesting is effectively multiple sub-awards; forfeitures follow service-condition rules (see token vesting & cliff accounting). A longer cliff or graded schedule changes the expense profile, and the lockup may affect fair-value/liquidity considerations. Design with the recognition consequence in view — after settling the IFRS 2 vs IAS 19 scope.

Why it is an adviser question

Each lever has legal, tax, accounting, and dilution consequences that differ by jurisdiction and by whether a special regime (e.g. French BSPCE) applies. A schedule efficient in one country may be penalising in another; an early election may help or harm depending on outcome and rules. The structuring is a deliberate, advised design — a template copied across jurisdictions is a liability, not a shortcut.

Practical guidance

1. Design all four levers deliberately — allocation, vesting, lockup, early-election.
2. Model lockup separately from vesting — a token can be vested-but-locked.
3. Treat 83(b)-type as US-specific — never a universal default; jurisdiction-confirm.
4. Design with the IFRS 2 recognition profile in view; settle scope first.
5. Check special regimes (FR BSPCE) before applying a generic token-grant design.
6. Adviser-confirm per jurisdiction; document the chosen structure and its basis.

How vendor tools handle grant structuring

Liquifi and Toku administer allocation, vesting, lockups, and election-tracking data. Confirm the tool models lockup separately from vesting, supports graded schedules, and records election status — administration of the structure is not the legal/tax design, which is jurisdiction-specific and adviser-led.

How Wag3s helps

Wag3s HR tracks the designed grant — allocation, vesting/cliff, lockup-separate-from-vesting, and election status — and feeds the IFRS 2-scope recognition with an audit trail, so the structure's accounting consequence is captured while the legal/tax design stays an advised, jurisdiction-specific decision. See the HR product page.

Further reading

• BSPCE vs Token Grants for French Web3 Startups
• Token Vesting & Cliff Accounting
• Token Compensation Accounting: IFRS 2 or IAS 19?
• Token Compensation Tax Withholding
• Token Vesting Accounting
• Web3 Payroll Guide

Sources

• Token-grant structuring levers: allocation, vesting schedule (cliff/period/graded), lockup (transfer restriction separate from and potentially beyond vesting), early-tax election where available
• 83(b)-type election is a US tax-code concept (elect taxation at grant within a strict deadline; risk of up-front tax on illiquid/forfeitable property) — US-specific, not universal; other jurisdictions differ or have none
• Structure drives accounting recognition (equity-settled IFRS 2 over service period; graded = sub-awards; forfeiture service-condition rules); jurisdiction-specific legal/tax/dilution; special regimes (FR BSPCE) differ — advised design