Automation and Bot in Blockchain

0. Blockchain, is a Bot

Automation, as a noun, is defined as a self-driven machine or a control mechanism that automatically follows operations.

As written in the Bitcoin whitepaper, the core of the blockchain network is a decentralized timestamping mechanism that guarantees the correctness of the ledger through cryptography and automation.

The blockchain itself is an automation program that automatically and endlessly generates blocks according to consensus mechanisms and cryptographic rules while keeping data in the ledger. We even have rollup with built-in ticking automation (automation²).

Of all the automation or bot types, a blockchain is most like a mechanical clock:

Under the narrative that blockchains are automation clocks, we learn that the developers of Crypto and Web3 are, in fact, watchmakers, building social mechanisms and technological systems that operate automatically and endlessly in a pendulum-like motion through decentralized technology. Once we get the cogs to start turning, each iteration will be based on our initial creation.

Choosing the correct end-to-end decentralized and secure solution for building the "clock" is critical, so Hyper Oracle ensures that zkMiddleware Meta Apps (zkIndexing and zkAutomation) are entirely trustless and decentralized through zkPoS and zkWASM, enabling the next generation of DApp development.

1. Blockchain, driven by Bots

For automation, bot, MEV, keeper, and other concepts:

  • Automation is a generic term for all automation programs, including MEV automation and keeper automation.

  • Bot is the instance of these automation runs, including MEV bots, Keeper bots, etc.

  • **MEV bot is a common type of bot that analyzes blockchain network activity for profit**. The concept of MEV is only vaguely defined, but in a broad sense, it can include all kinds of bots. See this is MEV and this is not MEV.

  • Keeper is a more "positive" and "beneficial" type of bot, usually set up by DApp developers themselves to trigger some actions periodically (TWAP update or liquidation), to keep the DApp running correctly and healthily. These actions may be too complex for on-chain computation, too frequent for governance, and too critical for permissionless, so keeper are required.

The blockchain is largely driven by Automation (or MEV Bots).

"This is a horror story." In the dark forest of Ethereum, you're not only up against other users but also a bunch of ruthless automation bots. They watch your every move and look for mistakes and weaknesses in every action you take to profit from you.

Here's some proof:

a) ~50% Uniswap V3 Trades = Bots

About 50% of the transaction volume on Uniswap V3 is contributed by bots, while about 20% of the unlabeled addresses, most likely, are also bots. This means that more than 2/3 of the transaction volume on Uniswap V3 is likely to be the outcome of automation.

Also, only about 15% of the transaction volume comes from the Uniswap V3 front-end, meaning that at most 15% of the transaction volume is directly submitted by real live users.

Don't worry, this is not a significant failure of Uniswap or DeFi, but that's the beauty of AMM and DeFi.

But the presence of these Bots does pose a problem:

Based on the mentioned point, we can bring up the biggest toxic flow creator on Ethereum, the market maker bots (~arbitrage bots).

b) DEX Dominance = Bots

Remember the Wintermute wallet hack last year? Wintermute started this wallet in May 2022 as a market maker bot. By the time it was hacked in September last year, it was the second most profitable address on Ethereum. Through market making, this bot made $90 million.

The all-time top profiter is Alameda's market maker bot, which was suspended in September last year.

So what are these market maker bots doing to make the market? They are doing cross-domain arbitrage.

Cross-domain means two cases:

  • CEX<>DEX scenario: Take advantage of the price difference between CEX and DEX to arbitrage.

Among them, CEX<>DEX scenario dominates, for two progressive reasons:

  1. CEX is the fastest, while there is always a block delay in on-chain prices.

  2. Prices on CEX lead the order flow for optimal DEX.

In Hyper Oracle's vision, by the time of DeFi 3.0, all CEX will be actively or passively upgraded to DEX. The DeFi protocol has proven the need for decentralization in the wave of moving toward end-to-end trustlessness and security. It is only a matter of time and process before CEX is completely phased out. In the long run, CEX-leading prices will also be replaced by DEX-leading ones.

So, as an arbitrage bot between a CEX and a DEX, considering only trades between Binance and Ethereum, how much will be gained?

  • The ETH/USDC pair alone could have created $40 million of profits (Wintermute's bot, as we discussed made a total of about $90 million in about six months).

  • There are arbitrage opportunities in almost every block (Wintermute's bot, as we discussed made a move every 2 to 3 blocks on Ethereum).

In addition, there are two very interesting related arbitrage opportunities (or MEV): OEV (GMX mainly uses an oracle to reduce arbitrage. Still, an oracle itself also has arbitrage space) and JIT (a sandwich-like arbitrage, highly related with previous Uniswap LP analysis), which we will probably mention in another article later.

2. Join the Bot team

Great, if it's so lucrative, I want to set up a bot.

First of all, the threshold for building an arbitrage market maker bot is high, the following requirements need to be met to make it profitable:

So, what other Bots can we build?

In fact, there are only two steps to making a bot:

  1. Design and develop the bot's strategy.

  2. Run the bot.

a) Bot Design and Development

Bot's strategy design and development include several key elements:

  • What: the final triggered target function (may be your bot contract or the contract of the target protocol)

  • Where: The network where the final triggered function is deployed (may be highly correlated with the final revenue due to gas costs and network speed)

  • When: When to trigger (based on time / on-chain variables / off-chain calculation results...)

  • How: Combine the above elements to form a complete strategy

Several characteristics need to be met during the development of a bot:

  • Invisibility of the strategy (to prevent others from seeing your strategy and compete with you directly)

  • Simulation of trigger results (to ensure that the strategy is executed correctly)

  • Optimization of on-chain contracts (both in terms of overhead and speed, e.g., grim-reaper below is an extreme optimization of the most common liquidation bot type. There are always more optimizations to be made. Sometimes complex mathematical optimizations are involved.)

b) Bot Running

Usually, to run automation or bot services, we need the involvement of third-party services for these reasons:

  • Need to run much blockchain infrastructure (fast access to the global state, fast RPC provider or relayer to commit tx, subscribe to smart contract events, monitor mempool)

  • Requires the bot's own hosting environment (AWS, etc.)

The main pain points of running them are:

  • Too much blockchain infrastructure required

    If you just want to run a simple bot, but you have to set up a bunch of services along with it (nodes, indexing services, MEV relays…). If you use third-party services, you also have overhead issues, and the speed is not always sufficient.

  • Unstable and inflexible hosting environment

    To guarantee the uptime of an automation or a bot, the hosting environment needs to be stable. For example, MIP63 uses 4 different methods to rotate to ensure the stability and uptime of the keeper service. At the same time, in extreme cases, we may need to change the code on-the-fly, which requires the development friendliness and deployment speed of the hosting environment.

3. Hyper Oracle’s zkAutomation

Now, we are ready to introduce the ideal platform for automation/bot: Hyper Oracle's zkAutomation.

You can check out our latest zkAutomation Demo. It is a bot based on ETH price fluctuations, where the data source and trigger condition are entirely based on a user-defined programmable zkGraph.

With zkWASM and other zk circuits, zkAutomation can be used for any use case and scenario, including any automation/bot and keeper.

If you choose to join the bot world, zkAutomation's zkGraph ecosystem and tools can help you:

  • Define several elements of automation/bot (target functions) without code/command line

  • Easily define triggering conditions that are off the chain, and ensure that triggering is completely trustless and secure with zk

  • Implement fully end-to-end verifiable triggering across significant time intervals (Powered by zkPoS)

zkAutomation provides a hosted environment to help you with your automation/bot:

  • Eliminate the need to run additional infrastructure

  • 100% uptime and flexible changes under a decentralized network for each automation/bot

So your automation/bot has countless benefits and new scenarios with zkAutomation.

We are excited to see how developers will build end-to-end decentralized applications with zkAutomation and zkIndexing and map out the new era of DeFi 3.0 products in the future. Come build with us! We are happy to brainstorm and explore ideas together - let us know by filling out this interest form.

About Hyper Oracle

Hyper Oracle is a programmable zkOracle protocol that safeguards blockchain security and decentralization. From indexing to smart contract automation, its meta apps make on-chain data verifiable and secure with math as a consensus. Hyper Oracle empowers developers to interact with blockchain data in new ways.







Subscribe to ORA
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
This entry has been permanently stored onchain and signed by its creator.