Timed Token Approval - LSP7/8

[Heisenburgirs]

As you may have seen recent events concerning "NFTTrader's" old & exploited contract where hacker was able to withdraw Bored Apes, Mutant Apes among other NFTs from the holder's wallets with ease, simply because the holders gave "NFTTrader's" contract token approval since 2 years ago.

This triggered talks on X about ephemeral approvals, about which I wrote extensively on my X - https://twitter.com/heisenburgirrs/status/1736342440502603855

Session keys & vaults, as explained in the above thread, can be effective tools to better control who has approval on your tokens and for how long, but at the end I added:

You can also fix it natively by introducing timestamp to LSP7/LSP8, when approving you also provide deadline for approval.

This seems easiest solution to the problem, but then again you need to re-approve after some time

When approving a contract, in case of ERC20 you approve allowance amount - which can be limited or infinite - and in case of ERC721 you call "setApprovalForAll" which approves all NFTs held by you.

We can implement similar logic and check for the approval session. When transfer occurs we check if the session is active, this can be done by comparing current timestamp with timestamp set in the session struct and if it has surpassed the struct timestamp, it reverts, meaning session for the approval has expired.

Struct session { uint256 approvalTimestamp; // Timestamp of when approval happens uint256 approvalExpiryTimestamp; // Indefinite or specific, this is when approval expires }

Similarly to approval allowance, users can select either indefinite session or specify the time after which approval expires and transfer fails.

Again, this issue of indefinite approval for tokens can be fixed by using another contract as a middleman or using vaults to which the contract won't have approval for, but I think there's much easier way to allow users to set approval expiry and that is within LSP7/8 itself.

I'd like to hear what others have to say.

In my opinion, as outlined in my thread, it'd be best to implement approval expiry within token standards themselves. This will result in much better user and developer experience.

[xtc0r]

What about permit2? Just giving a timed approval is not a good UX.

[xtc0r]

These links have more technical information about permit2 https://github.com/dragonfly-xyz/useful-solidity-patterns/tree/main/patterns/permit2

https://github.com/dragonfly-xyz/useful-solidity-patterns/tree/main/patterns/erc20-permit

[xtc0r]

Reference implementation from open Zeppelin https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Permit.sol

[Heisenburgirs]

Looked a bit more into it and seems like Permit2 is using off-chain services to reduce gas costs.

What you could do - and I'm brainstorming on the fly - is add additional parameter to transferFrom, where it takes signed message. The signed message comes from user who wishes to let contract A transfer 100 tokens.

1. User calls function A on contract B, signing amount of tokens (allowance) and passing the signature
2. Contract B calls transferFrom and provides signature, token contract verifies if signature is valid and lets contract B use exactly the signed allowance amount

This effectively means you don't approve separately, you just pass in signed allowance amount to the contract and it can use that as a receipt to say "hey I'm allowed to spend this one-time allowance".

This is how you could theoretically implement one-time approvals, but you need to make sure the receipt is only used once, also user will need to sign and confirm transaction, which is bad UX.