Forced Inclusion

A mechanism for users to bypass the operator and submit transactions directly to the settlement layer.

In the optimistic rollup model, the operator controls which transactions are included in each batch. A malicious or negligent operator could choose to ignore certain users — refusing to process their orders or withdrawals. This is the censorship problem: even with a fully correct and verifiable matching engine, a user can be prevented from accessing their funds if the operator simply stops including their transactions.

Forced inclusion provides an escape hatch. Users can submit transactions directly to the settlement contract on Ethereum, bypassing the operator entirely. The operator is required to include forced transactions within a defined time window. If the operator fails to include a forced transaction within this window, the settlement contract enters a halt mode and the operator loses their bond.

This mechanism is the primary user protection against operator censorship. Combined with fraud proofs (which protect against incorrect execution), forced inclusion closes the remaining trust gap: with both mechanisms, a Vela user's funds are safe as long as at least one honest party is monitoring the system.

Forced inclusion is a roadmap item for the M6 settlement milestone. In the current beta, withdrawals are processed by the operator manually and there is no forced inclusion mechanism. This is one of the primary trust assumptions of the current system.

• Users will submit forced transactions to a queue in the settlement contract, with a small ETH bond to prevent spam.
• The operator has a fixed window (e.g. 24 hours) to include the forced transaction in a batch.
• If the operator fails, the settlement contract enters halt mode: no new batches can be submitted until the forced transaction is processed.
• In halt mode, users can initiate emergency withdrawals directly from the settlement contract using the last published state root.