Prerequisites & Cycle Timing
Prerequisites
- Supra CLI setup and profile created
- An account that holds SUPRA. Registration aborts with
EOWNER_NOT_ELIGIBLE_TO_RECEIVE_SUPRAif the account is not registered to receive SUPRA. - Sufficient funds in your wallet to cover:
- The flat registration fee and a deposit equal to
--task-automation-fee-cap, both taken when the task is registered - The automation fee, taken from the account balance at the start of each cycle in which the task is active
- Gas fees for each execution
- The flat registration fee and a deposit equal to
All amounts are in quants (1 SUPRA = 100,000,000 quants).
Understanding Cycle Timing
Automation is organised in fixed-length cycles. The registry uses cycles for bookkeeping: activating newly registered tasks, removing expired and cancelled tasks, and charging the automation fee. Governance sets the cycle duration, so read it from the chain instead of assuming a value.
Automation tasks themselves are executed at the end of each block.
Reading the current cycle
supra move tool view \
--function-id 0x1::automation_registry::get_cycle_info \
--rpc-url <RPC_URL>The same view through the REST API:
curl -X POST <RPC_URL>/rpc/v3/view \
-H 'content-type: application/json' \
-d '{"function": "0x1::automation_registry::get_cycle_info", "type_arguments": [], "arguments": []}'The response contains these fields:
| Field | Meaning |
|---|---|
index | Sequence number of the current cycle. |
state | 1 while the cycle is running. Tasks can be registered or cancelled only in this state. |
start_time | Start of the current cycle, in seconds since the Unix epoch. |
duration_secs | Length of the current cycle, in seconds. get_cycle_duration returns this value on its own. |
If a registration or cancellation aborts with ECYCLE_TRANSITION_IN_PROGRESS, the registry is moving between cycles.
Submit the transaction again after the transition finishes.
Key Behavior
- A task registered during a cycle is pending. It becomes active when the next cycle starts, and the automation fee for that cycle is charged at that point.
- Once active, the task can be triggered by block activity, as frequently as every block.
- A task is removed at a cycle boundary when it has expired or been cancelled.
- Registration timing still matters: the expiry time must fall after the end of the current cycle, otherwise the
registration aborts with
EEXPIRY_BEFORE_NEXT_CYCLE.
Cycles affect when registrations are picked up and when fees are charged, not when an active task is executed.
Why This Matters
- A task does not run until the next cycle starts, so it may not run immediately after registering.
- Set
--task-expiry-time-secswith enough buffer for pickup and execution.
Give your task buffer time after it becomes active by calculating the expiry like this:
expiry = start_time + duration_secs + buffer
start_time and duration_secs come from get_cycle_info. buffer is the number of seconds you want the task to run
after it becomes active. The registry also rejects an expiry that is more than task_duration_cap_in_secs after the
registration time. See Calculate task-expiry-time & task-automation-fee
for how to read that cap.
While cycles govern registration and fees, active tasks execute block by block, so you get more frequent and responsive automation than the cycle length suggests.