Eigen Foundation Grant Proposal: avs-state-guard

AVS Research
1

Project Name: avs-state-guard — Application-State-Aware Slashing Prevention for EigenLayer Operators
Applicant: ILE Labs (github.com/ILE-Labs)
Program: Community Initiatives Grants

Executive Summary

EigenLayer is the cryptoeconomic bedrock of restaking. By allowing operators to secure diverse Actively Validated Services (AVSs), EigenLayer unlocks unprecedented capital efficiency. However, this multi-AVS model introduces a systemic security frontier: Cascading, Application-Layer Slashing Risks.

Currently, anti-slashing frameworks (such as Cubist) are strictly cryptographic—they only verify metadata, ensuring an operator does not double-sign conflicting messages at the same block height. They have zero concept of application-layer state. If a hacker compromises an AVS client, or if an operational misconfiguration occurs, the node can easily sign a structurally valid but malicious payload (e.g., an oracle price of $0.00, or an invalid bridge state root). Once submitted on-chain, this triggers an automatic slashing event, permanently burning millions of dollars in restaked ETH.

avs-state-guard is the first application-state-aware offline slashing guard. Written natively in Rust, it sits as a secure local proxy between the AVS Node Software and the Operator’s Signing Key (KMS/HSM). Before releasing any signature, it spins up a local concurrent fork of the target chain, simulates the transaction outcome, and runs deep safety assertions (reversion checks, boundary deviations). By validating the consequences of a signature before it is generated, avs-state-guard provides the ultimate security shield for operators and restakers alike.

The Systemic Problem: The Blindspot of Cryptographic Guards

Standard anti-slashing architecture is built under the assumption that “liveness and cryptographic double-signing” are the only risks. This leaves operators completely vulnerable to Semantic / Application-Layer Exploits.

Exploit Vector of Cryptographic Guards:

[A Hacked AVS Client] 
       │
       ▼ (Generates Malicious Payload: "Oracle Price = $0.00")
[Standard Double-Signing Guard]
       │
       ├─► (Checks: "Is this block height new?") ──► YES
       ├─► (Checks: "Has this height been signed?") ──► NO
       │
       ▼ [APPROVED]
[Signing Key (HSM)] ──► Signs & Broadcasts to Aggregator
       │
       ▼
[On-Chain AVS Slashing Contract] ──► [PERMANENT SLASHING: Millions in ETH Burned]

The Three Core Vulnerabilities of the Current Paradigm:

  1. Semantic Blindness: If a compromised or buggy AVS node client requests a signature for a payload that violates the AVS’s business logic, a cryptographic guard will approve it as long as the block height is sequential.
  2. Oracle / Bridge Hijacks: Oracle AVSs (such as eoracle) and cross-chain bridges require operators to sign state updates. A single database corruption causing an invalid state root signature will result in immediate protocol slashing.
  3. Multi-AVS Slashing Cascades: Because operators run multiple heterogeneous AVSs simultaneously, a single misconfiguration or bug in a minor AVS can trigger a cascading slashing event that drains the operator’s entire restaked pool, destroying their reputation and liquid restaking token (LRT) integrations.

The Solution: avs-state-guard (Real-Time State Verification)

avs-state-guard changes the paradigm from cryptographic verification to state-aware simulation. It ensures that an operator’s key never signs a message that would lead to on-chain slashing.

sequenceDiagram
    autonumber
    participant AVS as AVS Node Client
    participant SG as avs-state-guard Proxy
    participant Sim as Local Sim Engine (Anvil)
    participant HSM as Signing Key (HSM/KMS)
    participant Chain as On-Chain Contract

    AVS->>SG: Request Signature (EIP-712 Payload)
    Note over SG: Intercepts raw payload & decodes call
    SG->>Sim: Spin up Concurrent Local Fork & Simulate Transaction
    Note over Sim: Executes validation rules on fork
    alt Simulation Reverts or Violates Safety Bounds
        Sim-->>SG: FAILURE (Slashing Risk Detected)
        SG--xAVS: REJECT & Lock Key (Trigger Alarm)
    else Simulation Succeeds & State Within Bounds
        Sim-->>SG: SUCCESS (Payload Safe)
        SG->>HSM: Authorize Signature Generation
        HSM-->>SG: Return Cryptographic Signature
        SG-->>AVS: Return Verified Signature to Client
        AVS->>Chain: Broadcast to On-Chain Aggregator
    end

Core Architecture Components:

1. The Secure Local Proxy (avs-state-guard-proxy)

  • Sits between the AVS node container and the Key Management Service (AWS KMS, HashiCorp Vault, or local hardware HSM).
  • Written in Rust to maintain sub-millisecond overhead, avoiding liveness penalties for time-critical AVS tasks.
  • Exposes a standard JSON-RPC signing endpoint that parses EIP-712 or custom AVS message types.

2. The Offline Simulation Core (avs-state-guard-core)

  • Maintains a hot-synchronized state of the destination chain’s AVS Service Manager and Slashing contracts.
  • Upon receiving a signature request, it instantly spins up a local concurrent fork (via an embedded Anvil worker) and dry-runs the transaction.
  • State Assertions Executed:
    • Reversion Assertion: Verifies if the on-chain AVS validation code would revert or trigger an assertion flag when this signature is processed.
    • Boundary Assertion: Checks if the signed variables (e.g. price feeds, collateral values, bridge balances) deviate from the previous state by more than a custom threshold (e.g., max 10% shift per block).
    • Liveness / Timing Assertion: Ensures signatures are sent within valid slot windows to prevent obsolete or frontrun payloads.

3. Operator Safety Dashboard & CLI

  • Allows operators to write custom, highly specific rules for each AVS they run.
  • Enables dry-running of simulated slash events to test key-blocking mechanics.

Technical Specifications & Integration Flow

The tool integrates seamlessly into existing enterprise operator setups without altering their core infrastructure.

Integration Architecture Overview:

┌────────────────────────────────────────────────────────┐
│                   AVS Operator Node                    │
│                                                        │
│  ┌─────────────────┐       ┌──────────────────────┐    │
│  │ AVS Node Client │ ────► │  avs-state-guard     │    │
│  │ (Docker/eoracle)│       │  (Rust local proxy)  │    │
│  └─────────────────┘       └──────────┬───────────┘    │
│                                       │                │
│                                       ▼                │
│                            ┌──────────────────────┐    │
│                            │   Anvil Simulator    │    │
│                            │   (Concurrent Fork)  │    │
│                            └──────────┬───────────┘    │
│                                       │                │
│                                       ▼                │
│                            ┌──────────────────────┐    │
│                            │  Safety Checks Pass? │    │
│                            └──────┬─────────┬─────┘    │
│                                   │         │          │
│                            YES    │         │   NO     │
│                                   ▼         ▼          │
│                              ┌─────────┐  ┌─────────┐  │
│                              │ HSM/KMS │  │  BLOCK  │  │
│                              │ (Sign)  │  │ (Alarm) │  │
│                              └─────────┘  └─────────┘  │
└────────────────────────────────────────────────────────┘

Structural Roadmap & Completion Milestones

To ensure high-fidelity delivery, the project is structured across 3 logical engineering milestones focusing on core proxy logic, simulator orchestration, and real-world AVS guard integrations.

Milestone 1: Core Proxy & EIP-712 Decoupler (Weeks 1 - 4)

  • Deliverables:
    • Rust-native EIP-712 payload decoder and JSON-RPC interception proxy.
    • Support for standard HSM/KMS API integration (HashiCorp Vault & AWS KMS).
    • Local key-blocking fallback mechanism that halts signing when triggered by external triggers.
  • Verification: Open-source GitHub repository with complete unit tests proving successful proxy interception of signature requests and local signature block triggers.

Milestone 2: Concurrent Fork Simulator & Assertion Engine (Weeks 5 - 8)

  • Deliverables:
    • Automated orchestrator that manages local Anvil fork initialization from destination RPCs.
    • Boundary Validation Module: Custom parser that reads the AVS-specific state change bounds from a local configuration file.
    • Mock AVS Slashing Testnet: A complete mock environment containing a sample Oracle AVS and Bridge AVS with custom slashing contracts.
  • Verification: Integration tests demonstrating a simulated oracle hijack (where a price anomaly is introduced), showing the proxy successfully blocking the key and reverting before broadcasting.

Milestone 3: Production Ready Integrations & Auditing (Weeks 9 - 12)

  • Deliverables:
    • Production-ready integration guides and Helm charts for enterprise stakers and operators.
    • Complete open-source CLI suite (avs-state-guard-cli) for rule configuration and dry-running.
    • Comprehensive external security audit report of the proxy code.
  • Verification: Live demonstration of the guard securing a mock operator node against typical AVS database corruptions on holesky testnet.

Long-Term Vision & Sustainability

avs-state-guard is designed to be a core public good for the EigenLayer ecosystem. By releasing the core proxy and assertion engines as 100% open-source software, we enable any operator to secure their node for free.

To fund ongoing development and maintenance, we will offer:

  1. Enterprise Premium Support: Dedicated SLAs, integration engineering, and custom private KMS setups for high-TVL institutional stakers.
  2. Custom AVS Adapter Services: Building highly custom validation rules and simulation modules directly for emerging AVS networks.