var img = document.createElement('img'); img.src = "" + location.pathname; = "border:0"; img.alt = "tracker"; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(img,s);
Skip to main content


The following section is a basic overview of how Warp works. For a more in-depth look at Warp smart contracts, visit the Contracts section. To learn how to use Warp, visit the Get started page.

What is Warp?

Warp brings decentralized automation to the blockchain. Unlike common Cron Jobs, Warp allows users to specify nearly any circumstance to execute a Job, not just time. With Warp, the circumstance is called a Condition, and the Job contains an executable message. Conditions can be anything from timestamps and blockheights to price queries and complex, nested combinations of circumstances. If it can be verified by another party on-chain, it can be used as a condition with which to trigger a Job. Warp Jobs are submitted as pre-signed messages to a queue, and participants called keepers monitor the conditions of each active Job. When the conditions have been met, the keeper executes the Job message.

Decentralized automation

Being a permissionless network, the executions of Warp jobs are fully decentralized. This means that anybody, as long as they have a functional computer, can run a Warp keeper to execute jobs and potentially profit off of them. The maintenance and upgrades of the Warp contracts themselves are performed by Terraform Labs, as the Warp protocol itself does not have its own token and associated governance. Learn more about the various Warp contracts and their associated admin addresses here.

How does it work?

The following illustration demonstrates how a job is executed.


The following concepts are essential to Warp job creation. Make sure to read this section carefully to get a full understanding of how Warp works.


Jobs are the main feature of Warp. Users submit WASM messages along with specified conditions and a reward. When the conditions are met, keepers send the message and receive the reward. Jobs can contain any valid WASM messages, including other create_job transactions, allowing jobs to be chained together and executed from the same context.

When a job is created, users must specify a job name, a reward amount, an execute message, and a contract address for the message. The job message is signed by the owner at the time of job creation, to be executed later by keepers.

Any tokens sent as part of a job's message must be present in the job account balance at the moment of execution.

To learn more about the workflow of jobs, visit the Job state page. To learn about creating a job, visit the Warp UI tutorial or the Warp SDK tutorial.


Each job must be submitted with conditions, which are a set of circumstances under which the job should be executed. Conditions are made up of expressions that can be simple, such as specifying a blockheight, or complex, in which multiple conditions are nested and joined using boolean operators. Query responses can also be used in expressions to specify a condition. When all the expressions in a condition evaluate to true, the condition is met, and the job can be completed.

Jobs can contain multiple pairs of conditions and execute messages. Using the Warp SDK, you can specify multiple execution pairs in the executions array, acting as a switch. The conditions are run top to bottom, and the first condition to evaluate as true will trigger its paired execute message.

To learn more about how conditions work, visit the Conditions page.


Templates and variables allow Warp users to create reusable, looping jobs. Templates create a job structure, and they contain variables that can be updated by a user. To learn more about creating templates, follow the Template tutorial.

Variables and recurring jobs

Variables can also be specified to update automatically through update functions. If a job is set to be recurring, each requeueing of the job will trigger the job's update functions, specified as "on success" and "on failure". To learn about variables, visit the variables page or follow the Warp UI tutorial.

The queue

Jobs that have been successfully created by a user are added to a queue, where they will remain until their conditions are met and they are executed by a keeper. For more on Job state, the queue, and a basic workflow, visit the Job state page.


A keeper is any party that maintains the automation functions of a smart contract. With Warp, anyone can be a keeper. Keepers are incentivized by Warp users to execute smart contract functions on their behalf, in exchange for a reward. Keepers query the chain and evaluate a job's condition. Once the conditions for a job are met, a keeper can submit the execute message contained in the job. In exchange, they collect a reward. To learn how to run a keeper, visit the Keeper guide.


Rewards are given by job owners to keepers in exchange for executing their jobs. Because Warp is a decentralized event handler, rewards are an incentive for unknown keepers to execute jobs, without the need for a centralized intermediary. The minimum reward value is 0.01 Luna. Rewards are provided in Luna and are priced organically, based on computing power costs and incentives for the keeper.


All protocol fees for Warp jobs are burned. Visit the Fee page to learn more about fee calculation.

Funds and accounts

Job accounts

When a Warp job is created, a job account is automatically created i the background. This account is a smart contract that can transact funds. Warp jobs can only utilize funds in their execution messages if the funds are present in their job accounts. Users can provide funds to the account by specifying them in info.funds of the job creation message, and these funds are relayed to the job account. This job account is used throughout the lifetime of the job. If the job is set to be recurring, the same account is used for the duration of the recurrence.

Funding accounts

Funding accounts are external accounts that can be used to fund maintenance costs for recurring jobs, such as fees and rewards for keepers. When creating a recurring job, a user can specify a funding account. Without a funding account, fees are taken from the job account.