EigenLayer Tokenomics: EIGEN Token, Restaking Rewards & AVS Security

EigenLayer tokenomics is the economic design behind the EIGEN token and the restaking system that secures Actively Validated Services. It covers how ETH and liquid staking tokens get restaked to secure AVSs, how EIGEN works as a work token, and how rewards and slashing risk flow between restakers, operators, and the services being secured.

EigenLayer tokenomics is the economic design behind the EIGEN token and the restaking system it secures. It covers three moving parts: how ETH and liquid staking tokens get restaked to secure Actively Validated Services (AVSs), how EIGEN functions as a work token rather than a fee-capture token, and how rewards and slashing risk flow between restakers, operators, and AVSs.

This post walks through those three parts in order: the EIGEN token itself, the restaking rewards mechanism, and the AVS security model. It is a teardown of one named, live protocol, not a general restaking explainer.

Here is the economic logic underneath the whole design. An AVS pays for pooled cryptoeconomic security instead of bootstrapping its own validator set. That payment is the value-creation engine the token design sits on top of. The token is infrastructure. The service being secured is the engine.

#What Is EigenLayer Tokenomics? (Direct Answer)

EigenLayer tokenomics: the economic design governing the EIGEN token and EigenLayer's restaking system, covering how restaked ETH and liquid staking tokens secure Actively Validated Services, how EIGEN functions as a work token, and how rewards and slashing risk are shared between restakers, operators, and AVSs.

Break that definition into three parts: a token, EIGEN, with a specific job, a mechanism, restaking, that puts collateral to work, and a security model, the AVS layer, where that collateral earns rewards and takes on risk. Each part depends on the other two.

It is worth studying because a lot of teams are now designing restaking-adjacent or AVS-adjacent token models, and EigenLayer is a concrete reference point for the tradeoffs they are about to make. Reading one live system closely beats reading ten abstract explainers.

If restaking is a new term, start with our restaking glossary entry, then come back to the token design.

#How EigenLayer Restaking Works

Restaking reuses collateral that is already securing Ethereum. A staker who has staked ETH, or who holds a liquid staking token representing staked ETH, deposits that same collateral into EigenLayer's smart contracts and opts it into securing one or more additional services. The collateral does two jobs at once instead of one.

Restaking builds directly on Ethereum's existing proof-of-stake staking model, documented in Ethereum's staking documentation, rather than on a new consensus layer of its own. That is the important framing: EigenLayer is a layer of reuse on top of staking primitives that already exist, not a claim about Ethereum's own roadmap.

#Restaking ETH and liquid staking tokens

A restaker starts with staked ETH or a liquid staking token. They deposit it into EigenLayer and choose to extend that collateral to secure services beyond Ethereum itself. The economics here, what you could call actively validated services tokenomics, come down to one trade: an AVS pays restakers and operators for security instead of building and paying for its own validator set from scratch.

#Operators, AVSs, and the shared-security model

Two more roles complete the picture. Operators run the infrastructure that validates work for an AVS. Restakers delegate their collateral to an operator rather than running that infrastructure themselves. An AVS is any service that needs its own cryptoeconomic security and will pay for it: an oracle, a bridge, a data-availability layer, or similar middleware. The shared-security model lets many services draw on one pool of restaked collateral instead of each raising its own.

That reuse is the whole pitch, and it is also where the tradeoffs live. We come back to those below, in the AVS security section. For the broader liquid-restaking category this post deliberately does not repeat, see our LRT tokenomics guide.

#EIGEN Token Utility and Design

EIGEN token utility is easier to understand once you drop the assumption that it works like a standard governance or fee-capture token. It is documented as a work token aimed at a specific problem: securing conditions that cannot be verified purely on-chain. EigenLayer describes this as intersubjective security, a backstop for slashing disputes that require social or off-chain judgment rather than a clean on-chain proof.

Think of it like a court of last resort for faults an automated contract cannot adjudicate on its own. If an AVS claims an operator produced a faulty off-chain result that code alone cannot settle, EIGEN is designed to be the collateral and coordination layer that resolves it. That is a different design goal than a token whose main job is capturing protocol fees or counting governance votes.

EIGEN is issued as an ERC-20 token, the same standard defined in its Ethereum Improvement Proposal that fungible tokens on Ethereum commonly use. Naming the standard says nothing about the token's regulatory status. ERC-20 is a technical interface, not a legal classification. It is worth keeping those two ideas apart, because they get blurred often.

One honest caveat. Parts of this design are still maturing. Which slashing conditions are live versus planned, and how intersubjective disputes get resolved at scale, are areas where the documented design is ahead of track record. We are describing what the token is built to do, not asserting that every mechanism is already battle-tested. And to be direct about scope: this is mechanism description, not advice to buy, sell, or hold EIGEN or any other token.

#How Restaking Rewards Actually Flow

EigenLayer restaking rewards do not come from one source. They stack in layers, and keeping the layers separate is the point of this section. A restaker can earn native staking yield on the underlying ETH, plus rewards paid by the AVSs their operator secures, minus the operator's commission for running the infrastructure.

Here is the reward-flow chain, start to finish. A restaker deposits ETH or a liquid staking token. They delegate to an operator. The operator opts into one or more AVSs. Each AVS pays rewards for the security it receives, sometimes in its own token, sometimes in ETH, sometimes through EIGEN-denominated incentive programs. Those rewards then split between the operator's commission and the delegated restakers behind them.

To stay concrete without forward-looking numbers: restaking has attracted a large pool of collateral, and you can track EigenLayer's total value locked over time on DefiLlama as a scale reference. That figure shows how much capital has opted in. It does not tell you what any restaker will earn, and this post makes no yield projection. The mechanism defines how rewards are split. What that split is worth depends on which AVSs an operator secures, what they pay, and market conditions none of us control.

#The AVS Security Model and Its Tradeoffs

The AVS security model is a genuine design tradeoff, not a free lunch, and the two sides are worth stating plainly. On one side, shared restaked security lets a new service launch with meaningful economic security from day one instead of spending months bootstrapping its own validator set. On the other, that same shared collateral now carries correlated exposure across every service an operator has opted into.

#Shared security benefits for new AVSs

For a new AVS, the appeal is direct. Building an independent validator set is slow and capital-intensive, and a thin one is cheap to attack. Renting security from an existing pool of restaked collateral lowers that barrier. The service can focus on being useful and pay for security as an operating cost rather than raising a war chest to bootstrap it.

#Cross-AVS and operator concentration risk

The risks are the mirror image of the benefits, and founders evaluating a similar design should name them specifically. First, operator concentration: a small number of large operators can end up securing many AVSs, which concentrates influence and failure risk. Second, correlated slashing: collateral shared across services means a slashing event in one place can touch collateral committed elsewhere. Third, the intersubjective-fault problem: some slashing conditions require off-chain judgment, and judgment is harder to make trustless than a signature check. Audited staking and slashing contract patterns, like those documented in OpenZeppelin's contract libraries, handle the on-chain half of this well. The off-chain half is the harder design problem.

There is a securities-adjacent question worth naming carefully here. When an AVS pays restakers for securing it, does that arrangement raise questions under the Howey test, the framework U.S. courts use to decide whether something is an investment contract? In our view, the closer a reward stream sits to a passive return earned largely from other people's effort, the harder that question becomes. We are not asserting that any specific EIGEN or AVS arrangement is or is not a security. That is a fact-specific, jurisdiction-specific determination for a legal team and the relevant regulator, not a claim editorial content should make.

Close the loop back to where we started. The AVS security model only works if the AVS is providing a real service worth securing. Restaking someone else's collateral does not manufacture value on its own. The security is infrastructure. The service being secured has to be the engine, or the whole arrangement is a mechanism in search of a business.