Skip to main content

Phase 6: Decentralized Scheduler and EigenLayer

· 5 min read
OrcaRail
OrcaRail
Crypto payment rails for web2 apps

April 20, 2026 — Phase 6 is the phase where we explicitly do not build something, unless a real requirement forces it. EigenLayer restaking is powerful, but it is not a general-purpose home for "a payment system." This post explains what an AVS would give us, when it is worth building, and why Chainlink + NestJS is sufficient for most of what we need.

TL;DR​

  • EigenLayer is restaking + slashable attestations from ETH operators. It is not a chain, not a contract platform, not a custody solution.
  • Two places it could help OrcaRail: a Keeper AVS for decentralized charge() and a Bridge Attestation AVS for cross-chain settlement.
  • We will defer the build unless a customer or compliance requirement demands decentralized liveness beyond what Chainlink Automation + NestJS gives us.
  • If we ever build one, we start with Othentic / Eigen Foundation templates, not from scratch.

What EigenLayer actually gives you​

An AVS (Actively Validated Service) is a network of operators running an off-chain computation whose attestations are posted on-chain with cryptoeconomic security from restaked ETH. Misbehavior is slashable.

What that gets you:

  • Decentralized liveness: a task runs even if one party (OrcaRail) goes offline.
  • Slashable correctness: a bad attestation loses the operator stake.
  • ETH-economic security: you inherit a slice of Ethereum's validator stake instead of bootstrapping your own token.

What it does not get you:

  • A smart contract platform. Contracts still deploy on Ethereum / L2s.
  • Custody. EigenLayer does not hold USDC for you.
  • Solana or Bitcoin native support. Cross-chain bridges exist, and they add complexity and trust.
  • A general scheduler. You still define the off-chain task and on-chain verification yourself.

Where an AVS could help OrcaRail​

1. Keeper AVS (decentralized charge())​

Today and through Phase 3, the keeper picture is:

  • NestJS scheduler (primary)
  • Chainlink Automation or Gelato (fallback)

That gives us two-way redundancy. A Keeper AVS would give us N-way redundancy with slashable liveness: operators attest "these IDs were due and I called charge," and missing a due charge is a slashable offense.

When it is worth it:

  • When we have a customer whose contract forbids any single-party reliance on our infrastructure.
  • When regulatory compliance explicitly asks for it (rare today).

When it is not worth it:

  • When the marginal reliability over Chainlink is small and the engineering cost is months.

2. Bridge attestation AVS (Relay replacement)​

Our cross-chain settlement today uses Relay (see api/src/withdrawals/services/bridge). Relay is trusted. An AVS could attest "funds observed on chain X, release on chain Y" with slashable security — similar shape to Hyperlane ISM-with-EigenLayer or Omni.

When it is worth it:

  • When Relay introduces terms or performance we cannot accept.
  • When the platform processes enough cross-chain volume that bridge risk is material.

3. Fraud / compliance oracle​

"Is this wallet sanctioned?" "Was the merchandise delivered?" — policy checks currently in the NestJS webhook path could become AVS attestations. Niche use; only useful if the platform takes on an explicit on-chain policy responsibility.

Why we defer the build​

  • Chainlink Automation + NestJS is ~0 engineering cost. A Keeper AVS is months.
  • Building an AVS means running operators (or coordinating others to) and maintaining slashing conditions. That is an operational burden comparable to running our own blockchain node fleet.
  • The security improvement is only meaningful once we already have two-way redundancy. We do not yet (we get it in Phase 3). Compounded: only after Phase 3 is stable does a Keeper AVS become a candidate.
  • Even conservatively scoped, an AVS will have its own custody considerations (restaked ETH, operator compensation economics).

Decision log​

We will keep a public decision log at /docs/non-custodial/eigenlayer-evaluation with the current recommendation and any triggers that would flip it. Today's recommendation: defer.

Triggers that would re-open the discussion:

  1. A sales conversation explicitly blocked by "single-party keeper" risk.
  2. A regulatory framework that names AVS-backed liveness as an acceptable control.
  3. Chainlink Automation pricing or availability degrading meaningfully on our most-used chains.
  4. A partnership where we could reuse someone else's keeper AVS at near-zero ops cost.

If we do build it​

  • Start from a template. Othentic and Eigen Foundation publish templates for task-attestation AVSes. We will not hand-roll slashing.
  • Keep the on-chain entry point unchanged. SubscriptionHub.charge(ids[]) stays public and permissionless. The AVS just becomes one more caller alongside NestJS and Chainlink.
  • Don't introduce new tokens or staking mechanics for our own volume. Operators are paid in ETH out of the platform gas budget; no OrcaRail token.
  • Audit it. Even a template-based AVS needs an audit.

Status checklist​

  • Decision log page live
  • Quarterly review of triggers
  • POC sandbox (not production) if a trigger fires

What is next​

The final phase deletes the custody code paths that Phases 1 to 5 replaced: Phase 7.

Reference docs: Phase 6 status · EigenLayer evaluation · Keeper strategy