Ad Hoc Solution.MD

I have to start by saying that a priori, any decision made in a different platform requires a higher degree of scrutiny and should be rejected at face value, until further digested.

Over time, via the same fallacy, people have argued that some findings were Medium, because OpenZeppelin filed them as Med, completely ignoring the different Taxonomy that C4 uses (High, Med, Low), vs the OpenZeppeling Taxonomy of (Critical, High, Med, Low, Informational)

Similar reasoning for Immunefi which would most of the time classify a Loss of Yield as High, while we have historically downgraded to Medium as leak of value vs loss of principal.

That said, the argument uses the same logical fallacy that is trying to use as a way to attack the system

First of all Leak of Value has to be defined from the perspective of:

• The System
• A User using the system as intended

In this context the system leaks no value since it has no value to leak, both to it's own perspective as well as to the perspective of the user

The claim of an airdrop is given away and can be regained only once the DT token is burned, that is not changed.

In terms of the User, the user is leaking their value, due to misusing the system, they created a token to grant powers and for a reason that I can only rationally argue as self-rekt they decided not to claim the token back.

Accepting this issue is intellectually equivalent to saying:

• Using UniV2 in any way is a Medium Severity because it's mathematically inferior to Cowswap or similar
• Using UniV3 is a Medium Severity because all but 1 tick combination is optimal

These are arguments that you'd be hard-pressed to take the opposite side on

In a similar way the system is built in this way, you state that that can cause issues to the people using it I agree, but the pre-requisite is the owner not claiming their tokens back Since the end-user choses to use the system, then we must agree that they understand that they have to rescind the token to regain exclusive rights of the underlying

Them not doing it is then a self-rekt

Ape Attack

Quoting the very article you mentioned: https://www.theblock.co/post/138410/someone-borrowed-5-bored-apes-to-claim-1-1-million-of-ape-tokens#:~:text=%22We%20think%20it%27s%20an%20attack%20as%20the%20airdrop%20mechanism%20has%20a%20vulnerability.%20The%20airdrop%20claim%20depended%20on%20the%20spot%20state%2C%20whether%20a%20user%20held%20the%20NFT%20at%20that%20time%20of%20claim%20and%20the%20attacker%20exploited%20this%20vulnerability%20to%20profit%2C%22%20a%20spokesperson%20from%20BlockSec%20said.

The actual vulnerability, as agreed by The Block mind you, non-technical individuals, quoting BlockSec is not in the Tokens nor the ability to Flashloan them, but in the Claim Contract which allowed for Spot claims instead of requiring a "balanceAt"

The leak of value would be in the Airdrop Contract, and since the airdrop contract exists only for that purpose, then the Airdrop Contract has a High Severity Vulnerability

But you can't blame the vulnerability on this system

This system defends itself by allowing rescinding after X time If you don't rescind in-spite of the fact that you can, that's a gotcha not a leak of value

### Your arguments

• Although the rescind() function is permissionless, there is no incentive for anyone to do so. By your own admission the incentive is claiming the airdrop, so the incentive is obvious

• Neither the documentation nor the code demonstrate any plans for keepers to actively monitor delegated tokens and trigger "rescind()" after expiration. Just like any discussion on timelocks, etc.. the fact that such a contract is not here doesn't imply that it doesn't exist Similar arguments have been done on Core vs Periphery contracts, the non-existance of a Router doesn't imply the leak of value

• Why bother setting up keepers, which could be costly, when a simple check could solve the problem? Agree, which is why the finding is not closed but downgraded to QA

Crux of the Argument

The argument boils down to saying that the duration of the DT is greater than what's stated since the owner needs to rescind

To which I agree but claim that it is not a vulnerability, but a gotcha of the implementation

### Counter Argument

The fallacy mentioned was "ad-hoc-rescue", the fallacy I claim the finding to have is "ad-hoc-issue" the issue is in an integrator and they must perform those checks

There are many underlying reasons as to why claiming spot is an issue, and claiming that the implementation in the code in-scope is the root cause is inaccurate to the facts that all spot-claiming can be manipulated and the current issue