Skip to Content

FAQs

How is Supra’s automation different from third-party bots or keepers?

Supra’s automation is built into the validator layer. There are no off-chain agents, bots, or centralized relayers. All task evaluation and execution happens on-chain, natively, and deterministically.

Can I automate any smart contract?

Yes, as long as the target public entry function specified in the payload transaction during registration is deployed on Supra and matches the argument types of the deployed function.

What happens if my task exceeds its gas cap or fee cap?

If an execution needs more gas than --task-max-gas-amount, the execution fails. If the gas unit price for a particular block is higher than the gas_price_cap, the task is skipped for that block. If the automation fee for a cycle exceeds your fee cap, the task is removed at the start of that cycle and a TaskCancelledCapacitySurpassedV2 event is emitted.

Can I cancel a task after registration?

Yes. You can cancel a task using the CLI or by submitting a transaction to the cancel_task function. A pending task is removed at once. An active task stays in the registry until the current cycle ends and is removed at the next cycle boundary. To remove tasks immediately, use supra move automation stop-tasks.

NOTE:

  • The registration fee is non-refundable.
  • If the task is still pending, it is removed immediately and half of its deposit is refunded.
  • If the task has already become active, the automation fee for the current cycle is still charged and is non-refundable. No fee is charged for later cycles, and the deposit is returned at the cycle boundary.

Is there a way to simulate tasks before committing them?

Yes. The Supra CLI supports a --simulate option that allows you to preview the outcome of a registration without executing it. This is useful for validating arguments and function calls before submitting the transaction.

Example:

supra move automation register --simulate \ --task-max-gas-amount <MAX_GAS> \ --task-gas-price-cap <GAS_PRICE_CAP> \ --task-expiry-time-secs <EXPIRY> \ --task-automation-fee-cap <FEE_CAP> \ --function-id "<ADDRESS>::<MODULE>::<FUNCTION>" \ --args address:<RECIPIENT> u64:<AMOUNT> \ --rpc-url <RPC_URL>

See Calculate task-expiry-time & task-automation-fee for how to derive each placeholder from the chain.

How frequently are tasks evaluated?

Tasks are evaluated at the end of every block. If the condition becomes true during block processing, the task is executed in the same block.

How is pricing determined during high congestion?

A congestion threshold is set by governance as congestion_threshold_percentage of the registry’s maximum gas cap. The fee estimate uses the next cycle’s cap, get_next_epoch_registry_max_gas_cap, and the charge at a cycle boundary uses the active registry_max_gas_cap. If the max_gas of all the registered tasks exceeds this threshold, an additional fee applies, based on how far the threshold is exceeded. In the current charging model, the congestion fee grows with the congestion_exponent-th power of that excess, so a higher exponent makes it rise faster. Read the current values with get_automation_registry_config.

Can I use automation across chains?

At present, automation is scoped to the Supra network. However, cross-chain automation will be supported through SupraNova, allowing source conditions and target actions to occur across different blockchains.

What happens when a task expires?

It is removed at the next cycle boundary and its deposit is refunded. No additional actions are needed from the user.

Are refunds given if a task is not fully used during a cycle?

Yes. If a cycle ends earlier than planned, partial refunds of the cycle fee are processed for the unused time.

Last updated on