Current Status: Public Beta
Vela is in public beta. Some components of the trustless architecture are fully implemented; others are on the roadmap. The table below is the ground truth.What Is Trustless Right Now
These properties hold today, in the current beta:| Property | How it works |
|---|---|
| Order authentication | Every order is signed with your ECDSA private key. The engine verifies signatures before accepting orders. No one can place orders in your name without your private key. |
| Matching correctness (auditable) | The matching engine is deterministic. Every batch is published to the local DA layer. Anyone with access to the batch files can run verify_execution() to confirm the engine applied price-time priority correctly. |
| Order book transparency | The public WebSocket feed shows all resting orders in real time. You can verify that your order is in the book at the price you specified. |
| Fill reporting | Fills are reported via private WebSocket channels with tamper-evident data (order ID, fill price, quantity, is_maker). |
| Open source | The full engine source code is available on GitHub. The code you’re trusting is the code you can read. |
What Requires Trust in Beta
These properties require trusting the operator (Monolith Systematic LLC) in the current beta:| Property | Current State | Planned Trustless Version |
|---|---|---|
| Deposit custody | Deposits are held by the operator. No on-chain contract. The operator can theoretically abscond with deposits. | On-chain deposit contract (M6). Funds held by smart contract, not operator. |
| Withdrawal execution | Withdrawal requests are recorded but not settled on-chain. The operator controls when and if funds are returned. | On-chain withdrawal settlement (M6). Forced inclusion (M6) guarantees operator must process or face on-chain challenge. |
| Fraud proof enforcement | Fraud proofs are generated locally but not submitted on-chain. There is no on-chain penalty for operator fraud. | On-chain verifier contract with operator bond slashing (M7). |
| Censorship resistance | The operator can refuse to process orders from specific accounts. No forced inclusion mechanism is active. | L1 DelayedInbox contract with 24-hour timeout (M6). |
| Batch availability | DA batches are written to local storage on the operator’s server. The operator controls access. | Celestia or EigenDA integration (M7). Batches are publicly accessible. |
Risk Summary for Beta Users
Low risk:- Having orders matched incorrectly — matching logic is open source, deterministic, and auditable
- Having signatures forged — ECDSA prevents this cryptographically
- Deposit loss due to operator insolvency or operational failure — covered by trust in the operator
- Temporary inability to withdraw — the operator controls withdrawal processing in beta
Recommended approach for beta: Use only funds you are willing to lose. The beta is for testing and trading experience, not for holding significant value. The on-chain guarantees are coming — they require the smart contract work in M6 and M7.
The Trustless Roadmap
The path from the current beta to full trustlessness is defined and in progress:M6 — On-chain Settlement
- Deploy deposit contract: funds held by smart contract, not operator
- On-chain withdrawal settlement: engine approves, contract releases
- Forced inclusion (DelayedInbox): users can force transaction processing via L1
M7 — On-chain Verification
- Deploy fraud proof verifier contract with operator bond
- Integrate Celestia or EigenDA for public batch availability
- On-chain enforcement: fraud proof submission slashes operator bond
Comparison to Other Systems
| System | Deposit custody | Matching trustless | Censorship resistant |
|---|---|---|---|
| Centralized exchange | Trust exchange | No | No |
| Vela Beta | Trust operator | Auditable | No |
| Vela M6 | Smart contract | Auditable | Yes (forced inclusion) |
| Vela M7 | Smart contract | On-chain enforced | Yes |
| On-chain CLOB (e.g. Serum) | Smart contract | On-chain enforced | Yes |