ERC-7854 is an Ethereum token standard that introduces explicit lifecycle phases into ERC-20 tokens. Instead of deploying a separate vesting contract that holds tokens on behalf of recipients, ERC-7854 bakes phase logic directly into the token itself, so a single token address can move from presale through vesting to fully tradeable, and eventually to a burned state, without any off-contract custody. The proposal was authored by contributors to the Ethereum standards process and is tracked on the Ethereum Improvement Proposals repository.
​

By April 2026, teams deploying employee compensation tokens, DAO treasury instruments, and structured token launches had begun using phase-aware designs to enforce business logic at the token layer rather than the application layer. The standard addresses a gap that classic ERC-20 leaves open: nothing in the base spec prevents a holder from transferring tokens that a project intends to be non-transferable until a future date or condition.
​

ERC-7854 is an Ethereum token standard that extends ERC-20 with a phase registry mapping each holder address to one of four lifecycle phases: presale, vesting, tradeable, and burned. Phase membership controls transfer eligibility. A token in presale reverts any transfer call; a token in the tradeable phase behaves exactly like standard ERC-20.
​

The standard does not require a separate custodian contract. Phase logic sits in the token's _beforeTokenTransfer hook. The registry is append-only: phase index can only increase, so a token cannot be re-locked once it reaches the tradeable phase.
​

The core innovation is moving the constraint from an external vesting contract into the token's own _beforeTokenTransfer hook. OpenZeppelin's classic VestingWallet holds tokens in escrow, meaning the recipient's wallet shows zero balance until the vest date. ERC-7854 instead assigns tokens to the recipient immediately but marks them as non-transferable. Recipients can see their full allocation from day one, which is material for financial reporting and tax treatment in many jurisdictions.
​

Phase logic is enforced by a PhaseController role, a configurable access-control address that may be a multisig, a DAO governor contract, a keeper bot, or an oracle feed. The controller calls setPhase(address recipient, uint8 phase) or, in batch variants, setPhaseBatch(address[] recipients, uint8[] phases). Time-locked transitions use a queued scheduler that fires automatically at a pre-committed block timestamp.
​

Phase transitions in ERC-7854 are either time-triggered or condition-triggered. A time-triggered transition queues a target phase and a UNIX timestamp; at the block where block.timestamp >= unlockTime, the next transfer attempt by or for that address advances the phase automatically. A condition-triggered transition requires the PhaseController to call setPhase after verifying an external condition, such as a governance vote passing or a KYC check clearing.
​

The internal transition table is append-only by design. A token that has reached the tradeable phase cannot be moved back to vesting. This irreversibility prevents rug mechanics where an issuer could re-lock tokens that recipients reasonably believed were liquid. The EIP specification codifies this as a state-machine invariant: phase index can only increase.
​

A typical issuance flow looks like this:

In the vesting phase, the standard introduces a vestedAmount(address account, uint256 timestamp) view function that returns the transferable fraction at any point in time. Integrating wallets can surface this as a progress bar without needing to know the project's off-contract vesting math.
​

ERC-7854's access control model assigns three roles: Owner, PhaseController, and Minter. The Owner sets and revokes role assignments. The PhaseController calls phase transitions. The Minter creates new token supply, always in phase 0. Role separation means a project can assign the PhaseController to an onchain governance address while keeping the Minter under a hardware-wallet-secured multisig, limiting blast radius if either key is compromised.
​

The PhaseController address is the highest-privilege operational role. If a project assigns this role to an externally owned account (EOA) rather than a smart contract, the controller can advance phases unilaterally, which replicates the trust assumptions of traditional vesting. Projects aiming for credible decentralization should route the PhaseController through a Compound-style Governor or a Gnosis Safe with a minimum threshold of co-signers. On-chain governance assignment is the distinguishing feature that separates ERC-7854 from a custom lock-up contract.
​

Several independent EVM security auditors, including firms that reviewed ERC-4626 vault implementations, have flagged two common misconfiguration patterns in early ERC-7854 pilots:

The specification's recommended mitigation for timestamp drift is to use a time buffer of at least 64 seconds between the expected unlock time and any enforcement of finality, matching the approximate 2-epoch finalization window on post-merge Ethereum.
​

ERC-7854 moves vesting logic onchain into the token itself rather than an escrow contract. Recipients see a full balance immediately, no claim transaction is needed per milestone, and the phase state is publicly auditable. The tradeoff is a more complex token contract and governance overhead from the PhaseController role setup.
​

The table below compares ERC-7854, OpenZeppelin VestingWallet, and a plain time-locked multisig across the dimensions teams typically evaluate when choosing a vesting mechanism.
​

The comparison shows that ERC-7854's primary advantages are recipient transparency and governance flexibility. Its primary cost is deployment complexity: the PhaseController governance setup requires decisions that a VestingWallet deployment skips entirely. Teams shipping a simple 4-year cliff for a single employee tranche may find VestingWallet simpler. Teams managing a public token launch with multiple investor tranches, a community allocation, and a DAO treasury reserve benefit from ERC-7854's unified phase registry.
​

ERC-7854 addresses four concrete deployment scenarios: token launches requiring presale lockups, employee compensation programs, DAO treasury management, and protocol-controlled reward tokens. Each uses a different combination of phases and transition triggers, but all share the same token contract architecture.
​

A project raising in a presale round mints tokens directly to contributor addresses in phase 0. The presale lock prevents secondary market activity before the TGE, eliminating the information asymmetry between insiders who receive tokens early and retail participants who buy at listing. Compared to a simple smart-contract lockup, the ERC-7854 approach keeps the token visible in wallets like MetaMask and Rainbow from day one, which improves contributor experience and reduces support overhead from "where are my tokens?" queries. ENS DAO's 2021 airdrop, which shipped 100M ENS tokens to 137,000 addresses via a separate distributor contract, is an example of the problem ERC-7854 is designed to avoid: recipients had to claim, and unclaimed tokens accrued for months before the DAO swept them.
​

For employee token compensation, ERC-7854 maps naturally to a 1-year cliff / 3-year linear schedule: phase 0 during the probationary period, phase 1 during the linear vest, phase 2 at full vest. A PhaseController governed by an HR multisig can accelerate to phase 2 on acquisition events or terminate by burning the unvested fraction on separation. The IRS's Publication 525 treatment of restricted property recognizes transfer restrictions as a valid indicator of unvested status, which aligns with the phase 0 and phase 1 design.
​

DAO treasuries that release tokens to grant recipients, protocol contributors, or ecosystem funds can use ERC-7854 to enforce milestones. The PhaseController is set to the DAO's Governor contract, which means only a successful governance vote can advance a grantee's tokens from phase 1 to phase 2. This creates an accountability loop: the grantee must demonstrate deliverables, and the DAO votes to unlock, rather than tokens releasing automatically on a time schedule regardless of outcomes. As of Q1 2026, Compound Finance's treasury held approximately $360M in COMP and protocol-owned stablecoins; multi-tranche ERC-7854 deployments would allow milestone-gated distributions without complex off-chain coordination.
​

Liquidity mining and protocol rewards often suffer from mercenary capital: recipients sell immediately, driving down price and discouraging long-term alignment. ERC-7854's vesting phase allows protocols to distribute rewards in real time (so recipients see accrual) while delaying transfer eligibility by 30–90 days. Aave, which distributed over $200M in AAVE rewards across V2 and V3 by Q1 2026 (DeFiLlama TVL and emissions data), has managed this problem through separate staking mechanisms; ERC-7854 consolidates the equivalent logic into the token itself.
​

Phase 1 is the vesting phase, where tokens shift from non-transferable to partially transferable on a schedule. ERC-7854 defines a linear model by default: transferable fraction equals elapsed time since vest start divided by total vest duration, times total allocation. Cliff variants withhold 100% until a date, then begin linear release. The contract exposes this via vestedAmount(address, uint256).
​

The mechanics are implemented in the transfer hook. When a phase-1 holder initiates a transfer of amount X, the hook computes vestedAmount(holder, block.timestamp), subtracts any previously transferred vested amount (tracked in transferredAmount[holder]), and checks that X does not exceed the remaining transferable balance. If the requested amount exceeds the available vested amount, the transaction reverts with a InsufficientVestedBalance error rather than a generic revert, giving the user a clear error message.
​

This granularity matters for tax accounting. Under the IRS's Section 83 treatment of restricted stock units (Publication 525), the taxable event for token compensation is typically when the restriction on transfer lapses. In an ERC-7854 deployment, that event is the partial or full phase-2 transition, creating a clear onchain timestamp for tax purposes. In VestingWallet-based deployments, the taxable event interpretation is less clear because tokens remain in the escrow contract's address until claimed.
​

Projects deploying ERC-7854 for employee compensation should include a vestingSchedule view function that returns the cliff timestamp, vest start, and vest end for a given address. Several EVM audit firms have recommended this addition because it allows employees to compute their transferable balance independently without relying on the project's dashboard, reducing disputes during termination events.
​

ERC-7854 introduces three attack surfaces that standard ERC-20 tokens do not have: the PhaseController role, time-lock manipulation, and the phase transition audit trail. Auditors reviewing ERC-7854 deployments should verify that the PhaseController cannot act unilaterally after the TGE, that all scheduled transitions use a time buffer, and that the phase mapping storage is not overridable by arbitrary callers.
​

The most consequential risk is PhaseController key compromise. If the controller is an EOA and the private key leaks, an attacker can advance all recipient tokens to the tradeable phase simultaneously and dump them. Mitigation requires routing the controller through a time-locked multisig or a Governor contract with a minimum voting delay. The Ethereum Foundation's smart contract security guidelines recommend a minimum 48-hour timelock delay on any privileged admin action that affects token holders.
​

A second surface is the batch transition function. setPhaseBatch with a large array of addresses can exceed the Ethereum block gas limit of roughly 30M gas per block as of Q1 2026. Deployments managing more than approximately 5,000 recipient addresses in a single batch need a chunked execution pattern, where the PhaseController calls multiple batch transactions across consecutive blocks.
​

Finally, the phase mapping storage itself should be verified against reentrancy. If the token contract calls an external oracle to check a condition before transitioning, the oracle callback creates a reentrancy vector. The standard recommends the checks-effects-interactions pattern: write the new phase state before calling any external address.
​

ERC-7854 exposes phase state through two view functions: phaseOf(address holder) returns the current phase index for a given address, and vestedAmount(address holder, uint256 timestamp) returns the transferable amount in the vesting phase. Wallets and block explorers that implement ERC-7854 support can surface this as a human-readable status — "Locked (Presale)", "Vesting (42% transferable)", or "Fully Tradeable" — rather than a raw uint8.
​

MetaMask and Rainbow do not yet natively display ERC-7854 phase metadata as of Q1 2026, but both support ERC-20 metadata extensions that third-party snap or extension developers can use to surface the phase state. The ENS Avatar and Token Metadata standards provide a precedent: wallets that implement the metadata extension spec render rich token information even when it requires offchain lookups. ERC-7854 phase state is fully onchain, so it requires no offchain query once the wallet implements the view call.
​

Block explorers like Etherscan display ERC-7854 phase state if the contract source is verified and the explorer indexes the PhaseSet events that the standard requires token contracts to emit on every phase transition. The event signature is PhaseSet(address indexed holder, uint8 phase, uint256 timestamp). An Etherscan query on a verified ERC-7854 contract will show a complete audit trail of all phase advances since deployment, which is the onchain accountability record that separates ERC-7854 from ad-hoc lock-up contracts with no event logging.
​

ERC-7854 tokens in the tradeable phase are standard ERC-20 tokens and integrate without modification with routing infrastructure. Phase 0 and phase 1 tokens cannot be bridged because the bridge's lock call reverts, providing automatic containment for multi-chain distributions without additional compliance logic.
​

For treasury teams distributing employee tokens across Ethereum, Polygon, and Base, deploying the ERC-7854 contract per chain and synchronizing phase transitions via a cross-chain governance message enforces the same vesting schedule on each chain. Eco's payment infrastructure routes fully tradeable ERC-20 tokens across 15 supported chains. As phase-aware tokens enter wider circulation, the interplay between phase gating and cross-chain intent settlement will matter for developers building compensation or treasury tooling on top of routing infrastructure.
​

Eco's payment infrastructure routes fully tradeable ERC-20 tokens across 15 supported chains. As phase-aware tokens enter wider circulation, the interplay between phase gating and cross-chain intent settlement will matter for developers building compensation or treasury tooling on top of routing infrastructure.
​

Sources and methodology. ERC-7854 specification details sourced from the Ethereum Improvement Proposals repository. Aave emissions and DeFi TVL figures from DeFiLlama, April 2026. OpenZeppelin VestingWallet behavior from OpenZeppelin Contracts v5 source. Compound treasury figures approximate as of Q1 2026. Protocol figures refresh quarterly.
​

By Eco research. Updated Apr 2026.
​

The four phases are presale (phase 0, non-transferable), vesting (phase 1, partially transferable on a schedule), tradeable (phase 2, standard ERC-20 behavior), and burned (phase 3, terminal). Phases can only increase numerically, so a token cannot be moved from tradeable back to vesting.
​

No. ERC-7854 embeds phase logic in the token contract's transfer hook. Recipients receive tokens to their wallet immediately at issuance and can see their full allocation, even while tokens are non-transferable. A separate escrow or vesting wallet contract is not required.
​

Tokens in phase 0 or phase 1 will revert transfer calls, so they cannot be deposited into Aave, Uniswap, or similar protocols. Once a token reaches phase 2 (tradeable), it is fully ERC-20 compatible and works with any DeFi protocol without modification.
​

The PhaseController role controls transitions. That role can be assigned to a multisig, a DAO Governor contract, a keeper bot, or an individual address. For credible decentralization, most projects route PhaseController through a Governor with a minimum voting delay of at least 48 hours before any phase advance executes.
​

A compromised PhaseController can immediately advance all recipient tokens to phase 2, enabling a mass dump. This is the critical risk in ERC-7854 deployments. The mitigation is to assign PhaseController to a time-locked multisig or Governor contract, not an EOA, so any unauthorized transition attempt faces a mandatory delay during which the Owner role can revoke and reassign the controller.
​