Security model
The exchange trades bearer assets that cannot be put under a contract. This page is explicit about the risk that introduces and the invariants that bound it. Read it before trading.
Bearer-leg settlement is race-bounded and non-atomic.
A Webcash or Voucher secret cannot be locked, escrowed, or made conditional. When it trades against an arbitrable leg (Bitcoin ARK or RGB), there is an unavoidable window where one party has delivered and the other has not yet. The flow is referee-mediated and the residual risk is bounded by proofs, signed acks, and rotation — but it is not atomic. Do not treat a bearer trade as an all-or-nothing atomic swap.
The receipt for any RGB ↔ Webcash/Voucher trade must make the bearer-race risk explicit. RGB ↔ RGB is different: it can settle through an RGB-server-enforced state transition and may be atomic. See the pair matrix.
No custody, anywhere in this flow.
This website holds no funds and no swap state. The referee holds no bearer secrets and never both halves of a 2-of-2 signing path. Settlement is driven by your wallet; the referee only arbitrates the conditional leg against proofs. The orderbook is peer-replicated, not centrally matched.
Security invariants
- Webcash and Voucher are never treated as conditionally lockable. They are bearer rails and only become safe enough for exchange when paired with an arbitrable or contract-arbitrable leg.
- A Bitcoin ARK / referee partial signature is never released without fresh proof that the bearer or RGB side reached the required state.
- The referee verifies the maker PGP fingerprint binding against Extro identity data before using an order public key.
- ZKP verification binds ciphertext bytes, order id, fill amount, recipient fingerprint, public token hash, and circuit version.
- Every state transition is idempotent and signed; every externally visible transition has an audit-log entry.
- Wallet hooks are idempotent by (swap_id, kind, payload_hash).
- Push delivery is not trusted as proof of wallet processing. A signed wallet ack or an independent rail post-check decides state.
- KV alone is not assumed to provide serializable transitions until a storage audit proves the exact write pattern is safe.
Before production trading
The exchange module, referee, ZKP verification, keyserver push, and rail checks are staged behind mock implementations until each is replaced by a real, audited component. Security audits run before production trading is enabled.
Treat any pre-audit deployment as testnet. Amounts you put through a bearer leg are at bounded but real risk during the settlement window.