You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you replace EFBFBD with any random byte (like "FF") - then you have a proper length ABI-Encoded custom error (with 4 bytes in the beginning, and 32+32 bytes two uints after).
I'm not sure where this replacement happens - on the Ethers side (in fetchJson they use toUTF8 encoding) or on Flashbots Relay side.
But if it happens on Ether's side - maybe we can use another connector?
The text was updated successfully, but these errors were encountered:
can confirm I am also facing this issue. Was struggling to understand why that is but this issue seems to be on point of my conclusion as well.
Can we bump this? It's pretty frustrating not being able to get the correct return bytes of a transaction and corrupt the result. Although I am pretty sure that's coming from the backend relay and its not an issue with this package
Unable to decode the revert error from Simulation (and probably from real txs too).
What I've noticed when I decode the revert string to HEX, is that it contains a lot of "EFBFBD" bytes:
"EFBFBD" is used as a standard UTF8 replacement bytes if the source byte cannot be encoded into UTF8:
https://blog.gdssecurity.com/labs/2015/2/18/when-efbfbd-and-friends-come-knocking-observations-of-byte-a.html
As you can see it couldn't encode 9C.
If you replace EFBFBD with any random byte (like "FF") - then you have a proper length ABI-Encoded custom error (with 4 bytes in the beginning, and 32+32 bytes two uints after).
I'm not sure where this replacement happens - on the Ethers side (in fetchJson they use toUTF8 encoding) or on Flashbots Relay side.
But if it happens on Ether's side - maybe we can use another connector?
The text was updated successfully, but these errors were encountered: