diff --git a/content/interviews/nair-open_networks.md b/content/interviews/nair-open_networks.md
new file mode 100644
index 0000000..a123851
--- /dev/null
+++ b/content/interviews/nair-open_networks.md
@@ -0,0 +1,256 @@
+---
+narrator: Sujith Nair
+subject: Open Networks
+facilitator: Nathan Schneider
+date: 2025-10-24
+approved: YYYY-MM-DD
+summary: "An architect of India's digital identity and payment protocols is now building a protocol for nearly any kind of commerce."
+location: "Bangalore"
+#headshot: "first_last.png"
+topics: [decentralization, economics, government, identity, open source, organizations, software, standards]
+links:
+  - text: "Beckn Protocol"
+    url: "https://becknprotocol.io/"
+  - text: "Foundation for Interoperability in Digital Economy"
+    url: "https://fide.org/"
+---
+
+*Can you tell me how you like to introduce yourself?*
+
+I see myself as a digital plumber who solves for three fundamental things. One is, what kind of digital plumbing restores agency to people at a humanity scale? Second, how do you keep choice at the core of it? Choice should always rest with the individual. Third is the equation of power. I think most of the time, in the pretense of empowering, we actually seem to be extracting power with whatever we do. How do you solve for that and think of digital plumbing to facilitate equalizing power?
+
+I also see myself as an eternal student of the idea of the internet---not a particular version of the internet, whether it's version one, two, three, or whatever number you want to have, but the core idea of the internet. I think that's such a powerful idea.
+
+A digital plumber has to solve for the three things that I said, but most importantly, it's putting people back in the center. I think that's fundamentally what I want to see myself as: a plumber with a certain set of objectives that I want to solve. I'm a protocol builder in order to do those things.
+
+*Let's talk about the story of how you got to this point of working on building national and global protocols. When did you first come to understand yourself as a plumber?*
+
+There's a bit of a story before that. I'm an electronics engineer by training. As an electronics engineer, one of the first things you learn to deal with is the economy of resources that you have to do something. Today you can write any cool Java code or vibe code and get what you want out of it. But if you're dealing with only so much memory in a chip, and so many instruction sets, and you want to get very complicated logic to do something, you realize that you only get one chance to write the whole thing and compile, and it's going to take four hours of your time. I think about computation at a more fundamental level. That's ingrained in my training.
+
+I went on to do a whole lot of things. I've been a software engineer, I've been a management consultant. Luckily, I ended up doing management consulting in public sector spaces. Most consultants will look at how to improve clients' shareholder value in some sense. For me, the impact was quite evident from day one of my job. The scale and impact that you have with public sector projects is phenomenal, so you embrace that idea very quickly. Scale is at the heart of how I design. In India, we see scale as the fundamental design criterion. It flips us from thinking about *scaling what works* to asking *what works at scale*.
+
+What works at scale is something that I learned at a very interesting moment. I was a management consultant, and I was always finding it hard to come to terms with being a problem solver, because most of the time, the solutions that I had been building didn't seem to be working. Problems are always shape-shifting, problems are complex. You're probably using one vantage point, one perspective to study the problem. There are so many others---society, habits, anthropology, all kinds of things. I realized that I was always at odds with the idea that I'm not able to solve enough parts of a problem.
+
+Then I walked into a project, the ID project called Aadhaar. For me, it was the key inflection point in my life. That was where I finally realized that you will never be able to solve the problem as a lone hero. The problems are too complex, too diverse. And solving problems at scale is a whole other proposition altogether. That's when I realized that you don't have to solve the problem, you just have to find a way to distribute the ability to solve it.
+
+If you can distribute that ability to solve, then you're creating optionality for many solvers to come. Some people will solve for one context, some will solve for different contexts, but overall, there's an abundance of solutions that you're introducing, and that abundance will figure out enough options. Maybe your problem is solved in different contexts in different ways. That is what I learned with the Aadhaar project.
+
+*Let's talk about that project, because it's a foundational piece of the India Stack. Talk about how you got involved in it, what your role was, and explain a bit about what it is and how it works.*
+
+I was a management consultant with Ernst & Young, and I was brought in as a team lead for one of the many tracks of the Aadhaar program. One of the first roles I was entrusted with is to get the whole biometric system that de-duplicates---that proves you are who you are, and you're unique, and there's no duplicates of you. That system had to be set up for the initial scale of two hundred million people. It was the largest system of its kind in the world at that time. This is 2009, 2010 we are talking about. My job was to get it running.
+
+I didn't even understand biometrics or image processing, and it's not an exact science. There's a certain amount of non-determinism in that technology. I was sitting with these experts, because nobody had done this at scale. U.S. Visit probably was the largest then, about one hundred million. But we were talking about two hundred million, which needed to extend itself naturally to 1.4 billion.
+
+The good thing about scale is that it forces you to fundamentally question all your boundaries and constraints. It forces you to think in first principles. Most of the time, scale makes your requirements for the problem look dumb. It takes away some of those requirements we think about for enterprise-scale or organizational-scale problems. You take away those boundaries, and you suddenly think, "Oh, I was probably working with wrong assumptions here." That's what scale does to you.
+
+At the time, biometric technologies were still evolving and not mature enough to support population-scale deployment. Rather than committing to a single technology path or assuming today’s tools would meet tomorrow’s needs, the team recognized that the real challenge was not procurement, but innovation at unprecedented scale.
+
+This led to a fundamental reframing of the problem: instead of purchasing a fixed biometric system, the focus shifted to creating a competitive environment that would continuously improve performance over time. The solution was to treat biometric de-duplication as a service, not a product---opening it up to multiple providers who would compete on outcomes rather than implementation.
+
+By abstracting the system into a black box and evaluating providers purely on accuracy, speed, and efficiency, the architecture encouraged rapid algorithmic improvement without locking into any single modality or approach. Scale itself became the incentive for innovation, pushing providers to constantly refine their methods.
+
+This model delivered two powerful outcomes: it future-proofed the system against evolving technologies and dramatically reduced costs by driving efficiency through competition rather than relying on upfront assumptions. The broader insight was that large public digital systems benefit most when procurement is designed to catalyze sustained R&D, not just to acquire software---especially when operating at national or global scale.
+
+*The core thing that you were doing was managing the protocol among these different actors who were providing the actual biometrics.*
+
+I was just given four and a half months to do all this. We were ready to go live in four months. Nobody slept. But we were a little high on this idea of solving for something unprecedented. Scale gets you excited. It's a moonshot. When you're dealing with moonshot success rates, you become much more free to try things. Those are the things that excited me. That was my first role in the Aadhaar program.
+
+Then I worked very closely on the rest of the program strategy as part of a larger team. I worked very closely with the chairman, who's now my co-founder, Nandan Nilekani, and also with the chief architect, who's also a co-founder with me now, Pramod Varma. He's pretty much the architect of everything you've seen---Aadhaar, UPI, Beckn, and all of that.
+
+Throughout that process, I've been listening to how they were thinking about framing the problem. I don't think anybody in 2009 would have framed the way Nandan framed it. He said, "Aadhaar is an infrastructure. It is not an ID, it's not a solution, it's an infrastructure." I was like, "Wow, I've never heard that framing before."
+
+I didn't have the vocabulary then, but I understood the essence of it. I understood that infrastructure distributes the ability to solve. A solution is over-curated with a certain notion of a solution. But if you have infrastructure, it unlocks many solutions, both public and private---context invariant, context-intensive, all of that. That stuck with me as a theme, as a motive that I would build and shape the rest of my career on. How did that manifest into protocol? This way of thinking is deeply enshrined in everything that I do as a design.
+
+In fact, if you come to our Bangalore office, we have a little forest inside a glass cube called a vivarium. That is emblematic of how we think: forest. What's a forest got to do with protocols? What does a forest have to do with the internet? Because we think that nature has something to tell us. What's the difference between a forest and a garden? A forest scales bigger, faster. It doesn't need a gardener. A garden needs a gardener, because it's curated. The gardener believes that this is how the garden should be. But a forest is something that creates its own diverse flora and fauna, and also maintains an equilibrium. It's a self-sustainable, fast-growing thing. When you think about what works at scale, you should think about forests---not gardens.
+
+With a garden, you have a sense of control. You curate what you want. You pave the way for what you want. With forests, it's emergence. One of the first things you have to do as a plumber is to let go of being the lone hero trying to pave the path. Assume that if you set up the infrastructure decently right, there will be solutions that are unforeseeable, even by you. That's what, for me, forest is the metaphor I use for the internet. Because there's nothing in the design of the internet that'll tell you that after fifty years there's going to be a ChatGPT, or thirty years hence, there will be Amazon. It was unforeseeable by the builders of the internet and by the design of the internet. To create this flywheel of value creation---unforeseeable, constantly scaling up like a forestry of value---is my primary motive for building infrastructure and protocols. Protocols are so important because I'm looking at building forestry with that plumbing, not curating solutions.
+
+*Can you describe some of the real-world impact of these tools? How have biometric identity and payments changed life on the ground in the Indian context?*
+
+When I was doing Aadhaar, we had no inkling of what was going to come, but I had a sense that it's not going to stop with Aadhaar, because this way of thinking is so powerful that it'll create new design patterns. Soon after that, Unified Payments Interface, or UPI, kicked off. This is 2009 we were talking about. The iPhone is out, Android is on its way, the App Store is all there. In India, for a country as big as it is, banking penetration among adults was 18 percent. This is 2009. You know that in nine years, we went from 18 percent to 85 percent?
+
+That had never been done in the history of an industrialized civilization. I mean, the Bank of International Settlements said it would take fifty years. We did it in nine---not because we opened up more banks, or more banks went to the villages in the rural parts. It was a different framing. We said, "Instead of taking banks to villages, can we take banking to villages? To take banking to villages, the cost of banking has to plummet."
+
+It required infrastructure to make those know-your-customer costs plummet. With Aadhaar, we created this very simple extension wrapper called EKYC, with which the cost of KYC fell from about $12 per person to about $0.03. It became easy to get anybody a bank account---even for a guy who could put in only a $1 deposit, it's worth it. The cost of banking had come down because we worked with the abundance that was available.
+
+Normally, when you solve problems, you have a scarcity mindset. But Aadhaar and UPI worked with abundance. The abundance was mobile phones, data penetration, and low-cost data. India went from consuming one gigabyte per capita per month to one gigabyte per capita per day. Smartphones were everywhere. What could we build around it? That is how we enabled banking. Regulators and the government saw the value. This was a time when people really wanted change. We just took that, grabbed that, and went ahead.
+
+The same framing of the question set us on the path of UPI. With payments, we were at just about one hundred million or one hundred and twenty million transactions a month---probably what a Portugal would do. Today, we do twenty billion transactions per month, all on UPI. I'm not even counting the three hundred million that MasterCard and other providers have grown up to from one hundred million. Again, it came from finding the abundance around which we could make payments so cost-effective that everybody finds it just natural to do? It should be cheaper than moving physical cash.
+
+Again, where is the abundance? Mobile phones are abundant, printing a QR code is much easier than pushing sixty million clunky point-of-sale machines out there. We unbundled the banking experience from the bank. We created this ecosystem of apps, which became like massive payment browsers in some sense. The money still remains in the regulated, safe bank. But the protocols give you an experience pipe. I can use different apps like Google Pay or PhonePe, and add all my accounts across five different banks in one place. I can have one experience. I can split it across five apps if I have to. But that unbundling of the experience of banking, and reducing friction in the experience of banking, converted digital payment into a population-scale habit.
+
+It's a point of no return. It's like the internet. Today, you can't really take the internet out of your life. UPI was the juggernaut, but even we never thought it would be that big. It hit a tipping point.
+
+*What caused that tipping point? Was it a particular set of actors adopting it? What made this take off?*
+
+Two to three tipping points. One came as a black swan event: India demonetized a few banknotes in 2016. That created a cash shock. But, as we say, we were prepared to be lucky when such events happened. The larger tipping point was that payment became accessible. It became as simple as checking a WhatsApp message.
+
+The mobile phone was becoming easier with touchscreens and all of that, making it very intuitive for anybody to use any app. That habit was kicking in. Cameras were available abundantly, and QR codes were easy and innocuous for everybody to scan. We were filling payment rails around them. Then demonetization was the steroids for it to take off.
+
+*On identity and on payments---those are things that private companies love to own. While you were building these protocols in collaboration with the government, were there companies trying to own the rails for themselves?*
+
+I would always assume two things. One, there will always be these animal spirits in the private sector that want to own the whole thing, own the whole pipe. Second is there'll always be governments without capacity to keep them in check. These two, for me, are features, not bugs. The question is, how do you work with them? That's where design and architecture matters.
+
+Because it's an open protocol, what it fundamentally has is no surface area for a takeover. Nobody has a kill switch. If Google walks out, it's not like everything else is going out with them. There are a hundred other apps that will jump in. Banks are always there. We created an open playground. Everybody can participate, but nobody can take over the ground in some sense. I think that's a very important feature of design. That's why protocols are less extractive than platforms, and UPI made sure of that by design. That keeps the private sector in check.
+
+The other thing is, how do you draw them to you? If they can't take control, maybe they will fight it by staying away. It's a whole other thing to draw them in and make them use the system more. In India, we have the benefit of opening up scale. We went from one hundred million to twenty billion as a market expansion. It was so rapid and so big that nobody could afford to stay away.
+
+At the beginning of the UPI, the biggest banks and the biggest wallets said, "We don't need it. We don't need it, we won't touch it." They thought that they had enough. With protocols, you flip the question by saying, "Okay, you want to be a market leader? But do you want to be a market leader in a ten dollar market or in a one hundred thousand dollar market?" If the base is growing, you might be caught napping in a smaller market, being a dominant player there. In places like Brazil and India, scale creates a healthy attraction for private players to innovate on top of it. Despite their VC-funded motives to always keep securing their moat, they realized that there is a lot more to gain by embracing the protocol than fighting by it.
+
+It was a very India-style playbook that played out---the demographics, a young population, mobile-first, large scale, all of the narratives. I won't say that with protocol you'll always achieve this. Sometimes it won't work. But we had all those elements supporting the design. I'm glad we did this instead of putting another big, government-run payments app or a platform by itself.
+
+*My first encounter with really widespread QR code payments was in China---basically all under the WeChat umbrella---and India was able to go a different route.*
+
+Both probably achieved the same objective, but the route was very different. Of course, in China, government has a lot of say in the big companies. In India, we didn't want to make that assumption. Most of the tech companies in India are U.S. companies in some sense. We have Amazon, we have Uber, we have all of them here. We wanted to open up the economy, and I think it really makes sense. Therefore, we wanted an infrastructure that is more techno-legal. We wanted the technology to have the legal compliance and competition economics baked into the design, rather than leaving it to the institutions and their capacities to fight for those.
+
+*How are these protocols being governed now? How are corporations and the government now involved in their development?*
+
+Great question. That has also been an evolution. When we started off with Aadhaar and DPI, they were pretty top-down sovereign efforts---government-funded and government-initiated, government-operated. We went from that to this new stage with Beckn, where we're completely open to participation from civil society, the market, and, incidentally, government. We're keeping it as open as possible. That has been an evolution. We went from sovereign platforms to sovereign protocols. UPI is sort of a sovereign property of government of India.
+
+*Is it still stewarded largely by the government?*
+
+In a way, yes. I mean, if you look at NPCI, it's a Section 8 company, like a 501(c)(3). But RBI, the central bank has a bit of a view in it. NPCI was created by a set of all the banks in India, so the banks are the shareholders of that. But because they're all banks, and because it's payments, it comes under a very clear regulatory cover. Now, with the protocols that we're building, including many of the same authors of those earlier protocols, we are very consciously saying all our protocols will be born open source. It'll not even be owned by the authors. It's all supported by the community, and there's governance that manages it.
+
+I have a view on governance in general, which is a departure from the European view of governance. Governance has to emulate the life of adoption. I've seen protocols that come with very elaborate governance structures but little adoption to speak of. I think the best way to protect the integrity of a protocol is to drive adoption, and then stabilize that with governance. Governance, for me, is an add-on stability control, rather than a way of saying, "I will not trust anybody from day zero, so I will start governing it as if this is the only thing I'm born to protect." Until and unless you embrace value---until the protocol creates and generates value---governance becomes an academic exercise and the protocol can become over-governed.
+
+If you really want to govern things, put it out there. Get enough people to put their stakes in adoption. Then you would actually do a better job governing it. How you evolve the governance has to be in sync with adoption.
+
+Everybody follows TCP/IP because it makes perfect sense to follow TCP/IP. You don't want to create another protocol because there's so much value on top of TCP/IP. It may not be the best design to do what it is expected to do, but it got adopted. I come with a very practical mindset, and I'm not here to build the most beautiful protocol, or the most elegant protocol, or the most perfect protocol. There's no such thing as a perfect protocol. What matters is the protocol that drives practical adoption at scale.
+
+That's a very pragmatic, Indian playbook that has delivered results multiple times. We look for adoption as a way to improve the quality of the protocol. There's no way we could have put fifty people on the committee. If that governance committee were to make an improvement, it would have taken two decades.
+
+*I wonder if you could say a bit more about the role of government. In many of our countries around the world, we have, to put it mildly, shifting notions of civil liberties. Questions of speech and identity are very much contested. How do you understand the role of government in these systems? What risks do they present, for instance, for the ability of government to control data and economic flows? What are the risks here, and have you seen them play out in ways that concern you?*
+
+The fact that we live in that kind of a world---it's a feature, not a bug. There are different ideological takes and positions. Swing to the right, swing to the left---what's stifling civil liberties versus what's maintaining order. There are different views. I think it's important to be a little dispassionate and indifferent to that when you're designing protocols.
+
+I would let the users and the beneficiaries pick. Our job is to give them the choices. At a population scale, I think people can understand what liberty is. Give them choice and agency, and make sure that there is not only one position from big tech. You know you are the product if I'm giving you free everything, so you become my product, and I keep harvesting you. You're monetizing people. I want users to feel they're empowered.
+
+I don't want to be an activist and ideological in my design approach. I just want to make sure that the fundamentals of what I think anybody should have are in their hands, rather than somebody else telling them what they need or what they deserve.
+
+*So if the protocol is able to preserve meaningful choice and competition, questions about potential government overreach could be addressed through that competition? Actors in the market can offer a more privacy-protecting alternative?*
+
+My sense is that somebody else will offer a differentiation. If somebody's saying, "I'm tracking, I'm curtailing privacy," somebody else will come and say, "Oh, I will solve for privacy," because that's an opportunity.
+
+It is the case with governments and subnational governments and federal governments. They will feel that tension, and accordingly they'll respond. The question is, do you have the infrastructure to facilitate that? Therefore, for me, not having bias in design is very important. We all have some ideology deeply ingrained in us, and that probably appears in our design. I think the internet has a lot of Western values as compared to what you see in Asia. But there's only so much you can do. How can you make sure that you're still offering enough for people to figure out how to use it for their best interest?
+
+It's not a prescription. It's not a solution. It's saying, we are enabling you to find your own prescription. We can't tell you what the prescription is.
+
+*Let's talk about Beckn, which is the protocol you've been focused on most recently, which adds a further dimension to the kind of stack that you've been involved in building all these years. Talk about what Beckn does, where the idea came from, where the motivation comes from, and what it's enabling.*
+
+Absolutely. Beckn started off for completely different reasons, if I may. I think in 2018, I got a call from Nandan Nilekani and Pramod Varma. I had worked on Aadhaar and had been a volunteer in the rest of the evolution of the India Stack, as it's called today. I went on to do work in urban mobility. I was doing micromobility, I was bringing interoperability into transit ticketing, and all of that. Nandan was taking notice and saying, "You seem to be taking this playbook of infrastructure-thinking to another place." He was very curious.
+
+I remember that Friday phone call. He said, "Let's talk about mobility." When we met the following Monday---I think it was the 18th of November, 2018, we were whiteboarding, and I thought probably Nandan was just curious to know about mobility. I was telling him about why it's so indexed on forms of transport rather than the general purpose of mobility. It's not consumer-centric, it's form-centric. That's how transportation mobility has evolved, but probably we can rewrite that, and it's not about building another platform. We can make it more purpose-centric, not form-centric, and make it more customer-centric. At the end of the day, it has to answer one simple question: How do I go from point A to point B? It doesn't matter who answers, or how they answer it, so long as you get that answer. That's where I thought about a mobility protocol---a mobility UPI is what we thought.
+
+I didn't even realize that was the expectation in the room. You know how the best pitches are the ones where you don't know you're making a pitch? Then he popped the question: "Let's do it." I said, "Let's do what?" He said, "Let's start working on this protocol."
+
+I left my role at a mobility startup, and I started working on setting up the foundation. We knew it was going to be open source, and it's got to be a foundation in some sense. I personally gave it six months' time. I said, "Let's see what comes out in six months, otherwise I'll have to put my resume back out in the market." We wrote the protocol. I'm sure there could have been ten better varieties of the Beckn mobility protocol. But I don't care how good or bad the protocol is, I want it to be adopted. I want the market-making side of it to happen.
+
+We started writing the protocol pretty fast. We went through this classic recursive abstraction inquiry---this inch-wide, mile-deep process. We realized at some point that the underlying grammar of discovery and fulfillment is actually not only about mobility. It is the same between any provider and any consumer for any economic resource. If you take mobility content out of it, then you realize that it's any moment of value.
+
+The fundamental question is, why do you need the consumer and provider to be on the same platform? We did not do that for email. I mean, the sender and receiver can be on two different clients. We did not do that for telephone. I could be on Airtel and you could be on AT&T. Why can't consumers and providers similarly discover each other, trust each other, and exchange value?
+
+We thought that the internet moved value. But the internet moved content, and people construed value out of it. There was no protocol that turned data communications into actually transacting---where you can do a contract on the fly, a contract that establishes a moment of value exchange. Beckn had that. It had all the wisdom that we accrued through our big wins and big mistakes of the last five to ten years.
+
+If it's a protocol that is written in the decade of the 2020s, it has to definitely look much better than what was written fifty years ago. We packed in some of our past lessons. How do we bake policy into it? How do we bake governance into it? How do you reduce the surface area for countries which have no capacity to govern? How do we make sure the protocol manages that within the protocol itself? We realized it could be abstract enough to do anything. At that time, I thought, "Maybe we'll do logistics, maybe we'll do a little bit of commerce." That was the range I was thinking of.
+
+I never in a million years thought that it could move energy. We do about seventy-five gigawatts of energy transactions today on the protocol. I never thought that it could be used for moving energy as value. We're doing carbon trading. We're doing water systems.
+
+It's funny that the same pattern repeats in all sectors. In overly fragmented sectors, the stakeholders are always thinking that there will be some little messiah in the center who'll bring everybody onto one platform. We said no. I mean, if you need a messiah, something is already broken in the society. I said, "Can they not do it directly?" It's not just about two people talking to each other. The two people talking to each other create value for a third person to connect with them. It's a cascading chain of value creation.
+
+It's never one thing. It's always the multiplier, cascading, combinatorial things that'll emerge. Today, I'm doing livelihoods and energy together. How can I use an energy network as a way to generate livelihoods for unemployed youth in Africa? A passive income? If they can use a solar panel and battery and sell it to an open network, the infrastructure is doing its job. Those intersections come by making the protocol as general purpose as possible. This was one of our very important learnings.
+
+When we looked back, I thought, "We should have done this from the first day of Aadhaar." We'd been building DPIs, but they're purpose-specific. We're now at a stage of realizing that the more purpose-agnostic an infrastructure is, the more forest it creates.
+
+Stop building roads for every particular car. Most of the protocols that I see are too purpose-specific, which actually curtails their adoption. We serendipitously got there, but we never thought about it. Now we have learned that being more purpose-generic means you can create that hourglass effect that TCP/IP did. TCP/IP did not know you can do banking or commerce on top of that. But the fact that it existed created all of this. We are not calling it DPI anymore, we're calling it Universal Digital Infrastructure. That's what we're doing with Beckn as a very conscious, purpose-generic effort.
+
+*Is it in any way bound up in the earlier protocols on payments or identity? I mean, what is its relationship to the stack that's been growing?*
+
+It's interesting. With Beckn, we have created a whole new narrative called "open networks." We have created a new category and paradigm. If you're building digital infrastructure, it had better be with open networks and not open source platforms. People are realizing they can create an open networks agri-stack, an open networks health stack, and an open networks energy stack. The World Bank just recently announced that it is taking Beckn to a bunch of countries. They have restructured their tech with DPI and sectoral open network stacks.
+
+Open networks is a category by itself. It's not getting folded into anything, but people are building on top of open networks as the underlying paradigm.
+
+*And so you could mix and match different underlying primitives like identity and payment rails?*
+
+That is true. Each of them are loosely coupled. You don't need an ID to run open networks. I can have an ID, which is a government program, and I can have open networks coming from the market and civil society, and both can coexist with each other. You don't have to bundle them together. They can coalesce naturally. That's the thing about protocols. Protocols do not assume what is on top and what is below. You can always bolt on things, like primitives, and add whole new derivatives on top. Let it happen. That's why protocols are such a powerful way to create compounding value. You can always build things on top of it.
+
+*In this context, you're working as an independent organization, right? How will Beckn be governed?*
+
+We are making protocols fiercely independent and open source, without being controlled by any organization by itself. Everybody can fork it, anybody can use it, but the underlying protocol itself is not under the control of anybody.
+
+There is this very limited, sometimes myopic understanding of open source that it has to be forkable as the necessary condition of being open source. But it's like saying, "I can fork English." English is probably the most OG of all protocols---or language in general, for that matter. If I say that I'll fork the dictionary and look at the screen and say it's not a screen, it's a tree, we're going to lose each other. It makes no sense. The purpose of a protocol is to make sure everybody speaks the same language. By forking, you'll probably break interoperability at its core.
+
+*In practice, forking is usually a kind of nuclear option.*
+
+Forking is important when the governance is broken or corrupted. Forkability is a necessary sustainability feature, but you have to be mindful of the fact that you are making a trade-off at some point. If you're forking, you also probably have to re-establish the interoperability. But I think that's the whole point. In India, we don't say things in English, we speak Hinglish, because there's a little bit of Hindi. All of that is fine, so long as you're not fundamentally changing the language in its structural integrity.
+
+*When changes are made to Beckn Protocol, is it under the control of your organization? Are adopters starting to contribute and participate and have power in that process?*
+
+Yes, there are a lot of contributions that are happening. We're expanding into a more global structure with the help of Robin Berjon from the W3C. We have a healthy process.
+
+Robin and I agree that we don't want governance for the sake of governance. We don't want people to debate until the cows come home about whether it should be that or that, whether something should be asynchronous or synchronous. Show me the adoption and the value, because there are always trade-offs to every decision. We may define some constitutional principles on which the protocol will be designed and architected. If anybody has serious issues with those, that's a big one. But so far, I think those principles could hold their ground.
+
+Currently, most of the adoption is happening in one part of the world, which is mostly India, although we have networks in Kenya and other places. But to bring in diverse perspectives, we thought we should open up the global governance around it. Right now, there are four or five people governing it, some from FIDE and some from elsewhere. But we want to expand that globally. I'm just being mindful about the structure getting so big that nothing happens. I think protocols are generally notorious for slow speed. The pace at which a society wants to unlock value---we want to be at least responsive enough for that. How do you manage agility and governance? I don't think there are right or wrong answers. We will probably adapt as we evolve.
+
+*Tell me a bit about the adoption story. I mean, where did adoption really take off? Were you involved in testing in particular markets, and what did you learn from that early experience?*
+
+We are, by design, sector and mission agnostic. If somebody wants to use Beckn protocol for things that I don't even know about, it's absolutely fine. But we have a few sectors we are very clearly indexed on---like mobility, of course. That's where we started this work. Our first takeoff happened when a peer-to-peer mobility project in Kerala started showing some early signs of promise. But it didn't scale as much as we thought it would, maybe because of over-indexing on how to govern the network. But when we did a take-two of that in Bangalore, it just took off.
+
+Bangalore started because I got a phone call from the drivers. The drivers called me and said they needed the Beckn Protocol, and I was shocked. I said, "Listen, I can't even get half of Bangalore's tech community to understand and appreciate Beckn." Protocol is not the kind of thing that just rolls off the tongue.
+
+I had these taxi drivers and autorickshaw drivers calling me, saying, "I need Beckn Protocol." I said, "What do you know about Beckn? You must have got this wrong." He said, "No, I need Beckn Protocol. You are from Bangalore. What are you doing in another city? We need it here. We would like to meet you."
+
+I met them in a coffee shop, and they came with Figma screens, and a whole lot of thinking around it. I said, "But why?" They said, "I don't know if Uber is my boss or my partner." And there's a political economy. "I can't set my price, I don't have this, I don't have that. It's between me and the consumer, but I have to also take care of the incentives for the company in the middle."
+
+They said, "We think there's a better way to do it. Why should the algorithm pick the driver? Why can't we just show all the drivers and give the choice architecture to the consumer?" They actually designed that.
+
+The best ideas come from people who live in the context. I've always believed that as a protocol builder---I can never be that person. I've always told myself and my team that you'll always be an outsider to the context. Its cares and concerns are something that you will never understand enough. If you recognize that you're always outside the context, and believe that people who live in the context can find the right solutions, then you can enable them. I think this was one such case. It really took off.
+
+Today we have about half a million drivers getting the full ride revenue for themselves. Of course, they need some software that they subscribe to as a daily fee, so it's a paltry sum of about one-third or one-fourth of a dollar. For that, they can use it for the whole day and get however many rides they can.
+
+Here's the other thing that we discovered. This is such an interesting lesson in sociological interactions. We realized that even more than the drivers, the riders loved it. For them, it didn't feel like they're paying Uber a company, it felt like they were giving to society. It unlocked the sense of, "Oh, I have this ability to give something back to the driver." The company that implemented this, Namma Yatri---they call it scaling empathy. You can never get that from a tech platform. This is all about societal trust.
+
+Around that time, just as demonetization was a black swan for UPI, we had COVID. The pandemic task force reached out to me, saying, give us your platform, you need to unlock some of the supply chains. I said, "I don't have a platform, I have a protocol."
+
+I just had to utter these words, "Think of it like UPI for commerce." That set the ball rolling for a pandemic-initiated unlock that went on to become ONDC, or Open Network for Digital Commerce, which has clocked three hundred million transactions---across retail, logistics, food, tourism, multimodal transport, agriculture, and a whole bunch of other sectors.
+
+It's a Beckn network. It has a company, ONDC Limited, with a little bit of support from the government, but it's mostly not government funded. All the big banks and stock exchanges and institutions are involved. Of course, we couldn't take money from Amazon and Uber, but we could take other private capital to fund it as a not-for-profit. Think of it as India having its own commerce internet, so to speak. That's essentially what ONDC is.
+
+Those were the two big takeoffs, and that got people to start imagining more. If I can move groceries, if I can move mobility, can I move energy? Somebody just knocked on the door and said, "Can I use it for EV charging? Can I use it for peer-to-peer energy trading? Can I use it for demand flexibility?" That led to what we now call the Digital Energy Grid. It is an HTTPS of energy, in some sense. Protocols for energy, which are application agnostic. See, these are a natural emergence. The forest.
+
+Seeing that early pattern of the forestry, someone starts saying water, somebody else is saying climate and carbon provenance. We are looking at open data as the basis of an inclusive market economy. There are companies we're talking with about compute on an open network, instead of one big cloud. Can we have a decentralized network of micro-data centers as compute? It's naturally playing into this agentic world, and it's very interesting how this has all been one serendipitous unlock.
+
+We find Beckn being a very critical infrastructure in the world of AI agents. As much as we think AI can amplify Beckn, we think Beckn can amplify AI. We're seeing pretty interesting patterns there, and that's the next thesis I'm working on.
+
+*Where Beckn becomes the way in which agents are able to automate commerce in a structured way?*
+
+Yeah, absolutely. The way I see it, in an agentic economy, it's not just about how advanced the models are or how advanced the agents are. You also need a neutral infrastructure. Business happens at the speed of trust, and you need a neutral infrastructure that produces trust---between agents and with humans and the agents. The analogy I use is that brakes were invented so that cars can go faster. You need a neutral infrastructure to make the agentic economy flourish. That is critical for agents to be a trustworthy companion for doing something of value, especially transactions.
+
+It's an opportune moment, because AI, like the internet, is a super infrastructure. It's a paradigm-shifting technology. We don't want to make the same mistake that we did with the internet, where we created platforms that are more like a digital wrapper of the brick-and-mortar version. Think of Amazon as a wrapper of Walmart, or think of Uber as a wrapper of the yellow medallion.
+
+We don't want agents to be an AI wrapper on old digital commerce models. We're flipping the narrative and saying, what if there's an AI agent abundance, and we put a commerce wrapper on it? This allows us to create a whole new playground, which fixes some of the problems with the traditional model.
+
+We don't want to come from the past. We can come from the future. If this is the abundance, how would you rethink commerce? Before it's too late. Otherwise, we'll have the same thing again. I think there's an opportunity to preempt that.
+
+*I wonder, with all the unexpected emergence in these forests, have you seen things emerge that you wish didn't? Have you seen protocols that you've built used in ways that run against what you hoped they would be used for?*
+
+As a protocol author, you're never happy with any of the implementations. People ask me "Did anything go wrong?" I think everything went wrong! But I think I'm being too pedantic about this, because if you're an English teacher teaching grammar, you'll always be ticked off with the way people speak English in front of you.
+
+But do I see larger systemic risks or missteps that have happened with Beckn Protocol? Not yet. Maybe that is because it has not become a dominant infrastructure yet. It's probably not so important that people are actually thinking about misusing it. But we don't see that yet.
+
+Let me put it this way. Protocols are coming back because of AI. Most of these big tech AI labs are making protocols now---MCP, A2A, and you heard OpenAI talk about an agentic commerce protocol with Stripe. We think that there could be a tendency to push protocols to get their way of doing things. I'm not saying everything they do is bad, but there are, of course, tendencies on all sides. I see that to be an emergent risk, not just with Beckn, but with all protocols.
+
+Now, for example, we have the World Bank, the Googles of the world, and the Microsofts of the world wanting to adopt Beckn. But my sense is, given the heightened consciousness about sovereignty and anti-competition, some of these big companies want to tread that path carefully. I think we can find a way to mitigate those risks. But those risks continue to remain real.
+
+One of the things we want to do is move faster. We are five years old, we are three hundred million transactions old, so I'm assuming that it'll be very difficult for anyone else to circumvent us and create another thing. I have a difficult time explaining in Europe that we work with big tech, but that doesn't mean we work *as* big tech. We don't let them control how this infrastructure grows. They never get to keep the kill switch or interfere in the design.
+
+That's how India can work with them, not work against them. It's not laissez-faire, neither is it like Europe or China. It's a thing of its own, because we have a techno-legal framework to contain everybody's tendencies to overstep. We think that that is the only way you can balance out these forces. Otherwise, it'll become ideological take versus ideological take, and I think you end up losing more in that fight, rather than creating combinatorial value. As long as you take care of agency, choice, and putting power back to the people, you can unlock incentives for value creation on top of it.
+
+I think we can manage it to some extent, but of course there's no guarantee.
+
+*Do you have any other lessons that you want to share from your time as a protocol plumber?*
+
+One of our biggest challenges is that all the great computer science talent has moved away from building protocols. It's a minority that does this work. I mean, if I go to GitHub, Namma Yatri gets more hits than Beckn Protocol. It's funny. A GitHub guy told me, "You've got to be building cool products. Nobody wants to do protocol." Maybe the AI hype will change that.
+
+You know, I've always liked hype, because hype brings speed and imagination with it, as much as there's a lot of slop and froth in there. I'm hoping that AI will bring people back to protocols. I think we need to be getting more talent. One way to get talent is to, *a*, make people see protocols the way they are, or *b*, make them use sexy software that has a protocol baked into it.
+
+Nobody wants to code anymore. It's all vibe coding and all of that, and you've got to play with the trend, but we need to be careful. Protocol builders and protocol contributors are a dwindling minority.