Zeneth

With Flashbots, users can send transactions directly to miners so their transactions may be included in a block without ever being seen in the mempool. Miners typically include your transaction in a block because they earn revenue from gas fees, but with flashbots you can include transactions with a gas price of zero, as long as you also include a transaction that pays the miner in ETH in some way.

This is commonly used to protect yourself from bots. For example, by making a large Uniswap trade or executing an arbitrage via Flashbots, bots cannot see your transaction and frontrun it.

Zeneth uses Flashbots for a different reason—improving UX.

A major UX problem in Ethereum is that most wallets are not contract wallets, but externally owned accounts (EOAs), such as MetaMask. With EOAs, you always need ETH for gas unless you happen to be interacting with a contract that supports meta-transactions. This can be problematic for user-facing applications as their new users need to acquire both ETH and often some token to user their application. For example, you don't need ETH for transaction fees on zkSync, but if I'm a new user trying to get DAI into zkSync, I need to first find ETH, use that to pay for gas to enter zkSync, then never use that ETH again. This adds a lot of friction to user onboarding.

Zeneth fixes this. You can now bundle any sequence of transactions, send them for zero gas, and at the end use our "SwapBriber" contract which will swap some of your tokens for ETH to pay the miner. In the demo video you can see the following sequence of transactions:

1. User signs a zero-gas price transaction approving the zkSync contract to spend their DAI (https://etherscan.io/tx/0x5bcf4ce03c6c1ec442f5572d857c37991143a481d7be52c5400231f8587a4e17)
2. User signs a zero-gas price transaction depositing their DAI into zkSync (https://etherscan.io/tx/0x3df79d261af35c6b9bf7a69c3ee1be9a5f7d558cd19595acac761e0bd10cb629)
3. User signs a zero-gas price transaction approving the SwapBriber contract to spend their DAI (https://etherscan.io/tx/0x29f2507ca6bd010cbafbc863078d90ce8e79ad2d2288b44927125c50454c8d07)
4. User signs a zero-gas price transaction transferring tokens to the SwapBriber contract, which swaps those tokens for ETH and transfers the ETH to the miner (https://etherscan.io/tx/0x90f16b53efde82ad4cb3eed92c43bb8bf234b6009d1d24a8ec51c4be5052dd7f)

Then, all four of these transactions are sent as a bundle to the miner, who includes them in a block.

Zeneth has three main components. The first is the SwapBriber contract which does one main thing—transfers tokens from a user, swaps them for ETH, and send the ETH to the miner. This is intended to be used as the final transaction in the bundle. The contracts were written using Solidity 0.8.4 and Hardhat.

The second component is zeneth-js, our library to simplify creating and sending flashbots transactions. This is used by the frontend to generate and send bundles. It asks the frontend to provide just the data, gasLimit, to, and value for each transaction, along with the sender's address, and it handles nonce management and signing prompts.

Ideally, transaction signing in zeneth-js would be done with eth_signTransaction, but MetaMask does not support this, so we had do some hacky things to get users to sign transactions with eth_sign. This is both dangerous for users and bad UX, so hopefully MetaMask adds eth_signTransaction support soon. In the meantime, you can checkout the signBundle method if you're curious to learn more about this step. zeneth-js was built with ethers, and is mainly a wrapper around the @flashbots/ethers-provider-bundle package to simplify usage.

The final component is the frontend. This helps the user prepare their transactions, then delegates to zeneth-js to handle the signing. Flashbots works by sending your transaction bundle to their endpoint, but it does not support CORS, meaning our frontend website could not dispatch the bundle. We worked around this by setting up a dead-simple server in the middle. The frontend will send the bundle to the server, and the server routes it to Flashbots. The frontend was built with React and Next.js, and routes to an Express server