ELPIS / PRIVATE BETA

An agent shouldn't have the last word on a payment.

Elpis puts rules between an automated payment request and the money behind it. Set limits, check the work, record a decision, and keep a recovery path where one exists.

Request access Watch a decision

Private beta on Arc Testnet. The playground evaluates decisions with no account and no money. When real money arrives, it will be audited contracts and payments capped at $100.

DECISION RECORD / EXAMPLEIllustrative

PAYMENT REQUEST

Pay for a completed job

A sample evaluation. No wallet connected. No transfer executed.

Recipient and limit
Within policy
PASS
Acceptance condition
SHA-256 commitment
SET
Submitted file
Digest matches
PASS
Release eligibility
Decision recorded
READY
On-chain transfer
Not submitted
PENDING

A decision is not a payment receipt. Execution requires separate authorization and chain confirmation.

01 / THE PROBLEM

Authorization isn't delivery.

Giving an agent permission to spend doesn't tell you whether the thing it bought was delivered.

Payments and agents already have plenty of ways to initiate transactions. Elpis addresses what comes next: agreed acceptance conditions, evidence, an auditable decision and a separate settlement step. It also lets operators put limits on the original request.

How the settlement decision works

02 / IN PRACTICE

The record should explain itself.

Open the playground

A request arrives

An agent proposes a payment. Elpis evaluates its permissions, limits and recipient rules.

The work is checked

The submitted evidence is measured against the condition agreed before the job started.

A decision is recorded

Release, refund or hold. The decision and its reasons can be replayed.

Settlement is authorized separately

A payment rail executes the transaction. The decision alone never proves funds moved.

POST /api/v1/jobsJSON EXAMPLE

{
  "provider": "example-agent",
  "condition": [{
    "kind": "deliverable_hash",
    "hash": "0xbfb0c59be7146dc7bcac…"
  }]
}

Abbreviated for display. See the complete executable example.

The input and output schemas are public. The resulting decision is reproducible; a matching hash alone does not prove a service was performed.

03 / WHAT'S INSIDE

More than a verdict.

Use the API on its own, or connect it to the treasury and recovery tools. They're built around the same transaction history.

Spending rules that run before the payment.

Limit amounts, restrict recipients, separate proposal from approval, and set treasury reserves. The model may request an action; policy decides whether it is allowed.

Read about spending controls

Make delivery measurable.

Commit to acceptance criteria, collect evidence and record an attestation another party can reproduce. Outside witnesses and oracle claims must be independently verified.

Read about verification

Escrow, without pretending refunds are magic.

Use supported settlement integrations and the Lazarus cancellation window. Final transfers cannot simply be reversed, so the interface makes that boundary explicit.

Understand recovery

REST APITYPESCRIPTPYTHONMCPERC-8183WEBHOOKSIntegrations

04 / PRIVATE BETA

Built with a small group. On purpose.

We provision every builder by hand: a testnet treasury, a scoped API key, and a direct line to the people writing the code. You build with the REST API, MCP or the SDK — and you try to break it.

Ask for a build key

YOU GET

A provisioned treasury on Arc Testnet, scoped keys, webhooks, and the docs behind this site.

WE ASK

Build something real. Report what confused you, what broke, and what you needed that wasn't there.

THE BOUNDARY

The contracts are not audited yet, so no real money moves. When it does, payments start capped at $100.

AFTER THE BETA

Licensed software on your own infrastructure. Capability-priced plans, no transaction fee.

Licence tiers and renewal

BUILD WITH US

See the decision first. Then build.

Request access Open playground