Honeypot contracts: can APR repair them?

[Mokita-J]

APR for vulnerable smart contracts aims to fix the contract to mitigate its vulnerability.
It is implicitly assumed that the contract is the victim and an attacker can exploit it.
Thus, automatically repairing the victim contract benefits the contract and not the attacker.

Enter honeypot contracts. A honeypot contract is a malicious contract that entices participants with the prospect of substantial rewards.
Usually, this contract's source code is public but it contains some misleading logic that tricks the participant into thinking that calling this contract is an easy grab of ether.
In reality, there's always a catch and the participants lose their ether instead of gaining more.
Thus, in this context, the contract itself is the attacker, and the participants are the victims.

The techniques used in honeypot contracts are similar to other frequent vulnerabilities present in vulnerable contracts.
E.g. uninitialized storage, reentrancy, etc.
Popular smart contract vulnerability benchmarks like smartbugs-curated consider honeypot contracts "vulnerable", they are included in their dataset.

The question is: by applying APR to honeypot contracts are we no longer benefiting contracts but rather its callers?
In practice, the attacker would not repair its honeypot contract. So should we even have these contracts in datasets?

[monperrus]

Surprisingly some literature on this topic: https://scholar.google.se/scholar?hl=sv&as_sdt=0%2C5&q=honeypot+smart+contract&btnG=

[Mokita-J]

8/10 papers on the first results page are honeypot detection tools.
Scam contract detection seems to share similar heuristics with Vulnerable contract detection.

[Mokita-J]

For RepairComp we will not consider honeypot contracts as vulnerable.