TREASURY / ELPIS

Payments

The full payment lifecycle: propose, escrow, execute, verify — and how to undo one.

Lifecycle

State	Means
DETECTED	The intent exists. No money committed.
EVALUATED	All controls have run and produced facts.
STAGED	Held in on-chain escrow; cancellable until the window closes.
APPROVAL_REQUIRED	Held for a person. Reasons name the control that asked.
BLOCKED	A blocking rule refused it. Terminal.
EXECUTING	The transaction has been submitted.
EXECUTED	The transaction is mined; verification is next.
VERIFIED	The chain was read back and confirms the transfer.
FINALIZED	Complete. Irreversible from here.
CANCELLED	Recalled inside the window; escrow refunded on chain.
ROLLED_BACK	Execution failed and was unwound.
COMPENSATED	Made whole by a compensating action.
FAILED	Errored; no funds moved.

Proposing

POST /api/v1/actions

{
  "accountId": "acc_vendors",
  "amount": "1250.00",
  "address": "0x…",
  "label": "Acme Hosting",
  "documentRef": "INV-1042",
  "obligationId": "obl_…",
  "reference": "invoice-1042"
}

amount is a decimal string. Base units are what the chain uses; the API accepts both.
reference or an idempotency-key header makes retries safe.
documentRef is required above the document anchor threshold.
Passing a known counterparty’s address links the payment to its trust history.

Undoing a payment

Situation	Action	Effect
Staged, inside the window	Cancel	Escrow refunded on chain; daily budget restored.
Staged, window closed	—	It is now settling; only a compensating action is possible.
Approval pending	Reject	Terminal refusal; no money ever moved.
Executed but reverted	Automatic	Recorded as a refusal, never as a payment.
Finalized wrongly	Compensate	A new action pays it back; the original stays in the ledger.

Cancelling is not a database update. It is a real on-chain refund, verified like any other transaction — which is why the window is the guarantee, not a promise.

Idempotency

A retry of the same intent must never be a second payment. Elpis derives a key when one is not supplied (from the pool, recipient, amount and window) and refuses duplicates with 409. The key is what makes an agent safe to retry.

Verification

After execution, Elpis reads the chain independently. Only a confirmed transfer becomes VERIFIED and then FINALIZED. A missing or null hash is treated as pending, never as success. See Verifiability. For a job that outlives a single payment and settles in milestones, see Settle on proof.