Slashing bounties and Virtual Operators: AutoLayer's V2 design

Background in four lines

• Restaking reuses staked ETH to secure additional services.
• An AVS (Actively Validated Service) is one of those services.
• An operator runs the software that validates an AVS, and stakers delegate to operators.
• Slashing is a penalty applied to stake when an operator or service breaks the AVS’s rules.

The practical consequence: delegating to an operator is a trust decision. If that operator, or the AVS itself, triggers a penalty, delegators can lose part of their stake. The V2 design makes three things easier: running operators, choosing among them, and reacting to slashing risk.

Part 1: the Virtual Operator

Users can create, configure and run a Virtual Operator designed to validate various AVSs. The process:

1. A user creates an Operator in AutoLayer.
2. AutoLayer starts a qualification process for all AVSs involved, at minimal cost.
3. If an AVS has reached its capacity cap, the user is told right away.
4. A nominal amount of ETH may be used to cover the infrastructure needed to start the Operator.
5. After launch, any user can allocate funds to it.

The word “virtual” reflects the division of labour: the user decides the configuration, AutoLayer manages the infrastructure, and vaults can set their own rules for automation, auto-compounding and opt-out.

Part 2: the AVS Vault Manager

Once an Operator exists, the AVS Vault Manager is where users put money behind it. Each Operator within AutoLayer is designed to validate a unique set of AVSs. Different sets of AVSs mean different products, with varied yields and risk profiles.

Element	How it works
Assets in a vault	Both illiquid and liquid.
Yield strategies	From auto-compounding liquid rewards to wrapping illiquid ones. See compounding and liquifying.
Profit display	Realistic dollar-based APRs, to measure incentive inflation.
Operator flexibility	Operators can adjust their AVS mix using information and automations from AutoLayer.

The final row ties back to scoring. Operators can change their AVS composition based on the information and automations AutoLayer provides. That information is the AVS score and the LRT score described elsewhere in the same roadmap.

Part 3: the slashing bounty contract

The most unusual part of the design is the bounty.

The problem it addresses

Suppose someone notices that a slashing condition has been met for an AVS. In many designs, the observer would claim a bounty directly. We propose something different: instead of claiming straight away, the observer can trigger an auto-delayed process where they earn the same rewards with additional bonuses.

What the contract is meant to do

The contract has three jobs:

1. It safeguards users from slashing by halting the validation of the AVS before the slashing event occurs.
2. It also executes the slashing, to prevent double-dipping. Double-dipping here means someone collecting both the early-warning reward and the slashing reward.
3. Stakers are charged a small fee that contributes to the bounty fund.

Put together: a person who spots a breach is rewarded for triggering a delayed process that pauses the AVS’s validation first, so stakers can avoid the loss, and then the contract handles the slashing itself. The fee paid by stakers funds the rewards.

Design questions we are working through

A design like this has to answer hard questions, and a security review is expected to test each one:

1. Who judges a breach? The contract needs a rule for when a slashing condition counts as met.
2. How long is the delay? It must be long enough to act and short enough to protect stakers.
3. What is the fee? It is kept small, since it only funds the bounty pool.
4. How does it interact with the AVS’s own rules? An AVS defines its own slashing logic. A third-party contract halting validation would need to work within it.
5. What if the signal is wrong? A false report that pauses validation could itself cause a loss for stakers.

Why a bounty at all

Incentives shape behaviour. If the only reward for spotting a problem is a slashing payout after the damage, the incentive points toward waiting. A bounty that pays more for early action, and pays the same pool only once, tries to reverse that. That is the logic behind our design. Whether it works depends on the contract’s rules and on whether anyone is watching.

Where this sits among the other V2 features

The four V2 features are a set:

• AVS scoring: rate each service by who staked on it.
• LRT scoring: rate the token by how much of it is reused as collateral.
• Compounding and liquification: handle rewards.
• Slashing bounties: react when a condition is met.

Virtual Operators and the Vault Manager are the surfaces where these combine. For the wider product, see the product page and how it works.

What to check before trusting any slashing protection

If a protocol claims to protect you from slashing, ask for:

1. The contract address and an audit report that covers that exact contract.
2. A written description of who can trigger the halt and under which conditions.
3. The fee and where it goes.
4. What happens if the halt is triggered wrongly.

For context, our earlier Tortle Ninja contracts were audited by PeckShield. See From Tortle Ninja to AutoLayer and the security page. Read the risk disclosure as well.

Takeaway

The V2 plan has three parts: let users create Operators, let them choose among vaults by AVS mix, and add a bounty contract that tries to halt an AVS before a slashing event reaches stakers. Its real safety will depend on the contract rules and on independent review, so check the security page for audit status before relying on it.