The Seal of Approval: Know What You’re Consenting To With Permissions and Approvals in MetaMask
Even if your experience interacting with blockchains like Ethereum is limited to sending simple transactions between wallets, you will have approved, authorized or signed your transaction. This simply means you’re confirming its submission to the blockchain.
This same process applies equally to interacting with dapps in Web3: there is plenty to consent to, approve, and permit. But what’s really in a MetaMask approval?
To break this question down, we’ll need to first cover some core aspects of cryptography.
Keys and cryptography: what is approval?
All of your crypto activity is based on public key cryptography. Essentially, each wallet has a matching public and private ‘key’ generated when the wallet is created. Imagine a door that requires you to unlock a bolt and turn a latch to enter, with a different key for each. Possessing a single key doesn’t get you anywhere – you need the pair.
Although an oversimplification, we can take the challenge of this hypothetical door and apply similar logic to your crypto wallet. Your private and public keys are both necessary to transact: the private key for you to demonstrate that you initiated the transaction, and the public key for the recipient to verify the origin. Here’s how it works:
- You decide to send tokens to a contact.
- As you know the recipient’s wallet address, you hold their public key – the former is simply a hashed (encrypted) version of the latter. The public key is used to encrypt the transaction.
- The recipient, holder of the private key, receives the transaction. Since their keys belong together, only the corresponding private key – which only they hold – can decrypt the transaction sent by their public key.
So far, so good: we’ve established how pairs of private and public keys interact to underpin blockchain transactions. However, to apply this knowledge to approvals/signatures, we flip the roles of the keys: instead, the sender encrypts the message with their private key. Since others can easily find out the sender’s public key (their wallet address), the keys can combine to decrypt the message, verifying the sender’s identity. Only a matching pair of keys will reveal the contents of the message, meaning no one can dispute the origin.
Imprinting a kind of signature on every transaction guarantees immutability, with nobody other than you – the holder of your private key – able to fraudulently imitate you.
This involves giving the dapp permission to retrieve your wallet address, and is a prerequisite for interacting with the platform. This also explains why you’ll see it referred to as “a permission” or “permissions”; nouns that describe exactly what you’re doing. In some cases, dapps prompt you to give permission automatically; others require you to click buttons labelled “connect” or similar.
Giving your permission will, in our case, look something like this:
Whether or not you’re an experienced crypto native or a total beginner, to interact with any smart contract – the kind that runs dapps (including DeFi, blockchain gaming, NFT purchases) – you need to approve its access to your tokens.
This process is variously referred to, somewhat unsurprisingly, as token approval. What you’re doing here is:
- Allowing the smart contract to access your token balance. Think of this as the ‘smart contract stage’. MetaMask will clearly indicate at this point how much access you’re ceding: some dapps may specify a finite quantity of tokens, whilst others request unlimited access.
- Confirming that you want to complete the transaction in question: i.e. the ‘blockchain stage’, where you allow the smart contract to submit the transaction to the network on your behalf.
Say you want to perform a token swap on Uniswap, the largest decentralized exchange (DEX) by trading volume. When you initiate a swap in a token pair for the first time, you will be asked to approve smart contracts for the ERC-20 token pair you’re trading (although not for ETH itself, which does not need approval). Whilst this only occurs the first time you trade that pair, the next step – i.e. step two above – will be required every time, and means Uniswap’s protocols will execute your trade on request.
This process will resemble the below:
- Firstly, you will be prompted by the platform to approve the token. Click on the prompt and MetaMask will spring into action.
- MetaMask will show you the token’s contract address, confirming that it is requesting the ability to access and move your funds around. For reassurance you’re permitting the correct contract, it’s worth cross-referencing the token address against that listed on the dapp’s website – it can usually be found in their help center, knowledge base or docs. You even have the option to specify how far you want this permission to go – to do this, hit ‘Edit Permission’.
- This option lets you see precisely how much access you’re allowing. In this case, Uniswap wants access to a virtually unlimited quantity of stETH (1.1659), but we can place a limit on this permission if required, using the ‘Custom Spend Limit’ field.
With this feature, MetaMask keeps you in control of your token approvals – you need never blindly permit a dapp to access more than you want it to, or take on unwanted risk for the sake of trying out a new platform.
The trade request itself is where your key pair comes in: you sign the transaction with your private key. Think of signing on the dotted line with a pen; although with public key cryptography, the risk of identity fraud is negligible. In our example, consenting means you have authorized a Uniswap smart contract to move that token to and from your wallet on your behalf. Each time you try and initiate a swap, the smart contract is able to check your ‘message’ – i.e. the instruction to perform the swap – and verify that you, as the only person with access to your private key, were the originator.
How can I manage approvals and permissions?
One of the hallmarks of Web3 is providing users with full control over privacy and how they interact with its platforms. MetaMask’s non-custodial design reflects this. However, its principles extend to other features; the ability to view and manage dapp and smart contract approvals is amongst them.
Viewing connected sites in MetaMask
MetaMask includes a native feature for reviewing which sites your wallet is connected to. It’s called ‘Connected sites’ (as you can probably tell, we don’t like to overcomplicate). Similarly straightforward is the method for removing them.
Viewing token approvals
Etherscan recently implemented a token approvals checker that lets you view and revoke, well… token approvals.
A list of token approvals is displayed once you connect MetaMask and give Etherscan permission to view your wallet – familiar? You are then free to check their ongoing relevance and revoke accordingly. Helpfully, you can also view the specific asset involved, who you’ve approved (e.g. which dapp, referenced by name), and the quantity of tokens you’ve approved access to.
Don’t get rekt
The personal agency that comes with managing a non-custodial wallet like MetaMask is a double-edged sword. Just as keeping your secret recovery phrase secure is your personal responsibility and requires vigilance against scammers, you’re the only one who can manage the dapp permissions and smart contract approvals. Couple this with how easy it is to create a new ERC-20 token – there are approximately 485,000 tokens at the time of writing – and the risks become highly apparent. Whilst most will be made in good faith, any could be created by a bad actor.
Token approvals are a relatively common attack vector for scams – just check rekt.news to get an impression of the scale, and this Finematics article for an impression of the methods. As mentioned earlier, dapps must specify how many tokens they want to access. MetaMask, for one, will ensure that this information is displayed on the approval screen before you confirm, giving you a clearer picture of exactly what you’re signing up for.
Access requests from dapps can vary from specific, limited quantities right through to being completely uncapped, where the smart contract can draw as much as it wants from your wallet. Fundamentally, unlimited access is not a problem or red flag in itself – many reputable platforms such as major DEXs do this in order to spare you the pain of frequently re-approving if you use the dapp regularly. The problem comes with dapps that request unlimited access to your token(s) with the express intention of stealing.
Before approving a smart contract’s access to any quantity of tokens, you should go through a mental checklist to assess risk. You’ll often see the acronym ‘DYOR’ mentioned online: doing your own research before allowing access is definitely a good habit to adopt. For example:
- How well-known is the project?
- How long has it been around?
- Does it have an active community channel on Discord, Telegram, or Twitter?
- Are the dapp’s developers/owners transparent and publicly reachable, e.g. on Twitter or Discord?
- Has it recently had a security breach? It’s worth searching here.
- Have they undergone a third-party smart contract audit?
- Check the contract address on the block explorer. Some explorers, such as Etherscan, have a user-driven reporting mechanism where fraudulent addresses (contracts or wallets) are flagged. Even if they aren’t flagged, check for suspicious activity, such as large inflows or outflows of cash in short time periods.
Rather than just a token gesture indicating consent, token approvals are a mundane, essential aspect of interacting with Web3. Some key points:
- Public key cryptography is used to authenticate your permissions when interacting with dapps.
- Dapp permissions involve allowing dapps to view your wallet balance.
- Token approvals involve permitting a dapp’s smart contract to access and move a specific token in your wallet.
- Always research the dapp’s credentials and satisfy yourself that it’s trustworthy before approving its smart contract.