Post-judge QA

[JeeberC4]

🧑‍⚖️ Post-judging QA; deadline 09/09/2022 09:00PM PST

1. Please post feedback about specific findings on the relevant issue in this repo.
2. More general feedback for the judge can be shared here.

The judge for this contest is @GalloDaSballo

Reminders

• Please keep your comments as fact-based as possible.
• C4 judges have final authority in determining validity and severity.
• You are welcome to start new discussions here!
• Please link to specific issues wherever relevant.

Thank you!

[IllIllI000]

@GalloDaSballo should #139 be combined with #176?

[GalloDaSballo]

Thank you for your observation.

My rationale is:
#176 talks about a specific issue with mint which will cause a permanent DOS of functionality for that specific token, which is contingent on a token that can revert and a setup that allows that.

TL;DR #176 is about a Revert for Mint

#139 is about the fact that a tx can be forwarded to a Axelar Chain contract, and the delay / revert / reliance on sorting may cause it to no longer be useful, and due to how the system is setup, no guarantee is in place for the tx to be fulfilled by X nor to be refunded.

My interpretation is #176 is about a specific DOS
#139 is about the inability to "back away" if a relayed tx becomes old (you're forced to pay it even if useless / broken / deprecated)

What are your thoughts?

[IllIllI000]

I did not dig deeply into this contest, so you probably know more about these issues than I do, but when I read through the two issues it seemed as though #139 mentions that it may be meaningless to redo, the appropriate method is to cancel the transaction and failing to be able to mint in #176 would fall into that category, essentially 139 is a bulking without listing every possible issue, of which 176 is one. Does the minting issue not break the transaction?

[GalloDaSballo]

My perspective as to why they are different is

• With Add cancel and refund option for Transaction Recovery #139 you're talking about txs you wanted forwarded via callContract

• With XC20Wrapper may lost received token forever if LocalAsset(xc20).mint is reverted indefinitely #176 you are talking about the specific mint function that is to be executed via executeWithToken

More specifically, #139 is about the loss of an opportunity and the inability to back out, e.g. call contract to trigger a swap, swap is arbed out, cannot cancel the swap

While #176 is about the technical risk of loss of an asset due to the code allowing a revert, e.g. I burned my tokens and they cannot be recouped as the tx reverts indefinitely

I think they are distinct in that sense

What do you think?

[IllIllI000]

there's also callContractWithToken - not sure if that fits both cases. In any case, I don't feel strongly about it either way, and it looks as though you've spent time looking into it and have logic behind the decision so that's good enough for me!

[GalloDaSballo]

Thank you, let me know if you find an alternative opinion!