Trust Model
What you trust today, what you won't need to trust after M6.
Current Beta Trust Assumptions
The Vela public beta requires users to trust the operator for three properties:
1. Correctness
You must trust that the operator is running the correct matching engine and applying the correct algorithm to all orders. The fraud proof system allows you to verify this, but verification is local and informational — there is no on-chain enforcement. If the operator publishes an incorrect state root, you can prove it but not enforce consequences.
2. Liveness
You must trust that the operator will process your orders and withdrawals in a timely manner. There is no forced inclusion mechanism in the beta. If the operator chooses to ignore your transactions, you have no cryptographic recourse.
3. Custody
Deposits are trust-based. Your balance exists in the Vela state layer, but there is no on-chain settlement contract holding real assets in escrow. The operator could, in principle, refuse to honor withdrawals.
Post-M6 Trust Model
After the on-chain settlement milestone (M6), the trust model changes significantly:
| Property | Beta (today) | Post-M6 |
|---|---|---|
| Correctness | Trust operator; verify locally | On-chain fraud proofs; operator slashed if wrong |
| Liveness | Trust operator to process transactions | Forced inclusion; users can bypass operator |
| Custody | Trust operator with funds | Funds locked in settlement contract; always withdrawable |
What You Never Need to Trust
Even in the current beta, some properties are trust-free:
- Order authenticity: The engine cryptographically verifies every order signature. The operator cannot place orders on your behalf.
- Matching algorithm: The algorithm is deterministic and verifiable. Anyone can check that the published state roots are consistent with the transaction logs.
- Privacy: Your private fills and balance data are only accessible to authenticated WebSocket connections using your wallet. The operator cannot reveal your order identity to other users.