> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcium.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Queue ordering and fault handling

> How queue ordering, expiry, and Cerberus fault detection affect computation liveness and results

Queue rules determine which computation executes next, while Cerberus protects integrity after execution begins. Applications should handle queue expiry and failed execution as normal lifecycle outcomes.

## Order queued computations

Priority prices, account-lock ordering, and an optional leader choice determine which computation is selected from a Cluster's mempool. A queued computation can expire after 180 slots if it is not promoted for execution. The payer can then reclaim its computation charge.

These rules make ordering explicit. Applications can resubmit or apply their own fallback after queue expiry.

## Handle execution faults

Once execution begins, [Cerberus](/multi-party-execution-environments-mxes/mpc-protocols) detects protocol faults and aborts instead of producing a corrupted result under its stated trust assumption.

For a failed computation, the program allocates half of the base-plus-priority execution fee and the full callback reserve to rewards. It does not refund the unallocated half of the execution fee to the payer. See [Fee allocation](/staking/overview#fee-allocation).

After a recorded failure, the application decides whether to retry, choose another path, or initiate [Cluster migration](/clusters/cluster-migration).