La billetera oficial de Supra

Zero-Delay Automation: The Future of On-Chain Execution with Supra

March 03, 2025 - 5 min read

Bitcoin introduced blockchain technology by creating a decentralized digital currency. Ethereum expanded its capabilities by enabling smart contracts, which allow Turing-complete program execution on-chain. Since then, most new blockchains have adopted this approach. However, a key limitation of smart contracts is that they must always be externally triggered — requiring a transaction to execute a contract with the necessary input parameters.

Automation Networks solve this limitation by using a network of external nodes that continuously monitor the blockchain. When a specific condition is met, these nodes automatically send a transaction to execute the required action. This enables if-this-then-that style transactions, allowing for automation on the blockchain.

A Typical Transaction Flow for Existing Automation Networks

In most current automation networks, a user registers a task with a registry contract, which keeps track of all automation requests. This expresses the user’s intent to trigger a specific action on the blockchain automatically.

Once a task is registered, the automation network follows these steps:

  1. Monitor the Blockchain: Nodes continuously fetch the latest block.
  2. Evaluate Conditions: They check if the specified condition is met based on the blockchain’s current state.
  3. Reach Consensus (if decentralized): In a decentralized network, nodes agree on whether the condition is satisfied.
  4. Trigger Execution: A transaction is sent to the blockchain to execute the action.
  5. Mempool Processing: The transaction enters the mempool, waiting for inclusion in a block.
  6. Block Proposal: A block proposer selects the transaction and includes it in a proposed block.
  7. Finalization & Execution: The block is finalized, and the transaction is executed as part of it.

This process ensures automation of on-chain actions, but it may not be particularly seamless, as there are several stages where the automation could fail.

Most automation networks today trigger transactions based on time schedules or cryptocurrency price thresholds.

A key challenge is the delay between when a condition is met and when the transaction is executed on-chain, which can span multiple blocks. In time-sensitive applications, this delay can be costly. For example, if a collateral liquidation is triggered too late, its value may have already dropped significantly, leading to major losses for lenders.

Users must also pre-fund their automation accounts to cover gas fees and service charges. Since the automation network submits transactions on their behalf, it executes them under its own authority. If a transaction requires privileged access, users must delegate the necessary permissions to the automation network.

Supra’s Zero-Block-Delay Automation

As a vertically integrated Layer 1 blockchain, we considered offering enshrined automation services and explored the benefits of such an approach.

With Supra’s Zero-Block-Delay automation, active automated tasks are executed immediately at the end of each block, eliminating delays and trigger failures ensuring faster, more reliable execution.

Hey! Where are my conditional triggers here?

Our automation service eliminates the need to specify conditions separately from the on-chain actions they trigger. Unlike traditional automation networks, both the condition and the action are evaluated within the blockchain state itself. Time-based conditions are derived directly from block timestamps.

How It Works

All three steps below happen within a single block execution:

  1. Block Execution & State Computation – Validator nodes process transactions and compute the block’s state.
  2. Automation Task Execution – Once regular transactions are executed, the resulting state becomes the input for automation tasks. Active automation tasks are executed in the order they were registered.
  3. Finalizing State – These automation tasks become part of the block, and the output of the last task determines the final state of the block.

Since automation tasks execute at the end of each block, any condition that becomes true within a block triggers its corresponding action in the same block—eliminating delays.

For example, consider an automation task AT1 with the condition:

If C becomes true at the end of block B, execute_action() is triggered immediately within the same block, achieving zero-block delay from condition to execution.

Automation Task Registration & Execution

To register an automation task, the target smart contract—the one being automated—must first be deployed on the blockchain.

Registration Process

  1. The user registers the automation task, specifying the parameters required to invoke the target smart contract.
  2. The registry contract performs several validations, including:
    • Checking the syntax and type of the invocation.
    • Ensuring the user has sufficient balance for fees.
    • Verifying that automation parameters comply with system constraints.

Execution & Scheduling

  • Once a task is successfully registered, it is loaded by validators during the next epoch change.
  • Throughout the epoch, the task is automatically scheduled for execution at the end of every block.

Task Removal

A task is removed for one of two reasons:

  1. It expires after reaching its predefined expiry_time.
  2. The user cancels it by submitting a transaction.

Once expired or canceled, the task is removed from the automation registry in the next epoch change.

An automation task executes with the same authority as the user who registered it. For example, if Alice registers the task:

if Alice.balance > 10,000 then transfer(Alice, Bob, Alice.balance - 10,000)

This task will execute automatically at the end of every block, without Alice needing to sign each transaction. Her initial registration signature serves as proof of intent, ensuring that the task runs as if she executed it herself. This would ensure that every time Alice’s balance goes above 10000, the surplus amount is transferred to Bob.

To maintain zero-block-delay guarantees, a portion of block space is reserved for automation tasks.

Charging Model

The charging model includes multiple parameters that can be adjusted by Supra Governance to ensure fairness and efficiency.

Fee Structure

  1. Flat Registration Fee – A one-time, non-refundable fee paid at the time of task registration.
  2. Automation Fee – Charged for occupying automation reserve space, with two components:
    • Automation Base Fee: Based on the fraction of gas reserve used and the task’s lifespan (epoch_interval or expiry_time, whichever is earlier).
    • Congestion Fee: Increases linearly after hitting the Congestion Threshold (e.g., if the threshold is 50%, no fee applies below that; if tasks occupy 70%, a proportional fee is levied on the extra 20%).
  3. Gas Fee – Standard gas costs for executing the task in each block.

User Controls at Registration

  • Expiry Time – Defines when the task stops executing.
  • Max Gas – Limits the execution time per task, similar to a standard transaction.
  • Gas Price Cap (TBD) – Prevents execution if gas prices exceed a user-set threshold.
  • Automation Fee Cap – Limits automation costs; if fees exceed this cap, the task is automatically canceled to prevent excessive deductions.

Task Cancellation & Refunds

  • Users can cancel a task at any time, but it remains in the registry until the end of the epoch.
  • No refunds are provided for cancellations.

Compelling Use Cases

Lending Protocol Liquidations

A lending protocol issues loans backed by collateral. For example, it might lend Alice $800K in SUPRA against $2M worth of Terra LUNA. If the collateral’s value drops below the loaned amount, the protocol must liquidate it immediately to prevent losses.

In extreme market crashes—where LUNA’s price drops by 10% per block—delayed liquidation could be catastrophic. A 5-block delay could result in hundreds of thousands in losses, potentially escalating to millions for larger loans.

With Supra’s Zero-Delay Automation, the protocol can trigger liquidations in the same block the price threshold is breached, minimizing losses and ensuring financial stability.

Fully On-Chain Order Book DEX

Unlike the hybrid models that dominate today’s order book DEX landscape, Supra’s Zero-Delay Automation enables order placement, matching, and settlement to occur within a single block. The result is a significantly enhanced user experience, with transaction speeds comparable to those of centralized exchanges (CEXs). This could also enables real-time surveillance applications, such as automated alerts for monitoring order book activity on-chain.  

Future Plans

Cross-Chain Automation

Currently, Supra’s Zero-Delay Automation executes tasks within the Supra L1 blockchain. However, with the upcoming SupraNova cross-chain communication protocol, we plan to integrate automation with cross-chain transactions. This would enable fast, automated actions across multiple blockchains.

twitterlinkedinfacebookmail

RECENT POSTS

Recibe noticias, información y más.

Suscríbete al boletín de Supra para recibir noticias, actualizaciones, análisis de la industria y más.

PrivacidadCondiciones de usoUso de datos del sitio web y cookiesRevelación de bugs (errores)Política de privacidad de la información biométrica

©2025 Supra | Entropy Foundation (Suiza: CHE.383.364.961). Todos los derechos reservados