Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the offeror or person seeking admission to trading
Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D: Information about the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-10-21

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

FALSE

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

Warning

This summary should be read as an introduction to the crypto-asset white paper.

The prospective holder should base any decision to purchase this crypto –asset on the content of the crypto-asset white paper as a whole and not on the summary alone.

The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.

This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

EIGEN is an ERC-20 token on Ethereum associated with EigenLayer, a protocol in which participants stake assets with operators that run actively validated services (AVSs). EIGEN can be held, transferred and staked. Staked EIGEN can be delegated to operators and is exposed to slashing by AVSs, including partial or total loss, and to a withdrawal delay of 14 days. EIGEN has no fixed maximum supply, and new EIGEN is issued weekly through the Emissions Controller. EigenLayer describes a process called intersubjective forking for faults that cannot be determined on-chain; the EIGEN contract does not implement it.

EIGEN holders may hold and transfer their tokens, subject to applicable technical, contractual and legal restrictions. Holders may also elect to participate in eligible staking arrangements, either directly or through supported delegation mechanisms, subject to the relevant protocol requirements. Participation may provide access to staking incentives but can expose staked tokens to penalties, including partial or total loss where applicable slashing conditions are met.

These functionalities and potential incentives relate to the use of EIGEN within the protocol and do not, solely by virtue of holding or staking the token, confer ownership of EigenLayer, an entitlement to dividends, or a contractual claim against EigenLayer or its contributors to financial returns.

Not applicable

Bitstamp Europe S.A. is now seeking its admission to trading of the EIGEN crypto-asset within the EU so as to enable secondary market liquidity. The intended admission to trading aims to enable EIGEN holders to trade the crypto-asset on Bitstamp, a regulated European Union crypto-asset trading platform, subject to prevailing market conditions, trading activity and available liquidity.

TRUE

EigenFoundation

Based on our assessment of the available information, EigenFoundation, a Cayman Islands foundation company, appears to have been responsible for the initial issuance and distribution of EIGEN. EigenFoundation organised the initial distribution, makes allocations from the supply it holds, appoints the Protocol Council, which determines the overall emission rate and oversees upgrades to the emissions contract, and jointly holds the Pauser multisignature wallet with Eigen Labs. Eigen Labs, Inc. develops and maintains the relevant smart contracts but is not considered the issuer for the purposes of this white paper. Newly minted EIGEN tokens are created through a smart contract that can be triggered by any account, without requiring a separate issuance decision or action by a person for each minting transaction.

N/A as LEI is provided in B.7

N/A as LEI is provided in B.7

N/A as LEI is provided in B.7

N/A as LEI is provided in B.7

N/A as LEI is provided in B.7

N/A as LEI is provided in B.7

N/A as LEI is provided in B.7

2023-07-10

6488C83A9F81CC2MA168

N/A as LEI is provided in B.7

N/A as LEI is provided in B.7

EigenFoundation is an independent, shareholder-less foundation company established in the Cayman Islands. Its principal activity is to support the development, adoption and progressive decentralisation of the EigenLayer ecosystem.

The Foundation undertakes activities relating to ecosystem stewardship, the distribution and allocation of EIGEN tokens, the administration of community incentive programmes and grants, and the funding of research, development and ecosystem initiatives.

It also supports the establishment and development of decentralised governance arrangements, including mechanisms for community participation in protocol governance and oversight. These activities are intended to support the continued operation and development of the EigenLayer ecosystem.

Not applicable

Bitstamp Europe S.A.

5GGB

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

2015-05-19

549300XIBGTJ0PLIEO72

Bitstamp Europe S.A. is registered with the Luxembourg Trade and Companies Register under the number B196856.

Robinhood Markets, Inc with its registered office at 85 Willow Road, Menlo Park, California 94025, USA.

Bitstamp Europe S.A., acting in its capacity as a crypto-asset service provider (CASP) and operator of a trading platform, has prepared this crypto-asset white paper to support the admission to trading of the crypto-asset on its platform and to provide users with the information required under Regulation (EU) 2023/1114 (MiCA).

Bitstamp Europe S.A. is a Crypto-Asset Service Provider authorised with the CSSF under the number N00000003 to provide the following crypto-asset services:

• providing custody and administration of crypto-assets on behalf of clients;
• operation of a trading platform for crypto-assets;
• exchange of crypto-assets for funds;
• exchange of crypto-assets for other crypto-assets;
• execution of orders for crypto-assets on behalf of clients;
• reception and transmission of orders for crypto-assets on behalf of clients; and
• providing transfer services for crypto-assets on behalf of clients.

Bitstamp Europe S.A. is a payment institution authorised by the CSSF under number Z00000012 to provide the following payment services:

3.a) execution of direct debits, including one-off direct debits,

3.b) execution of payment transactions through a payment card or a similar device,

3.c) execution of credit transfers, including standing orders and

6.) money remittance.

Bitstamp Europe S.A. has notified the cross-border provision of payment services and of crypto-asset services in all EU and EEA member states.

Bitstamp has admitted the asset to which this white paper relates to, to trading on its own initiative on its trading platform.

Robinhood Markets, Inc. is the parent holding company of the Robinhood group.

MiCA Crypto Alliance Limited

MiCA Crypto Alliance Limited was mandated to assist in the white paper preparation by Bitstamp Europe S.A. Bitstamp Europe S.A. retains the role of person seeking admission to trading.

EigenCloud

EIGEN

EIGEN

EigenLayer is a protocol built on the Ethereum blockchain that enables the reuse of staked assets to provide cryptoeconomic security for additional decentralised services. Through EigenLayer, participants can restake eligible assets and delegate their stake to operators that support services known as actively validated services (AVSs). These services may include data availability, verification and other blockchain-related infrastructure.

EIGEN is a crypto-asset associated with EigenLayer and is designed to complement the security provided by restaked assets. It supports mechanisms for addressing certain forms of misconduct or failure that cannot be conclusively verified through blockchain-based processes alone. These mechanisms include staking, potential slashing and intersubjective dispute resolution. Staking and slashing operate through the EigenLayer contracts. The intersubjective dispute process is not implemented in the EIGEN contract. EigenLayer is part of EigenCloud, the product suite of Eigen Labs, Inc.

FALSE

Past milestones

In April 2024, EigenFoundation formally announced its establishment, the introduction of EIGEN and the first season of its token distribution programme. The initial distribution arrangements included an allocation of 15% of the initial EIGEN supply to stakedrops. EIGEN staking was envisaged to support the security of EigenDA, with the intention of extending its use to additional AVSs.

In May 2024, claims commenced for the first EIGEN stakedrop season. A second stakedrop season followed in September 2024. On 30 September 2024, the initial transfer restrictions on EIGEN were removed, enabling token transfers and broader participation in the EigenLayer ecosystem.

In November 2024, EigenFoundation introduced the EigenGov governance framework, intended to support the progressive decentralisation of protocol governance. In December 2024, the Foundation announced the establishment of the Protocol Council, responsible for reviewing and approving proposed protocol upgrades.

In April 2025, EigenFoundation introduced its community initiatives and grants framework, including an annual spending cap of 40,000,000 EIGEN for grants during 2025. The Foundation also established the Grants Oversight Council to review transparency reports concerning grant allocations.

During 2025, the EigenLayer ecosystem continued developing its staking, slashing and incentive arrangements. In December 2025, EigenFoundation published ELIP-12, which replaced the token hopper and action generator with the Emissions Controller and an Incentive Council that sets distribution weights. The Emissions Controller was deployed on 2 March 2026 and has run weekly epochs since 19 March 2026.

Future milestones

The future development of the EigenLayer project is expected to focus on the continued development of its cryptoeconomic security mechanisms, expansion of EIGEN staking arrangements and support for additional decentralised services. The EIGEN technical design includes progressive versions of intersubjective dispute-resolution and token-forking mechanisms. Protocol upgrades are subject to the applicable governance approval and timelock requirements.

Further development of the EigenGov framework is intended to support the progressive decentralisation of protocol decision-making, including the allocation of responsibilities among governance councils and other eligible participants.

The total initial supply of EIGEN at launch was 1,673,646,668.28466 tokens, excluding subsequent inflationary issuances. The initial supply was allocated as follows: 45% to the community, 29.5% to investors and 25.5% to early contributors. The community allocation comprised 15% for stakedrops, 15% for community initiatives and 15% for research and development and ecosystem growth.

The stakedrop allocation represents approximately 251,047,000 EIGEN tokens intended for distribution to eligible community participants over time. Approximately 186,582,000 EIGEN tokens were made claimable through Seasons 1 and 2 of the stakedrop programme, of which approximately 158,774,855 EIGEN tokens had been claimed as at 30 September 2024. Unclaimed tokens are intended to be reallocated to future community programmes.

The allocation for community initiatives is intended to support users, developers and other ecosystem contributors through incentive programmes, grants and related activities. The allocation for research and development and ecosystem growth is intended to finance ecosystem development, research initiatives and EigenFoundation's operational expenses. Tokens allocated to these categories may be distributed over extended periods and may be subject to vesting or lock-up conditions.

Following the removal of the EIGEN token contract's transfer restrictions, tokens allocated to early contributors, investors and EigenFoundation service providers were subject to an initial lock-up period of 1 year. On the first anniversary of the removal of these restrictions, 4% of each recipient's allocation was scheduled to become unlocked, followed by an additional 4% each month thereafter.

New EIGEN is issued after launch. Programmatic Incentives V1 issued new EIGEN weekly from August 2024 at a total rate of 4% a year of the supply at launch. Programmatic Incentives V2 replaced it on 9 October 2025 at a total rate of 7% a year of the supply on that date. The Emissions Controller, deployed on 2 March 2026, replaces the token hopper and action generator that carried out these programmes and mints new EIGEN in weekly epochs, as F.6 describes.

Not applicable

By admitting the crypto-asset to trading, holders may benefit from transparency in price formation and access to secondary-market trading opportunities. Admission to trading is intended to facilitate the ability of community members and other ecosystem participants to buy and sell the crypto-asset, subject to prevailing market conditions, trading-platform availability and applicable restrictions.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.

Bitstamp

BESA

Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.

There are no costs involved in creating an account on the trading platform, however trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.

Not applicable

There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest.

In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.

Not applicable, as this point pertains to an "offer to the public," whereas this white paper relates to admission to trading.

Not applicable, as this point pertains to an "offer to the public," whereas this white paper relates to admission to trading.

Crypto-assets other than asset-referenced tokens or e-money tokens

EIGEN is a crypto-asset operating on the Ethereum blockchain and associated with the EigenLayer protocol. EIGEN can be held, transferred and staked in EigenLayer. Staked EIGEN supports the security of AVSs and can be slashed by an AVS for faults, including faults that cannot be determined objectively on-chain.

EIGEN complements the use of restaked Ether (ETH) and other eligible assets within EigenLayer. EIGEN may be staked, and the resulting stake delegated to operators supporting AVSs, subject to applicable participation requirements. Staked tokens may be exposed to penalties, including slashing, where the relevant conditions are satisfied.

EigenLayer describes a process called intersubjective forking, in which participants support a new version of the token after a dispute about a fault that cannot be determined on-chain. The EIGEN contract contains no forking logic, so the outcome would depend on the coordination of participants.

EIGEN is transferable between compatible blockchain addresses, subject to applicable technical and legal restrictions. It is also used in staking incentive arrangements under which eligible participants may receive EIGEN distributions in accordance with the prevailing protocol rules. Such distributions are conditional on the applicable eligibility criteria and do not constitute guaranteed returns.

EigenGov is the governance framework established by the Eigen Foundation to oversee the development and operation of the EigenLayer protocol. Introduced in November 2024, EigenGov is designed to progressively decentralise governance responsibilities through specialised councils responsible for defined areas of protocol administration.

The first operational component of EigenGov is the Protocol Council, established in December 2024. The Protocol Council reviews and approves EigenLayer Improvement Proposals (ELIPs), including proposed changes to the protocol's core smart contracts. The current governance architecture also includes multisignature arrangements through which designated parties may propose upgrades, execute approved changes, cancel pending upgrades or pause certain protocol functions in specified circumstances.

The EigenGov framework envisages a broader governance role for EIGEN holders, including the ability to veto council decisions, signal preferences on proposals and endorse contributors for governance responsibilities. These token-holder mechanisms form part of the project's intended governance arrangements and have not been confirmed as operational. Consequently, holding EIGEN does not currently confer an independently exercisable right to veto decisions of the Protocol Council.

Not applicable

EIGEN is an ERC-20 crypto-asset operating on the Ethereum blockchain and associated with the EigenLayer protocol. It is transferable between compatible Ethereum addresses and can be held in wallets supporting ERC-20 tokens. EIGEN does not operate on an independent blockchain and relies on Ethereum for the recording and settlement of token transfers.

EIGEN was launched with an initial total supply of 1,673,646,668.28466 tokens. This initial supply excludes subsequent inflationary issuances. EIGEN does not have a fixed maximum supply, as additional tokens may be minted through the protocol's incentive mechanisms. The Emissions Controller creates about 2,356,969.864 EIGEN in each weekly epoch, which is about 7% a year of the supply of 1,750,891,899.13 EIGEN on 9 October 2025. The amount per epoch is fixed in the controller, and the Protocol Council can change it by upgrading the controller. The earlier programmes (4% of the initial supply, about 66,945,866.7314 EIGEN a year, and Programmatic Incentives V2 at 7% of the supply) are deprecated. New issuance increases the total supply and dilutes holders who do not receive emissions.

Eigen

https://eigenfoundation.org/

2026-11-20

2026-11-19

Not applicable

English

9QQH3Z86Z

QRLFSB800

FALSE

TRUE

TRUE

Not applicable. Holders of EIGEN do not, solely by acquiring or holding EIGEN, acquire any ownership, equity, profit-participation, repayment, redemption or compensation rights against EigenFoundation, Eigen Labs, Inc., any project contributor or any other natural or legal person.

The functionalities associated with EIGEN are protocol-based. They include the ability to hold and transfer EIGEN between compatible Ethereum addresses, stake or delegate EIGEN to eligible operators supporting AVSs, and participate in applicable staking incentive mechanisms. These functionalities are further described in F.2.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable

FALSE

TRUE

Not applicable

FALSE

Not applicable, as EIGEN does not have a demand-based supply adjustment mechanism. EIGEN nevertheless has an inflationary issuance mechanism. ELIP-012 provides for annual EIGEN emissions of 8%, comprising the 7% allocated under Programmatic Incentives v2 and an additional 1%for ecosystem initiatives.These emissions do not constitute a supply adjustment mechanism responding to changes in demand.

FALSE

Not applicable

FALSE

Not applicable

There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

N/A as DTI is provided in F.13

Networking, transport and session

EIGEN is a smart contract on Ethereum and uses no token-specific peer-to-peer network. A token transaction is signed in the sender's wallet, submitted to an Ethereum execution client and propagated to other nodes.

Ethereum runs 2 peer-to-peer networks. Execution clients find peers through a discovery protocol over the User Datagram Protocol (UDP) and exchange pending transactions over the DevP2P stack, which runs over the Transmission Control Protocol (TCP). Within DevP2P, the RLPx protocol authenticates peers and establishes encrypted sessions. Consensus clients use a separate stack built on libp2p, a modular peer-to-peer networking library. They discover peers through discv5, secure connections with the Noise handshake and exchange blocks and attestations (validators' votes on the chain) through the gossipsub publish-and-subscribe protocol.

Serialisation

Execution-layer nodes encode messages with Recursive Length Prefix (RLP), a compact method of representing nested data as bytes. Ethereum transactions follow the typed envelope defined in EIP-2718, in which a type byte precedes the transaction payload. The types in use are legacy transactions (type 0), access-list transactions (type 1), dynamic-fee transactions under EIP-1559 (type 2), blob transactions (type 3) and account-delegation transactions (type 4). Calls to the EIGEN contract are encoded according to the Solidity contract application binary interface (ABI): the first 4 bytes of the call data are a function selector derived from the function signature, followed by the arguments in 32-byte words. The consensus layer serialises data with Simple Serialize (SSZ), which uses fixed offsets so that individual parts of a message can be decoded separately.

Cryptography and key formats

Ethereum accounts are controlled by private keys. Signatures use the Elliptic Curve Digital Signature Algorithm (ECDSA) on the secp256k1 curve, and an address is the last 20 bytes of the Keccak-256 hash of the account's public key. Execution clients verify the signature on each transaction before processing it.

The EIGEN contract supports EIP-2612 permits: a holder signs an EIP-712 typed message that sets an allowance for a spender, specifying a nonce and a deadline, and any account may submit it, so the holder does not need ETH to approve a spender. The contract also accepts delegation of voting power by signature. The EIP-712 domain name is EIGEN.

Ledger and state model

Ethereum is account-based: the ledger records the balance and storage of each account and contract. The EIGEN contract keeps its balances, allowances, voting checkpoints and permission records in its own contract storage. EIGEN uses 18 decimal places, so the smallest unit is 0.000000000000000001 EIGEN.

EIGEN is a wrapper for a second ERC-20 token, Backing Eigen (bEIGEN), which H.3 describes.

Ethereum full nodes retain recent state only, around the last 128 blocks, and prune older states. Archive nodes retain every historical state and answer queries about token balances at past blocks.

Token standards

EIGEN is an ERC-20 fungible token. It builds on the upgradeable ERC-20 votes extension of OpenZeppelin Contracts 4.9.0 (the release that also supplies the proxy described in H.3), which adds EIP-2612 permits (described under Cryptography and key formats), ERC-5805 vote delegation with historical voting checkpoints, and ERC-6372, under which a contract declares the unit of time it uses. The contract counts time in block timestamps rather than block numbers and reports this as timestamp mode. Voting power is recorded only after a holder delegates it, whether to the holder's own address or to another address. The token is named Eigen and its symbol is EIGEN.

Interfaces and events

Wallets and applications submit transactions and read contract state through the Ethereum JSON-RPC interface. The EIGEN contract emits events, which are indexed log records that applications can monitor, for wrapping, unwrapping, minting, delegation and the standard ERC-20 transfers and approvals.

Execution environment

EIGEN runs in the Ethereum Virtual Machine (EVM), the deterministic runtime that executes compiled smart-contract bytecode identically on every Ethereum node. The contract is written in Solidity and deployed on Ethereum mainnet at 0xec53bf9167f50cdeb3ae105f56099aaab9061f83. Every operation consumes gas, a unit that measures computational effort, and a transaction that fails a contract condition or runs out of gas reverts without changing state.

Contract architecture and upgrade control

EIGEN consists of a proxy contract, which holds the balances and other state, and an implementation contract, which holds the logic. The proxy is an OpenZeppelin transparent upgradeable proxy. Calls from ordinary accounts are forwarded to the implementation, while calls from the proxy administrator are limited to administration functions, which prevents upgrade functions from clashing with token functions. The implementation is deployed at 0x2C4A81e257381F87F5A5C4bd525116466D972E50, and upgrades are administered through the ProxyAdmin contract at 0x8b9566AdA63B64d1E1dcF1418b43fd1433b72444. The implementation disables its own initialiser in its constructor, so the logic contract cannot be initialised directly.

The contract also has an owner address. The owner controls the transfer permission lists and the disabling of transfer restrictions.

Upgrades to EigenLayer contracts follow a governance structure built on multisignature wallets, which are accounts that require a set number of signers to approve each transaction. The Operations multisig (3 of 6 signers) and the Protocol Council (3 of 5 signers) propose upgrades, and the Protocol Council executes them through a timelock, a contract that holds an approved transaction for a minimum period before it can run. The primary timelock imposes a minimum delay of 10 days, and a separate timelock handles upgrades to bEIGEN. The Eigen Labs multisig holds the canceller role on the timelock and can cancel approved Protocol Council proposals. The Community multisig (9 of 13 signers) can act in an emergency, including by making time-critical upgrades and by replacing the timelock after a private key compromise.

Wrapping and unwrapping

EIGEN is a wrapper around Backing Eigen (bEIGEN), a separate ERC-20 contract deployed at 0x83E9115d334D248Ce39a6f36144aEaB5b3456e75. The EIGEN contract holds the bEIGEN that holders wrap. To wrap, a holder approves the EIGEN contract to spend bEIGEN. The wrap function then transfers the bEIGEN to the EIGEN contract and mints the same amount of EIGEN to the holder. To unwrap, the unwrap function burns EIGEN from the holder and transfers the same amount of bEIGEN to the holder. Neither operation charges a fee, and the contract contains no pause function. Earlier versions of the EIGEN implementation transferred EIGEN to the EIGEN contract on unwrapping rather than burning it. That mechanism is deprecated, and EIGEN unwrapped before the change remains held by the EIGEN contract.

The EIGEN contract also provides a batch transfer function, which sends EIGEN from the caller to several recipients in 1 transaction.

The wrapping mechanism is a technical conversion between 2 ERC-20 tokens. The EigenStrategy contract holds bEIGEN, so staked positions are held in bEIGEN and EIGEN held in a wallet is not staked. The mechanism uses no price reference or oracle, charges no fee and exchanges the same number of units on each conversion. It does not constitute a redemption promise at a fixed monetary value, a conversion price or a market price for EIGEN or bEIGEN, and it does not select or follow a fork of bEIGEN.

Issuance

EIGEN is created by wrapping bEIGEN or through minting allowances. Each allowance is assigned to a minter address when the contract is initialised and consists of an amount and the time after which it may be exercised. The minter can exercise it once, in full. EIGEN issued through an allowance is not matched by a deposit of bEIGEN at the time it is minted. The current implementation contains no function that creates or increases an allowance after initialisation. EIGEN is destroyed only by unwrapping, which burns the unwrapped EIGEN and returns the same amount of bEIGEN, so unwrapping does not reduce the supply that the contract reports. The EIGEN contract has no other burn function.

The supply of bEIGEN determines the supply that the EIGEN contract reports. The reported figure counts every unit whether held as EIGEN or as bEIGEN, so it is the combined supply of the 2 forms rather than the quantity of EIGEN alone. When the bEIGEN contract was initialised, it minted 1,673,646,668.28466 bEIGEN to the EIGEN contract in 1 operation. Further bEIGEN can be minted only by addresses that the owner of the bEIGEN contract has designated as minters, with no limit on the amount a minter may issue, and any holder can burn bEIGEN from the holder's own balance, which reduces the reported supply. The Emissions Controller, described in H.5, mints bEIGEN each epoch and wraps it into EIGEN.

Transfer restrictions (deprecated)

The EIGEN contract contains a transfer restriction mechanism. While it is enabled, a transfer is accepted only if the sender or the recipient appears on a permission list maintained by the owner, and minting and burning are exempt. The owner can disable the mechanism once, and the change cannot be reversed. EIGEN has been transferable without these restrictions since 30 September 2024, and the mechanism is deprecated.

EIGEN restaking strategy

EIGEN is accepted as a restaking asset in EigenLayer through the EigenStrategy contract, deployed behind a transparent upgradeable proxy at 0xaCB55C530Acdb2849e6d4f36992Cd8c9D50ED8F7. The strategy holds bEIGEN. When EIGEN is deposited, the strategy unwraps it into bEIGEN, and when a withdrawal is paid in EIGEN, the strategy wraps bEIGEN back into EIGEN. Deposits and withdrawals in bEIGEN involve no conversion.

The strategy issues deposit shares and uses virtual shares and a virtual balance offset to protect against the inflation attack, in which an early depositor distorts the share price by donating tokens to the strategy. The protection can cause small losses for depositors, most noticeably when the share exchange rate changes significantly. Withdrawals are queued and complete after 100,800 blocks (14 days). The factory that creates strategies does not permit duration vaults for EIGEN, and EIGEN is excluded from redistributable slashing.

Compilation

The deployed EIGEN implementation was compiled with Solidity 0.8.27, with the optimiser enabled for 200 runs and the Cancun EVM version. The source file in the current repository declares Solidity 0.8.27 or later, and its token logic is the same as that of the deployed implementation.

EIGEN has no consensus mechanism of its own. Its state changes are ordered, validated and finalised by Ethereum, which uses proof of stake. A validator deposits 32 ETH in the Ethereum deposit contract and then proposes blocks and attests to them (votes on their validity). Time is divided into slots of 12 seconds, and 32 slots form an epoch. In each slot, 1 randomly selected validator proposes a block, and a committee of validators attests to it.

Ethereum combines 2 protocols. LMD-GHOST is the fork-choice rule, under which nodes follow the chain that has gathered the most recent attestation weight. Casper FFG (Friend Finality Gadget) finalises checkpoints, which are the first blocks of each epoch. A checkpoint is justified when attestations from validators holding at least 2/3 of the total staked ETH support it, and it is finalised once the following checkpoint is justified. Reverting a finalised block would require validators to be slashed, meaning that they lose part of their stake, for at least 1/3 of the total stake.

A token transfer, wrap, unwrap or delegation is final once it is included in a finalised block. Voting checkpoints in the token contract are recorded by block timestamp, so they follow the block ordering that Ethereum produces.

Intersubjective forking is a process for faults that cannot be determined objectively on-chain but can be recognised by observers. Under it, participants would support a new version of EIGEN after such a dispute without forking Ethereum. The token contract contains no forking logic, and the process does not form part of Ethereum consensus.

Network fees

Every transaction involving EIGEN pays gas in ETH. Under EIP-1559, the gas price consists of a base fee, which is burned, and a priority fee, which goes to the validator that includes the transaction. The token contract adds no fee to transfers, wrapping or unwrapping, and no part of the gas fee is paid to the issuer or the EigenLayer protocol.

Validator and operator incentives

Ethereum validators earn newly issued ETH for proposing blocks and attesting to them, together with the priority fees of the transactions they include. A validator that signs conflicting blocks or attestations is slashed, which destroys part of its stake and removes it from the validator set.

EigenLayer operators earn rewards for running the software that AVSs require, supported by stake delegated to them. An AVS can slash an operator, meaning that it destroys or redistributes part of the delegated stake, when the operator breaches its commitments. EIGEN is excluded from redistributable slashing. Shares marked for burning or redistribution can be cleared only after a resolution delay of 50,400 blocks (7 days).

EIGEN emissions

The Emissions Controller, deployed on 2 March 2026, is the current mechanism for issuing EIGEN as an incentive. It runs in weekly epochs, which began on 19 March 2026. In each epoch, any account can trigger the controller, which mints about 2,356,969.864211533 EIGEN by minting bEIGEN and wrapping it. The controller then distributes the amount according to weights, which total at most 10,000 basis points (100%). The Incentive Council sets the weights, and the Protocol Council controls the total emission rate and upgrades to the controller.

The following 2 earlier mechanisms are deprecated. Programmatic Incentives v1 set the inflation rate at 4% of the supply at launch from 15 August 2024, of which 1% went to EIGEN stakers and 3% to ETH stakers. Programmatic Incentives v2 raised the rate to 7% of the supply as at 9 October 2025 (1,750,891,899.13 EIGEN), of which 4/7 (4%) went to EIGEN stakers and 3/7 (3%) to ETH stakers. The token hopper and the action generator that carried out v2 distributions, deployed on 26 September 2025, are superseded by the Emissions Controller.

Rewards distribution

The Rewards Coordinator contract distributes rewards to stakers and operators. It publishes weekly Merkle roots, which are cryptographic summaries that allow each recipient to prove an entitlement when claiming, and each root takes effect after a delay of 1 week. By default, an operator keeps 10% of the rewards earned by its stakers and can change that split. Since Rewards v2.2, rewards can also be directed to operator sets, which are groups of operators registered for an AVS. The contract also supports an optional protocol fee, which applies only where configured.

FALSE

Not applicable

TRUE

The reviews below cover the components described in H.2 to H.5: the EIGEN contract and its backing token, the strategy contracts through which EIGEN is restaked, the slashing logic that applies to restaked assets, and the rewards system that distributes EIGEN. Each review applies only to the code and commit that it examined, and severity labels follow each reviewer's own scale.

Sigma Prime | August 2024 - Strategy Factory

• Object: Review of the changes in pull request 522 at commit aa05081, which introduced the strategy factory for permissionless deployment and whitelisting of strategies, together with changes to the strategy interfaces and the strategy base contract on which the EIGEN restaking strategy builds. Third-party dependencies were excluded.
• Results: 4 findings: 1 medium (a failed token transfer during withdrawal can leave funds frozen), 1 low (token blacklist changes can be front-run) and 2 informational (documentation of the token-to-strategy mapping and general comments).
• Actions: All 4 findings were open at the close of the review.

Sigma Prime | September 2024 - EIGEN Rewards

• Object: Review of the EIGEN contract and its backing token bEIGEN at commit c5d6a9d, the Rewards Coordinator at commit decf99c and the token hopper system at commit 2a226d6. The review covered the changes that allow the tokens to be minted and burned and the contracts that distribute EIGEN to stakers and operators. It combined manual review with automated analysis using Mythril, Slither, Surya and Aderyn. Third-party dependencies, including OpenZeppelin, were excluded.
• Results: 6 findings: 1 high (the first-submission reward multiplier could be applied more than once), 1 low (bEIGEN cannot be burned by accounts outside the permission lists while transfer restrictions are enabled) and 4 informational (an incorrect cooldown calculation, a double-counted submission at the cutoff, EIGEN left in the EIGEN contract by the earlier transfer-based unwrapping, and general comments).
• Actions: 3 findings are resolved: the high-severity finding at commit 9cf6f41 by a deployment constraint on the hopper start time, the cooldown calculation at commit 3084969 and the double-counted submission at commit a554e28. 3 findings are closed after acknowledgement without a code change. For the bEIGEN burn restriction, the team confirmed that transfer restrictions would be lifted before the token upgrade was completed.

Sigma Prime | December 2024 - Rewards v2

• Object: Review of the Rewards v2 upgrade, covering the Rewards Coordinator contract at commit b8567e4, the middleware at commit 91400d9 and the Sidecar off-chain service at commit d9bb2ab. The upgrade introduced performance-based rewards from AVSs to operators, variable operator fees, an operator split for programmatic incentives and batch claiming. Third-party dependencies and the SQL components of Sidecar were excluded.
• Results: 13 findings: 1 critical (incorrect operator split filtering), 1 high (incorrect split window filtering caused by the end-time calculation), 1 medium (inefficient Merkle leaf encoding), 5 low and 5 informational.
• Actions: 7 findings are resolved, including the critical and high-severity findings, with fixes assessed at commits 47f1232 (contracts), 027226b (middleware) and 2941257 (Sidecar). 6 findings are closed after acknowledgement without a code change, including the medium-severity finding.

Certora | February 2025 - Slashing

• Object: Manual review and formal verification, using the Certora Prover, of the slashing implementation between 10 January and 11 February 2025. The scope covered the Allocation Manager, Delegation Manager and Strategy Manager contracts with their storage, the slashing and snapshot libraries, the interfaces and the EigenPod contracts.
• Results: 11 findings: 1 critical (an underflow in the encumbered magnitude calculation that could let an operator take more risk than its maximum magnitude), 1 high (reentrancy during withdrawal completion, with no complete exploit found), 2 medium, 5 low and 4 informational. The formal verification records each property as verified or violated, together with its assumptions. The underflow violated the magnitude solvency property.
• Actions: The critical finding and both medium findings are fixed, and the fix review confirmed the critical fix. The high-severity finding is partially fixed. The reviewer assessed it as theoretical in the reviewed code and recommended a cross-contract reentrancy guard. Of the low-severity findings, 2 are acknowledged without a fix, 2 await a fix and 1 was disregarded.

Sigma Prime | February 2025 - Slashing

• Object: Review of the slashing release (version 1.0.0) in pull request 679, with fixes assessed at commit f7413d9. The review combined manual analysis of contract interactions, business logic and storage with automated analysis using Mythril, Slither, Surya and Aderyn. Third-party dependencies were excluded.
• Results: 19 findings: 2 high, 1 medium, 6 low and 10 informational. The 2 high-severity findings concerned the interaction of AVS slashing with beacon chain slashing in the accounting of native ETH shares. The medium finding concerned queued native ETH withdrawals being excluded from slashable shares.
• Actions: 10 findings are resolved, including the medium finding. 9 findings are closed after acknowledgement without a code change, including both high-severity findings. For the first of these, the team confirmed the behaviour as an intentional design choice under which beacon chain penalties take priority over AVS slashing of the same ETH, and undertook to update the documentation.

Cantina | March 2025 - Slashing Competition

• Object: Public security competition held from 7 to 28 March 2025 on the EigenLayer contracts, with findings published on 8 July 2025.
• Results: 31 findings: 2 high, 3 medium, 13 low and 13 informational. Only the high and medium findings are detailed. The high-severity findings were a casting overflow in the removal of deposit shares that lets an operator participate with no backing ETH, and incorrect rounding in the slashing factor calculation. The medium-severity findings concerned undeposited ETH in an EigenPod incurring slashing, operators being unable to recover unslashed ETH after full slashing, and queued withdrawals that can become impossible to complete.
• Actions: No remediation status was published with the findings.

Certora | June 2025 - Moocow

• Object: Manual review between 23 and 27 June 2025 of the changes in pull request 1425, which added support for Ethereum's Pectra upgrade features to EigenPods. The scope covered the EigenPod contracts, the beacon chain proof library and the EIGEN token contract. Reviewed commit 48ba63b, with fixes at commit 8f83c9e.
• Results: 5 informational findings, none of which relates to the token contract. The findings concerned an unused error on fee refunds, an event description typo, duplicated calculations, redundant public key checks and documentation of consolidation requests.
• Actions: All 5 findings are fixed at commit 8f83c9e, and the fixes were confirmed.

Sigma Prime | February 2026 - Rewards v2.2

• Object: Second-round review of the Sidecar rewards changes in pull request 500, which compute reward distributions for stakers, operators and operator sets off-chain before the results are published on-chain as Merkle roots. The review covered the Go components, using manual analysis and the golangci-lint, vet and errcheck tools. Third-party dependencies were excluded.
• Results: 6 findings: 1 high (a missing allocation factor in the weighting of stakers by unique stake), 1 medium (a silent failure in the generation of staker delegation snapshots), 3 low and 1 informational.
• Actions: 5 findings are resolved in pull request 500, including the high and medium findings. 1 low-severity finding, on strategy registration enforcement in the v2.2 stake rewards path, is closed after acknowledgement.

Certora | May 2026 - Redistribution Slash Delay

• Object: Manual review on 11 and 12 May 2026 of pull request 1753 (release 1.13.0), reviewed from commit 7e02c2e to commit f53d878. The change adds a delay of 50,400 blocks (7 days) before strategy shares marked for burning or redistribution can be cleared, adds a dedicated pause flag for that clearing, and prohibits duration vaults for EIGEN and bEIGEN.
• Results: 5 informational findings: no proactive token-level denylist for duration vaults, stale documentation of duration vault blacklist behaviour, the slash resolution delay temporarily preserving deposit cap usage for slashed assets, the legacy burn function not being covered by the new pause, and an event that omits the slash resolution block.
• Actions: 3 findings are fixed, with fixes confirmed at commit f53d878. 2 are acknowledged. For the denylist finding, the team confirmed that allowing all tokens in duration vaults other than EIGEN and bEIGEN is the intended design.

Immunefi | Ongoing - Bug Bounty Programme

• Object: Continuous vulnerability disclosure programme for the EigenLayer smart contracts, launched on 14 June 2023, live and last updated on 14 November 2024. Testnet and mock files are excluded.
• Results: Rewards for smart contract reports range from USD 10,000 to USD 30,000 for medium severity, USD 50,000 to USD 250,000 for high severity and USD 250,000 to USD 2,000,000 for critical severity. Rewards are paid in USDC on Ethereum, and no identity verification is required.
• Actions: Reports of every severity require a proof of concept. Reports are assessed against the severity scale in the programme terms, and the EigenLayer team pays rewards directly.

Market volatility and liquidity risk

The market price of EIGEN can change sharply and without notice, and it depends on market-wide conditions, trading activity and the depth of order books. Limited depth increases slippage, widens the difference between buying and selling prices and can prevent a holder from selling a given amount at the quoted price. A holder can lose the whole amount invested.

Large-holder and scheduled release risk

Holdings of EIGEN can be concentrated, and sales or large transfers by significant holders can move the price and worsen execution for other holders.Allocations of early contributors, investors and EigenFoundation service providers are released in stages: after a lock-up of 1 year from the EIGEN unlock on 30 September 2024, 4% of each allocation was released at the anniversary and a further 4% is released each month. On that schedule the releases complete in about September 2027, so the transferable supply continues to increase until then.

Delisting Risks

Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.

EigenFoundation, a Cayman Islands foundation company, is treated as the issuer of EIGEN for the purposes of this white paper, on the basis set out in Part B.

Governance and control concentration risk

The Foundation's Board appoints the Protocol Council, which has up to 8 members serving terms of 6 months, and the Board or a majority of the Council can remove a member at any time with immediate effect. The Protocol Council executes routine upgrades and controls the total emission rate, and the Protocol Council and the Operations multisig operated by Eigen Labs are the only parties that can propose upgrades. The Eigen Labs multisig also holds the canceller role on the timelock and can cancel approved Protocol Council proposals. Decisions on supply and contract changes therefore rest with a small group appointed by the issuer, whose interests can differ from those of holders.

Conflicts of interest risk

Protocol Council members are compensated with assets worth USD 15,000 per term of 6 months, subject to vesting and lock-up terms set by the Board, and the Foundation can approve further discretionary incentive payments. The Board sets these terms and can remove members at any time. Members can also hold personal interests that bear on upgrades, emission weights or the allocation of resources, which can affect the impartiality of their decisions.

Discretionary allocation risk

The Foundation allocates EIGEN from the supply it holds to ecosystem development, research and its own operations. The timing, size and recipients of these allocations are at its discretion, and later sales by recipients can add to the supply in circulation.

Non-EU issuer and limited recourse risk

The Foundation is established in the Cayman Islands. The terms for its services are governed by Cayman Islands law, exclude persons under 18 and persons in sanctioned jurisdictions, provide the services as they are, cap liability at the greater of USD 100, the amount paid in the previous 6 months or the statutory remedy, and require individual arbitration administered by JAMS in English, with a class action waiver and an opt-out within 30 days. A holder's remedies against the issuer after a service failure are therefore limited, and enforcement against an issuer outside the EU can be more difficult.

Automated issuance risk

New EIGEN is created each week by the Emissions Controller, which any account can trigger and which distributes the amount according to weights set by the Incentive Council. No person approves an individual mint, and the Foundation cannot recall EIGEN once it has been distributed. A fault in the controller code can be corrected only by an upgrade through the timelock or contained by pausing the controller, and recipients of emissions, such as operators, AVSs and stakers, are not controlled by the Foundation.

Supply dilution risk

EIGEN has no maximum supply. The initial supply excludes later issuance. Since the first epoch on 19 March 2026, the Emissions Controller has created new EIGEN each week, which equals about 7% of the supply of 1,750,891,899.13 EIGEN recorded on 9 October 2025 over 52 weeks. Each mint reduces the proportional holding of every holder who does not receive emissions. The earlier mechanisms, Programmatic Incentives v1 (4% of supply) and v2 (7% of supply), are deprecated.

EIGEN wrapper and conversion risk

EIGEN is created by wrapping bEIGEN, a separate ERC-20 token. When a holder wraps bEIGEN, the EIGEN contract receives it and issues the same number of EIGEN units, and unwrapping reverses this. The EIGEN contract reports the total supply of bEIGEN as its own. The contracts perform the conversion, and holders have no claim against EigenFoundation or Eigen Labs to carry it out. A fault in either contract can prevent conversion, including the conversion needed for staking and withdrawal. The owner of the bEIGEN contract can designate further minters, and the contract does not limit the amount a minter may issue. Some EIGEN was created at initialisation through minting allowances without a wrap of bEIGEN at that time, so converting that EIGEN depends on the bEIGEN that the EIGEN contract already holds. Neither token has a price reference, and conversion does not preserve or guarantee the market price of either.

Staking and delegation risk

A staker who delegates EIGEN delegates the whole available restaked balance to a single operator, including later deposits. The operator allocates stake to AVSs, and an AVS can slash the allocated stake up to the allocated amount under conditions that the AVS defines, including faults that cannot be proven objectively on-chain. Staked EIGEN therefore carries a risk of partial or total loss that unstaked EIGEN does not carry.

Withdrawal restriction risk

Staked EIGEN can be withdrawn only through a queue with a delay of 100,800 blocks (14 days), during which the shares remain slashable and earn no rewards. The Pauser multisig can pause entry to and exit from the withdrawal queue, and a pause can be followed by upgrades to the contracts. A holder may therefore be unable to sell staked EIGEN for 14 days or longer, including during sharp price falls.

Reward variability risk

Staking rewards depend on AVS reward submissions, on the fee of the operator, which an operator can set between 0% and 100% for each AVS with a default of 10%, and on the emission weights that the Incentive Council sets. Rewards are not guaranteed, can fall to zero and stop accruing when a withdrawal is queued.

Intersubjective forking risk

EIGEN is intended to support the resolution of faults that cannot be determined objectively on-chain, through a process in which participants support a new version of EIGEN after a dispute. The token contract contains no forking logic, so any such outcome depends on the coordination of operators, stakers, exchanges and wallets and is not guaranteed. A fork would change which version of EIGEN holds value and could reduce the value of the original token.

Private-key custody, signature and irreversibility risk

Control of EIGEN depends on the holder's private key. Loss or compromise of the key causes permanent loss of control, and neither the Foundation nor Eigen Labs can restore keys or reverse a transfer, because a transaction is final once it is included in a finalised Ethereum block. The EIGEN contract accepts off-chain signatures that set allowances (EIP-2612) and delegate voting power, so a holder who signs a malicious message can authorise a third party to take EIGEN without sending a transaction. Phishing sites that request such signatures exploit this.

Privacy and address-linkage risk

The balances, transfers, delegations and staking positions of an address are recorded publicly and permanently on Ethereum. Once an address is linked to a person, for instance through an exchange withdrawal or through the wallet addresses, token holdings, transaction history and identification data that the Foundation or Eigen Labs collect when their services are used, the whole activity of that address can be attributed to that person. Data recorded on Ethereum cannot be erased on request.

Wallet and key-generation risk

A holder controls EIGEN through a wallet, which can be a browser extension, a mobile application, a hardware device or a smart-contract account. Malware, a compromised device or a malicious or defective wallet application can read a key, replace an address or alter a transaction before it is signed. A private key or recovery phrase generated with insufficient randomness, for example by a defective software library, a predictable seed or a vanity-address tool, can be reproduced by an attacker, who can then move every asset at the address, including EIGEN. A recovery phrase kept in a screenshot, a cloud backup or a compromised password manager exposes every account derived from it. A smart-contract wallet depends on its own code, upgrade rights and recovery arrangements. The EIGEN contract has no function to freeze or recover tokens, so EIGEN taken in this way cannot be returned.

Signature deception risk

The EIGEN contract accepts off-chain signatures that set an allowance (EIP-2612) or delegate voting power, and the holder sends no transaction when signing. A holder who signs a message that a website, wallet or application describes inaccurately, or shows only as unreadable data, can authorise a third party to take EIGEN or to receive voting power, and any account can submit a signed permit. A permit can carry a distant deadline, and an allowance stays usable until the holder sets it to zero or it is spent. An account holder can also sign an authorisation under EIP-7702 that makes the account run the code of another contract, and a malicious or defective contract so designated can take control of the assets in the account, including EIGEN. Phishing sites and malicious approval requests use these mechanisms, and a transfer made under a valid signature cannot be reversed.

Address poisoning risk

Every transfer is recorded publicly with its sender and recipient addresses. An attacker can create an address whose first and last characters match one that a holder uses and cause a small or zero-value transfer to appear in the holder’s history, so that a holder who copies a recipient from the history sends EIGEN to the attacker. In the OpenZeppelin ERC-20 code on which the EIGEN contract builds, any account can call the transfer-from function for an amount of zero between any 2 addresses, which records a zero-value transfer that appears to come from the holder’s address without any action by the holder. A transfer to a wrong address cannot be reversed.

Unspendability risk

EIGEN becomes unspendable when nobody can sign for the address that holds it or when the receiving address cannot send it onward. This occurs through loss of a private key, a transfer to an address that nobody controls, or a transfer to a contract that has no function to send EIGEN onward. The EIGEN contract has no function to recover tokens sent to it or to any other address. EIGEN that the earlier implementation of unwrapping sent to the EIGEN contract remains there, and bEIGEN sent directly to the EIGEN contract instead of being wrapped cannot be recovered by the sender. The contract rejects transfers to the zero address but accepts transfers to any other address, including addresses for which no key exists. Because the contract has no freeze function, an attacker cannot make EIGEN at an address unspendable through the contract, but can induce a holder to send EIGEN to an unspendable address through address poisoning or signature deception. The supply that the contract reports includes EIGEN and bEIGEN that are permanently unspendable.

Development and governance execution risk

Eigen Labs maintains the core contracts and operates the Operations multisig, and changes to the protocol need approval through the governance process before the Protocol Council can execute them. A disruption at Eigen Labs, or a delay in approving and executing a change, can postpone maintenance, fixes and new functionality, including the response to a vulnerability.

Adoption and ecosystem participation risk

The functions of EIGEN depend on continued participation by stakers, operators and AVSs. If participation falls or AVSs do not adopt EIGEN-based security, demand for EIGEN staking and the value of its protocol functions can fall.

Incentive framework change risk

The mechanism for issuing and distributing EIGEN incentives has changed twice since launch. Programmatic Incentives v1 (from 15 August 2024) was replaced by v2, and v2, with its token hopper and action generator, was replaced by the Emissions Controller, deployed on 2 March 2026. Rates, recipients and eligibility changed with each replacement and can change again, and the current controller has operated only since 19 March 2026.

Release compatibility risk

Core contracts, middleware, operator tooling and AVS software must run compatible versions. Incompatible deployments or upgrades can interrupt operator participation, contract interaction and AVS integration.

Interface and service dependency risk

Access through Eigen Labs interfaces and APIs depends on supporting software and service availability, and Eigen Labs can restrict access, suspend services for maintenance or revoke API access. A compromised interface, domain name or third-party script can also display transactions or signature requests that differ from what the holder intends, and the holder may sign them. Wallet errors or blockchain faults can cause a transaction to fail while it still incurs a network fee. An interruption of the interface does not affect the token contract, but a holder with no other means of submitting transactions cannot act until access returns.

Smart-contract and protocol-logic risk

Defects in the EIGEN and bEIGEN contracts, EigenStrategy, the slashing logic, the Rewards Coordinator or the Emissions Controller can cause incorrect accounting, unintended slashing, failed withdrawals, misdirected emissions or loss of assets. Independent reviews cover only the code and commits they examined. Findings remain open or unremediated in the published reports: all 4 findings of the August 2024 strategy factory review were open at its close, a high-severity reentrancy finding in the February 2025 slashing review is only partially fixed, and no remediation status was published for the findings of the March 2025 competition, which included 2 of high severity. The Emissions Controller has operated only since March 2026 and has a shorter operating history than the other contracts.

Upgrade and privileged-access risk

EIGEN, bEIGEN and EigenStrategy are deployed behind upgradeable proxies, so a privileged actor can change their logic. The Protocol Council (3 of 5 signers) executes routine upgrades through a timelock with a minimum delay of 10 days, and bEIGEN upgrades use a separate timelock. The Eigen Labs multisig can cancel a queued proposal before it executes. The Community multisig (9 of 13 signers) can execute time-critical upgrades immediately and replace the timelock, and the Pauser multisig (1 of 8 signers) can pause protocol functions. The owner of the bEIGEN contract designates its minters. Compromise or misuse of any of these keys, or of the owner and proxy administrator keys of the token contracts, could change token behaviour, mint bEIGEN without limit or interrupt staking, withdrawals and emissions.

Operator signing-key risk

Operators authenticate to the EigenLayer core contracts with an ECDSA operator key, which registers the operator, changes its parameters and can force the undelegation of stakers. AVSs use separate signing keys, most commonly BN254, to sign service messages. Keys generated with insufficient randomness can be reproduced by an attacker. Poor key management can lead to compromised operators, disruption of services and financial loss for delegated stakers, including through slashing.

Reward-calculation and claim-processing risk

Rewards are calculated off-chain by the Sidecar service and committed on-chain as a cumulative Merkle root each week, and the root becomes claimable after a delay of 1 week on Ethereum mainnet. An error or interruption in the calculation can delay or misstate claims. Reviews of the rewards system found defects in earlier versions, including a critical finding in Rewards v2 and a high-severity finding in Rewards v2.2, which were resolved.

Ethereum dependency and network-fee risk

EIGEN transfers, wrapping, staking and all EigenLayer contracts depend on Ethereum. Loss of finality, execution-client defects or incompatible protocol changes can delay settlement, prevent contract interaction or cause loss. Every transaction pays gas in ETH, the final fee can differ from the estimate, and a failed transaction still costs gas.

Software supply-chain risk

EIGEN and EigenLayer depend on software that no single party controls: the Solidity compiler and the OpenZeppelin libraries on which the contracts are built, the Sidecar and middleware that compute and deliver rewards, operator and AVS software, wallet applications, and web interfaces with their code libraries. A defect or malicious change in any dependency, update or package can alter contract behaviour, misstate rewards, expose keys or change the transactions that a user is asked to sign. The independent reviews of the EigenLayer code excluded third-party dependencies from their scope.

Signing-environment compromise risk

A signature is only as safe as the device and software that show what is being signed. If the computer, phone, browser or signing interface of a holder, operator, AVS or multisig signer is compromised, the interface can show one transaction while the signer approves different data, and a signer who cannot read the data on a hardware device cannot detect this. The multisig wallets that control upgrades, pausing and the Emissions Controller, and the operator and AVS keys, are exposed to the same risk, and one approved malicious transaction at the signer threshold can change contracts or move assets.

Quantum computing risk

EIGEN and its infrastructure rely on public-key signatures that a sufficiently large quantum computer could break. Ethereum accounts sign with ECDSA on the secp256k1 curve, and an account that has sent a transaction has exposed its public key on-chain, so a quantum computer could derive its private key, move the EIGEN it holds and forge the permit and delegation signatures that the EIGEN contract accepts. EigenLayer operators must use ECDSA operator keys, AVSs commonly sign with BN254 keys that rely on elliptic curve pairings, and the signers of the multisigs that control upgrades and pausing hold ECDSA keys, so the same weakness could expose delegated stake and the governance of the contracts. Ethereum validators sign with BLS, which a quantum computer could also break, and a loss of validator security would affect the finality on which EIGEN depends. No quantum computer can break this cryptography today, and Ethereum research is developing hash-based signatures and native account abstraction, with core post-quantum milestones targeted for about 2029 as planning targets that may shift. The EIGEN contract verifies permit and delegation signatures with ECDSA only, and changing this requires a contract upgrade. Protection therefore depends on changes to Ethereum and on holders and operators moving to quantum-resistant accounts and keys once these are available.

Offer-related risks

• Large-holder and scheduled release risk: Allocations of early contributors, investors and EigenFoundation service providers are released on a fixed schedule of 4% a month rather than in a single release, which limits the amount that becomes transferable on any date. The schedule does not restrict sales by holders of tokens that have been released.

Issuer-related risks

• Governance and control concentration risk: Changes to safety-critical functions pass through a timelock with a minimum delay of 10 days, which makes queued upgrades visible on-chain before execution. Immediate execution is reserved to the Community multisig, and the Pauser multisig can only pause and holds no other powers.
• Conflicts of interest risk: The Protocol Council charter requires the Council to assess material conflicts before each vote or multisig action. A decision affected by a material conflict must rest solely on the interests of the Foundation, and recusal of the conflicted member is the usual remedy.
• Automated issuance risk: The Pauser multisig can pause the token flows of the Emissions Controller, which stops minting and distribution. Distribution weights are capped at a total of 10,000 basis points (100%), so the controller cannot distribute more than it mints.

Crypto-asset-related risks

• Supply dilution risk: The emission amount per epoch is an immutable value in the Emissions Controller. The Incentive Council can change only the weights between recipients and cannot raise the amount minted, and the Protocol Council can change the amount only by upgrading the controller through the timelock.
• EIGEN wrapper and conversion risk: Wrapping mints EIGEN only after the transfer of the same amount of bEIGEN to the EIGEN contract succeeds, and unwrapping burns EIGEN before returning bEIGEN, with the transaction reverting if either transfer fails. Neither operation charges a fee, the EIGEN contract has no pause function, and the current implementation contains no function that creates or increases a minting allowance after initialisation.
• Staking and delegation risk: AVS slashing is limited to stake that the operator has allocated to the operator set, and it requires the operator to be registered with the set, the strategy to be included and the allocation delays to have passed. Slashed shares are cleared only after a resolution delay of 7 days, and EIGEN cannot be redistributed to a recipient chosen by an AVS.
• Signature deception risk: Permits and delegations by signature use EIP-712 typed data whose domain includes the name, version, chain and address of the EIGEN contract, so a signature cannot be replayed on another chain or contract. Each signature carries a nonce that is consumed on use and a deadline after which the contract rejects it, and a holder can set an allowance to zero at any time. These controls do not stop a holder from signing a harmful message.
• Unspendability risk: The EIGEN contract rejects transfers to the zero address, and the current unwrap function burns the unwrapped EIGEN instead of sending it to the contract, so no further EIGEN accumulates in the contract through unwrapping. These controls do not cover transfers to other addresses.

Technology-related risks

• Smart-contract and protocol-logic risk: The EIGEN and bEIGEN contracts, the restaking strategy, the slashing logic and the rewards system have been reviewed in 8 engagements by Sigma Prime and Certora and in 1 public competition run by Cantina between August 2024 and May 2026 (see H.9). EigenStrategy uses virtual shares to protect depositors against the share-inflation attack. A bug bounty on Immunefi, live since 14 June 2023, pays up to USD 2,000,000 for critical smart-contract reports. The withdrawal delay and the ability to pause give time to respond to a reported vulnerability.
• Upgrade and privileged-access risk: The transfer restriction mechanism in the EIGEN contract has been disabled irreversibly, and the contract has no pause, freeze or blacklist function, so no privileged actor can restrict transfers of EIGEN without first upgrading the contract.
• Operator signing-key risk: User Access Management lets operators and AVSs delegate specific permissions to other accounts and rotate, revoke and recover them through the PermissionController, so the operator key need not be used for routine operations. These controls apply to operators and AVSs and do not cover the wallet keys of stakers.
• Reward-calculation and claim-processing risk: Claims are verified on-chain against the published cumulative Merkle root, and the delay of 1 week separates publication of the root from claimability. These controls do not verify the correctness of the off-chain calculation.

Bitstamp Europe S.A.

549300XIBGTJ0PLIEO72

EIGEN

EIGEN has no consensus mechanism of its own. Its state changes are ordered, validated and finalised by Ethereum, which uses proof of stake. A validator deposits 32 ETH in the Ethereum deposit contract and then proposes blocks and attests to them (votes on their validity). Time is divided into slots of 12 seconds, and 32 slots form an epoch. In each slot, 1 randomly selected validator proposes a block, and a committee of validators attests to it.

Ethereum combines 2 protocols. LMD-GHOST is the fork-choice rule, under which nodes follow the chain that has gathered the most recent attestation weight. Casper FFG (Friend Finality Gadget) finalises checkpoints, which are the first blocks of each epoch. A checkpoint is justified when attestations from validators holding at least 2/3 of the total staked ETH support it, and it is finalised once the following checkpoint is justified. Reverting a finalised block would require validators to be slashed, meaning that they lose part of their stake, for at least 1/3 of the total stake.

A token transfer, wrap, unwrap or delegation is final once it is included in a finalised block. Voting checkpoints in the token contract are recorded by block timestamp, so they follow the block ordering that Ethereum produces.

Intersubjective forking is a process for faults that cannot be determined objectively on-chain but can be recognised by observers. Under it, participants would support a new version of EIGEN after such a dispute without forking Ethereum. The token contract contains no forking logic, and the process does not form part of Ethereum consensus.

See H.5

2026-01-01

2026-10-18

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at : https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Land use: 658.65540 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates. Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg