Instead of using the native currency, just use ERC-20 compliant tokens for the stakes. Using standards allows for greater interoperability.
However, this will greatly increase complexity inside the contract. It will require approve calls from the frontend (although, with Account Abstraction, they should be gone). It will incur heavier gas usage. It will generate edge cases. It will mean storing, per account, a balance per ERC-20, which, for some "deflationary" (burn % per transfer) tokens will mean reverts and issues. Will render testing and auditing much more difficult.
Lists must now store the ERC-20 token they are utilizing, and it can be updated. As Items cannot be challenged after a List update, Items shouldn't need to store the ERC-20 they're utilizing.
Disputes must store the ERC-20 that was being used at the time of the challenge, otherwise, an attacker can update the List's ERC-20 and drain the contract after rule.
greenlucid
commented
2 years ago
Instead of using the native currency, just use ERC-20 compliant tokens for the stakes. Using standards allows for greater interoperability.
However, this will greatly increase complexity inside the contract. It will require
approvecalls from the frontend (although, with Account Abstraction, they should be gone). It will incur heavier gas usage. It will generate edge cases. It will mean storing, per account, a balance per ERC-20, which, for some "deflationary" (burn % per transfer) tokens will mean reverts and issues. Will render testing and auditing much more difficult.Lists must now store the ERC-20 token they are utilizing, and it can be updated. As Items cannot be challenged after a List update, Items shouldn't need to store the ERC-20 they're utilizing. Disputes must store the ERC-20 that was being used at the time of the challenge, otherwise, an attacker can update the List's ERC-20 and drain the contract after
rule.