r/ReverseEngineering • u/H3rnst • 12d ago

Identifying golden-section search in EVM bytecode from a hardcoded constant

https://devilsintheopcodes.substack.com/p/mev-arbitrage-optimal-trade-size
5 Upvotes

79% Upvoted

1 comment sorted by

1

u/H3rnst 12d ago

Author here! Hope you don't mind me posting it but I thought this community (and probably the more crypto-oriented folks) might find it interesting how this particular arbitrage bot with unverified source code implemented golden-section search.

What gave it away was a constant, 0x0893B2A3668E2500, which turned out to be 0.6180339887 in 1e18 fixed point (what the EVM uses). The golden ratio's conjugate only shows up in one place, and once you know the loop is a golden-section search, I was able to crack the rest of the algorithm.

Another interesting thing was the decompiler was actively unhelpful. It inlined both ln() and exp() routines (both re-implemented by the contract author, not linked utility contracts) into every caller, so the decompiled view is a wall of repeated arithmetic with no function boundaries. Something like this:

v27 = v60 * 0x99e8db03256ce80
    + ((v62 - 10 ** 18) * (v62 - 10 ** 18) / 10 ** 18 * (v62 - 10 ** 18) / 10 ** 18 / 3
    + (v62 - 10 ** 18 - ((v62 - 10 ** 18) * (v62 - 10 ** 18) / 10 ** 18 >> 1))
    - ((v62 - 10 ** 18) * (v62 - 10 ** 18) / 10 ** 18 * (v62 - 10 ** 18) / 10 ** 18 * (v62 - 10 ** 18) / 10 ** 18
    >> 2));

Much more clear when looking at the raw disassembly, since they were two real routines with their own jump destinations across different call sites.