Known limitations & roadmap

An honest inventory of what the current build does not do. Nothing here is hidden behind marketing.

Not safe for real value

• Dev-grade trusted setup — single-contributor circuit key. Requires a multi-party ceremony + audit. See Trusted setup.
• Unaudited — no third-party security review of the circuit, verifier, or state machine.

Centralization (MVP)

• Single PoA sequencer — orders and produces all blocks; can censor / halt. Decentralization is a later phase.
• Single relayer — can censor withdrawals (not steal them). A relayer market is future work.
• Single-operator bridge — the relayer holds the sequencer key; the vault trusts one pubkey.

Pending (WSL / real-validator debt)

Both are blocked by the current dev environment, not by the design, and are the only remaining pre-launch engineering work:

• Real bridge-vault deployment — the deployable Solana program exists but is not deployed to a validator; the bridge runs against a faithful simulator today.
• BPF verifier path — the native builtin verifier is real and tested, but the same verifier deployed as a BPF program (calling the alt_bn128/poseidon syscalls) is not yet exercised on a real validator.

Scope not yet built

• No SPL token bridging — native SOL only so far.
• No WebSocket pubsub — clients poll getSignatureStatuses.
• No indexer-side note delivery — private-transfer recipients receive a note string out of band.
• Anonymity-set size — privacy grows with the pool; a young pool offers a small crowd to hide in (see What's public vs private).

Path to production

1. Multi-party trusted-setup ceremony.
2. Security audit (circuit + verifier + state machine + key handling).
3. Real bridge-vault deploy + BPF verifier path on a real validator.
4. Decentralize the sequencer; open the relayer set.
5. SPL token support; pubsub; an indexer-backed note-delivery channel.