Web3 Employee Token Grant Structuring: Allocation, Vesting, Lockups

A token grant is not a number you airdrop into a wallet; it is a designed instrument. Get the vesting, the lockup, or the tax-timing lever wrong and you produce accounting noise, a retention failure, or a tax bill on tokens that never vested. This is the cornerstone guide for the token-compensation cluster: the four levers that define a grant, how each one feeds the accounting, and why every one of them is a question for legal and tax advisers. The narrower pieces, the vesting and cliff recognition, the withholding mechanics, and the French BSPCE comparison, build on the design decisions set out here.

The structuring levers in brief

• A token grant turns on four levers: the allocation, the vesting schedule, the lockup (which is separate from vesting), and any early-tax election (a US 83(b)-type concept that is not universal).
• A lockup is not vesting. Vesting is the earning condition; a lockup is a transfer restriction that can run beyond vesting.
• An 83(b)-type election is US-specific, carries a strict deadline and real risk, and is not a universal mechanism.
• Structure drives the accounting: the schedule sets the recognition profile (IFRS 2 over the service period; graded vesting as sub-awards).
• Every lever has jurisdiction-specific legal, tax and dilution consequences, and special regimes such as the French BSPCE differ again.
• The result should be an advised design, not a template copied across jurisdictions.

The four levers

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

Lockup is not vesting

• Vesting is the earning condition (service or performance) that determines entitlement.
• Lockup is a transfer restriction that prevents sale or movement for a period, and it can run separately from and beyond vesting.

A token can be vested but still locked. Conflating the two mis-states both 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: for certain restricted-property awards, a recipient may elect to be taxed at grant on the value at that point, rather than at vest, within a strict deadline. It is US-specific and carries real risk, because you pay tax up front on possibly illiquid property that may never vest. It should 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 central YMYL caution of the article: an election made on a wrong assumption can leave a contributor taxed on tokens they never receive.

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 a graded schedule changes the expense profile, and the lockup may affect fair-value and 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, such as the French BSPCE, applies. A schedule that is efficient in one country may be penalising in another; an early election may help or harm depending on the outcome and the rules. The structuring is a deliberate, advised design, and a template copied across jurisdictions is a liability rather than a shortcut.

Practical guidance

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

Configuring a tool for grant structuring

A grant-administration platform holds the four levers as data, but it does not perform the legal or tax design, which is jurisdiction-specific and adviser-led. When you evaluate one, confirm that it can:

• model the lockup separately from vesting, so a vested-but-locked position is represented correctly;
• support graded schedules, not just a single cliff;
• record the early-election status where one applies.

Platforms such as Liquifi and Toku administer allocation, vesting, lockups and election-tracking data of this kind; the structuring decisions behind that data remain with counsel and your tax adviser.

How Wag3s supports the design

Wag3s HR tracks the designed grant, the allocation, the vesting and cliff, the lockup held separately from vesting, and the election status, and feeds the IFRS 2-scope recognition with an audit trail, so the structure's accounting consequence is captured cleanly. The legal and tax design across jurisdictions remains an advised decision; Wag3s is built to support qualified legal and tax advisers rather than replace them. 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

The multi-jurisdiction employee problem

Token grants become substantially more complex when contributors are located in different countries — which is the normal state for a Web3 project. A grant structure designed around US employees may create significant unintended tax events for contributors in France, Germany, the UK, or Singapore.

The core issue is that income-recognition timing differs by jurisdiction. In the US, the default recognition point for a restricted token is at vest (unless an 83(b) election is made). In France, a token grant may engage the BSPCE regime if properly structured, producing a deferred gain-on-sale outcome, or it may be treated as employment income at a point determined by French rules. Germany taxes at a different point again. These differences are not just timing — they affect the amount taxable, because token prices fluctuate substantially between grant, cliff, vest, and eventual sale.

A concrete example of the failure mode: a company grants tokens at a $0.10 reference price, with a 12-month cliff and 3-year total vesting. By vest, the token trades at $2.00. A US employee with a timely 83(b) election pays tax on the $0.10 grant-date value. A German employee without an equivalent election may recognize income at $2.00 at vest. The same grant, drastically different outcomes.

The retention implication is real. A contributor who receives a large income tax bill at vest — in some jurisdictions requiring cash payment on illiquid tokens — faces a retention crisis. The employer may be required to withhold and remit tax even when the tokens cannot be sold, creating a cash-flow problem for the contributor and a payroll-tax compliance obligation for the company.

Practical steps for multi-jurisdiction grants:

1. Map all contributor jurisdictions before finalizing the schedule. Tax treatment varies enough that a single schedule applied uniformly across jurisdictions can produce wildly different effective outcomes.
2. Identify whether any jurisdiction requires mandatory withholding on vest. Several EU jurisdictions require the employer to withhold income tax at the vest event, even if the tokens are still locked.
3. Document each jurisdiction's treatment as part of the grant agreement review — not as a footnote but as a per-recipient analysis.
4. Consider whether the vesting schedule design should differ by jurisdiction — a longer cliff that defers the income recognition event in favorable jurisdictions may be worth the retention trade-off.

Sources

• IFRS — IFRS 2 Share-based Payment and IAS 19 Employee Benefits: the schedule drives recognition, with an equity-settled award expensed over the service period at grant-date fair value (graded vesting as sub-awards, forfeitures under the service-condition rules). Which standard applies is the scope question.
• IRS — Digital assets hub and Frequently asked questions on digital asset transactions, for the US framework that surrounds restricted-property awards and the timing of income recognition.
• France — see the BSPCE vs token grants article and its BOFiP and Légifrance sources for a worked example of a special national regime.

The 83(b)-type early-tax election is a US tax-code concept with a strict deadline and the risk of up-front tax on illiquid or forfeitable property; it is not universal, and other jurisdictions have their own rules or none. Because the structuring levers, the election availability and the per-country treatment are arrangement- and jurisdiction-specific, confirm any design with qualified legal and tax advisers.