Why Warp?
The problem
Many types of blockchain transactions are responses to various changes on-chain. For instance, a user may swap two tokens on a DEX when the price reaches their desired level. A liquid staking token manager withdraws and compounds rewards when the number of rewards reaches a profitable level. An arbitrageur profits between multiple DEXes when the price is at a mismatch by swapping one or multiple tokens.
In short, many users have a need to sign transactions as soon as the blockchain data aligns with their needs. Currently, there are only two main ways in which this can be done. For one, a single user can manually make trades when the price is right by signing transactions with their wallet. On the other hand, liquid staking token protocols and arbitrageurs tend to set up a node paired with bots that constantly scan the chain for changes and execute their transactions when their conditions hold true. Both of these mentioned solutions are incredibly resource-intensive. A user either needs to delegate their attention or spin up expensive infrastructure to sign their transactions.
The problem is even more pronounced when the end users are protocols. Imagine a flow where a governance proposal needs several steps to successfully execute.
For example:
- Send tokens across through IBC when the proposal passes
- Purchase tokens on Osmosis when the price reaches the desired level
- Create a pair on Osmosis when tokens are purchased
- Provide liquidity on Osmosis with purchased tokens on new pair
This necessitates a centralized service provider to fully accomplish all these steps, whether it be manually or with the help of a bot. As a result, the chain suffers from a single, centralized point of failure.
Instead, what blockchains need is a decentralized event handler.
Warp: the Solution
A successful event handler has the following implemented features:
- Custom conditions: A user should be able to compare any value on-chain with an expected result. The protocol should be fully generic and accept any comparisons without limiting users to certain presets. Submitted jobs should also be capable of nesting and contain multiple conditions in a single set. Examples include, but are not limited to:
- Ensuring that a block height or timestamp has passed
- See if a price level is below or above a desired level for any DEX
- Check if the user’s balance is above or below an amount
- Check if a protocol’s yield is high enough to stake in
- All or any of the above
- Custom transactions: A user must be able to submit any possible WasmMsg as a transaction. This should also not be limited to a preset message. Examples include, but are not limited to:
- Swapping tokens on a DEX
- Sending tokens to another wallet or chain
- Staking, unstaking, bonding, unbonding
- Compounding liquid staking derivative token
- Submitting governance proposal
- etc
- Permissionless execution: Anybody should be able to sign a submitted transaction as long as the conditions for doing so are satisfied.
- Attractive incentives: Users who execute the transactions should have attractive enough incentives for doing so. These incentives could come from rewards pinned by users who submit the transactions to Warp.
- Decentralized: To ensure the protocol is as decentralized as possible, it should exist purely on-chain and allow anybody to act as an incentivized keeper to execute messages. Anybody who desires can become a participant both as a job creator and a protocol keeper.
With such a system, it is possible to design a fully on-chain event handler. This event handler can serve as an on-chain automation layer for users that can remove the need for manual transactions and centralized keeper bots.