As expected, this was the most exciting week with the maximum lines of code written.

• The first priority was to fix the “approve error”. As I discovered that the USDC(PoS) token has a proxy implementation, I read the underlying contract, only to find that “approve” function well defined in it, so I was not able to understand why it was not working.

• After exhausting about 6-7 hunches, I tried appending the api of this underlying contract to the USDC contract’s ABI, and the function worked! I understood that on the frontend, as the ABI did not have approve defined, as the USDC token’s abi only had delegate functions, and thus, it was throwing a does not exist error.

• After fixing the above issue, I wrote the code to make the approve and NFT minting transactions gasless, and ensured the the latter runs upon the completion of the former.

• I then proceeded to use Gelato’s status api to fetch the status of ongoing gasless transactions, and display real time updates.

• As the whole flow for the POC was now working, what was left was making UX improvements, and deploying the project, both of which did not have much roadblocks.

• The only issue remaining was that the onramp frontend was still only available in the US. I made the demo and tested things using a VPN for the time being. A future aim would be to ask for India access, or switch to a different onramp.

Overall, I had a lot of learnings from this building experience, and am super excited for demo day!

The 7th week was certainly the toughest, with a dozen emails sent to stripe’s developer support team, and atleast 25 messages on Gelato and Safe’s discord.

• The week’s start, like the previous week, was quite smooth. I began by writing a basic NFT minting smart contract, which was am ERC721enumrable token, with a setTokenURI functionality added to it, similar to ERC721storage.

• I was then able to integrate Gelato’s relay and 1balance to make minting the transactions gasless after a day of debugging and support from their discover channel.

• After this is when I hit a major roadblock. As I tried to integrate stripe’s onramp API, I got to know that its access is limited to the US.

• After a dozen emails exchanged with the dev-support, we were able to come to a solution and were able to get the onramp working for dollars to USDC(PoS) on polygon conversion. All other conversions were not available in the test mode.

• The major chunk felt done, until I got an “approve” function does not exist while calling it on the USDC token.

• The last day of this day was spent debugging this error and not making an significant inroads.

Overall, by solving all these dependencies, I was able to understand the value of a good developer support experience, and got better at articulating my queries.

Next Steps:

• Debug the “approve” does not exist error on a priority basis.

• Integrate the onramp flow to add USDC to the wallet.

• Add alerts to track status of the gasless transactions

• Make UX improvements and make the product ready for deployment

• Ship, ship, ship!

Now that the humongous task of finalising a project idea was complete, the only small, easy bit left was to actually build it 😛

• My week began by curating a proposal for my project idea, and elaborating upon topics like motivation, objectives, USP and execution plan.

• I then submitted my proposal to the Devfolio team, and proceeded to setting up a basic flow for the project.

• This phase involved reading up on existing libraries implementing onramps, account abstraction, web2 logins etc.

• During this week, I was able to achieve web2 based logins paired with SCW creation uniquely mapped to each user.

• Further, I decided to use gelato relay to setup a flow which allows the dApp to pay users’ gas-fee, or let the user pay gas-fee in non eth currencies as well, using gas abstraction, thus making the users’ experience gas-less.

Next Steps:

• The next step is to complete a flow where a user can gaselessly mint NFTs to their SCWs.

• Once the above is achieved, I will try to integrate an Onramp to this flow, and make my NFT contract paid, so as to pay credit card based payments for buying NFTs.

• I also aim to understand access control over these SCWs better, so as to have clearly defined custodies and security measures at each step of the process.

• Last but not the least, I wish to come up with a better project name than “onNFT”.

Week 5 had 2 major tasks lined up: preparing and delivering a presentation on our assigned DeFi topic, and zeroing in on a project idea for the second half of our fellowship.

Presentation:

For the DeFi presentation, I was assigned Furucombo, which is batching and visualisation software for DeFi. End users often want to use multiple DeFi protocols together for an application. Eg: some application of uniswap, some aave function etc

Such users can make optimise DeFi strategy, add multiple DeFi blocks, and get expected min input and output details using FuruCombo.

Overall, making this presentation gave me a hands-on experience with Furucombo, and I’m excited to use the software more when I dive deeper into DeFi.

Project Idea:

• The project ideation phase was quite a rollercoaster ride for me, which consisted of creating and scrapping 2 project ideas before I could finalise my idea.

• My first idea was to build a post deceasement asset transfer mechanism, which would essentially pair a deadman’s switch with a smooth onboarding for the owners’ layman family members/nominees. This idea did seem to have a decent product potential, but lacked technical complexity. It was recommended that I choose an idea which offers more technical bandwidth, so as to make it a better learning experience for me.

• Thus, after scrapping idea-1, I proceeded to reading about another area which has been gaining a lot of popularity: zK. This exploration was quite fruitful in terms of learning about this new field. I then zeroed in on another project idea: creating a zK based auth mechanism for Smart Contract Wallets. On reading up more, I came across banana wallet’s ethIndia, which was building on a similar usecase. On trying my hand at zk circom circuits, I became a bit skeptical about the time available to learn this paradigm.

• Finally, I decided to proceed with an idea around account abstraction, particularly, leveraging account abstraction to create a flow to buy NFTs using credit cards, without requiring to create a MetaMask account.

Next Steps:

• I plan to start by formalizing my project idea, creating a flow, and listing down the requirements.

• This will be followed by reading up on the current projects and libraries operating on account abstraction and onramps separately.

• I started by reading about the concept of multi signature addresses. Multisig wallets require more than one private key to sign and authorize a transaction.

• The keys might be held in different locations to enhance security.

• Understood the off-chain and on-chain dynamics for multisig

• Understood how changing, or adding removing signers are treated as external function calls when call is used.

• Overall, the challenge involved less of coding and more of conceptual understanding, and thus brought about a lot of new and intersting learnings.

🚩 Challenge 7 - SVG NFT 👛

• This project was relatively simple, as the concepts used for familiar.

• Storing metadata against TokenIDs was was something new which I learnt, as till now I had only worked with storing images on IFPS and attaching its URI as metadata to the NFT.

• The dynamic NFT serving definitely opens many possibilities, and thus I plan on reading up and experimenting with this one more.

This week also comprised of DeFi presentations, where I was assigned Furucombo protocol as my topic. I started by reading blogs about the protocol, tried to understand the usecase, and finally went hands-on and made a few example flows(combos) to deepen my knowledge.

Link to assignments:

Link to contract: https://goerli.etherscan.io/address/0x49E6B6b497827eBFc4769279D3F41522f436632c

Link to Defi presentation - Furucombo - https://docs.google.com/presentation/d/1-DFXoMh_y8JyqyPZMSi8Y1UPI-kPXzJt3xzq4GhzZcU/edit?usp=sharing

Challenge 4: 🚩 Minimum Viable Exchange

The objective here was straightforward → To build a decentralised exchange with ERC20 token and eth. It should let the user exchange either of these for each other, while fluctuating exchange rates in accordance with the reserves and liquidity.

• I understood the concept of price calculation in decentralised exchanges, and developed a price function to maintain the K invariance.

• The challenge involved writing two exchange functions, tokenToEth, and ethToToken , both of which required a use of various concepts learnt over the past 2 weeks. Writing these functions was thus a great refresher.

• I then proceeded to understand the concept of liquidity and its importance in financial instruments.

• Using this understanding, I wrote the deposit and withdraw functions which could compute and track individual and total liquidities.

• After struggling with two failed testcases, I was able to identify the edgecases that I had been missing and add the checks so as to pass the assignment, thereby completing the speedrun.

Challenge 5: 🚩A State Channel Application

The challenge began by explaining the problem of expensive transactions and low throughput with famous blockchains like Ethereum.

• We got to know about the existence if L2 blockchains, which try to fix the speed and scalibility of these L-1s by various methods, one of them being state channel.

• In state channel, the two interacting entities carry out a beginning and some logging transactions on-chain, and do rest of there communication in an off-chain peer to peer manner, so as to reduce the on-chain transactions, thereby leading to a better scalibility.

• Therefore the entities could inform the blockchain about the establishment of a channel between them, and then simply log the final result on the blockchain after the entities are done interacting off-chain.

• We again used the concept of ownable, and used basic learnings from previous challenges to implement the required functions.

• We also dealt with packing, hashing and arrafying a message.

• We then learnt to use the ecrecover utility to recover the signer from the prefixedHash.

• We further wrote defundChannel and challengeChannel functions which again tested are knowledge of basic operations like using mappings, and transfering eth across accounts.

Link to assignments:

Challenge 4: 🚩 Minimum Viable Exchange

https://enchanted-vacation.surge.sh/

https://goerli.etherscan.io/address/0x99316fD1775EF76cBa88a43332a1C0a43A4D27Fa

Challenge 5: 🚩A State Channel Application

https://icy-pig.surge.sh/

https://goerli.etherscan.io/address/0x7DA3A755d4520a565DeeFDbE22FD284745D6F8e6

This week was a great refresher for everything we had learnt, and at the same time it also brought about some very important new concepts that took time to understand and digest.

I believe that after completing these two challenges, I feel more comfortable about solidity fundamentals, and ready to build a project end to end.

Challenge 2: 🏵 Token Vendor

• The challenged made me dive deeper into transfer of tokens across contracts.

• The most new and interesting part was understanding approval flows, as to how tokens can be used to redeem a commodity like an NFT or even Eth.

• How to check the total eth balance of a contract: address(this).balance

• Learnt about and used transfer and transferFrom functions and understood the different between the two.

• Understood the concept of ownership and its transfer to another contract, so as to enable further inter-contract transfers.

Challenge 3: 🎲 Dice Game

• Learnt about block-hashes and why blocks by default don’t support randomness.

• Read up on and used the keccak256 hash function to create a randomisation mechanism.

• Understood the concept of sending ether along with function calls if that function is payable, for example sending 0.002 eth while calling rollDice .

Link to assignments:

Challenge 2: 🏵 Token Vendor

https://jittery-eggs.surge.sh/

https://goerli.etherscan.io/address/0x135cb207b6453c94da602e8a777d1b634f61b3b4

Challenge 3: 🎲 Dice Game

https://devilish-sofa.surge.sh/

https://goerli.etherscan.io/address/0x99019Dac70C60Ac8c8f2F37Fd70D6A6538737DD8

Questions & Feedback:

My experience with this week involved less spent time on coding and way more hours on trying to understand the underlying concepts. I did end up doing multiple rejected submission this week, and had to handle a lot more edge cases to get my submissions passed.

Overall, this week did bring about a steeper learning curve as compared to week 1, which was something which I was certainly looking forward to.

I’m even more hyped about week 3 now, WAGMI.

The Speedrun challenges

Coming to this weeks challenges, I shall be mentioning points about them individually. These points cover the challenges faced and the learnings gained.

Challenge 0 - NFT App

• Understood the need for scaffold-eth and the techstack which comprises it.

• Learnt about burner wallets, their need and their usage.

• Read up on the various testnets, and used goerli in our case.

• Understood the concept of faucets, failed to find good free faucets with multiple transaction support, and ended up using a PoW goerliETH faucet for my metamask wallet.

• Created the static build of the dApp and learnt how to deploy it on surge.

• Looked the deployed contract up on goerli etherscan to verify its successful deployment.

Challenge 1 - Decentralized staking app

Being new to solidity, this challenge offered a steep climb with a lot of reading, testing and learning. I tried a lot of different functions, and debugged tons of errors to finally get the logic working.

• Learnt the concept of “payable”, and receive and fallback functions.payble signifies that a function can receive eth.

• Explored the msg object, and its attributes like msg.eth and msg.value.

• Learnt about the block object and block.timestamp.

• Understood the mechanism to transfer eth from one contract to another using call method.

• Learnt about and used mappings, events and modifiers in solidity to achieve the requirements mentioned in the problem statement of the challenge.

• Wrote all the possible staking and function call conditions, and edgecases on a whiteboard and tried to come up with modifiers to handle each possible edgecase, including the sidequests.

A common bug discovered:

Commands like yarn deploy and yarn build often give an error saying: error:0308010C:digital envelope routines::unsupported

Solution for the same is to execute the following command in the shell: export NODE_OPTIONS=--openssl-legacy-provider

Experience

Being new to web3 and solidity, the first task for me was to understand the technical jargon like faucets. As the challenge-0 was mainly just a follow along, I did not face much difficulty in solving the same and could follow along smoothly for the most part.

The real climb and learning took place in challenge-1, as the basics of solidity were a prerequisite to it. I approached the challenge one sub-task at a time, and read a lot of blogs and documentation on concepts like: payable, receive and fallback, modifiers, msg, block, events, and call.

I used the debug UI to test my code after each step, and kept solving bugs on the go.

After about a day of coding, fixing errors, and handling edge cases, I jumped out of the chair when on running yarn test , all the test cases passed one go.

As a learner, the nature of challenge-1 threw me in the deep end, urged me to figure things out on my own, and thus ultimately ended up being a great hands-on learning experience.

I’m absolutely looking forward to the next 7 weeks of learning and shipping!