Permits are a fascinating function when it comes to blockchain transactions. Unfortunately this is an edge case where not much documentation is available, usually just a bunch of code and high level documentation. This article is a breakdown of the Permit function, use cases in projects that implemented this function, idea on how Permits could work with NFTs.
Permits
Permits are messages (wallet pop ups) which in the most cases are being used as token approval messages and meta transactions. Like approvals, Permits allow a third party to transact with your assets. Users create a signature that permits 3rd parties to move their tokens within certain constraints. Permits can allow a contract to use a user’s token without the user first needing to first send an approve transaction.
Permits ELI5
Permits are permissions that send the approval transaction to allow dApp to use and spend your tokens.
Example: Uniswap asks you for using DAI in order to swap DAI for some other token.
Permits as Approval messages
The best way to understand Permits is to take a look at how sending Approval transaction look like with and without the Permit function.
Signing a non-Permit transaction when dApp requires token approval:
- User submits transaction which will approve tokens to be used via dApp.
- Wait for transaction confirmation. User pays gas fee for this transaction
- User submits a second transaction for which the user pays gas.
In this case two transactions with gas (transaction fee) are needed for the on-chain operation to happen.
Signing transaction using Permit function for token approval:
- User signs the signature — via Permit message which will sign the approve function.
- User submits signature. This signature does not require any gas — transaction fee.
- User submits transaction for which the user pays gas, this transaction sends tokens.
In this case token approval will be executed via Permits as a signed message which is free compared to transactions that we would need to make in the first step. For code snippets and more technical overview head over to the ERC-20 Permit article by Markus Waas.
Standards
Right now there is only an ERC for Permit functions in ERC20 tokens. It builds on a different ERC, and there are already new ERCs incorporating it. Let’s take a look at the main ERCs involved in the Permit function.
EIP-2612
The Permit function is standardised as “EIP-2612: permit — 712-signed approvals”, usually it is being used and referenced as ERC712. This EIP defines a smart contract interface.
EIP-712
The “EIP-712: Ethereum typed structured data hashing and signing” can be used as a standalone EIP, it defines a format for signatures. This is the most used Permit standard.
EIP-3009
The “EIP-3009: Transfer With Authorization” enables token transfer via signed authorization, atomic interactions with ERC20 tokens using EIP-712 typed message signing specification.
Use cases
Permits are usually being used for unlocking ERC20 tokens from users’ wallets, which were used for trade or deposit tokens and for meta transactions (I’m not aware of any other functions). As an Ethereum user you may have interacted with Permit if you swapped tokens on Uniswap, or any other DeFi project, I’m not aware of any DAOs using Permits yet.
Implementation use cases
Just to name a few examples:
- The DAI Permit by Maker is the OG implementation of Permits as meta functionality of DAI
- Uniswap is using Permits as meta transactions via ERC712
- xDai staking token
- David Mihal made nice implementation of Permits which is being used by a couple of projects.
Permits and NFTs
We are playing with the idea of using Permits alongside with NFTs. Initially this idea was framed as a security improvement due to ownership transfer but now see it as more of a case of cheaper transactions and UX improvement. Usually an artist must transfer their NFT to an escrow contract for it to be auctioned, and the marketplace possesses the NFT for the duration of the auction. Using Permit the artist can retain ownership of the NFT during the auction, with the marketplace transferring it out afterwards
The idea of using Permits with NFTs is to improve UX when minting NFTs using marketplaces for listing by removing the need to perform an extra transaction, especially in the context of an escrow-less sale where the seller wants to keep ownership until the sale is performed.
The message that the Permit will sign will be the actual sell offer, which will be sent to the marketplace to list the NFT (alongside with the metadata). Buyer will sign the message from the creator and will make a transaction to purchase the NFT. This way the marketplace won’t own the NFT. The ownership will be transferred after the NFT is sold.
How it could work
- Creator will mint the NFT by signing the message with metadata and sales details included.
- The buyer will grab the message that incorporates the ownership (Approval) function and will make a transaction to purchase the NFT.
There are many iterations of how this idea can be played out. The actual implementation may turn out differently, we are exploring the options for Permits, unfortunately there is not much documentation on how to tackle this problem. Please share your ideas if you have something in mind how this idea can play out.
Get involved
We are working on implementation of this standard despite the fact of functioning implementation there is no motivation on the All Core Dev’s side to push this standard forward into “Final” status. This standard can be widely implemented if the marketplaces and wallets will agree upon implementing this standard. There is ongoing work on the implementation of this standard, if you are interested to work on making the NFT Permits standard happen, join the NFT Standards group and introduce yourself.
If you are involved with a marketplace or wallet and would love to work on the implementation of this standard, have ideas on how Permits could work with NFTs, I would love to chat with you!
Links:
Consider making donation to Ethereum Magicians Gitcoin grant to support NFT Standards Research and Development
Thank you to William Schwab for reviewing and helping me review previous versions of this article.
