Filecoin FVM Explained: Storage Deals, Smart Contracts, and Network Demand
Learn how Filecoin’s FVM and FEVM relate to storage deals, when to use direct deals or managed tools, and which metrics reveal real network demand.
EigenLayer is often summarized as a way to “use staked ETH twice.” That shorthand captures the capital-efficiency idea, but it can hide the important part: restakers and operators agree to support additional services, and those services may attach their own operational requirements, rewards, and loss conditions to the stake. A large restaking balance is therefore evidence of capital committed to the system; it is not, by itself, proof that every service has strong demand or that every operator is equally reliable.

This overview reflects the live EigenLayer documentation and Ethereum’s restaking explainer checked on September 30, 2026. Protocol interfaces, supported assets, operator sets, rewards, and slashing rules can change. For a decision about a particular position, check the relevant service’s current contract and operator terms as well as the latest protocol documentation.
EigenLayer is an Ethereum-based protocol that coordinates three main participants: restakers, operators, and actively validated services (AVSs). Restakers commit supported assets, operators run the software and perform service tasks, and AVSs use those operators to provide services such as data availability or other verifiable infrastructure. EigenLayer’s documentation describes supported restaking assets as including native ETH, liquid staking tokens, EIGEN, and other ERC-20 tokens, but the assets available for a specific path depend on current protocol support.
In a typical delegated arrangement, a staker deposits or restakes an eligible asset and delegates it to an operator. The operator separately opts into one or more AVS operator sets and runs the required software. The relationship is not simply “ETH secures everything”: the service, operator, delegated stake, and any slashable allocation determine what security is actually available. Read the EigenLayer overview and Ethereum.org’s restaking explanation before relying on a simplified diagram or headline.
Demand can come from both sides of the marketplace. A new service may want access to operators and economically committed stake without building a validator network from scratch. A restaker may want additional rewards for supporting that service. Operators may want service fees or other compensation in return for operating extra software and accepting service-specific responsibilities. The economic case is strongest when a service delivers something users need, operators can perform it reliably, and the service can fund rewards that make the work worthwhile.
Verified: EigenLayer documents AVS rewards and slashing mechanisms, so service participation can involve both a potential payment and a potential penalty. Context-dependent: whether this creates durable demand depends on the service’s actual customers, fee sources, reward policy, and the amount of work operators must do. Not established by a TVL chart: a high deposit balance alone does not show that customers are paying for the service or that rewards come from recurring operating revenue. To assess demand, inspect the service’s users, usage or workload measures, published reward source, and operator participation over time.
| Metric | What it can tell you | What to check next |
|---|---|---|
| Total value locked or total restaked | The current reported value of assets committed through the measured protocol scope. | Which assets and contracts are counted; whether values use token prices; whether the figure includes liquid restaking wrappers or duplicated claims. |
| Restaker and delegator counts | Participation breadth under the dashboard’s address definition. | Unique people cannot be inferred from addresses. Check whether one user can control multiple addresses and whether the count includes depositors, delegates, or both. |
| Operator count | The number of registered operators or operators meeting a dashboard’s activity filter. | Registration is not the same as active service delivery. Check service opt-ins, uptime or performance evidence, and how much stake is concentrated among the largest operators. |
| AVS count | The number of services included under the dashboard’s definition of listed, registered, active, or mainnet. | Those categories are not interchangeable. Check whether each service is live, has operators performing work, and has real users or fees. |
| Rewards paid or APR estimates | Reported distributions or projected rates for a stated period and asset. | Separate paid rewards from estimates, points, token incentives, and future promises. Check token denomination, emissions, operator commission, and whether the rate is sustainable. |
| Withdrawals and exit queues | Potential changes in participants’ willingness to keep capital committed. | Confirm the measurement window and protocol withdrawal or unbonding rules. A queue is not necessarily a completed withdrawal or a loss. |
TVL is especially easy to overread. It can rise because more tokens were deposited, because the market price of deposited tokens rose, or because the dashboard’s coverage changed. It can fall when prices decline even if token quantities stay flat. Liquid restaking tokens also introduce a measurement question: a wrapper may represent a claim on assets that are already counted at another layer. Different analytics providers may therefore report different totals without either number being a direct measure of unique economic security. Compare token quantities and contract-level balances where available, note the measurement date, and do not add figures from overlapping layers without checking for double counting.
Counts need definitions too. One dashboard may count every registered AVS; another may display only services marked live or active. Similarly, an operator can be registered with EigenLayer but not opted into a given service, or opted in without public evidence that the service has meaningful workload. Open the dashboard’s definitions and trace a sample of listed entities to the service’s own documentation and onchain records before using a headline count to compare ecosystems.
Operators add operational risk because they run software that must meet service requirements. A failure might involve downtime, incorrect work, a missed task, or another violation defined by the AVS. When slashing is enabled and the relevant stake is allocated as slashable, an AVS can impose a loss under its rules. EigenLayer’s current documentation describes “Unique Stake” as stake allocated to a particular operator set; it is slashable only by the AVS that created that set. This design localizes specified slashing exposure, but it does not eliminate smart-contract, implementation, operator, custody, or liquidity risks.
Common misunderstanding: “delegating to an operator makes my position risk-free.” Delegation changes who performs the service work; it does not remove the restaker’s exposure to protocol and service conditions. The precise exposure depends on the AVS, operator set, asset, stake allocation, and withdrawal state. Before delegating, identify the operator’s service opt-ins, the service’s fault rules, the amount of stake allocated to each operator set, the operator’s commission, and the applicable withdrawal delay. The Unique Stake documentation explains how the allocation is scoped; also read the linked slashing and safety-delay sections there.
Common misunderstanding: “one AVS failure automatically slashes all stake across every AVS.” That is too broad for the documented Unique Stake model, where allocations are exclusive to operator sets and slashable by the associated AVS. However, an operator may serve multiple AVSs, and a restaker may have stake allocated in more than one set. Separate allocations can still create multiple sources of exposure, and shared operators or infrastructure can create correlated operational failures even where the slashable stake is separated. Map the actual allocation and dependencies instead of assuming either universal contagion or perfect isolation.
Slashing is not the only risk. Smart-contract bugs, incorrect AVS code, compromised keys, operator concentration, governance or upgrade decisions, changing reward economics, and withdrawal delays can matter even if no slash occurs. Ethereum.org also highlights centralization, slashing, and withdrawal access as restaking risks. Treat protocol documentation as a description of mechanisms, not a guarantee that every implementation behaves as intended. For a material position, review audits and upgrade controls, check operator incident history, and size exposure so a complete loss would not force a sale elsewhere.
EigenLayer’s official deployed contract reference and the project’s core contracts repository can help readers trace protocol mechanisms. They do not independently prove an AVS is useful, profitable, or secure. For those conclusions, combine contract data with service-specific usage, reward, and operator-performance evidence.
No single public metric can establish future restaking demand, future reward rates, or the probability and scale of a loss. Operator uptime statistics may use incompatible windows or omit incidents; reported rewards may include temporary incentives; and an announced service can remain short of production use. If the service’s revenue, operator performance, or slashable exposure cannot be independently checked, label that information unknown rather than filling the gap with an ecosystem-wide TVL figure. Recheck the official documentation and service disclosures before acting, because supported assets, operator sets, and contract rules can change.
Learn how Filecoin’s FVM and FEVM relate to storage deals, when to use direct deals or managed tools, and which metrics reveal real network demand.
Understand how Lido’s stETH rewards accrue, what validator concentration means, and how to choose between the withdrawal queue and selling stETH.
Understand how Rocket Pool minipools pair operator and pooled ETH, why rETH can trade away from its protocol exchange rate, and how to assess operator rewards, costs, and risks.
Understand how USDS differs from DAI, when conversion matters, how sUSDS fits in, and which Sky governance changes users should verify in 2026.
How Jupiter routes Solana swaps, what fees users may pay, how JUP governance works, and which execution and aggregator risks matter in 2026.
Learn how Ondo’s OUSG and USDY tokenized Treasury products work, what OUSG’s published instant-redemption limits mean, and which issuer, liquidity, fund, and blockchain risks to check.
Compare JitoSOL, native SOL staking, and JTO governance while tracing MEV tips, protocol fees, buybacks, and the risks that affect realized returns.
Learn how Wormhole Guardians, VAAs, and token routes work, what to verify before bridging, and which warning signs call for a different route.
Learn how Pyth’s pull-oracle model delivers price updates on demand, what update fees cost as of September 2026, and how to protect smart contracts from stale or uncertain prices.
Learn how Injective’s on-chain order books work, what INJ burns actually signal, and how to assess liquidity, trading activity, and bridge dependencies.