Spender can front-run calls to modify token allowances, resulting in DoS and/or spending more than was intended
When updating the allowance for a spender that is less than the value currently set, a well-known race condition allows the spender to spend more than the caller intended by front-running the transaction that performs this update. Due to the nature of the `ERC20::approve` implementation and other variants used within the Beanstalk system, which update the mapping in storage corresponding to the given allowance, the spender can spend both the existing allowance plus any 'additional' allowance set by the in-flight transaction.\\nFor example, consider the scenario:\\nAlice approves Bob 100 tokens.\\nAlice later decides to decrease this to 50.\\nBob sees this transaction in the mempool and front-runs, spending his 100 token allowance.\\nAlice's transaction executes, and Bob's allowance is updated to 50.\\nBob can now spend an additional 50 tokens, resulting in a total of 150 rather than the maximum of 50 as intended by Alice.\\nSpecific functions named `decreaseTokenAllowance`, intended to decrease approvals for a token spender, have been introduced to both the `TokenFacet` and the `ApprovalFacet`. `PodTransfer::decrementAllowancePods` similarly exists for the Pod Marketplace.\\nThe issue, however, with these functions is that they are still susceptible to front-running in the sense that a malicious spender could force their execution to revert, violating the intention of the caller to decrease their allowance as they continue to spend that which is currently set. Rather than simply setting the allowance to zero if the caller passes an amount to subtract that is larger than the current allowance, these functions halt execution and revert. This is due to the following line of shared logic:\\n```\\nrequire(\\n    currentAllowance >= subtractedValue,\\n    "Silo: decreased allowance below zero"\\n);\\n```\\n\\nConsider the following scenario:\\nAlice approves Bob 100 tokens.\\nAlice later decides to decrease this to 50.\\nBob sees this transaction in the mempool and front-runs, spending 60 of his 100 token allowance.\\nAlice's transaction executes, but reverts given Bob's allowance is now 40.\\nBob can now spend the remaining 40 tokens, resulting in a total of 100 rather than the decreased amount of 50 as intended by Alice.\\nOf course, in this scenario, Bob could have just as easily front-run Alice's transaction and spent his entire existing allowance; however, the fact that he is able to perform a denial-of-service attack results in a degraded user experience. Similar to setting maximum approvals, these functions should handle maximum approval revocations to mitigate against this issue.
Set the allowance to zero if the intended subtracted value exceeds the current allowance.\\n\\clearpage
Requiring that the intended subtracted allowance does not exceed the current allowance results in a degraded user experience and, more significantly, their loss of funds due to a different route to the same approval front-running attack vector.
```\\nrequire(\\n    currentAllowance >= subtractedValue,\\n    "Silo: decreased allowance below zero"\\n);\\n```\\n