Authentication Witness
Authentication Witness is a scheme for authenticating actions on Aztec, so users can allow third-parties (eg protocols or other users) to execute an action on their behalf.
Background
When building DeFi or other smart contracts, it is often desired to interact with other contracts to execute some action on behalf of the user. For example, when you want to deposit funds into a lending protocol, the protocol wants to perform a transfer of ERC20 tokens from the user's account to the protocol's account.
In the EVM world, this is often accomplished by having the user approve
the protocol to transfer funds from their account, and then calling a deposit
function on it afterwards.
This flow makes it rather simple for the application developer to implement the deposit function, but does not come without its downsides.
One main downside, which births a bunch of other issues, is that the user needs to send two transactions to make the deposit - first the approve
and then the deposit
.
To limit the annoyance for return-users, some front-ends will use the approve
function with an infinite amount, which means that the user will only have to sign the approve
transaction once, and every future deposit
will then use some of that "allowance" to transfer funds from the user's account to the protocol's account.
This can lead to a series of issues though, eg:
- The user is not aware of how much they have allowed the protocol to transfer.
- The protocol can transfer funds from the user's account at any time. This means that if the protocol is rugged or exploited, it can transfer funds from the user's account without the user having to sign any transaction. This is especially an issue if the protocol is upgradable, as it could be made to steal the user's approved funds at any time in the future.
To avoid this, many protocols implement the permit
flow, which uses a meta-transaction to let the user sign the approval off-chain, and pass it as an input to the deposit
function, that way the user only has to send one transaction to make the deposit.
This is a great improvement to infinite approvals, but still has its own sets of issues. For example, if the user is using a smart-contract wallet (such as Argent or Gnosis Safe), they will not be able to sign the permit message since the usual signature validation does not work well with contracts. EIP-1271 was proposed to give contracts a way to emulate this, but it is not widely adopted.
Separately, the message that the user signs can seem opaque to the user and they might not understand what they are signing. This is generally an issue with approve
as well.
All of these issues have been discussed in the community for a while, and there are many proposals to solve them. However, none of them have been widely adopted - ERC20 is so commonly used and changing a standard is hard.