Skip to main content
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 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. After a recorded failure, the application decides whether to retry, choose another path, or initiate Cluster migration.