Arc Testnet · test assets only

Autonomous finance
designed to survive
being wrong.

Most agent safety asks a single question: should the agent be allowed to do this? Elpis asks the second question too — if an authorized agent is wrong, what happens next?

Runs against a real EVM and real Solidity, with Arc testnet as the production target. No mainnet value is ever moved.

Devilabs Demo Treasurylive
Total treasury
70,000.00
Liquid
45,600.00
Invested (recallable)
8,500.00
Committed
17,980.00
Safe to deploy
20,120.00
Recent agent activity
  • Payment staged
    900.00 USDC → Acme Hosting
    R2
  • Frozen
    Vendor wallet changed
    FROZEN
  • Recovered
    2,000.00 USDC returned
    R1
  • Verified
    Escrow released on chain
    FINAL
The thesis

Autonomy should scale with recoverability.

We do not claim an agent will never make a mistake. We build a financial system where it can safely act anyway, because the damage a mistake can do is bounded by design.

The safer an action is to recover from, the more autonomy the system permits. The more irreversible an action becomes, the stronger the controls before execution.

“Don't just constrain agents. Make their mistakes survivable.”

  1. 01Hard constraints limit what the agent can physically do.
  2. 02Critical actions require stronger approval.
  3. 03Recoverable actions are given more autonomy.
  4. 04Risky actions are delayed, escrowed and staged where possible.
  5. 05Every action is independently verified after execution.
  6. 06Every decision and state transition is recorded.
  7. 07When an authorized action is nevertheless wrong, there is an explicit recovery path.
Four control layers

Every action passes through all four, in order.

Model reasoning can suggest. It cannot authorize. The execution path depends on deterministic state and code, never on a language model's confidence.

01cannot be overridden

Deterministic rules

Balances, reserves, committed obligations, duplicate detection, ceilings and runway are ordinary code. A model cannot argue its way past them.

02enforced on chain

Execution constraints

The Lazarus vault holds funds in escrow, enforces ceilings and the recipient allowlist, and lets only a guardian freeze. Some violations are impossible, not merely discouraged.

03interpreted, never authoritative

Business policy

Soft rules in the owner's own words are interpreted into structured constraints. They can tighten controls. They can never loosen them, and they never release money.

04one click

Human approval

Irreversible actions, new recipients, changed wallets and amounts beyond trust require one click. The reason is always shown.

Recoverability

Every action gets a recoverability class before it is authorized.

The class is computed from how the action will actually be executed — never from an arbitrary AI score. If the execution layer cannot hold the funds, Elpis says the action is irreversible rather than pretending it can take it back.

R1
Reversible
R2
Recoverable
R3
Compensatable
R4
Irreversible
R1
Fully reversible

Internal movements and pre-execution proposals. Nothing leaves the treasury.

R2
Reversible before finalization

Escrowed or timelocked payments inside the Lazarus Window. Cancellable until release.

R3
Compensatable

Settlement cannot be undone, but a defined corrective action exists.

R4
Irreversible

Unrestricted settlement. Strongest approval, and Elpis says so plainly.

The core primitive

The Lazarus Window

An authorized action does not become final immediately. It is staged, and while the Lazarus Window is open the owner can cancel it, the supervisor can freeze it, and new evidence can halt it automatically. Only when the window closes — and independent verification passes — does it settle.

This is the lineage of the Lazarus Protocol, adapted from destructive infrastructure actions to financial settlement.

Lazarus WindowRecoverable
27:41until final settlement
900.00 USDC→ Acme Hosting
Cancel
Freeze
Finalize now
Treasury intelligence

The only number that matters is safe to deploy.

A wallet balance is not available capital. Elpis subtracts committed obligations and protected reserves, and the agent may only deploy what is left. The total is never called available.

Safe-to-deploy calculation
Total assets
50,000.00
Committed obligations
− 17,980.00
Minimum reserves
− 16,000.00
Safe to deploy
16,020.00 USDC
Security model

Eight rules the system will not break.

  1. 01Never trust LLM output as settlement evidence.
  2. 02Never let a prompt bypass a deterministic rule.
  3. 03Never mark a payment complete before verification.
  4. 04Never silently accept new recipient information.
  5. 05Never retry a financial action without idempotency protection.
  6. 06Never call compensation a rollback when the original transaction stands.
  7. 07Never present testnet or simulated actions as production.
  8. 08Default to failing closed for critical actions.

Arc + Circle

Built for Arc testnet with Circle's USDC and developer-controlled wallet tooling. The same vault that runs on the local EVM deploys to Arc unchanged.

Real execution

Transactions are signed and executed against a real EVM. Hashes come from real receipts, or the action reports failure — they are never invented.

Append-only ledger

Every state transition, control decision and recovery is written once, in order, and can be reconstructed end to end.

Most systems try to make autonomous agents incapable of mistakes.
We assume mistakes will happen.
Elpis makes autonomy proportional to how survivable those mistakes are.