You are already aware that executing transactions on the Ethereum network (including Polygon, Arbitrum and Optimism) requires #Gas fees. Now when the price of the Native Token is “affordable”, there is not much noise around gas fee; however, as soon as the price of the Native Token starts climbing your Twitter feeds will be filled with the high gas fee hue and cry. For obvious reasons. Add to the above, we have the fact that interacting with certain smart contracts, for example the Uniswap Router Contract (Uniswap App), a user has to make 2 transactions: first the function to allow a fixed number of tokens that can be used by the other smart contract in a transaction and approve second, the smart contract call which will then call the . transferFrom It is easy to guess that this increases the overall gas costs for doing transactions. While there are multiple methods in which the industry has tackled the “high” gas fees issue, this article is just focusing on, probably, the first large-scale implementation: the DAI Smart Contract’s Permit Function. If you are designing your smart contracts that will require the issuance and management of ERC20 Tokens, it will be in your interest to design your ERC20 Token Smart Contract with this function. While in theory we could be writing for a lot more, instead we are doing a quick demo of the use case of the in the Smart Contract for the . Permit function DAI Stablecoin Lets get our hand dirty (A) Local Set-up You can clone the tutorials repo from here: and then progress to the eip-2612 folder Github (B) Installation Once the code is set-up on your local system, you need to make sure you install all the dependencies using or depending on your personal preference. npm i yarn install (C) What is happening in the code Lines 1 to 17 are straight forward; so are the lines 19 to 21. Lines 18: nonce This is NOT the nonce of any wallet address. This is the nonce that is maintained by the DAI Contract independently. Reason: imagine if I were to grant an signed message, approving your address to use my DAI. This message is used by you, but not once, but twice → this would technically qualify as “Double Spending” and hence the maintenance of an independent by the DAI Smart Contract nonce Line 63: The signing of the message. Type: _signTypedData Now, DAI follows the EIP712 standard for typed message signing. I will not complicate this (unless someone really wants, then just mention it in the comment below). In simple terms, it is a standard that needs to be adopted for the purpose of signing a message that can be put into “execution” by the Smart Contract and in this case, the DAI Smart Contract. As you can see, the requires 3 parameters: _signTypedData : think of these as the details of the smart contract for which this message is intended to be domain : defines the names and types of the individual items of the message types : literally the message that you would like to pass to the smart contract. message Seeing the above in action (a) Run the script: node scripts/sign.js Yes, I am not using Hardhat, cause I do not need to. You can get the job done by using Ethers alone. It is just generating the signature. For convenience, I have set the nonce to the value that the contract returns. That is to say, that it will automatically fetch the correct nonce, based on the value stored in the contract. For security purpose, I am setting the deadline to be from the current block.timestamp. That is to say that this signature must be lodged with the Smart Contract in . Then, I will deliberately fail to register this signature in 15 seconds and lodge a transaction. It should fail 15 seconds 15 seconds of generation (b) Once it is run after using in your environment variables, you will get something similar to the below image in your console: (c) Testing if the approval went through: — creating a Private Testnet on , forking from the Ethereum Mainnet buildbear.io — first getting some tokens into a different account from the BuildBear Faucet: —Visiting the DAI Smart Contract in my Private Testnets Explorer: — Using the Permit Function (in the Write Contract part): 📝 — Executing the transaction (Obviously failed transaction): ❌ — checking why it failed by visiting the trace of the tx: 🤯 and voila! I was able to see what happened inside the transaction and not just the revert reason. Trying to run the same script but this time with 2 mins as the expiry and re-doing everything for a successful tx will lead to: Obviously if you notice that I lodged the above transaction from a completely different account, which would otherwise be known as the ‘relayer’. This account paid the gas price for submitting to the blockchain that the account ashall have the permission to transfer my DAI tokens. 0xD31950cD762281b9849c33bfa5CE9A42B756155 Proof: And that is all in relation to how to use the in the DAI contract. Permit Function About BuildBear BuildBear provides you with a private test node, making the testing process smooth and efficient. To learn more about BuildBear, read here docs Get the above Github code from . 👈 here Also published . here

Read My Stories

Too Long; Didn't Read

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

A Guide to Using the Permit Function of the DAI Stablecoin

Too Long; Didn't Read

Shivam Agrawal

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

A Guide to Using the Permit Function of the DAI Stablecoin

Too Long; Didn't Read

Shivam Agrawal

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES