TRUST / ELPIS

Security and trust boundaries

Where Elpis checks evidence, where it relies on external systems, and what has not been independently reviewed.

What the service protects

Elpis aims to keep an agent's requested financial action separate from the authority to execute it.

Its controls include API-key scopes, treasury policy and limits, signed witness integrations, audit records and recoverability rules. Each protection has a boundary; none makes an arbitrary transaction risk-free.

Boundary	What to verify
Account and access	Session handling, MFA, scoped tokens, revocation and organization isolation.
Spending policy	Recipient changes, budgets, reserves, approval gates and on-chain constraints.
Evidence	Committed terms and authenticated witness/registry integrations; untrusted oracle strings do not authorize release.
Execution	Which wallet signs, which chain is selected, what contract receives the transaction, and its confirmed receipt.
Recovery	Whether funds are still staged or already final, and what the particular vault permits.

Independent review status

No independent third-party smart-contract security audit has been completed for Elpis. Passing automated tests, internal reviews and a successful Cloudflare build are useful but are not the same as a separate security research team attempting to break financial invariants.

Before broad high-value mainnet use, the vault, evaluators, contract interactions, access controls and backend release paths should be independently assessed. The audit should yield findings and a review of fixes.

Public guidance is provided here and in Production status. Deeper audit preparation files are maintained privately by the development team.

This status describes the review performed—not a claim that exploitation is possible or that a particular vulnerability exists. An audit would also not guarantee that future exploits are impossible.

A decision is not a transfer

The standalone Jobs API records a deterministic decision and an attestation. It does not itself prove that funds changed hands on chain. Verify any settlement by transaction hash, chain ID, contract address, final receipt and beneficiary.

Execution states

accepted evidence → release decision
authorized transaction → submitted
confirmed chain receipt → payment executed

A SHA-256 match establishes correspondence to the committed bytes, not independent delivery, identity or quality. Caller-supplied witness names and oracle values are not authenticated evidence.

Safe public testing

Use the public playground for risk-free deterministic examples; it does not sign payments.
Use tightly scoped keys and account permissions in developer integrations.
Keep treasury funding and execution subject to deliberate review and conservative limits.
Confirm the current chain and custody setup before submitting real value; mainnet finality cannot be reversed by the website.
Do not share signing secrets, recovery codes or API tokens in bug reports.

Report a vulnerability

Report vulnerabilities privately to security@devilabs.dev. Include the affected component, a minimal reproduction using an account you own or mock data, and likely impact.

Do not exploit production accounts, access other users' data, move other people's assets or publish working exploitation instructions before a coordinated fix.

For the operating runbooks and custody assumptions, see Production status and Custody.