This is a follow-on to #10. As of that fix, we take into account the transaction position for the open candidate, but not for the close candidate. As a result, if there are multiple open candidates for a target, when looking for a close candidate for the second open, we could end up selecting the first open, resulting in a fake sandwich (with the oddity of having open after close).
This can be observed with:
node dist/scripts/search.js --from 12343644 --to 12343645 search 0x3328f5f2cEcAF00a2443082B657CedEAf70b fAEf which pulls out a fake sandwich around this tx with this open (position 199) and this close (position 3).
This is a follow-on to #10. As of that fix, we take into account the transaction position for the open candidate, but not for the close candidate. As a result, if there are multiple open candidates for a target, when looking for a close candidate for the second open, we could end up selecting the first open, resulting in a fake sandwich (with the oddity of having open after close).
This can be observed with:
node dist/scripts/search.js --from 12343644 --to 12343645 search 0x3328f5f2cEcAF00a2443082B657CedEAf70b fAEf
which pulls out a fake sandwich around this tx with this open (position 199) and this close (position 3).