My this mirror address has been compromised, though you can still read all my previously written blogs here.

https://mirror.xyz/0x6C2265693900a68b9c9CBE2d6Eae3bd9336060db

Since I still had my ENS and they were not compromised, I have created this new blog where I will be writing my future blogs.

https://mirror.xyz/plusminushalf.eth

Thank you to everyone who subscribed to the mirror, it will super helpful if you could subscribe again here, apologies for the inconvenience but there is no way to change ownership of my previous mirror account :(

I am waiting for the EIP-3074 or some variant of it that will allow me to deploy an SCW at this address and get my blog back. If you want to know more about how can that be done, read my previous blog

https://mirror.xyz/0x6C2265693900a68b9c9CBE2d6Eae3bd9336060db/r_4LxC3wuyliCPERSoAcSyLfKA0Y9oZzvr1L_j9s1Tk

Banner credits: Photo by Mishal Ibrahim on Unsplash

In this blog, I will be exploring how Metamask & Tally-ho wallet stores their private keys. I hope you and I both will learn during this exploration.

If we want the data to be encrypted with a password & then stored, the best standard to use is AES-FCM. The crypto API provided by the browsers support this by default.

To encrypt a message using AES-FCM we need two things, a key which will be used to encrypt the messages and an initializationVector to add randomness.

How to create a key?

We can use crypto API importkey to generate our master key and then derive the key to encrypt messages for AES-GCM from the master key using deriveKey function. While creating the key we will also generate random bytes salt, the salt must be saved and is needed along with the password to recover the key. Below is the code which generates a new Key if the salt is not passed & recovers the key if the salt is passed.

type SaltedKey = {
  salt: string
  key: CryptoKey
}

async function generateSalt(): Promise<string> {
  const saltBuffer = crypto.getRandomValues(new Uint8Array(64))
  return bufferToBase64(saltBuffer)
}

async function generateOrRecoverKey(
  password: string,
  existingSalt?: string
): Promise<SaltedKey> {
  const { crypto } = global;

  const salt = existingSalt || (await generateSalt())

  const encoder = new TextEncoder();

  const derivationKey = await crypto.subtle.importKey(
    "raw",
    encoder.encode(password),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  )

  const key = await crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: encoder.encode(salt),
      iterations: 1000000,
      hash: "SHA-256",
    },
    derivationKey,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  )

  return {
    key,
    salt,
  }
}

How to create an initialization vector?

To create our initializationVector we can use the crypto API provided by the browsers.

const initializationVector = crypto.getRandomValues(new Uint8Array(16))

Encrypting text

Now we have generated the key & also initializationVector. We are ready to encrypt our messages. Before encrypting our message, we must encode it using TextEncoder. It takes in the string & emits a stream of UTF-8 bytes.

type EncryptedVault = {
    salt: string
    initializationVector: string
    cipherText: string
}

async function encryptMessage(
    message: string,
    password: string
): Promise<Vault> {
  const encoder = new TextEncoder()
  const encodedPlaintext = encoder.encode(message)

  const { key, salt } = await generateOrRecoverKey(password)
  const initializationVector = crypto.getRandomValues(
      new Uint8Array(16)
  )

  const cipherText = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv: initializationVector },
    key,
    encodedPlaintext
  )
  
  return {
    salt,
    initializationVector: bufferToBase64(initializationVector),
    cipherText: bufferToBase64(cipherText),
  }
}

When we call the above function, encryptMessage, we get three things in return salt, initializationVector, cipherText. We can store all these three values in the browser's localStorage. These values along with the user's password can be used to decrypt the cipherText.

How to decrypt cipher text?

To decrypt the cipherText, we need the three values we stored above along with the user's password. We will first recover the encryption key using the password & salt. After that, we will use the key & initializationVector to decrypt the cipherText. The code below can be used to decrypt

type EncryptedVault = {
    salt: string
    initializationVector: string
    cipherText: string
}

async function decryptCipherText(
  vault: EncryptedVault,
  password: string
): Promise<V> {
  
  const { crypto } = global

  const { initializationVector, salt, cipherText } = vault

  const { key } = await generateOrRecoverKey(password, salt)

  const plaintext = await crypto.subtle.decrypt(
    { name: "AES-GCM", iv: base64ToBuffer(initializationVector) },
    key,
    base64ToBuffer(cipherText)
  )

  return new TextDecoder().decode(plaintext)
}

Usage

Let's round up with the usage of functions we have created above to encyrpt & decrypt a message.

// Encrypting message
const password = "<Some-Strong-User-Password>"

const messageToEncrypt = "Hello, world"

// We can save this vault directly in localstorage & retrieve later when we need to decrypt the stored message
const vault = encryptMessage(messageToEncrypt, password)


// Decrypting message
const descryptedMessage = decryptCipherText(vault, password);

// Validate the messages are equal :)
assert(descryptedMessage === messageToEncrypt)

Reference

Metamask has also released a module which will do all these stuff for you & give you simpler API, check out their module browser-passworder

Usage:

const { strict: assert } = require('assert');
const passworder = require('browser-passworder');

const secrets = { coolStuff: 'all', ssn: 'livin large' };
const password = 'hunter55';

passworder
  .encrypt(password, secrets)
  .then(function (blob) {
    return passworder.decrypt(password, blob);
  })
  .then(function (result) {
    assert.deepEqual(result, secrets);
  });

I am super excited to share that I will be participating in the Ethereum Protocol Fellowship (EPF). This blog is my first update for the fellowship.

What will I work on?

We are moving closer towards the finalisation of EIP-4337. A lot of effort by the core team has been put into designing the contracts, mempool, DOS protections etc. But the team haven't had time to properly support UserOps through one of the browser extension wallets.

In this cohort, I intend to work on making a user-facing wallet which can then pave the way forward for the wallets in the Ethereum ecosystem. The larger goal is to test the eip enough and make it ready for everyday use. Once we get AAs into everyday use we can then easily work towards the depreciation of EOAs from the ecosystem.

Update

1. Read EIP-4337

2. Won a hackathon by building a project on 4337

   https://devfolio.co/projects/cupcakes-0027

3. Created a repo to showcase the latest Account Abstraction SDK and how anyone can create their own SCW

   https://github.com/plusminushalf/demo-aa

4. Wrote the onboarding journey of an AA user on a chrome extension wallet

   https://hackmd.io/@plusminushalf/onboarding-aa-challenges

5. Finalised the feature list of the chrome extension wallet

   https://hackmd.io/@plusminushalf/4337-compatible-wallet/edit

Next Steps

1. Front-end architecture

2. Front-end UI finalisation

3. Bundler that will be used

4. Request ID explorer

What is Polygon <> Devfolio Fellowship?

It is a sponsored 8-week mentor-led program for you to take the next step in your Web3 development journey. You can apply to two tracks based on your experience level in web3, Beginner Track & Buidler Track. 25 fellows were selected for both tracks. I was selected for the builder’s track.

The beginner track was for students still in college and early in their web3 development journey. The cohort was much more organised and filled with structured coursework, weekly lectures, and tasks. Not only they had a tight schedule, but they also had access to dedicated mentors from the industry.

Buidler Track was more on its own in terms of schedule as each one of them had proposed a different project that they wish to work on before getting selected. While we were to plan our day & work, we were connected with mentors from the industry-specific to our project. I was for instance connected with Yash from Biconomy, who was working on EIP-4337 as well. The project-related pairing meant I could go as technical as I wanted and also ask as many architecture questions as I wanted. Kudos to the team for finding project-based mentors for all 25 builders.

Hacker House?

Hackers? House? What is that? What is a house doing in the midst of an online fellowship?

Before I try to explain it in my words, I would suggest you watch this recap video made by the Devfolio team

https://twitter.com/devfolio/status/1569572836871634945

Hacker house gave us the opportunity to meet every fellow in person and make bonds that will last forever! We had in-person talks from web3 founders, engineers, community managers, and VCs. We were given a holistic experience to help us launch our product on web3. There were also surprise visits from the founders of Redbus, Dunzo, Builders Tribe, The product house, Router Protocol, Transak, and many more. After the sleepless nights of the building during hacker house, we got to present our products to VCs, including** Builderstribe, Lightspeed, Accel Partners** and many more.

Those 7 days of hacker house have given us access to people a lot of us would only dream of and friendships we will cherish for the life ahead.

How to become a Fellow?

While I don’t know if Polygon will have another Fellowship program next year or not but if they do, I would recommend every web3 enthusiast who is at the start of their career in web3 to apply for it. It is one of the life-changing experiences that would change your career trajectory completely.

Everyone who was interested to be a part of the fellowship had to apply on Devfolio’s website. Upon selection of your application, there was another interview aligned with Devfolio’s team. I have already published my application at mirror.xyz/plusminushalf.eth, feel free to take inspiration.

What all the fellows had in common was that all had done a lot of research about their projects, had a plan on how to execute them and were looking for the fellowship as a catalyst to 10x their product development through feedback from mentors and industry experts.

I think it’s time I say goodbye and add this experience to the list of memories I will cherish in future.

PS: I wanted to share that we recently won the Unfold Hackathon, you can see what we built in that hackathon here: https://devfolio.co/projects/cupcakes-0027/

PPS: EIP-4337 is getting ready to disrupt the Ethereum wallets and coming faster to you than you imagine ;)

Until next time, WAGMI 🚀

I have a couple of motivations to write this blog. Firstly, to help you understand what all work is pending for the wide adoption of EIP-4337. Secondly, tell you about how you can help in accelerating the process by contributing.

Above is how EIP-4337 makes smart contract wallets a reality. We can start developing smart contract wallets, paymasters, etc compatible with EIP-4337 with a relayer service today. But for it to become the norm & completely decentralised there is some work left. Let’s look at all the parts one by one and see where the work is left.

User: ERC-4337 web & native Client SDK

The journey of any userOperation starts with a client. There is no support for eth_sendUserOperation from any wallet and Walletconnect also lacks the documentation for the above function as of 15th Aug 2022.

If you have used Walletconnect or are a part of the organisation, I would love to get in touch & understand how I can contribute to add support. This will be one of the biggest blockers in its wide adoption.

Bundler: UserOp Block Builder

Like miners, we have bundlers in EIP-4337. Support for bundling userOperations hence is necessary for the nodes. We also need to have DoS protection, for eg, there should be only ONE userOperation in the mempool at any point in time. Every implementation of the bundler must have the DoS protection module.

Nethermind is one of the first organisations to have support. Their c# node is running on Görli for full support as of now, while their Go implementation (forked from MEV-Geth) is in progress.

We currently lack the implementation for other nodes & L2s. We hence would need help in adding support to Geth, Erigon, Optimism, Arbitrum, Polygon etc.

Usage: Documentation and tutorials

One of the major sources of how EIP-4337 work is the official documentation itself, link: https://eips.ethereum.org/EIPS/eip-4337.

But it is quite technical and not useful for everyone. This is where the initiative from Infinitism & ERC-4337 Fan Club comes to help us with the launch of eip4337.com. This though as you can see is almost empty.

I would suggest beginners start contributing to eip4337.com as this will be the best way to start your journey to Account Abstraction. You can find its repo on Github and start the conversation in the discord server.

While the above were the essentials, the work for contributions doesn’t stop there. There are still a lot of ways one can contribute and there are many things that are still pending to enhance the EIP. I have listed a few more things that are still either not built are under experiments:

1. UserOp Standalone MEV Bundler - This will help extract the maximum value even in EIP-4337 with the use of private mempools, such as the ones managed by the Flashbots team.

2. BLS Aggregation Bundler - While Infinitism is working on adding support for BLS signatures in smart contract wallets, Bundlers would also need to support these signature types & currently no implementation has been started in this area.

3. Production Grade ERC-4337 Paymasters - Infinitism has released the first set of paymaster contracts to start with. This is where I have also been personally working & will be releasing something soon.

4. BLS Proxy Wallet Smart Contract - We have our first SCW which is EIP-4337 compatible, web3well, but we would need many more such implementations.

5. More SCWs - EIP-4337 opens up a plethora of things that we can do with our wallets now, think about changing recoverable private keys, pausing accounts, accounts based on username passwords, post-quantum signature supports, changing private keys, gets. The possibilities are endless & I look forward to all the unique implementations the community will come up with.

All the above have been collected from ERC-4337 Progress Report #0. This doc keeps on getting updated so keep an eye on it.

There is a lot of work still and things are moving fast, and we are ever closer to AA being a reality. That said Ethereum also has so many other things going for it, did you know the merge is also closer than ever before? The time is set, it is now inevitable, we all are waiting for 58750000000000000000000. The current ETA is Thu Sep 15 02:32:54 2022 UTC, follow bordel.wtf for the live updates.

Until next time, WAGMI!!

As I discussed in the last article Future of your Ethereum wallets, wallets of the future will be smart contract wallets. A natural progressive question is: how will you move all your EOA (Externally owned accounts like Metamask) assets to the smart contract wallets (SCW)?

Will you have to transfer all the assets one by one? This is not a plausible solution because this requires a transaction per asset (making it extremely expensive). At worst, some powers (like hard-coded owners in a smart contract, or SBTs) might not be transferable at all.

EIP-4337, as discussed in Future of Ethereum wallets, propose a ton of security benefits. Though, the biggest roadblock to its adoption is the existence of 71M EOA Wallets. We can’t leave these wallets that holds the total Ethereum economy as of today. Hence we need a way to help the majority of the Ethereum platform to move away from EOA to SCW.

Well where there is a problem, there is a solution. Let’s discuss the two ways in which we can make the transition of EOA to SCW possible in an affordable way.

1. Typed Transaction Envelope

2. Introduction of AUTH_USURP opcode

NOTE: None of the ways listed below has been finalised as of now & we have no clarity as to what will finally be adopted by the Ethereum community.

Typed Transaction Envelope

EIP-2718 introduces a way for users to define the type of transaction. This allows EVM to run special codes based on the type of transaction. Using this we can introduce a special transaction, let’s call it replace code, that will replace the original account data with the new SCW account call data (SCW’s deployment initdata). This would allow users to migrate their accounts in a single transaction & also sign for a previous public address with newly SCW address.

Introduction of AUTH_USURP opcode

Another interesting approach to solving the problem is the use of EIP-5003 & EIP-3074. EIP-5003 builds over the foundation laid by EIP-3074, especially with the introduction of opcode AUTH.

Let’s understand AUTH opcode and how it functions. It allows users to set authorised addresses. When a user calls AUTH opcode, it set’s a new address to validate & send transactions on behalf of the original address. This allows users to have multiple private keys for the same account. Note, however, that the ultimate account authority is still with the original address. The original address signer can at any point in time change authorised addresses.

Now that we know that AUTH opcode allows us to set authorised addresses, it still has the problem that the ultimate power is still with the original signer. For our use case, that is to move from EOA to SCW, we need to revoke the ultimate power from the original signer to the new SCW signer. This is where EIP-5003 comes into the picture.

EIP-5003 introduces a new opcode AUTHUSURP. The user will have to first use the AUTH code to set a new authorised address. Then we will have to call the AUTHUSURP code which will deploy the SCW at the authorised address defined by AUTH opcode above. Upon successful deployment, the opcode would return the newly deployed address. The new address would also be registered as one of the authorised addresses for the original address. Hence allowing the users to use the new signature & public key for all their previous assets and also interact with non-transferable assets (since the new address is listed as the authorised address for the original address)

How soon?

The above-pointed methods are still in the idea stages, I read about them from Ethereum’s planned road to account abstraction by Vitalik. The latest changes to the document were made a month ago as of 3rd Aug 2022. A lot of work has been put into making account abstraction a reality & improve the lives of all web3 users.

My recent search on Account Abstraction has been one of the key motivators for my today’s research. I see this as an opportunity for myself also to learn more about how EVM works, and how its opcodes work.

While transferring from EOA to SCW is one of the problems, high gas fees in SCW are also an emerging issue. I will also keep you updated on how Ethereum plans to solve that in my future blogs.

Until then, WAGMI!

We all want to know what is next in the web3 world. Today we will deep-diving into the future of Ethereum wallets & how it will change the experience for both developers & users.

One word answer for what is coming next to Ethereum is Account Abstraction. It will change how we authorize transactions & interact with blockchains. The change will open the possibilities of having recovery wallets, username-passwords wallets, paying gas fees in tokens other than ETH, or getting gas fees sponsored and having a gassless experience.

Let us dive into how all of this is possible?

Account Abstraction

So you might have come across this word already. Vitalik has been asking for it since Feb ’20, you can see its birth here.

But Why account abstraction? What is account abstraction? How account abstraction works?

Why account abstraction?

Currently, in Ethereum every transaction has to be signed by an externally owned account (EOA, like metamask, trust wallet, etc.). This signature acts as the authorization mechanism. Miners are looking for transactions in the public mempool. These miners first verify the signature of each and every transaction before picking it up for execution.

The process of signing every transaction have the following problems:

1. A single way to verify a transaction’s authenticity. If this is compromised, the whole blockchain is compromised.

2. A single point of failure, your private key/mnemonic. Once this is compromised, all your funds are compromised

3. Stuck with the blockchain’s native token for everything we need to do on the blockchain.

Let's dive into each one of the above-listed problems in detail.

A single way to verify a transaction’s authenticity

One of the biggest problems with the currect architecture of Ethereum is that there is only a single way to verify a transaction’s authenticity. All transactions must be signed with an ECDSA to prove their authenticity. What if we get some vulnerability in the current algorithm (ECDSA) in the future? What about quantum computers, we know quantum computers are coming and can break ECDSA.

The problem is that if we ever have to change the algorithm to authorize transactions in the future, we will have to send an update to all the ETH nodes. For context, the current process of pushing updates to ETH nodes is through voting. The majority of the nodes have to vote in favour and pass the change. Once voted on, the change has to be planned and rolled out with proper tests. What if this takes 6 months? If there was a vulnerability in our authorization layer then all our accounts will be exposed to attacks & hacks until the change has been passed, tested & deployed to all the eth nodes.

A single point of failure, your private key/mnemonic

Another problem in the current architecture is the single point of failure, i.e EOAs. You get a mnemonic when you create your account. That mnemonic is the access to all your crypto funds forever. There is no way to change the mnemonic, what if you forget the mnemonic? The funds are lost forever!! What if someone steals your mnemonic?? Well, write a script to transfer all your funds ASAP! (ps: the hacker already has that script and your funds are already gone). You see the problem, everything boils down to your mnemonic. Once your mnemonic is compromised, your funds are not secure anymore.

Stuck with the blockchain’s native token

The current consensus layer also forces everyone to pay gas fees in ETH. While I love ETH & would love to hodl it for long. I would want some predictability in my wallet & have most of my liquid funds in some sort of stablecoins. There is no way for me to pay gas fees in stable coins with EOAs. The flexibility of paying fees in any other coin or method except for the native blockchain coin is impossible. This inflexibility will lead to problems in scaling Ethereum to billions of people.

What is account abstraction?

Account abstraction is an initiative toward solving the above problems. The latest initiative is drafted in EIP-4337. The protocol allows users to have smart contract wallets without any change to the current consensus layer. This will allow users to have their preferred way of authenticity, allow users to recover or change their proof of authenticity, and also allow users to pay gas or let others pay gas on their behalf.

How account abstraction works?

After multiple attempts from the Eth community, they have settled on EIP 4337. This protocol was the preferred choice because it did not need any change to the current consensus layer.

I will try and briefly explain how this EIP works and how it will abstract accounts for us. Let us first list down the components of this EIP:

1. User operation

2. Bundlers

3. Entry Point Contract (EPC)

4. Wallet Contract

5. Paymaster Contract

The journey

The journey starts with a user’s intention to execute an operation on the chain. The user then will bundle their intention of the execution in an object called, User Operation. A user operation describes the following

1. User’s execution code

2. User’s operation’s authenticity proof

3. Wallet creation code if the wallet doesn’t exist on the chain as of now

4. The max amount of gas that is allowed to be exhausted for the operation

5. Paymaster information, a paymaster is a contract that is ready to pay the gas fee instead of the user for the above-stated operation

What is the difference between a transaction versus a user operation? Transactions are fully signed (according to ECDSA) instructions from the account (EOA). While user operations are not signed but do contain proof of their authenticity & instructions that are to be executed. The proof though may not be according to ECDSA standards. The proof’s authenticity has to be decided by the smart contract wallet where the account is hosted and the consensus layer has no say on the user operation’s proof.

Once the user has created the User Operation, they send it to the public network for Bundlers to pick this operation & execute it on the chain. Bundlers are nodes who are ready to process these user operations. Bundlers can sort these user operations based on their gas fees and the reward they can earn by processing the operation successfully.

How are bundlers different from miners? Miners pick transactions that reward them and execute them, while bundlers pick user operations that reward them and execute them. In theory, a miner could become a bundler as well. But before Account Abstraction becomes mainstream, we expect there to be a smaller set of bundlers in the ecosystem than miners.

Bundlers then route each and every user’s operations through an Entry Point Contract. The role of the Entry Point Contract is to route the user operation through its wallet’s smart contract and get it authenticated from the contract. Along with the operation’s authenticity, the Entry Point contract also verifies if the wallet has enough balance to pay for the gas fees & reward for the bundler.

If the wallet’s contract is not deployed Entry Point will also deploy the wallet and then verify the operation.

Once the operation is verified, it will also verify the paymaster (if specified) & verify if the paymaster has enough balance to pay for the user’s operation.

In the above verification process itself, either the wallet or the paymaster has to transfer the maximum amount of gas required for the successful execution of the operation.

Coming back to our verification, upon successful verification of operation & paymaster, the Entry Point will then pass the complete user operation to the Wallet contract for it to execute.

Post the execution of the operation, Entry Point will refund the extra unutilized gas left back to the wallet/paymaster (depending on who paid earlier). If a paymaster was involved Entry Point will also call its postOp function to inform it about the exact amount of gas used for this operation. This will allow the paymaster to keep a track of the payments it is sponsoring.

This is how we will be able to in future solve the three problems stated above. The architecture allows users to

1. Have multiple ways to verify a transaction’s authenticity.

2. Generate a new signature & discard the old one.

3. Stop any transactions from their wallet if their signature has been compromised.

4. Transfer funds to their nominees in case of the death of the owner of the wallet.

5. Pay gas fees in a token different from ETH.

6. A gasless experience if another party (paymaster) is ready to sponsor their transactions.

I did not get a lot of time to go in deep into each and every component of the EIP. Keep an eye out for future blogs for them. I will also be writing soon about how the complete system is secure and DDOS proof!

Until then, WAGMI!

With the advent of EIP 4337, I expect on-chain wallets & paymaster services will explode and help a large number of people get onboarded with web3. A lot of DAOs & old age companies would want to sponsor gas fees & want a smoother experience for their users. But deploying a Paymaster, and having a developer code the custom logic would be painful for every other organisation. This is where I feel, a service which would automatically deploy/manage & let organisations monitor the transactions that they are sponsoring would come in super handy for organisations.

Category: DAO Tooling

Competition: EIP 4337, is still new and is in the beta phase. While sponsoring gas has been around. People have sponsored gas through meta transactions as well. Though this requires changes to the underlying smart contract people are interacting with. https://www.biconomy.io/ is one such organisation which is helping people sponsor gas although with meta transactions.

Objectives

1. Deploy a Paymaster smart contract.

2. Configure basic rules that will govern the type of user operation the organisation is willing to sponsor. I have listed a few below, this list though is not polished:

   1. Sponsor first X transactions by a wallet while interacting with Y contract.

   2. Sponsor all gas fees up to $X while interacting with Y contract.

   3. Sponsor all the transactions while doing an airdrop - one-time paymaster.

   4. Sponsor gas of people who hold a specific NFT.

Problem it solves

1. Onboarding the user is tough, it is super irritating to have the native token of the blockchain at all times. This creates a layer of friction for DAOs when users are interacting with them.

2. Deploying & maintaining your own Paymaster would require all organisations to have a developer at hand.

3. Once the above two problems would be solved, it would also lead to the problem monitor all the transactions they are sponsoring. This will be super helpful to calculate CAC for an organisation & also see the ROI they are getting from these transactions.

Implementation

I am yet to start working on this project, I have started helping stackup, an on-chain EIP 4337 compatible wallet with developer documentation. This I believe helps me give a better understanding of EIP 4337 & also see things in action. Then I would start building this service.

Implementation Plan:

1. There are two ways I can go from here. Create multiple paymaster contracts with configurable values and deploy on demand. Or create a master paymaster which will allow the execution of multiple strategies based on its deployment configuration.

2. I will as of now use stackup.sh entry point & its wallets for the purpose of this fellowship, though entry point could always be changed through ownerOnly functions

3. I will then create a dashboard which will list all the transactions which will be sponsored and orgs will be able to monitor them. For this, I will be creating a subgraph which will explore the list of transactions that will be routed from the paymaster contract. This is still theoretical as of now and I will have to check its validity.

How would it help Polygon Ecosystem? If we have the capability for organisations to easily sponsor gas and make the web3 experience simpler for users. This would indeed lead to an increase in the transactions that will be helping Polygon’s chain.

Why this project?

While I was investing with Defi across chains, I myself have faced issues where I don’t have the native token of the chain and I have to go back and do the whole thing of bringing gas, which is frustrating! Looking for a solution to this problem I stumbled upon EIP 4337, and I loved the idea. Though soon realised it was still in the early stages. I figured out there are a couple of DAOs who are trying to solve the problem of paying gas in the native tokens, namely: Sequence & Stackup. I have also started working with Stackup & I will be helping them with the developer documentation and contract auditing.

While the above problems solved my immediate problem I also realised that Paymaster service would play a crucial role in future & I don’t see any such solutions for them as of now.

Post the application I was invited for a virtual interview, here are the things we discussed

1. My web2 journey so far

2. What motivated me to explore web3

3. What all things I have tried in terms of development in web3

4. Why I proposed the following projects in my proposals

5. What research have I conducted so far while writing the proposals & am I aware of other people who might be working towards a similar idea

The conversation was mostly fluid and interactive.

Questionnaire

What would you consider to be your standout project? Something which you're really proud of or had fun building

It is difficult to choose a single project, I have fun building a lot of things in my past. I feel, there is one project that I enjoyed a lot though, this was 8086 Microprocessor Emulator. Back in college, while studying Engineering Physics in 2014, I was fascinated to study about 8086 processors. It made me wonder if we could emulate the entire processor in a web browser since computers are much faster now. Using this would enable me to write some assembly code and explore the different types of programs with it mimicking the Silicon Valley era of the 1970s. With this goal of mine, using Javascript I started writing the emulator which would run in a sandbox memory (this included runtime memory, registers & segments) environment & allow emulating all the 8086 opcodes. I ensured that architecture was composable for other emulators to be built in future, while 8086 was the first one to be supported. Each emulator would have a command interface, where each command would take arguments as operands and memory. And each command would either set or get a type of memory (runtime, register or segment). Each command state along with the latest memory snapshot was also saved in the backend so that it can be loaded from any previous predefined state. While tinkering and being able to emulate small programs, this project also allowed me to think at the architectural level.

Why are you applying to the Fellowship and what do you hope to take away from it? [in more than 300 words]

Open source communities have been one of the major reasons for my growth in the past. Back in 2014, I started my open source journey with KDE’s Season of KDE fellowship program and then was admitted to the Google Summer of Code 2015 fellowship program. These two programs have helped me accelerate my career, and build a deeper understanding of software architecture and I expect the same from Polygon Fellowship.

Post the acquisition of my last venture, I have been diving deep into Web3 and running experiments to understand it better. Currently, I am exploring opportunities in web3 where I can contribute or build the infrastructure which will help other DAPPS grow faster. Polygon is the most prominent L2 and with a great Defi ecosystem, can definitely help me with the right mentors to accelerate my learnings and goals. I expect to find such mentor(s) who will accelerate my growth & open doors to new technologies/infra that are in the development stage. My goal is to have a successful project at the end of the Fellowship, a deeper understanding of web3, and solve a real problem faced by others.

Project proposals

My first proposal

https://mirror.xyz/0x6C2265693900a68b9c9CBE2d6Eae3bd9336060db/W-67K1zUgVUcegVar8-2IMhM7y7XL8IlzScFnlwPVQ8

My second proposal

https://mirror.xyz/0x6C2265693900a68b9c9CBE2d6Eae3bd9336060db/wK5DMmVruWhcojT1MJLq9os2HfoRbmbdGCB0GSMXDfc

Deploying the nightfall wallet on the intranet would add another layer of security for organisations to access their funds deployed on the blockchain. An easy tool for them to deploy, monitor & keep a track of wallets would make a world of difference when it will come to auditing. People may leave or join the team in an organisation handling the on-chain payments. Giving the ability for admins to securely create/update/delete/transfer funds from wallets of people who will be leaving the company would give another layer of security over nightfall.

Objectives

1. Ability to control wallets deployed on an intranet.

2. Deposit, withdraw, and transfer from any of the wallets deployed on the intranet

3. Not revealing the mnemonic directly to the end-user (employee) of the organisation’s wallet.

Problem it solves

While nightfall allows organisations to have access to private-public blockchains, it is super important for organisations to also be able to manage their wallets efficiently. People join and leave teams all the time in organisations and managing these wallets across all new and previous employees would be an administrative nightmare. This project aims to solve that problem and make the adoption of nightfall easier for organisations

Implementation

I am yet to start work on this project. I intend to build over the existing wallet implementation https://github.com/EYBlockchain/nightfall_3/tree/master/wallet. The idea is to deploy the wallet on a server, the organisation can then choose who will have access to this server and how people will be able to connect to this (either via intranet or VPN). Admins will then be able to add, remove and manage the wallets. View the transactions that are happening through these wallets. Now the question is how will employees access these wallets and make transactions? For this, we will have org-based authentication, which will allow users to be able to prove their org identity and login into the portal. Employees then will be able to make transactions from the wallets to that they have been given access by the admins.

Why this project?

For nightfall to be successful on the scale, organisations would eventually need administrative services for them to administer the funds smartly. Having the ability to monitor, and manage the wallets and transactions happening through these wallets would an added layer of security and also remove the single point of failure problems if the person who possesses the mnemonic leaves the company. Having this ability of the nightfall will accelerate its growth in the long term and allow for more transparent access to web3 wallets across the organisation.