Restaking AVS Design: Building Services on EigenLayer
EigenLayer AVS design is the process of architecting an Actively Validated Service that uses restaked ETH from EigenLayer to secure its operations, instead of bootstrapping its own validator set. This guide dives deep into the technical decisions—registration on EigenLayer, crafting slashing conditions, choosing operator selection mechanisms, and aligning incentives—that define a robust AVS. We'll ground everything in real protocols like EigenDA, Lagrange, and Omni, with concrete examples and a comparison table to clarify trade-offs.
Building an AVS is not for the faint of heart. You're essentially creating a new crypto-economic primitive that inherits Ethereum's security but must enforce its own rules. The choices you make in slashing logic and operator selection directly determine the service's trust model and capital efficiency. This walkthrough arms you with the knowledge to design an AVS that is both secure and economically sound.
- EigenLayer AVS design is primarily about defining slashing conditions that are cryptography-proof and enforceable on Ethereum.
- Operator selection must balance permissionless entry with stake-weighted quorums to prevent sybil attacks.
- Reward rates must mathematically exceed the expected frequency and severity of slashing events to attract rational operators.
- Use graduated slashing and separate bonds to avoid catastrophic losses for minor faults.
- Test every slashing condition with worst-case scenarios on testnet before mainnet launch; false slashing is reputation death.
- Start curated, then go permissionless—bootstrapping trust is easier with a known set of operators.
What Is an AVS and Why Does EigenLayer AVS Design Matter?
An AVS (Actively Validated Service) is any system that requires off-chain validation—think sidechains, data availability layers, oracles, bridges, or zk-Rollup sequencers. Traditionally, each such service would recruit its own stakers, fragmenting security and raising capital costs. EigenLayer changes that by letting ETH stakers 'restake' their stake and opt into validating your AVS, sharing Ethereum's security budget.
EigenLayer AVS design therefore focuses on how you specify the validation rules (what operators must prove) and the penalties for misbehavior. The core artifact is a slashing contract that EigenLayer's core protocol enforces. Your design must answer: Who can slash? Under what conditions? How do operators opt in? How do you incentivize participation beyond slashing? Getting this right is the difference between a secure AVS and a honeypot.
AVS Registration: The On-Chain Lifeline
Every AVS on EigenLayer must register itself via an AVS registry contract on Ethereum. This contract defines the service's metadata, its slashing conditions (as a set of fault types), and the quorum thresholds for validation. For example, EigenDA registers as a data availability AVS with a slashing condition for 'signing conflicting DA batches'.
The registry also specifies the operator set—a list of restakers who choose to validate your AVS. Operators call a function to opt in, and EigenLayer tracks their total stake. When designing registration, consider: Will you allow permissionless operator entry? How often can operators leave? What are the minimum and maximum stake limits? Many AVSs set a per-operator minimum stake to avoid dust attacks (EigenDA's is roughly 32 ETH) and a maximum to avoid over-concentration.
Concrete example: Lagrange, a zkOracle AVS, registers with multiple quorums—one for data feeding, one for proof generation—each with different slashing conditions. This modular registration allows fine-grained security.
Crafting Slashing Conditions: The Heart of Trust
Slashing is the mechanism that punishes operator misbehavior. In EigenLayer AVS design, you define fault types (e.g., double-signing, unavailability, invalid state transitions). Each fault must be submittable on-chain as a proof. The proof is verified by EigenLayer's core slashing contract, and then a portion (or all) of the operator's restaked ETH is forfeited.
Best practices: Keep slashing conditions unambiguous. Avoid subjective judgments (e.g., 'bad behavior') because they lead to governance attacks. Instead, use cryptographic evidence: a signature over conflicting data, a missing liveness attestation within a timeout window, or an invalid state root. For example, an oracle AVS might slash if an operator signs two different price feeds for the same block.
Balance is critical: too harsh slashing deters operators, too lenient invites attacks. Many AVSs use a graduated penalty—first offense: 1% slash, second: 5%, third: full slashing. Also consider a bond rather than full restaked amount; the operator posts a small bond that is slashed first, allowing the restaker to keep the majority of their ETH safe from petty faults. Design review: EigenLayer's AVS guide recommends using a 'frozen' period before slashing to allow challenges.
| Slashing Condition | Proof Type | Example AVS |
|---|---|---|
| Double-signing | Two conflicting signed messages | Omni (cross-chain messaging) |
| Liveness fault | Missing attestation in time window | EigenDA (data availability) |
| Invalid state root | Fraud proof | Lagrange (zkOracle) |
Operator Selection: Who Validates Your AVS?
Operator selection is the process by which your AVS chooses which restakers to include in its active set. EigenLayer allows two main models: permissionless and curated. Permissionless means any restaker can opt in, and your AVS's quorum is formed by the top N stakers by amount. Curated means you (the AVS builder) maintain a whitelist, often based on reputation or past performance.
Most advanced AVSs use a stake-weighted quorum with a minimum self-stake. For instance, if 3 out of 5 operators must sign, the total stake of those 3 must exceed a threshold (e.g., 67%). This prevents a sybil of tiny stakers from controlling the quorum. Some AVSs also assign different weights to operators based on their track record—a weighted voting model.
Real protocol: AltLayer as a rollup AVS uses a permissioned set of high-stake operators initially, then gradually opens to permissionless once the AVS is battle-tested. They also implement a 'rotating selection' where a subset of operators is chosen randomly each epoch to prevent long-range collusion.
Incentive Alignment: Rewards, Fees, and Slashing Symmetry
Slashing alone doesn't make operators join—they need rewards too. In EigenLayer AVS design, rewards come from two sources: AVS token emissions (if you have a native token) and service fees paid by users of the AVS. For example, EigenDA charges fees to rollups for blob inclusion, and those fees are distributed to operators proportional to their stake.
Critical design point: Rewards must be commensurate with slashing risk. If the potential slash is 10% of stake per fault, the annual reward must exceed the probability of slashing times 10%. Otherwise, rational operators will not participate. Many AVSs set rewards higher initially and taper as the service matures, though in practice the incremental AVS yield on restaked ETH has been modest — typically well under 1% to low single-digit APR.
Additionally, consider programmatic incentives: you can create a reward contract that pays out in your AVS token or in ETH. Some AVSs use a liquidity mining style program to bootstrap. But beware of inflation—over-issuance of AVS tokens can dilute value. A balanced approach: charge a small fee to users and distribute 100% to operators, with no token emission. This is the model used by Wormhole's AVS (proposed) for cross-chain verification.
Quorum Design: How Many Signatures Are Enough?
Every AVS must define a quorum threshold—the minimum number of operator signatures (or stake weight) required to produce a valid output (e.g., a DA certificate, a rollup batch, an oracle price). The classic trade-off is security vs. liveness. A high quorum (e.g., 80% of stake) is more secure (harder to corrupt) but less available (harder to get enough signatures in an adversarial network).
Advanced designs use stake-based quorums: you require signatures representing >2/3 of the total stake in the operator set. This ensures Byzantine fault tolerance. But because EigenLayer operators are also validators on Ethereum, you must consider correlation: many operators may run on the same infrastructure, increasing simultaneous failure risk. Mitigate this by enforcing a diversity requirement—e.g., no two operators in the quorum may share the same IP subnet (checked via off-chain reputation or on-chain attestation).
Concrete example: EigenDA uses a stake-weighted quorum of 2/3+ for blob inclusion, plus a 'dispersal' round that collects attestations. Missing attestation triggers a slower liveness slashing. This two-tier quorum balances security and liveness.
Security Model and Trust Assumptions
By building on EigenLayer, your AVS inherits Ethereum's security for stake slashing but introduces new trust assumptions. The primary assumption: the EigenLayer protocol is honest in executing slashing and distributing rewards. Since EigenLayer is itself a set of Ethereum smart contracts, it inherits L1 security. However, your AVS must be careful about reorg resilience—if Ethereum reorgs, slashing proofs might need to be invalidated.
Another assumption: operators are rational. They will not commit provably slashing offenses because the cost outweighs the benefit. But irrational adversaries (e.g., a state actor) might accept slashing to disrupt your AVS. To guard against this, design gradual unlocking: operators cannot withdraw restaked ETH immediately; they must wait a 'unbonding period' (e.g., 7 days on EigenLayer) to allow time for slashing proofs to be submitted.
Finally, consider shared security risk: multiple AVSs draw on the same operators, but EigenLayer's live slashing design (unique stake, shipped with the 2025 slashing upgrade) isolates the impact — operators allocate a distinct portion of stake to each AVS's operator set, and a slash in one AVS burns only the stake allocated to that operator set, not the allocations to other AVSs.
Comparison: AVS vs. Traditional App-Specific Validator Sets
| Feature | AVS on EigenLayer | Traditional App-Specific Set |
|---|---|---|
| Capital Efficiency | Restake existing ETH; no new token sale | Must raise capital for native tokens |
| Validator Set | Large, permissionless (if designed) | Smaller, often permissioned |
| Slashing | Programmable faults | Often single slashing condition |
| Interoperability | Shared security across AVSs | Isolated security |
| Bootstrapping | Easier; tap into restakers immediately | Harder; need to incentivize validators |
| Economic Complexity | Higher (multi-AVS risk, correlation) | Lower |
Real-World AVS Examples: EigenDA, Lagrange, and Omni
EigenDA is the canonical AVS—a high-throughput data availability service for rollups. Its EigenLayer AVS design uses a permissionless operator set with a 2/3 stake quorum. Operators attest to blob availability; missing attestation triggers a liveness slashing after a timeout. Rewards come from rollup fees, distributed proportionally.
Lagrange is a zkOracle AVS that verifies off-chain data using zero-knowledge proofs. They register multiple slashing contracts: one for data providers (slashed for incorrect data) and one for proof generators (slashed for invalid proofs). Operator selection is curated initially, with plans to open. Restaked ETH provides the cryptoeconomic security; Lagrange also has its own native token, LA (launched in 2025).
Omni is a cross-chain messaging protocol that uses EigenLayer to secure its validator set. Their AVS design features a unique 'active validation' where operators attest to cross-chain events, and slashing occurs for double-signing of conflicting messages. Slashed funds are burned or frozen by EigenLayer's core contracts rather than redirected to an AVS-controlled insurance pool.
Step-by-Step: Designing Your Own AVS on EigenLayer
Now let's synthesize the design process into actionable steps.
- Define the validation task: What precisely must operators prove? (e.g., 'I have stored this blob', 'I saw this block on chain B'). Be specific and cryptographic.
- Specify slashing conditions: List at most 3-5 types of faults. For each, write a Solidity 'verifyFault' function that takes cryptographic input and returns a boolean. Test with worst-case gas.
- Decide operator selection: Permissionless or curated? Set minimum stake, maximum stake, and quorum threshold (e.g., 67% by stake). Consider diversity rules.
- Design the reward system: Will you charge fees? Issue tokens? How are rewards distributed? Ensure APR > expected slashing loss.
- Implement the registry contract: Follow EigenLayer's 'AVSRegistry' interface. Register fault types and operator set.
- Build off-chain client: Operators need software to fetch tasks, produce attestations, and submit proofs. Provide a reference implementation.
- Test on Holesky testnet: Deploy AVS, onboard test restakers, simulate slashing events, and iterate.
- Audit slashing logic: Engage multiple firms to review verifyFault functions. False slashing can destroy trust.
- Launch with a trusted operator set: Start small, then gradually open permissionless gates.
Step-by-step
- Define the validation task as a precise, cryptographically verifiable statement.
- Specify up to five unambiguous slashing conditions with Solidity verifyFault functions.
- Decide on operator selection model: permissionless or curated, with stake-weighted quorum.
- Design reward system: fees or token emissions, ensuring reward rate exceeds expected slashing loss.
- Implement an AVS registry contract following EigenLayer's interface.
- Build an off-chain client for operators to perform tasks and submit attestations.
- Deploy on Holesky testnet, simulate slashing, and refine.
- Conduct multiple audits on slashing logic to prevent false slashing.
- Launch with a curated operator set, then gradually transition to permissionless.
Common mistakes to avoid
- Defining slashing conditions that are too subjective or impossible to prove cryptographically in a dispute.
- Setting quorum thresholds too low (sacrificing security) or too high (sacrificing liveness) for the given operator set size.
- Neglecting unbonding period: allowing instant withdrawals gives adversaries an escape hatch before slashing proofs land on-chain.
- Copying another AVS's slashing logic without adjusting for your service's latency and fault tolerance requirements.
- Ignoring operator correlation: many EigenLayer operators run on the same cloud or client, increasing simultaneous failure risk.
- Failing to budget for gas costs: complex slashing proofs can be prohibitively expensive on Ethereum, discouraging watchtowers.
Frequently asked questions
What is the minimum amount of restaked ETH needed to launch an AVS on EigenLayer?
EigenLayer does not enforce a fixed minimum; you set the threshold. In practice, meaningful cryptoeconomic security requires far more than a token amount: established AVSs set per-operator minimums in the tens of ETH (EigenDA's is roughly 32 ETH) and are backed by total restaked stake worth billions of dollars, though you can start with much less on testnet.
Can an operator participate in multiple AVSs simultaneously?
Yes, that is the core innovation of EigenLayer. Under the current slashing design (unique stake, shipped with the 2025 slashing upgrade), operators allocate a distinct portion of their stake to each AVS's operator set, and a slash in one AVS burns only the stake allocated to that operator set — stake allocated to other AVSs is untouched.
How do I prevent false slashing in my EigenLayer AVS design?
Use cryptographic evidence only, not subjective reports. Include a challenge period during which the operator can dispute the slashing proof. Design a 'frozen' state that prevents withdrawal during dispute resolution.
What is the role of the EigenLayer core contract in my AVS?
EigenLayer's core contract manages restaking, delegation, and the global slashing execution. Your AVS contract registers faults, and when you submit a valid proof, the core contract enforces the stake withdrawal and burn.
Related reading
Track the entities behind the concepts
DeFi Intel maps 11,000+ protocols, tokens and companies to a typed knowledge graph — with live data, incidents and regulation.