Skip to main content
The Computation Lifecycle in the Arcium Network governs how computations transition from definition to execution and completion. This structured process ensures seamless coordination, resource optimization, and precise handling of execution timelines.

​
Lifecycle Overview

The lifecycle of a computation in the Arcium Network follows a clear progression of steps. These steps ensure computations are securely defined, efficiently commissioned, and accurately executed. Here are the five key stages:
  1. Definition: A computation is defined within the context of an MXE, providing a blueprint for its execution (see the Defining & Commissioning Computations Section for details). This includes specifying inputs, outputs, logic, versioning, and access permissions.
  2. Commissioning: A defined computation is instantiated by specifying arguments, execution windows, and other parameters required for execution.
  3. Mempool Placement: Commissioned computations are queued in the mempool.
  4. Execution: Nodes execute the computation securely, ensuring privacy and accuracy.
  5. Post-Execution Callbacks: Following execution, actions defined for success or failure cases are carried out to ensure seamless workflow integration.

​
Execution Validity Windows

Each computation can specify an optional execution window consisting of:
  • Valid After Timestamp: The earliest time a computation can be executed.
  • Valid Before Timestamp: The latest time a computation can be executed.
These timestamps ensure that computations are processed at the right moment. If the “valid after” timestamp is in the future, the computation remains in the mempool until that time. If the “valid before” timestamp is in the past, the computation is no longer valid and cannot be executed. By default:
  • Valid After: Set to zero (no delay).
  • Valid Before: Set to infinity (no expiry).
However, these defaults are overridden when explicit timestamps are provided during commissioning.

​
Post-Execution Callbacks

Once a computation is executed, the system triggers callbacks based on the outcome:
  • Success Callbacks: Handle actions for successfully executed computations. These may include:
    • Dynamic On-Chain Actions: Triggering on-chain processes based on computation results.
    • Static On-Chain Actions: Fixed on-chain processes to address success scenarios.
  • Failure Callbacks: Manage actions when a computation fails. These are always static and include:
    • Static On-Chain Actions: Fixed on-chain processes to address failure scenarios.
Callbacks ensure that the system remains flexible and responsive, even in the event of unexpected outcomes.
⌘I