Making Wallets Programmable with Alokik Bhasin
ETHGlobal·Thu, Oct 9, 2025, 12:00 AM
Join us for a talk by Alokik Bhasin, Group Product Manager at Circle, titled, "Making Wallets Programmable." _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 🇺🇸 *Pragma San Francisco* Pragma San Francisco 2024 was a special gathering of founders and builders that took place October 16th and 17th at The Contemporary Jewish Museum in San Francisco, CA. Pragma San Francisco 2024 was an opportunity discuss the future of web3 and reflect on the past. Watch the full Pragma San Francisco playlist here: https://youtube.com/playlist?list=PLXzKMXK2aHh4LcwDpGf_itZrAu7XRNb07&si=3x3y9J3avgNTITUe ETHGlobal's Pragma series takes place in cities around the world, and is designed to be a different kind of event. Pragma is a one-stage conference with founders-only on stage, bringing together a small group of curated attendees and speakers to discuss the future of web3 and reflect on the past. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ✅ *Follow the Alokik Bhasin* X: https://x.com/alokikbhasin ✅ *Follow the Circle* X: https://x.com/circle ✅ *Follow ETHGlobal* X: https://x.com/ETHGlobal Warpcast: https://warpcast.com/ethglobal Website: https://ethglobal.com YouTube: https://www.youtube.com/c/ETHGlobal _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Are you interested in Ethereum development and entrepreneurship?_ 👉 Sign up for the next ETHGlobal event: https://ethglobal.com/events 🎁 Get exclusive access and perks with ETHGlobal Plus! https://ethglobal.com/plus 📣 Want us to throw an event in your city? Tell us where! https://ethglobal.com/city _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Transcript
And for our next talk, I want to invite our next speaker, Hello Alokick from Circle, to tell us how they're doing more with programmable money. So please give a big round of applause to Hello Kick. Hello, thank you very much, Karthik. Hello everyone. I am Aloik.
I am a group PM at Circle. I focus a lot on how we can create a better experience with stablecoins and increase the utility of using stablecoins. So I couldn't raise my hand quickly. How many of you are familiar with USDC or have used USDC during the last year? Okay.
Plenty of hands. How many of you are familiar with CCTP or have exchanged USDC between countries? Okay. Yes. And how many of you have heard of programmable wallets, which are like Circle's wallet-as-a-service offering?
Okay. Very few. Okay. Brilliant. Yes.
Well, today I'm going to tell you that not many of you have heard of programmable wallets, and that's what I 'm here to talk to you about. This is one of the new offerings that Circle created over the past year, and I 'm going to talk a lot about what it is, why we created it, and where we think these wallets and wallet infrastructure are headed. Circle is an asset issuer. We created USDC. We also created CCTP.
First, I want to talk about why wallets are important in our view of programmable money and making USDC easier to use. When we look at our approach, and I think it's a mission statement, but I think it's super powerful: what we 're trying to do is increase global economic prosperity through frictionless value exchange . And I think what I want to focus on is the path around frictionless value exchange. frictionless value exchange. TRUE?
When you look at stablecoins in general, they are becoming the dominant way in which value is exchanged. It is the dominant means of exchange that exists in the chain. When blockchains existed about 10 or 15 years ago, they started primarily with Bitcoin as the clear asset that people used to exchange value. And over the years you've seen that change go completely from Bitcoin to ETH, to stablecoins, and the volume is significant when you compare it to traditional financial volumes . The value transferred in stablecoins on public blockchains today is almost on the scale of, for example, a Visa network, right?
In recent years it has grown to reach a significant value. Therefore, the exchange of value is happening very well with stablecoins, and we continue to talk to thousands and thousands of companies that use USDC in different ways. These are like full-chain primitives, like DeFi, that use USDC, the ERC20 token DeFi, that use USDC, the ERC20 token , in their DAPs, right? For more traditional companies that use it, such as fintex, payment providers, and a lot of different people around the world, both off-chain and on-chain, and how they use USDC to facilitate the exchange of value. And I think we keep hearing that, as more and more people try to use USDC, there's still a lot of friction in the way value transfer is done, right?
Friction, and we think a lot about what friction is we think a lot about what friction is . There was friction for end users, there was friction for developers trying to integrate USDC into their applications, and as we talked to more and more of these companies, it became very clear that much of this friction was actually occurring at the wallet level. Okay, I'm going to point out a few different things that I assume we're all familiar with, right? Nobody wants to manage secret keys. Gas is a big problem when paying with native tokens on each chain.
We are increasingly moving into a multi-chain world and have USDC with different assets on different chains. You still need to remember different directions. There's a simple transfer if I need to make it to any of you. It's just two or three lines of questions to make that simple P2P transfer. You have to sign for each transaction.
Just a bunch of basic problems that people have. And what end users really want, and what we hear, is just a simple web experience, right? That's exactly what people want. And when you look at the construction side, right? If I'm a developer trying to create an application, all I want is for it to be secure.
This is like Crypto Rails Cryp, everything is cryptographically proven. There has to be a simple, safe, and secure way to do it. It needs to be flexible for different use cases. It has to be scalable, and I think this is very interesting because many of our initial customers, or customers we tried to talk to, were like large web companies, two companies trying to create an application. And the type of questions we get about scalability are like, "How can we support 1,000 TPS on blockchain?
Rails," because that's what they're used to, right? And it has to be grouped together. There's also a lot of fragmentation, like if you're trying to build an app, you have to have like five different providers depending on what you're trying to do, right? And all developers care about is: "Give me a simple developer experience so I can focus on the real problem I want to work on," which is whatever problem they're trying to solve by bringing their users into the chain by bringing their users into the chain . And this led us to create programmable wallets a year or a year and a half ago.
So we launched a beta version on June 30th with a very simple goal, right? How do you enable the Web 2.0 experience with a simple DevX so that more and more people can join the chain? The name is the name, the name explains itself, like for example, how we make wallets more programmable, and that was the key that led me to think about what a programmable wallet is or how we think about wallets and what level of programmability they have. We thought about this a lot and I think we came to the conclusion that the key to creating a wallet is three different parts, and these three parts are equally important and fundamental to the functioning of wallets.
Obviously, one is the whole part of the account. You have externally owned accounts , EOA accounts, or smart contract accounts , and how that part can be managed. The next thing you need to do is protect the key, right? And the third part, which we also believe is a very integral part of how a wallet should work of how a wallet should work , is the blockchain infrastructure , which is how you read and write to the chain at scale. I think it's easy to do, for example, a few read/ few read/ write transactions on the chain.
But when you think about thousands of types of transactions, when you think about enterprise scale, it becomes much more interesting. And based on our initial customers, who used to be web companies, we thought: "How can we make the key management layer and blockchain infrastructure extremely programmable?" How can we create simple REST APIs that make it easy for the developer to create a key management solution? We got to the MPC backup keys that were controlled by the developer or the end user, as the name suggests. In one case, the end user has full control, and in the other case, the developer has full control, and then you can read and write to blockchains at scale.
So I 'm thinking about large, enterprise-scale companies trying to move to blockchain. How do we make it possible? Our first anchor client or use case that we launched with was Grab. For those who don't know, Grab is like a super app in Southeast Asia with nearly 200 million users. Well, they think of them as a mix of Uber Door Dash.
It's like a super app that many people use in Southeast Asia. And they had a simple request. They wanted to climb. They wanted to focus on use cases and, as you can see, they were trying to get a lot of people to connect to the chain or create a sort of invisible Web 3 wallet embedded within their application. And they needed simple things, didn't they?
And we started working with them in June or August of last year. And it was one of the first enterprise implementations of 4337 compatible smart contract accounts because we thought gas management was an important part of what they wanted to offload important part of what they wanted to offload . And this is just one example. We see a lot of other different companies trying to connect to the chain there trying to connect to the chain there , like a big publisher trying to make payments in USDC and working with Readpay, which is trying to get credit or debit cards that are fully backed on the chain. Well, many use cases of what we like, such as real-world use cases of using USDC, required this highly scalable wallet, right?
But we keep coming back to: "What do you think of the experience, when you built programming capability at the blockchain infrastructure level , as well as at the key management layer?" I don't think it's enough. What we're getting at is that you still need one-click experiences, or actually no-click experiences at all, right? You still need things in the chain. Much of what we 're building is essentially off- chain logic to enable an on-chain use case , right?
And that made sense in a world where gas prices were very high. But we are increasingly moving towards a world where gas prices are low. Much of that code that is actually off the chain may be on the chain. And the third thing, which is extremely important, is that it has to be without custody. I believe that creating a good user experience is very easy if you have the key under control, but it is extremely difficult if it is not safeguarded.
That's why many transactions are still carried out today on centralized exchanges because of that simple user experience, which we think about a lot and wonder how we can make the account layer of a wallet as a service much more programmable, service much more programmable, right? We were much more focused on the other two parts, but what if we made the account creation part much more focused and much more programmable? And that's what I wanted to talk to you about today, which is: we're very excited to launch modular smart wallets, modular smart wallets, right? We believe this is the direction wallet infrastructure is heading, and this is what we think is super exciting in terms of what we can do and all the great experiences we can enable. What are modular wallets?
Modular wallets are simply modular smart contract accounts that make the account side much more programmable, right? They are completely chained together. There are a lot of different smart contracts that can extend the functionality of a wallet. On the right, as you can see, you have a base account and you have different types of modules that you want to extend the functionality of an account. Someone might have access keys, someone might have session keys.
And it's basically a simpler way to create a portfolio. I'll talk a little more about why we believe this is important, but I think the crux of the matter is that all of this is interconnected. With things in a chain, the code is always the law, right? It's always available, right? It's always available, right?
It's open. These are smart contracts. Anyone can use them. You can add a smart contract and extend its functionality. We are co-creating a standard around this ERC6900 for modular smart contract accounts.
Therefore, they are extremely easy to compose for anyone else to write them. We are not the only ones who write it. There are many people trying to write composable smart contracts that anyone can connect and that are very flexible so that you can have a specific user experience depending on what you are creating. I'll share an analogy, which isn't perfect at all, but I think it's something I've been thinking about a bit. For example, you have third-party owned accounts, and that was the predominant way people transacted, and it still is , right?
And the analogy is very similar to a basic telephone; It does two things: it signs a message and stores assets, much like how basic phones were extremely good at sending an SMS or calling someone, right? Extremely good for that use case. And then I started seeing some examples surrounding smart contract accounts, right? I think there were a lot of smart contract accounts before account abstraction in 2023. You had, for example, a lot of different people trying to create very good smart contract accounts and they did a great job in certain use cases, right?
But there's the real analogy; it's very similar to when smartphones were trying to build both the hardware and the software, right? And I think with account abstraction, smart contract accounts obviously became trendy in 2023. Last year everyone was talking about account abstraction, it's still being talked about, and it's a key to unlocking the user experience. But I think this is heading towards modular smart contract accounts, modular smart contract accounts, right? And I think of this more as the smartphone moment for wallet infrastructure, right?
Much like how the iPhone and Android built these app stores, they were highly composable systems where people could build apps and enable more features; very similar to that, like these ERC and these different standards, and there are two standards, 6900 and 7579, that focus a lot on building modularity at the wallet level, and it's not like wallet developers write; Any DAB can write a module, anyone can write a module. What is an example of that? We have many companies that focus on "How can we store our USDC much more securely?" Right? I think you can create an account with, let's say, three different modules.
You can have, for example, a weighted multi-IG, you can have a chained whitelist, you can have spending limits; all of that applied in a chain. Therefore, you can get a base account and get these three modules, and all of that exists in a chain. You don't have to write any off- chain code or rely on any off-chain providers to get those features. TRUE? We also have many people who want to exchange value without friction.
So imagine something like a DAB creating an integrated smart wallet. And what they really want are very simple, automated experiences. Therefore, you can have a base account that has access keys for a different type of key management. You can have something like session keys where you can grant scope permission to a specific address to withdraw money at regular times. So think of it as a circle.
We're thinking about things like, "How can we enable USDCled subscriptions on-chain?" and things like that. And much of that can be enabled through these modules. And it's important to know that it's not just the wallet developer who 's building these modules, 's building these modules, right? As USDC, as an asset issuer, we can also say, " asset issuer, we can also say, " You know what?
This is a good example of how someone can use USC or how someone can use, ahem, CCTP." And we created these two modules, and suddenly any wallet that is compatible with this standard can start using it. I think that whenever you build something modular or try to build something composable, standards are very important. I think we do n't want to be in the app store and the Android store, where it's like a closed ecosystem that no one else can build. The openness of the standard is important and we adhere to an ERC6900, which is a modular account standard written by engineers from Alchemy at the Ethereum Foundation, Quanstamp and some engineers on our side.
And the idea behind doing this is: can we make it open? Can we make it composable so that anyone can build on these standards? And I think that, as happens to me, when I think about what the 10X wallet is, I think that having, as a developer, when you try to build that 10X wallet, having programmability in every part of the system, account creation, key management and blockchain infrastructure , I think is very important, right? And then you can choose which use case you are trying to solve use case you are trying to solve , and how you want to solve it seamlessly. So, as I said, we will soon be announcing and launching modular wallets.
We're going to work on a lot of different modules, like a wallet as a service provider, but also like USDC and CCTV. We will discover how we can further improve the USDC and CCTP user experience by creating more modules that anyone can attach to their wallet to make it more extensible. These are some of the modules we are working on, some of which we are writing, others that we are working with, as ecosystem partners, to write ecosystem partners, to write . But we're always here, uh, if you want to learn more about the modules, if you want to talk about how we can further improve the stablecoin experience, uh, we'd be happy to talk about it. Thank you so much.
Automatic transcript — names and jargon may be misspelled.