Gas optimizing proxy for DeFi apps which utilizes a custom Balancer pool+OpenGSN paymaster as a treasury


Created At


Project Description

Rising gas prices have been an increasing issue with Ethereum this year. Thankfully, L2 ethereum/optimistic rollups are on the horizon, but there are still some shortcomings, such as onboarding, migration of existing apps, and movement of funds/data. from one L2 solution to another. We need a more immediate solution. Something simpler that can be deployed to mainnet today and can be immediately integrated into existing DApps.

As of today (Oct 20th), Etherscan gas tracker records the largest gas users to be "Uniswap Router V2", "Tether USD Stablecoin", and "USD Coin". These three coins all have one thing in common: they execute many "small" transactions which could, with a little optimization, actually be much cheaper if some system were to batch many users who are doing the same thing together in some way. Every transaction has at least 21000 of gas overhead just to run separate transactions, plus whatever additional is required to run repeated calculations which could be optimized together at the expense of slippage (in the case of Uniswap).

Crescendo attempts to solve this problem by allowing users to submit a single approve transaction which not only approves Crescendo to spend coins, but also embeds data in the higher order bits of the allowance u256 which are used to process a predefined action. Using this data, Crescendo contract will combine the approvals of many users together and offer a reward to a transaction "minter", targeting profitability for a miner at around 10 minutes. The transaction minter listens on the blockchain for "Approve" events targeted towards the Crescendo contract, and includes the addresses in the exec transaction for when its good to run.

Crescendo only requires clients to use a single approval transaction to do everything that it does, and it has the potential to greatly reduce transaction costs for smaller, more casual investors. By targeting Uniswap and ERC20 token transactions, Crescendo effectively reduces the overall gas cost of the largest protocols running on Ethereum, meaning Crescendo is not just good for its users, but the Ethereum Ecosystem as whole.

Logo icon made by Smashicons from

How it's Made

In order for Crescendo to repay transaction minters and accept fees from client users, it must maintain a pool of funds for WETH and any other cryptocurrencies it transacts with. This is solved by creating a Treasury contract utilizing a Balancer ConfigurableRightsPool. The trading fee is 0.000001 (as low as balancer allows) since liquidity providers don't need to be incentivized to provide funds to the pool, so it could be an interesting experiment in 0 fee trading. Additionally, the Treasury contract implements the IPaymaster interface for OpenGSN. Crescendo does not directly use the paymaster interface since it does not fit well with the batching model, but it would be useful for cases where fees are accepted in one cryptocurrency but must pay miners in ETH. The Balancer pool provides an effective automatic bridge for that, so that the funds are converted by arbitragers.

2 implementations of Crescendo have already been completed for the Hackathon: an ERC20 transfer proxy, and an Uniswap batching proxy. Transfers are already fairly optimal, but the overhead of the 21000 gas for the transaction accounts for almost half the transaction gas expendature, so a well optimized transaction batcher can reduce overall gas usage for 10+ transactions vs. having the transactions each running separately. It was not the originally considered use for Crescendo, but it demonstrates how even very efficient transactions can be optimized For Uniswap, many trades being executed in the same direction can be combined into a single uniswap call at the expense of slippage, greatly reducing gas overhead. The CrecUniswap strategy is expected to be cheaper gas expense when batching 3-4 transactions together, at the expense of slippage since the transaction cannot be run immediately and larger trade is occuring at once.

Crescendo started as an experiment to see if transaction batching could be effective and simple enough to be usable before L2 becomes more capable, and so far, that seems to be the case. I am suprised at how well it has turned out so far.

background image mobile

Join the mailing list

Get the latest news and updates