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:

• The minimum granularity of time in a blockchain is 1 block, not 1 second, and the criteria for measuring the length of 1 block varies across networks (length of time / whether fixed).

• The way the "now" in time is determined in a blockchain depends on the network mechanism, such as the longest chain rule.

• Time in a blockchain can be constantly reversed, even future events can change the past. The difficulty of time travel varies from networks. We also have a "Groundhog's Day"-like test network, which is dedicated to periodically returning to the genesis. We even have rollup with built-in ticking automation.

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.

• DeFi = Bots + AMM

  Uniswap, as a permissionless neutral protocol, is based on x * y = z quotes without influence, constantly shifting up the curve and back down again. Uniswap itself is a manifestation of automation, where arbitrageurs and traders work together to maintain equilibrium at all times. At this point, bots can be considered primarily positive rather than negative for the agreement because the effect of keeping prices "stable" is achieved.

• DeFi = Pools

  Pools are a way to make the blockchain more decentralized. Mining pools, liquidity pools, and lending pools are all pools to aggregate orders together. This is due to technical and performance limitations, but it also allows liquidity-poor DeFi to maximize capital efficiency because the funds in a pool can flow anywhere without restriction.

• DeFi = Better Network

  The presence of bots makes validators more profitable (most of the revenue from bots for AMM is distributed to block nodes). As a result, the higher income attracts more nodes, and the network becomes more diverse and secure.

But the presence of these Bots does pose a problem:

• Bots are still taking profits from users

  Due to dominant toxic order flow and block latency, bots can naturally extract revenue from users' actions. This contradicts the previous idea that DeFi = Bots + AMM, which has many advantages but is still not as good as a CEX in some aspects (Curve can do 80% as well as Jump, and that's enough ).

• Bots may be taking profits from retail LPs

  Through the analysis of 0x94305, 0xShitTrader, and thiccythot_ and official Uniswap research, we have found that the ordinary users who are LPs may be the ones being harvested by bots. There are three types of trading composition, depending on the volume of each transaction from slight to significant (the last two increase significantly in extreme markets): ordinary user trades, bot trades, and hacker trades. The average user is good and can provide positive returns for an LP; the hacker is also generous in this respect, ultimately price insensitive, and only wants to get out quickly, so an LP can make a lot of money from this trade. Still, the bots will be thinking hard about how to make a profit, which harms LPs (although this kind is only 15% of the trades). We recommend reading the analysis of DeFi researchers in this paragraph in depth.

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:

• Cross-chain scenario: Exploit the price difference between different blockchains to arbitrage.

• 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:

• Availability of large amounts of assets on and off the chain

• Infra and CEX API for super-fast data access

• Excellent risk control capabilities

• Scenarios are limited to "slow" blockchains like Ethereum

So, what other Bots can we build?

• Various MEV Bots (DEX Sniping, CEX Sniping…)

• MEV Bot Sniper Bot (Turtle Soup strategy in MEV world)

• Hacker Sniper Bot

• DeFi Liquidation Keeper Bot

• Various Keeper Bots (V2 TWAP Oracle Update)

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.

LinkTree: https://linktr.ee/hyperoracle

Website: https://www.hyperoracle.io/

Twitter: https://twitter.com/hyperoracle

Discord: https://discord.gg/MgyYbW9dQj

Blog: https://mirror.xyz/hyperoracleblog.eth

GitHub: https://github.com/hyperoracle