Limits.
Erebus has no escrow, delivery verification, or relationship privacy. It also needs further security review and operational testing before production use.
This page describes the Starknet backend. For Monad, see Monad limits.
What Erebus does not do
The current implementation has the limits below. Configuration changes alone cannot remove them.
Hide who you are dealing with
The counterparty's address is written in public calldata at channel-open. This exposure happens upstream of our encryption, so no wire-level change can fix it.
Hide that a negotiation happened
Wire v3 removes the fixed v2 salt classifier, but the submitting account, transaction timing, action shape, and note count all stay public.
Prove production readiness from bounded runs
Four bounded mainnet workflows have passed. That does not establish capacity, uptime, an independent security review, or safety with real value.
Revoke facts already disclosed
An expiry stops later verification. It cannot make a recipient forget a record they already opened before it expired.
Escrow, or deferred delivery
The pool transfers funds at settlement. It cannot hold funds until a later delivery or release them under an external condition.
Settlement transfers funds immediately. The pool cannot hold them until a later delivery or release them when an external condition is met. Your application must decide whether to pay before it calls settlement.
What is unfinished
- Transaction signing and infrastructure
- The prover and preflight RPC receive the pool private key, so a hosted provider sits inside the identity's confidentiality boundary. Getting to production needs a written provider policy, endpoint rotation and revocation, a supported self-hosted fallback, tested backup and restore, and a key-loss drill.
- Transaction safety
- The client records operation IDs and supports reconciliation. Further work includes long-running failure tests against real provider timeouts, journal pruning that preserves recovery evidence, spending limits enforced in Rust across restarts, and operator alerts when the transaction outcome is uncertain.
- Security review
- No independent cryptographic or security review has covered the wire, the settlement binding, the disclosure design, the hosted-prover transport, or the recovery journal.
- Scale and operations
- Only suitable for bounded, low-frequency workflows right now. Provider latency, RPC load across long channels, pool fees, concurrent negotiations, and restore time are all unmeasured at scale.
- Product
- No delivery-versus-payment, escrow, refunds, deferred execution, or outcome-only proofs. A scoped grant reveals a deal record, but it doesn't prove that anything was actually delivered.
No independent cryptographic or security review covers the wire, the settlement binding, the disclosure design, the hosted-prover transport, or the recovery journal. Four bounded mainnet runs show that the workflow completes; they do not show capacity, uptime, or safety under adversarial conditions, since none of that has been tested.
Where that leaves you
Use Erebus for small evaluations: develop against mock, run a demo, or test a small transaction on Sepolia. The recorded mainnet runs do not establish production readiness.
Use a dedicated low-value identity for anything that touches mainnet. Registration cannot be reversed, and it permanently exposes that identity to the auditor. Whichever prover you choose gets that same permanent exposure from its side.
Erebus does not hide who you are dealing with, does not support escrow, and cannot prove that delivery happened. If your use case needs any of those, that gap cannot be closed with a configuration change.
The current gap list lives at production-gaps.md ↗ and status.md ↗ has the actual current state.