Skip to main content

EigenLayer evaluation

This page is a living decision log. Its purpose is to explain what EigenLayer could do for OrcaRail, where it does not help, and when we would build on it.

Current recommendation​

Defer.

Rationale: NestJS scheduler + Chainlink Automation (or Gelato) gives us two-way redundancy for SubscriptionHub.charge(). The marginal reliability or decentralization gain from a Keeper AVS is not yet worth the months of engineering + ongoing operator coordination.

What EigenLayer is (precisely)​

EigenLayer is a restaking protocol on Ethereum. Validators who secure Ethereum can opt-in to provide additional economic security to secondary networks called AVSes (Actively Validated Services).

What an AVS provides: an off-chain computation (a "task"), a committee of operators that attest to the result, on-chain verification of those attestations, and slashing for provably wrong results.

What EigenLayer is not:

  • A chain.
  • A smart contract platform.
  • A custody solution.
  • A substitute for audits, contract design, or operational discipline.

Where an AVS could fit in OrcaRail​

1. Keeper AVS (decentralized charge())​

Idea: operators watch SubscriptionHub, submit charge(ids[]) when due, and attest on-chain that they did so on time. Missing a due charge is slashable.

Pros:

  • Decentralized liveness. No single party (OrcaRail) is essential for subscriptions to function.
  • Slashable correctness for SLO misses.

Cons:

  • Engineering: build an AVS (task definition, slashing condition, operator client, aggregator) or adapt an off-the-shelf template. Months either way.
  • Operational: recruit and support operators (or pay for a service that does).
  • Marginal benefit: our existing Chainlink + NestJS pair is already two-way redundant.

Would we build it? Only if triggered (see below).

2. Bridge attestation AVS​

Idea: replace Relay's trusted bridge with an AVS that attests "funds observed on chain X; release on chain Y" under slashable security.

Pros:

  • Cross-chain settlement without trusting a single bridge operator.
  • Aligns nicely with existing ISM-style messaging frameworks (Hyperlane, Omni).

Cons:

  • Relay already works well for us at current volumes.
  • An AVS-backed bridge is a bigger bet than a Keeper AVS: we either build it ourselves or depend on an emerging network.

Would we build it? Only if Relay becomes unworkable or a partner offers an off-the-shelf AVS-backed route.

3. Policy / compliance oracle​

Idea: AVS attests to facts that drive on-chain policy decisions — sanctions list membership, delivery confirmations, fraud signals.

Pros:

  • Moves policy checks out of centralized servers.

Cons:

  • Niche. Only useful if OrcaRail takes explicit on-chain policy responsibility.

Would we build it? No, not in the near term.

Triggers that would flip the recommendation​

We will revisit this recommendation quarterly. Any of these triggers would open a design doc for the relevant AVS:

  1. A sales conversation explicitly blocked by "single-party keeper" risk we cannot mitigate otherwise.
  2. A regulatory framework that names AVS-backed liveness or attestation as an acceptable or preferred control.
  3. Chainlink Automation availability or pricing degrading meaningfully on a chain where we process material volume.
  4. A partnership where we could reuse someone else's keeper or bridge AVS at near-zero operational cost.
  5. OrcaRail becomes large enough that "payment rails must survive OrcaRail being offline" is a reasonable expectation.

If we do build it​

Design constraints we would follow:

  • Start from templates. Othentic and the Eigen Foundation publish AVS templates for task-attestation networks. We would not hand-roll slashing.
  • Keep the on-chain entrypoint unchanged. SubscriptionHub.charge(ids[]) stays public and permissionless. The AVS becomes one more caller alongside NestJS and Chainlink.
  • No new token. No OrcaRail staking token. Operators are paid in ETH (or USDC) from the platform gas budget.
  • No new custody. The AVS does not hold or route funds.
  • Audit. Even template-based AVSes need an audit.
  • Sunset plan. If Chainlink, Gelato, and in-house keepers cover the reliability gap, we should be able to decommission the AVS.

Open questions (tracked; not blocking)​

  • Is there a natural cohort of AVS operators that already run payment-related infrastructure (indexers, keepers)?
  • What are realistic attestation latencies for "due within the minute"?
  • What is the minimum operator-set size for credible slashing?
  • How does Eigen's mainnet slashing primitive integrate with our existing monitoring?

Decision history​

DateDecisionNotes
2026-04-20DeferChainlink + NestJS two-way redundancy sufficient; re-evaluate quarterly.

New entries land here when the decision changes.

See also​