How Elpis thinks about a payment
The key objects and why deciding, authorizing and executing are separate events.
One transaction, several decisions
Elpis distinguishes a proposed action from a committed job, a verification result, and a confirmed transfer.
Agent requests an action
↓ policy rules / limits / approval
Job terms are committed
↓ delivery evidence is submitted
Decision: RELEASE | REFUND | HOLD
↓ explicit authority + underlying escrow
Transaction submitted
↓ chain receipt verified
Execution confirmedThe objects
| Object | What it represents |
|---|---|
Action | A proposed treasury operation, subject to policy, limits and approval. |
Job | A durable record of agreed acceptance conditions, a provider and optional deadline. |
Condition | A rule committed before work. Changing it creates a new commitment. |
Proof | Evidence offered for evaluation. Its authenticity depends on the source and verifier. |
Decision | A reproducible result: release, refund or hold. Not itself a blockchain transaction. |
Attestation | A digest representing decision inputs and result, suitable for deterministic replay. |
Vault | A separately authorized on-chain mechanism that may hold and transfer funds. |
Guardian | An address with limited stop/recovery powers as defined by the specific contract. |
Claims are not verified evidence
Anyone can type an address into a JSON field. That does not make it a signature. Anyone can type an oracle value. That does not make it an authenticated feed.
The public evaluator accepts deterministic inputs. Witness-gated release requires a configured verifier. Unsupported signature/oracle claims cannot authorize a live job release through the standalone Jobs API.
What recovery means
Some operations are internal, some remain cancelable while staged, and others are final on confirmation. Elpis labels them R1–R4 according to their mechanics, not an optimistic estimate of whether a refund might be possible.
Read Recoverability before using Lazarus Window controls with real value.