Man, feels like I woke up and chose gratitude. But this has been on my mind for a couple of months now. I’ve been in the building ‘random cool things’ scene for my own joy for three years. Starting off with a simple web design task for a literary club, who knew it would be a journey with a billion ups and downs?

Right after meddling with React and some frontend stuff, in May 2021 I asked Harsh if we should win a hackathon. Mind you, I have zero ideas about how hackathons operate except for some knowledge about the SIH. The guy bailed on me as I waited for him to get online. Yikes. Time ran out but he never showed up. No worries, next event.

We built a small hack at Bhilai Hacks which was hosted on Devfolio. And this was the first time we came across this platform. Little did we know. One hack followed another, but one thing remained a constant. By last February I had built a total of seven projects at different Devfolio events including the fellowships.

Seems alright…right? Yeah. But it’s not the platform or the bounties but the folks who have been behind the platform. Online hackathons felt intimate and offline ones felt at home. So here’s a small list of stuff I got out of this journey with Devfolio:

• The Nights — Avicii // a fellow shared this gem to be rediscovered during the online part of the Polygon fellowship)
• Blinding Lights — Something about a Goose, don’t quite remember ;)
• Schwags — Hands down. Top-tier stuff.
• Coolest-wholesomest fellows as friends
• Insane memories. And a Polaroid photo too.
• Mentorship — Countless moments, screwups and conversations.
• Insane limits I’ve hit and pushed a little — tech and otherwise.
• A gallon of problems — Stuff I want to build more stuff for.
• My current job — not worrying about placements paid off!
• And the cutest diaries of all time!

I’m quite grateful to have received all the support, and schwags (mostly schwags hehe, jk). And I can bet on one fact, which is if you are building something, Devfolio will stand behind you however possible. Thanks for all the happiness and for building this community for builders! I hope all the greatness to y’all.

Signing off, Never Stop Building 🛠

Hello folks!
The last report of the Human Wallet journey is here. Oh btw, we have a name for it — One! One wallet for all your crypto needs.

This week was the last one at EIF 3.0 and I am feeling spontaneous and happy with a tinge of sadness. I had a really good time meeting the EIF deadlines and working under pressure. :P
Counterintuitive but well, being accountable for your passion project works out for the best. More about building in week 8, it was hectic and I’ve made massive progress in the last few days. From getting the onboarding flow just right to creating a simple Send ETH screen for testing purposes.

Where are we now

The Human wallet is now able to onboard users with their phone numbers and create an account for them. How simple is the onboarding? Well, open the wallet, enter phone number, verify OTP, select a username and kaboom. You’ve a wallet which can now do all wallet things. The application has a Send feature for testing. More to come soon. Users can also pause their accounts and stop all future transactions until it is unpaused.

Week 8 started with adding keyring functionalities to the web application. The keyring allows us to have multiple accounts and encrypt them with a device PIN. After ironing out a few handlers, we were good to go on the onboarding front. Users could now create new accounts on the wallet with their mobile numbers.
Next up was adding a Send ETH feature to the wallet to test out if the keyrings and providers work as expected. To my surprise, yes they do!

This has been all about the demo application that I have built in the second half of the fellowship. The first one was heavily based on getting out stories from users and understanding what sort of experiences are needed to make life simpler for a crypto user. I will be taking these thoughts and observations ahead with the project to build out the Human Wallet.

Hiccups

Account abstraction with ERC4337 is very tricky business. There are a ton of moving parts to the whole system and many checks in place to ensure smooth execution. Which implies a lot of edge cases, staking requirements and even more build time. It has been rewarding and nerve wracking to discover everything 4337 related!

Right now I am facing issues with hosting my own Paymaster which is needed to pay gas fees for new accounts being deployed. Once that is sorted next up is refactoring and ironing out a few edge cases in the onboarding logic. Also web3Auth came up with native sms auth, so gotta switch to that asap and ditch firebase.

Also Vite broke my heart with build failures at the last moment. I have no clue why it’s failing. So I’ll be porting the codebase to CRA and hope for the best.

Looking forward to…?

I’ve learned that the milestones I set for myself were a little more optimistic and that I need an intern to write CSS for my app. Just kidding. No, I need that intern asap.

I am keen on building this product and have it tested soon. Features like fingerprint unlock and alternate recovery mechanisms are up next. There is a ton of work ahead and it is going to be fun figuring this out. Which is why I would be building in Nights and Weekends S3 with Ankit Pal (Polygon Fellow and, an unhealthly relentless builder).

That is all from the ETHIndia Fellowship 3.0, see you soon!

gm people of web3,
Welcome to the second to last report on building the Human Wallet Project at the ETHIndia Fellowship. This report covers the sixth and the seventh week of building, head-scratching, pointless optimisations, progress and dealing with painful bugs. Let’s get this party started.

The Local Validation

Week 6 started with fiddling with the account-abstraction repo to create custom runOps and deployment scripts. After a few config changes, adding the HumanWalletApi, and testing the contracts on the hardhat network week six ran out of time.

I did struggle a lot with making the UserOps work with the custom API since a few gas parameters for pre-verification were not accurate. But well. Hard-coded values are the best fix. So I fixed the VerificationGasLimit manually :P

Deployment Pain

In week seven I started to test the contracts on Goerli with the Infinitism bundler. Which was, if I put it ever so gently, like having a multi-organ failure. There were many config-related issues at first but those cleared out eventually. I tried Alchemy, Infura and Stackup nodes to run the bundlers. Alchemy and Infura have throttled the eth_getLogs method which crashes the Infinitism bundler after a UserOp has been submitted. So those attempts failed a couple of times. There were also issues with gas estimation which reverted many ops. All efforts that went into getting the Infinitism bundler were a bust.

Stackup bundler did not let ops through citing ‘Unauthorised Request’. Then I moved on to work with the Stackup example repository which fixed the auth issue (still figuring out why). Then I published a few packages (built on top of the Infinitism forks) for the wallet SDK and contracts. Imported these packages in the Stackup repository, create new scripts to support the HumanAccount implementation and voila!

Factory Revelations

The contracts, bundler and client were now working perfectly for deployed accounts/contracts. Attempts to transact with a fresh account and deploy it were reverted by the bundler. The HumanAccountFactory accesses the state while deploying a new account. See, bundlers are protected from DoS attacks. And one vector could be bad UserOps that access the state while deployment and keep the bundler busy. To get over this, the bundlers need such factories to stake some ETH with the EntryPoint contract.

So the next step was adding a few ownerOnly functions to the HumanAccountFactory which would deposit ETH, stake and unstake from the Entrypoint. This setup works smoothly and now I am happy to say that the contracts are good to go for the first iteration.

Client Needs

Just like human clients, the human-wallet client is also a very attention-hungry entity. Right after deploying a new set of contracts to Goerli, I have been working on the final onboarding steps like encrypting the device with a pin and persisting the wallet state. Next up is a quick build sprint for the home page of the wallet and the transfers UI.

Phew

So this was everything human-wallet from weeks six and seven. In other news, there was a delightful panel on Web3 Wallets last Friday where some very smart folks from 0xpass and the Ethereum Foundation talked about well, Web3 Wallets and account abstraction. EIF fellows who are building 4337 related projects also presented their ideas.
Shoutout to Banana Wallet SDK and Rugproof! Some great builds are just around the corner. 👀

Take care, folks!
Keep building and hydrating.

gm builders 🌻
This week has been eventful for crypto. Mild panic but everything seems to be okay now. India celebrated Holi for two days this time, which meant two bank holidays. Full disclosure — human wallet, a web3 wallet also got a little break over these two bank holidays.

Welcome to my fifth weekly report on build time at ETHIndia Fellowship! I’m building the Human Wallet and these are the latest updates:

React PoC

I initialised the repository for the wallet's proof-of-concept React application, adding basic styles and routes. Next up was building the onboarding interfaces which took the most extended amount of time! Phone number and OTP inputs are so damn tricky. Anyways, I spend the whole weekend building out the SMS Auth interfaces and adding web3Auth-firebase integrations. We can now retrieve the ownerPrivKey on the client which will be used for modifying the ACL Module only.

Check out this React OTP input blog which I referred to while building.

Jayesh 🌿🦇🔊 on Twitter: "having a lot of fun building on sunday yay / Twitter"

having a lot of fun building on sunday yay

Mentor Call

Meet Tomiwa, my mentor at the ETHIndia fellowship, he’s got quite the right set of tools to pick brains, inspire new ideas and encourage people to build. I had my first call with him last Wednesday. We had a candid chat about what this project is about and its different aspects, features, and design feedback. All conversations human-related were the highlight for me. Absolutely love caring for people with CSS haha. This call really helped me double down my focus and shift the priority order for a few tasks.

And scene! These are the most significant updates from week 5. I had fun building the reception (onboarding) of the application and as bland (concrete-like) as it looks right now, it works great and I’m excited to deploy some contracts with phone numbers yay!

Gm builders,
This is the weekly report for the fourth week at the ETHIndia Fellowship. In other news, there’s unseasonal rain in many cities like Mumbai and Pune. But this week has been about looking at different SDKs and AA-related news while wishing that I was at ETHDenver. There was also a lot of me thinking about many attacks on the smart contract designs and then finalising an architecture.

AA News

The account abstraction world is happy with some crispy news coming from ETHDenver. With the same excitement, I took a look at if Gelato and Safe SDKs can be used to build Human wallet. Unfortunately, I was not able to figure out how to utilise them. I would’ve enjoyed Gelato one balance to provide a gasless experience.

Smart Contracts

This week I have gained more clarity on how to structure the contracts to provide the desired features. I’ll be using this as a guide to build with the Infinitism contracts. Coming up with the design was a little tough given the fact that ownerKeys of an account should be mutable and that the access to the accounts on different chains is to be synchronised.

Next up I will be creating the Account and AccountFactory contracts and some tests yay! Week 5 will be more building and less contemplating about current issues. React PoC for onboarding and deploying contracts will be the next huge goal to aim for.

Hello people!
Welcome to my third weekly report on the ETHIndia Fellowship where we look at the Human Wallet's (I guess that’s what we will call it before finalising a name) development journey. This week was mostly building sandcastles and then creating waves that each take away a part of it. All sandcastles are metaphorical and represent different purposes like testing authentication methods, UX to tech architecture decisions and such. I really wish I could be on the beach and build real ones though.

UX to Tech

I put a lot of time into iterating on how the tech side of things should work for the desired user experience. After a fair few iterations and tests, this is the flow I’ve landed upon to make things work for onboarding. More on the tests later.

Owner keys only exist to create new device keys and register them. They are discarded as soon as the device key is declared on the contract. Whereas device keys are used to create UserOps and act as the authenticating keys. Take a look at the following diagram to understand what the bigger picture of access control looks like.

The recovery using social guardians is not included in this diagram as I am still thinking of different ways to go about it. I’m thinking of a magic-link type of system where the user generates a link and guardians can visit it to submit a signature to grant the account access to the user. This prevents a spam attack on the guardians if the identity linked to their public key is exposed (assuming that we use in-app notification methods).

A ZK guardian management thingy would be ideal but that remains out of the scope of this project at the moment. I’d love to iterate on this once there is a good MVP ready.

Exploration

This week was also all about exploring different ways to authenticate users. I was looking into Web3Auth along with Auth0, Twilio and Firebase. These logins have significance in providing an effortless wallet recovery of the ownerKey.

The first experiment was authenticating a user using their phone number. For this, my first choice was to check out Auth0-Twilio which worked fine if there was an additional method to authenticate users using username-password or any social login. But it was not possible to keep SMS auth as the first step. Plus Auth0 flow requires redirecting the user to their page, which could be avoided using firebase.

Web3Auth-Firebase took the W with SMS auth. I tweaked a few things in the Firebase-Google Web3Auth example repo to make it work with phone numbers. I then added an MFA step with a Google login. So any user will need to log in with their phone number and google account to recover their wallet without the help of guardians.

These tests here took almost seven hours each to set up and test. Web3Auth verifiers take their sweet time to initialise and get ready before using them. And I expired the 50 requests per day limit of Firebase SMS auth :P too.

Next was a little dive into different AA-related SDKs and contracts by StackUp, Infinitism and Candide. Trying to figure out how things are working and making notes about the deployments. I am curious about Safe’s upcoming AA SDKs and their way of going about 4337. I tried finding relevant code and documentation but unfortunately, it is a little sparse compared to StackUp or Infinitism.

Along with these updates I am also close to finalising a case study for the designs I will be implementing, yay! So that was me building sandcastles, destroying them and rebuilding to find a better design. That sums up week 3, thank you for reading and I hope you have a great day!

Ay, it’s week two! Welcome to the second weekly report of the ETHIndia Fellowship! 🌻

Last week I was busy the first three days tending to the last first unit tests of the last semester of my very first B.Tech degree. Phew, that took a moment to write.
But seriously, I started working on the wireframes and completed the user and product UX research summaries. Finally, I was also exploring the web3Auth modules to figure out the tech part to onboard users.

Users???? Humans??????

I have penned down all my user-related thoughts and assumptions in this article — Human-centred Wallets. But humans who?. Please feel free to hit me up if you’ve any points to discuss! I’m very keen on figuring out this part of the project.
As Steve Krug writes, “We don’t figure out how things work. We muddle through”. Oh yes! I also am reading Don’t Make Me Think by Steve Krug (as a part of the UX research? NO. I’m just a psychology nerd :p).

Wallets right now

To get a lay of the land of the warzone that wallet development has become, I was installing-using-analysing-contemplating different web3 wallets. All of them were non-custodial with Argent being an exception having the most web2 integrations.

I have onboarded, recovered and transacted with the following wallets on Android:

Honestly? We gotta something or the other from each of these. But Metamask has one of THE worst experiences. Rainbow wallet used to be better but their latest version seems to be worse than the previous one (I’m still confused about when and where did it lose all of its colours???).

I’m referencing the above wallet experiences and building the wireframes. These points are a very brief overview of the issues. Gathering screenshots for some wallets like Metamask was difficult since it was blocked by the application. This feels like a must-have feature in wallets (with an option to turn it off. else it is just a pain in the back).

Language Experience

This task is taking more time than I thought it would. I wanted to figure out a more generic yet informative language experience to utilise in my build. This language should ideally help users understand most features and mechanisms without having to learn a lot about the network. I’d be iterating more on this topic in Week 3.

Tech

Finally, I was also reading Auth0 and Web3Auth docs to find out how an owner private key can be generated and backed up. Trying Web3Auth demos was underwhelming as none of them seemed to work as intended. Anyways I have a few ideas surrounding SMS authentication to retrieve a private key using Web3Auth. I’d be implementing and testing these later this week. I also took some time to catch up on the more recent development of Infinitism’s EIP4337 contract and bundler implementation.

So that was pretty much the Week 2 report of the ETHIndia fellowship!

Gm everyone! 🌻

Welcome to the drawing board of my EIF 3.0 project. Here we take a look at what the Web3 wallet user experience is, its efficiency, benefits, and drawbacks. Then we compare these to the ideal experience to find out what we can build to enhance it further.
The following article is a summary of what I have understood about the current and future state of users and their experiences. This is part of my research for building a ‘human-centered’ wallet.

Following are the points I realized and put together after talking to designers, users, and students (both crypto native and non-native).

Who are the users now?

The users of web3 and the crypto ecosystem currently include a mix of early adopters, tech enthusiasts, investors, traders, and developers. They are generally individuals who have a strong interest in the potential of decentralized technologies. This implies that we understand the basic know-how and the technical jargon that comes with it. We would love for this to be abstracted but it is fine if it isn’t.

Who would the users be?

…most end users would not care about decentralisation, for me it is just an add-on and a means to an end.
— 0xAnkita, Web3 UI/UX designer

In the next few years, the user base of the web3 and crypto ecosystem is likely to expand beyond the current early adopter audience. These users will need seamless flows and low prerequisites to onboard and start using web3.

For such folks, the issue of centralization v/s decentralization will not remain relevant as much as it is with us, early adopters.

Let’s take a look at their anticipations and expectations for using wallets:

Anticipations (of the current users)
_____________

1. A wallet that works without much hassle
2. A safe and secure plugin/app to hold assets
3. Control over gas parameters
4. Should be able to interact with most dapps
5. Support multiple similar networks and currencies
6. Good portfolio tracking tools

What would their goals for using web3 and crypto look like?

Extrapolating the current status of the ecosystem, we could be looking at a good balance between traditional and decentralized finance.
A world where the macro-economic conditions are mostly regulated by institutions (a necessary evil); But also a world where personal finance, investments, and payments have convenient P2P/decentralized alternatives.

The following goals can be outlined for an average web3 user in the future:

Goals
_____

1. Simpler payments. (Receiving & sending)
2. Secure self-custody of assets and accounts
3. Interacting with in-person P2P marketplaces
4. Interacting with different networks would feel similar to interacting with different centralized financial service providers. 
5. Store purchasing power safely

Anticipations (of the to-be users)
_____________

1. A wallet that is intuitive and easy to navigate
2. Universal support
3. Abstracted network and gas information
4. Seamless human-readable transaction experience.
5. Secure and easy recovery
6. Seamless integrations with trad-fi and web2

What will the to-be users need?

Convenience, safety (under the hood), and learning curves depending on their familiarity with the ecosystem.

The above points imply the necessity of a layer to abstract the current experiences to cater to more users who come later on the adoption curve. This asks for a simpler UI, a better language, and in-app support.

Abstraction comes at the cost of the user’s freedom to control the finer workings of the application. Abstracting too much from a financial provider app is also a caveat we should look out for.

What do they NOT need?

We would also need a more generic new set of words to describe this abstracted version of web3. “Self-custodial Account Abstraction wallet for simple recovery” will not cut it. I am also trying to build an alternative language framework for my EIF project as an effort to simplify the wallet-related jargon we face.

Future users also would not need fine control over gas fees and parameters as much as we need it now. This is assuming that networks eventually solve scaling issues and gas-related issues.

They would not need to handle recovery as we do now. For example methods like written seed phrases and hardware wallets.

Conclusion

These are some of the ongoing threads in my brain that I was referring to for design inspirations and decisions.

As for how to achieve a “human-centred” wallet, I’m finalising a small case study on existing wallets and will be linking it in the next EIF weekly report. I’d also provide a detailed account of what things could be abstracted and how.

gm folks! 🌻

Welcome to the first weekly report of the ETHIndia Fellowship where I walk you through the beautiful, lame, exciting and painful moments I encounter as I build one of my passion projects.

About the ETHIndia Fellowship - it is an eight week program where builders get to build their best ideas, get mentorship and support from the EthIndia organisation as well as industry experts.

Project Idea

TLDR; A wallet experience created not for web3 or crypto but for humans.

I would be putting my heart into trying to create the best Web3 onboarding & recovery experience. For that I will be building on EIP4337 — Account Abstraction to put together a wallet that will abstract most annoying interactions that a crypto-non-native user would not be aware of and a crypto-native user would like to get rid off. For convenience’s sake let’s call the to-be wallet ‘Human Wallet’.

To be very honest I am nervous about my plan to build the project since UX design and research is a completely new domain for me. But I guess that is a good sign?

Note: I am referring folks who have used web3 or have held crypto assets as crypto-native.

Plans

To build a ‘human wallet’ we would need insights on people work and interpret common issues with the current experiences. But most importantly, we would need to understand what it takes to build a user experience. I would be working on the UX design for the first three weeks of the fellowship and then build the application.

Work

“Everything the user feels before, during and after having interacted with your product.” — Georgia Rakusen

The usual process for designing a UX is research, talking to people, quantitative surveys, existing product surveys, prototyping, feedback and iterating. Here’s a blog I found helpful — Guide to UX for Web3.0

Step 1: Talking to people
I am completing my last semester and what could be a great way to get insights on how students think about the trad-fi and web3 experiences. The questions included a few points about UPI, internet banking for the crypto-non-native folks. Unfortunately I couldn’t find a crypto-native student.

I also had a great chat with a Web3 UI/UX Designer this week. I couldn’t complete all the planned interviews this week so I’d be compiling all the insights in another article shortly.

I was also watched a few videos by ZeroToDesign where a few designers review the Metamask experience on iOS. Link

Step 2: Product Research
Secondly, I was installing and trying out all top wallets in the ecosystem and noting points about their experiences, quirks and solutions. All tests were based on Android because an optimal mobile design would result in a good desktop design but not the other way round. I would be publishing the insights in the next article.

And now?

Overall this week was a little more oriented towards reading and understanding how to go about the UX design. The next week is going to be even tougher with exams but I’m aiming to publish the insights and UX designs along with some low-fidelity wireframes.

Like every good thing out there in the world, the Polygon Fellowship had to come to an end too. Technical knowledge aside it has been a very long journey of personal growth. I have shared all few of these points in my earlier blog here. I do want to go in the details and elaborate more but I am moving to a different place and there is not a lot of time for this blog.

This blog is divided in two parts: 1. Week 7 and 2. Hacker House.

Week 7

Here’s a few technical things I did learn in week 7. I had not started work on the Samrajya DAO smart contracts for governance and treasury before reaching BLR. I did start working on the tokenomics and the architecture design on Monday (1st August).
After getting feedback from a few people on how DAO’s are built and what’s expected I was left even more confused. I think that is the case with every community DAO. A ton of sessions and talking left me a little too tired to focus and build though. I had forked a repo with of a DAO governance implementation by Patrick Collins.

After almost pivoting to a different idea and coming back to square one I was clear about how I wanted to tackle the technical specifics. I had a great conversation with Garvit (a very kind and cool builder track fellow you must follow) about the DAO tokenomics and contracts. It was inspiring and got my brain worked up. The next day I resumed work on the repo and made a little progress on on-chain governance. Tweaked the TimeLock contract to host a treasury too and then started writing tests for it. I really do not remember what exactly happened when after that.

And it was already time to get some frontend designs implemented and work on the pitch. With the designs done I went to the drawing board for the pitch deck. Got done with the demo and yay! I am most proud of my on-chain governance and treasury management contracts. That completed the goal of the learn solidity and build something cool with it.

Hacker house :))

Oh what an absolute blast the hacker house was. If there is something I would want to live as my hell-loop, the final day of the Hacker House would be it. The vibe, the very sweet humans and the EthIndia cold brew coffee. Here’s one to something I never imagined I would experience 🥂.

So what went down in BLR exactly? Insane amounts of networking! I was headed to the venue stuck in traffic and a little late. Reached the Hacker Hall half way through Sandeep Nailwal’s keynote. I wish I had caught the rest of it. After the virtual meet with Sandeep was done, all of the members got to talking.

It was a complete cultural shock to me as the fellows from builder track shared their visions about their projects and startups. It was very evident to me that the Hacker House is not a place where I can build a lot of things. I thought of it as a hackathon venue where people would keep building and It was instead a place to meet cool people, get insights on building products and companies. The hacker house is not where you expand your technical skills, rather it’s a place where you expand your horizons from using OpenZeppelin contracts to creating your own standard/layer/business.

We used to have lunch and dinner at Murphy’s barely avoiding death by the hitting the toes on the tables. Every guest speaker used to be swarmed with fellows interacting, providing feedback and making connections. Successful and influential people being accommodating and reciprocating the warmth was a very nice feeling. Not that I presumed them to not be this way but the “corporate” culture suggests otherwise. God that’s a lot of negation in a single sentence.

The first seven weeks of the fellowship pushed me to learn and unlearn solidity and web3 concepts. But the last one pushed me to get to know people better, think about building a business and how to plan the journey of a project to a product.

The graduation ceremony was a very emotional moment. It was one of those moments when you have an epiphany to enjoy the heck out of the remaining hours with the cutest of builders. After party is also a whole different blog haha. But I have loved every second of the hacker house and I am grateful to be at the right place and at the right time with this fellowship. Thank you Devfolio and Polygon.

“Cuties hai sab <3”

There’s a lot to talk about but unfortunately that’s all that I could manage in this one. I really do hope that I get to share more. See ya folks!