3 ms·
So these traders didn't fully "parse" the meaning of the token, and are just assuming it's some kind of "standard"/"patterned" trade that they are used to? Som
by kzrdude 6y ago
So these traders didn't fully "parse" the meaning of the token, and are just assuming it's some kind of "standard"/"patterned" trade that they are used to?
Somehow the real details of the transaction must be machine readable and parseable if they bother.
- skybrian 6y agoThe sandwich traders didn’t decompile the contract before calling it and instead assumed it’s like all the others, based on pattern-matching I assume. This is sort of like signing a contract without reading it. I suppose simulating what the call would do using a trial run would also work?
- SilasX 6y agoRight, don't traders have everything necessary to run the smartcontract locally (i.e. via Ethereum's virtual machine), with the input they expect it to have at the time of execution? That doesn't require decompiling, any more than I have to decompile a calculator app to verify that it gets the right answer for 2+4. If so, then yeah, sometimes judges do throw out deceptive contracts based on "gotcha" clauses with non-obvious implications the counterparty couldn't have reasonably expected. But here, it would be like if the signer had continuous access to a resource that would instantly answer any implication about any scenario they had in mind, and the signer refused to test it for even one scenario they were planning to use the contract for. I image judges being a lot less sympathetic to that kind of mistake.
- gbrits 6y agoThe deception works because the sandwich-traders are generalizing their code to 'work' for all kinds of contracts. This with the intent to just about frontrun anything that matches their pretty broad criteria. Since there's likely multiple predators operating, only the fastest one wins. This doesn't leave time to test individual contracts out locally. Or so the rationale most likely goes