Skip to main content
An activation is the unit of work you submit to the Grid. It is an ordered batch of operations addressed to a single entity, signed by a private key, and admitted to the network through a shard mempool. If you are coming from Ethereum: an activation is the closest thing the Grid has to a transaction. This page covers the developer model: what an activation contains, how you submit one, and how the network executes it. For the byte-level layout, the signed pre-image, and how replay protection works, see Activation structure.

​
What an activation contains

An activation has four conceptual parts:
  • A target. A single entity, identified by its address. The activation will execute on that entity, and only that entity, on the shard the entity is currently assigned to.
  • A signer. An Ed25519 public key whose private key authorized the activation. By default the target is the signer’s own entity, so a wallet acting on its own assets does not need to set the target explicitly.
  • A list of operations. One or more operations, executed in order, against the components installed in the target entity. Each operation names the component it calls and the arguments it carries.
  • A validity window. A valid_until_block value that bounds how long the activation may be admitted. Past that block, the network will reject it.
There is no per-account sequence number. Two activations from the same signer can be admitted in either order, as long as both are still inside their validity window and neither is a duplicate. See Activation structure for the details.

​
Operations

The body of an activation is a list of operations. An operation is a call into one component on the target entity: it names a component (by index inside the entity), the function on that component, and the arguments. Operations in the same activation execute synchronously, in order, against the same entity. If any operation reverts, the whole activation reverts and no state changes are written. Activations only ever touch one entity directly. To act across entities (paying another wallet, calling a service), the executing component emits a continuation: a follow-up activation, generated by the protocol, that runs on the target entity. Continuations are how cross-entity flows compose. From the submitter’s perspective, you sign and submit one activation; the network executes the resulting graph of activations and continuations, and reports back the outcome.

​
Lifecycle

The developer flow has four steps:
  1. Build: Assemble the activation: target, operations, validity window. The CLI exposes this as gen client build-activation; an SDK builds the same structure in memory.
  2. Sign: Sign the activation with an Ed25519 key. The signature covers a fixed 82-byte buffer derived from the activation’s fields and the hash of its operations payload; see What is signed. Signing can happen in-process, or in an external signer (HSM, KMS, hardware wallet) that only sees the buffer.
  3. Submit: Send the signed activation to a Grid RPC endpoint via gen_sendExternalActivation. The mempool admits it after checking signature, expiry, and dedup. Admission is the point at which the network has accepted responsibility for executing the activation.
  4. Query: Poll for status with gen_getActivation (RPC) or gen client get-activation (CLI). Status moves from pending to either success or failed. Once it reaches success or failed, the result is deterministically final; there is no confirmation count to wait through.
For the full picture of every cross-entity step the activation triggered, query gen client get-trace instead; it returns the activation plus all continuations it produced. See Traces for the model.

​
Activation ID

Every activation has a unique ActivationId, derived from the same 82-byte buffer that is signed: 
ActivationId = ( SHA256(signed_buffer), resolved_target )
The ID is determined entirely by what was signed. Two signers cannot collide. The same signer cannot collide with themselves unless they sign two structurally identical activations; even then the tag field exists specifically to disambiguate. You use the ActivationId to look up status, fetch the receipt, or pull the full trace. It is the handle for everything you do with the activation after submission.