Thread by @FishingKrab

How is one of the top sandwichers on BSC saving more gas without using the Chi gastoken?

A thread 🧵 1/n

2/n: For a project (long tail MEV strat) at Project Blanc, I’ve been doing some analysis on how big players win PGA. During the research, I found a pretty interesting tx: bscscan.com/tx/0xb1e64c667…

3/n: When bots are doing PGA, they can only raise there gas price up to the point where gasPrice*gasConsummed > profit. If they see someone going abovethis limit (because they found a better input that grabs more profit), they cancel the tx to limit their cost as much as possible

4/n: The most common way to cancel a transaction is to replace it with a transaction that has a higher gas price that sends 0 wei to itself. This method consumes 21k gas. So what about the tx we found ? It uses 13,697 gas ! It’s a 34% reduction. So what’s the trick ?

5/n: A common trick is to use gas tokens like CHI. A gas token uses the trick of calling SELFDESTRUCT on a contract which reimburses you for “cleaning” the chain.

6/n: But on this tx we can’t see any CHI transfer so it may be some custom gas token. After doing the extraction of the bytecode at one of the contracts destroyed by this bot, we can see a few things

7/n: Custom bot’s bytecode: 0x3360701c60db18585733ff
Chi’s bytecode: 0x6eb3f879cb30fe243b4dfee438691c043318585733ff
That’s a lot of saving ! But how are they achieving that ? Let’s decompile Chi’s bytecode into assembly to get a better understanding

8/n: I’m not going to explain exactly how this is working (there is way better explanation here blog.openzeppelin.com/gst2-bytecode-…) but the idea is to check if the caller is the CHI token contract and if so, do a selfdestruct.

9/n: Doing this check requires having the address (or a part of it) in the contract’s code. That is the
“b3F879cb30FE243b4Dfee438691c04” part in 0x6eb3f879cb30fe243b4dfee438691c043318585733ff.

10/n: So how is this bot saving more gas ? Let’s decompile its bytecode into assembly too. For context, the bot's contract address is 0x0000000000DBa7f30bA877D1D66e5324858B1278

11/n: As we can see, the contract address has 10 leading zeros followed by “db”. Mining an address like this takes some time (we will dive into this too). So instead of checking the full address, why not just check if the caller has 10 leading zeros followed by “db” ?

12/n: That’s what is done here. Lines 1, 2 and 3 just take the caller address, move it right 7 bytes ( = moving the string 28 characters to the right) and compare it to 0xdb

13/n: Does this mean that I can use this bot’s gas contract if I have an address with 10 leading zeros followed by “db” ? Technically yes, but you don’t want to. It is possible to mine he address with some software like this one github.com/johguse/ERADIC….

14/n: This is a fork of github.com/johguse/profan…. The table in the README gives us some numbers. A GTX 1070 does around 179.0 MH/s. To find a corresponding address, we need to compute 281,474,976,710,655 combinations. That’s around 18 days of computation.

15/n: Generating a new address with 10 leading zeros (without caring about the “db” at the end) is 1,099,511,627,775 combinations, so around ~1h40mn.

16/n: This is where this bot is genius: he mints just enough gas contracts so it is not economically interesting to waste some computation to steal them !

17/n: It is still possible to mine the right address just to bother the bot operator but he would only need to add one or two more leading zeros to his contract to be uncrackable

18/n: So this is how some genius bots save more gas with custom contracts. That’s all for today, I may do another thread next week on how he is re-initializing his contract while keeping the same address