Non-custodial, actively defended: how ether.fi thinks about security

When an exploit hits a DeFi protocol, the window to prevent loss is measured in seconds. ether.fi is built, end to end, to use them. How non-custodial design and active defense work together across four layers.

When an exploit hits a DeFi protocol, the window to prevent loss is often measured in seconds. ether.fi is built, end to end, to use those seconds. This post explains the strategy, and the four posts that follow take each layer of it in turn.

Two properties

Two ideas define how ether.fi operates, and they are not in tension.

• Non-custodial. The protocol cannot move your funds to itself or to anyone else without your signature. The defensive powers the protocol does hold are covered under “actively defended” below. They can pause the system and, once per-address isolation ships, isolate a flagged attacker’s address. They can block a bridge before a crosschain transfer completes, and invalidate an attacker’s in-flight withdrawal claim before it pays out. They cannot redirect your assets to ether.fi or to a third party.
• Actively defended. When an exploit is in flight, ether.fi acts to stop it.

The first is a limit on ether.fi. The second is a commitment to you. Both come from the same design goal: minimize what any single party, including ether.fi, can do unilaterally, while maximizing what can be done to stop an attack in progress.

This doctrine governs the whole product stack, from weETH and eETH to eBTC, eUSD, Liquid, and Cash. Where a product necessarily adds powers, a credit card spending flow for example, that is stated in its own documentation rather than papered over here.

Where the real risk lives

A staker’s risk is usually not in the protocol they deposited into. It is in the surfaces around it: the other DeFi protocols funds are routed through, the bridges they cross, the transactions a wallet is asked to sign, the chains everything runs on. The largest losses of the last two years prove the point. Radiant, Bybit, Resolv, and KelpDAO each lost funds to compromised keys, infrastructure, or bridges, not to bugs in core protocol contracts. The next two posts examine how ether.fi bounds those exact surfaces.

So the protocol is designed for the external case. When one of those surfaces fails, the damage should be bounded, not cascade through the protocol into its users. A failure on one chain should stay on that chain. A compromised key should run into code-enforced limits rather than reaching user funds. That principle runs through every layer below.

The doctrine

The industry has a recurring failure mode. A protocol could pause during an active exploit and lock funds, but does not, citing decentralization while users are drained. ether.fi does not accept that tradeoff. It accepts the cost of a false-positive pause to avoid the cost of a missed exploit, and the capability to make that call in real time is in place: monitoring (Hypernative, ML and rule-based) is wired to live controls that can pause the protocol, invalidate an attacker’s in-flight withdrawal claim, and block the bridges.

This does not make ether.fi a custodian. Non-custodial means you keep your keys and the protocol cannot move your assets unilaterally. Actively defended means that when an attacker tries to, the protocol is positioned to stop them, and that the authority to do so is bounded and visible. The two kinds of authority differ in speed by design. Authority to change the contracts is bounded by a 10-day timelock and recorded onchain. Authority to pause in an emergency is immediate but narrow, and equally visible.

These privileged actions are not taken by an undefined team. They are divided between two separate multisignature wallets. A 6-of-10 Upgrade Admin, behind the 10-day timelock, can change the contracts. A separate 4-of-7 Operating Admin runs them day to day and can pause in an emergency. No single signer set can both rewrite the contracts and operate them, and the multisig members and thresholds are public onchain.

Four layers of defense

A failure in one layer is designed to be bounded by the others.

1. Operational security. The foundation. How ether.fi keeps the people, keys, and infrastructure that hold privileged power from being compromised in the first place. This is where most of the industry’s recent losses actually happened.
2. Smart contracts. Bounds enforced by the code itself, so they hold even against an attacker who obtains privileged keys: admin keys cannot move user funds, rebases pass an onchain 5% APR cap (thus, can move eETH TVL by only ~1bps per day), and upgrades are timelocked. The contracts are audited by independent firms including Nethermind, Zellic, and Certora, with the full audit registry public and carry a public bug bounty.
3. Crosschain. Every active lane is verified by a strict four-of-four independent DVN quorum (Canary, Horizen, Nethermind, LayerZero Labs), with per-chain pause and rate limits, across the chains ether.fi operates, so an incident on one chain cannot drain the rest.
4. Active defense. Real-time detection and interception of live exploits, and the commitment to act when one is in flight.

Layer 1 keeps the protocol from being compromised. Layers 2 and 3 are code-enforced bounds that hold even if Layer 1 fails. Layer 4 is the real-time response when an attack still gets through. The next four posts take each in turn.

What this strategy does not promise

No security posture is complete, and claiming otherwise would undermine the rest of it.

• ether.fi cannot recover funds an attacker has already moved off its surfaces. Its authority reaches as far as its contracts do. Once value is swapped on a DEX or bridged off the chains ether.fi operates, it is beyond reach. That limit is the operational meaning of non-custodial.
• Real-time detection does not catch every attack. Some exploits never appear where they can be seen in time.
• Acting fast has a cost, and the controls are built to keep that cost off honest users and the protocols that integrate weETH. A defensive pause is scoped as narrowly as the incident allows: per contract, per flow, and, once per-address isolation ships, down to the attacker’s own address. The goal is to target the attack rather than the protocol. ether.fi also works to keep integrating protocols’ critical liquidation paths clear of a defensive halt. The residual risk is narrow but real, and ether.fi would rather absorb it than let an exploit run.

These limits are named here because the defenses below only mean something if you can see their edges.