Audit reference: [FIL-1132b525-L03]
There is an annoying griefing vector where the publiclly accessible EIP 2612 permit transmitted in a message to the network can be applied by a griefing 3rd party to credit the payments contract with the permitted allowance before the users' intended message lands on the contract. Because we don't try catch the permitting function this will cause an annoying failure for the user's message forcing them to go back and deposit with the unpermitted version.
To be clear the user gets exactly what they want in the griefing scenario from POV of system state. However they have to do an annoying UX retry because payments contract isn't smart enough to handle it for them. We should go with audit recommendation
Wrap the permit call in a try-catch block to handle permit failures gracefully. If the permit fails, check the approval. If approval is sufficient, proceed with the deposit.
Audit reference:
[FIL-1132b525-L03]There is an annoying griefing vector where the publiclly accessible EIP 2612 permit transmitted in a message to the network can be applied by a griefing 3rd party to credit the payments contract with the permitted allowance before the users' intended message lands on the contract. Because we don't try catch the permitting function this will cause an annoying failure for the user's message forcing them to go back and deposit with the unpermitted version.
To be clear the user gets exactly what they want in the griefing scenario from POV of system state. However they have to do an annoying UX retry because payments contract isn't smart enough to handle it for them. We should go with audit recommendation