User-Owned AI: On-Chain Training, Inference, and Agents, with NEAR's Illia Polosukhin

Today, my guest is Illia Polosukhin, founder of NEAR, a hyperambitious, multifaceted project that describes itself as the blockchain for AI and aims to build a future where AI belongs to everyone. Illia is not your average blockchain founder. Before starting NEAR, he was one of 8 co-authors of the seminal 2017 paper “Attention Is All You Need,” which introduced the Transformer architecture and helped launch the current AI revolution.

The credits on that paper say that Illia and another co-author “designed and implemented the first Transformer models” and were “crucially involved in every aspect of this work.” In fact, NEAR started as an AI project but took a major detour into crypto when Illia and his team realized just how difficult it was for them to pay their data-task workers all around the world. Today, given his pedigree, Illia could no doubt command one of those mythical billion-dollar compensation packages from Zuck’s Superintelligence Labs. But instead, he’s building the foundational infrastructure for user-owned, privacy-preserving AI that can operate at global scale.

In this conversation, we start with foundational principles and work our way up the technology stack. We begin with an overview of how NEAR’s proof-of-stake consensus mechanism creates security for network participants without requiring trust in a centralized authority. In short, because the protocol is open and permissionless, anyone who is willing to put value at risk can become a validator, and thus no one can prevent the flow of valid transactions.

From there, we discuss how NEAR is leveraging NVIDIA’s confidential computing capabilities to create a permissionless network that allows anyone with compatible GPU hardware to sell inference compute while keeping both the model weights and user data private, even from the hardware operators—all with only a 5% overhead relative to normal computing. To be honest, I hadn’t realized just how affordable this privacy layer had become. While it does require trust in the chipmaker, it’s clearly a huge deal for all sorts of scenarios and does seem to help explain how frontier model developers have been able to ship their models to so many different inference partners without leaking the model weights.

After that, we dig into NEAR’s plans to decentralize model training itself with a process that allows contributors to provide whatever compute or data they have in exchange for a cryptographically guaranteed share of the model’s future revenue. While it remains to be seen whether a community-driven project can produce a 1-trillion-parameter model that performs at the level of today’s leaders, at a minimum, Illia and his team seem to have designed an incentive structure that could make it worthwhile for people to contribute the estimated $100 million worth of resources required to compete at that level.

Finally, we talk about what AI and crypto can do for one another, including how AI might finally put the smart in smart contracts and how blockchain technology can provide stronger guarantees that AI agents will act only as intended. This is something I’ve been envisioning, if only in quite fuzzy terms, for years, and so I was really excited to hear just how concrete it’s starting to become.

In the end, I was so eager to understand the foundational technology on which Illia’s vision rests that we barely had time for the vision itself. But I do think this is really valuable knowledge. The good news is that we’ve already scheduled another recording, so definitely stay tuned for part 2, in which we’ll explore the applications that people are already starting to build at this intersection of AI and crypto and also try to get a handle on the giga-agent future by exploring Illia’s vision for how AI agents will interact, transact, and even participate in governance.

I hope you enjoy this technical deep dive into the infrastructure for user-owned, privacy-preserving AI with Illia Polosukhin, founder of NEAR Protocol.

Welcome to the Cognitive Revolution.

Thanks for having me.

I’m excited for this conversation. I think this is going to be one where I’m going to learn even more than I usually do, because you’re right at the intersection of AI and crypto. Sometimes these 2 technology waves are characterized as different camps that don’t understand each other, or at times are in some sort of online rivalry that may be mostly made up. But I’ve got this sneaking suspicion that I’ve never quite been able to fully develop: these 2 technologies might actually need each other to reach their fullest potential and to do so in a way that we can keep control of them over time.

I’m really excited to dig into all of that with you. For starters, though, if my deep-research reports are to be believed—and this wasn’t hallucinated—I do know for a fact that you were one of the authors of the original Transformer paper. But then I understand from deep research that the project we now know as the NEAR Protocol started as an AI project and then evolved into a crypto project before now coming back to the intersection of crypto and AI.

I’d love to hear a little bit of the story of how you went from being an author of “Attention Is All You Need” to branching out on your own, realizing that you actually needed crypto as well as attention, and bringing us up to the present day.

For sure. That’s good deep research there. My background is in machine learning and AI. I joined Google when I saw—I don’t know if you remember this Cat Neuron paper—where they effectively trained an autoencoder model. They would feed images in, compress and uncompress them to get back the same image, and that model, trained on a bunch of images on the internet, figured out that there was a cat. There was a neuron specifically that, if you activated it, would show up as a cat.

For me, it was like, this is the approach neural networks are working with now. But I think images are not where the knowledge and intelligence lie. I think text is. So I joined Google and was very much like, “Hey, how do we focus deep learning on natural language?” The most straightforward path to advancing and checking the intelligence of any human or machine is to ask questions.

My team worked on question answering, and we actually had some of this in a product on Google.com back in the day. Before Gemini, you would get these short answers. Part of the challenge we had was that the state-of-the-art models were too slow. Long short-term memory, or LSTM, models need to read 1 word at a time. If you feed them a bunch of articles from Google search results, it’ll take forever for them to respond.

That was one of the motivations for Transformers: How do we consume all this context as effectively and as much in parallel as possible, and then figure out how to answer?

After that work, I thought the pace of AI’s evolution was accelerating. This was 2017, and I wanted to build products on top of it. So I left Google to start NEAR AI with my co-founder, Alex Skidanov, on the premise that we wanted to teach machines to code.

That’s something I’ve believed for a long time: If machines can code, we’re effectively changing how we interact with computing. It’s changing from a few people being able to author code and talk to machines, while everybody else effectively needs to consume their magic, to everybody being able to do everything with a machine that normally only a few developers can do.

We were trying to build that back in 2017. That sounded like science fiction. Now it’s just called vibe coding. We were trying to build vibe coding in 2017, and our expectation was that what we were seeing in 2022 and 2023 was what was going to be happening in the industry. As we know now, we’re lacking probably an order, or a couple of orders, of magnitude of compute.

We were trying to be smarter, so what we tried to do was get a lot more training data. Again, it’s called instruction fine-tuning data. We were trying to get people to write a little piece of code for some instructions or write instructions based on code. The people who can do this are effectively computer science students from developing countries, where a few cents here and there adds up to dollars. A few dollars a day is reasonable money for them to work online and practice coding.

The challenge we faced was paying them. People like students in China didn’t have bank accounts; they had WeChat Pay. Back then, in Ukraine, if you received dollars in your bank account, you were actually, by law, required to sell half of them. There was no way to pay into some countries for whatever reasons. PayPal didn’t work, transfers didn’t work, and there were all kinds of weird, pure payment problems that we faced while trying to collect more data.

We ended up saying, “Okay, we’ve heard of this blockchain thing. It’s a global payment network. It should solve our problem.” We were just trying to use blockchain as a solution to our own problem of coordinating and paying a bunch of people.

As we did our research—this was 2018—we realized that architecturally, none of them scaled. They were very slow, hard to use, and hard to build on. So it was like, “Hey, if there was a blockchain with these criteria—easy to use, scalable, with microtransactions at always-predictable prices—we would use it.”

But there was none, so we should just build that and then use it ourselves and come back to AI. We thought we were going to build it in 6 months, to be clear. We were like, “Hey, it’s easy, right? It’s just some systems. We’re going to ship it and come back.”

It took a little bit longer, but indeed we effectively built a highly scalable blockchain focused on ease of use, really abstracting out the blockchain itself from the user experience, as well as being highly programmable. You can effectively run arbitrary software written in Zig, Rust, JavaScript, Python, and so on, on the blockchain as well. Obviously, all the financial stuff—payments, loyalty, remittances—is being run through it. A lot of microtransactions are going through it, as well as a few other use cases.

It is one of the most used blockchains. We have 15 million monthly active users on it. As 2022 and 2023 happened, we started building up the team back into, “Okay, now that this acceleration is happening, and with the new learnings we’ve had through the blockchain experience, where can we bring that vision of ‘AI will change how you experience computing’ forward?”

This is the history. Now, looking forward, the important part is that AI will write code and be able to interact with other tools and systems. You’re effectively removing the need for other apps and even websites, because, as the stack matures, anything can effectively be built on the fly. It can go in directly and get the information you need.

Interestingly, there are a few things happening. One is that devices are going to become more run by what we call an AI operating system. However much people want it to run locally, you will not be able to process everything locally. In the background, you want it to summarize news for you, and so on. You need some way to offload the compute.

The problem is that it needs to have all of your context. That’s how we’re going to get to AI that’s truly helpful: it will know everything about you. But that is a very scary situation if some third-party company has all your data. We just saw everything from your chats being leaked to people in organizations effectively reporting your chats to the police. So there’s already a challenge with how this data is handled by centralized AI companies.

First of all, we want everything to be private. I think that’s fundamental. We want AI to be private. We want AI to have all your context. We want it to be able to go and execute actions on your behalf.

The other interesting thing that happens in this future is that a lot of the existing aggregators, like Google, DoorDash, and Amazon, as well as other middlemen, like the FDA, for example, are middlemen. They take all the pharma filings, process them, evaluate them, and say, “Okay, yes, this medicine is safe on average.” Then they allow pharma companies to stock it.

Your AI can do all this work. It can go and find the factory in China directly to order stuff. It can go directly to the AI of the pharma companies, discuss your exact medical situation with them, and find the exact medical compounds that you need at this moment. You don’t need to check if, on average, it’s going to be good for the average person. You actually need to check if it’s good for you right now, which is what you need to address.

You’re removing this middleman system that our societies are actually built on and going very much direct, peer-to-peer. That could be between different people, people and companies, or even people and autonomous agents. That’s where blockchain comes in on the other side, because it’s effectively facilitating those types of transactions.

There are effectively 2 pieces to this vision. One is how we ensure privacy and verifiability. The other aspect is that if this is how we see and interact with the world—through this AI lens—a small alteration to that AI can effectively lead you to perceive the world differently.

The example I use is, if you go into ChatGPT right now and, at the beginning, say, “Hey, subtly convince me, while we’re talking about some other topic, of X”—let’s say voting for somebody else that you don’t like—and then you go through the conversation, it will actually start working in ways to change how you think about things in the chat on another topic.

This can be an explicit prompt right now, or it can happen indirectly. We don’t know. We also have this concept of what we call user-owned AI, because you want AI to be yours, not theirs. Privacy is part of this, but the other part is that we need to know what goes into the model itself. We need to know and have verifiability that, when you run it, there are no additional ways that it’s actually being affected.

That’s a big part of it. To do that, you need a different model. You need to build a movement, not a company, because if you build another company doing that exact thing, you’ll end up with the same result. You need to build a movement around this idea where people are actually willing to contribute to building this more as a common good that’s accessible to everyone, while creating an economic engine behind it to power it, because this actually requires a lot of financial investment and resources.

On the other side, as this AI becomes your interface, how does it interact with other AIs? That’s where what we call intents, AITP, and other components are coming together. That’s really the vision we’re working toward.

There’s a lot there to unpack. I’m going to try taking it from what I think is the most foundational layer and work up toward the giga-agent future. Most fundamentally, when we talk about this—and obviously, there are a lot of problems in society today, including the loss of trust in institutions—“trustless” is becoming a general description of society, perhaps something that certain technologies can achieve.

A lot of people listening don’t have a great handle on where the trust comes from with different blockchain schemes. I know that, in the original Bitcoin, the idea with proof of work is that it’s really costly to mine a new valid block. Because it’s so costly, nobody could plausibly rewrite the whole chain to the present. You’d have to do that so many times in a row that nobody could really ever get there.

The canonical version is the canonical version, and that difficulty of extending the chain means that nobody can corrupt the history. Unfortunately, that’s pretty costly to run. I looked it up, and I think Bitcoin is consuming the same amount of electricity as the country of Poland today, according to my internet research.

We’ve now seen this move to proof of stake, where you have a lot less compute required, but you have to make sure you have a really thoughtful incentive design. People are essentially putting their holdings of tokens up and putting them at risk—locking them up, putting them at risk—and saying, “I represent that I’m going to do the right thing for the broader community, and if I don’t, I stand to suffer some consequences,” as a validator in the network.

Can you elaborate on that just a little bit? Because everything we’re going to talk about, ultimately, if I understand correctly, is built on the idea that we have a set of validators that we don’t necessarily have to trust as individuals, but we sort of have to trust collectively. We also have to trust that the incentives are such that they don’t have any reason to defect from the stable equilibrium.

Can you give us a little bit more about what that stable equilibrium is that you have designed? Who are the validators? In your mind, what is the ground that people can put their confidence in—that everything else we’ll build on top of this, and we’ll cover, is really on a solid, albeit distributed, foundation?

Yeah, that’s a very good question. To contrast it with our traditional internet right now, we’re using Riverside to record this. We went to Riverside.fm, and we relied on DNS to tell us that Riverside is this IP address. DNS is a distributed system, but it actually has a single organization that effectively decides how it’s done.

Similarly, we have SSL certificates that give us encryption, but there are certificate authorities that issue the certificates, and there’s an authority that gave them that authority. So there are effective points of centralization on the current internet where you cannot verify by yourself that something is correct.

When we think of blockchains, the important way to think about it is from your perspective. You want to verify that what you’re interacting with is correct, and you want to know how hard it is for someone to lie to you and show you fake information. As you said, with Bitcoin, if you’re looking at some state—for example, you just received a bunch of bitcoin—the cost of making that untrue is effectively how much it costs to produce that number of blocks. Indeed, for example, to lie to you about an hour of history costs $2 million.

That’s the idea. With proof of stake, it’s a little bit different because, in Bitcoin, it’s possible that, for example, Google has a lot of servers and could create a fake blockchain that’s days or weeks long, present that, and effectively lie to people and steal a bunch of money. I don’t think Google is doing this, but it’s just to give you an example. With proof of stake, and specifically this idea of Byzantine fault-tolerant consensus, you actually have this notion of finality. If two-thirds of the stake is non-malicious, then they’re following the protocol, and there’s no way to have a fake history or lie to you. You can verify this from the beginning.

We launched the NEAR blockchain mainnet in October 2020, and since then you can verify that every single transition was correct and all the rules were followed. That’s the idea. Now, who are these validators, and what is the stake?

For NEAR, it’s similar to other proof-of-stake projects. There are a lot of projects in the ecosystem, and we have a number of other companies building on top of us. They effectively have a vested interest in the security of the network, so they become participants.

Becoming a validator is permissionless. You can actually start a validator right now. On NEAR, you can also run a very lightweight node. Somebody recently ran a node on an 8-year-old laptop. We also have, for example, a Vodafone entity and other entities like that running nodes, and we have crypto exchanges participating in the network as well.

It’s really about the participants in the network who become validators because they have a vested interest. They have some of the stake as well, so they have both a business interest and a financial interest in the network. They become participants and validators. Then there’s also a community: we have universities and individual developers running nodes as well.

That’s the idea. You have an open network where people can join. We’ve had a pretty large number of new validators join in the past 6 months, and in turn they put some of their money at stake. Other users can also delegate, effectively saying, “I trust this participant, and I’m going to add more stake to them.” Then there’s a reward that’s split between all of them to incentivize them to do this.

This is maybe a really naive question, but if it is permissionless, maybe we could talk about the importance of permissionless versus permissioned. I’m sure you’re following the Tempo project. I don’t know if you see them as a direct competitor—there are obviously a lot of projects out there—but Tempo has Stripe behind it, as I understand it. My understanding, from reading through what they’ve said, is that they plan to start with trusted validators and then gradually become more permissionless over time.

I’m not sure whether this is one of those things where it really is a spectrum or whether it’s more binary. I always say AI defies all binaries, but when it’s something like “Is it permissionless or is it not permissionless?” that sounds binary. How do you become more permissionless? If there’s some permission involved, it still seems like there’s some permission. I’m a little confused about exactly how much that matters.

Then, if I just show up with a node, how do you know who I am or who I say I am? If I show up and say, “I’m Coca-Cola. I’m your new validator,” do you have to meet me in real life? Do you go to the Coca-Cola office and kick the tires on the servers to do that sort of real-world validation?

These are obviously noob questions, but knowing how much I might one day rely on my AI agents built on top of all this, I do want to make sure I’m solid in the foundational understanding.

No, no, these are all good questions. I think permissionlessness is indeed a spectrum, and there are maybe a few step functions. There are a few networks where there’s effectively a very specific set of validators. The issue with this is that, let’s say these validators don’t like you for whatever reason. They can effectively not let your transactions, or your AI agent’s transactions, onto the chain. They can effectively censor you.

That’s the main challenge with even a subset of permissioned validators: for whatever reason, they can exclude you from the network, and you cannot do anything. The benefit of a permissionless network is that you can join as a node yourself and say, “I’m actually going to join the network.” Even if they don’t let me in, I can push transactions and interact with the network directly. That’s the biggest change.

For normal people, it’s not that big of a deal. For people who’ve been through certain experiences—I'm from Ukraine, and I’ve seen different types of situations—I’ve had multiple banks that effectively closed up even though I was a client of theirs. Obviously, there was a war and everything, but things like that are pretty important. It’s obviously important for journalists, but it’s even more important for businesses.

If I’m a business, and the payment processor I’m using—or a competing business—is effectively controlling whose transactions are included and whose are not, or is delaying my transactions, they can affect my business. That’s why there’s this idea of neutrality: you want the ability for everyone to join, because then there’s no single party, or coalition of parties—a cartel, you might say—that can pull on it.

The other question is, “Okay, you want to join, and you say you’re Coca-Cola. You can actually do that, but nobody will believe you because there’s no social signal.” If, for example, Coca-Cola tweets, “We just started the NEAR validator. Here’s our address; here’s how to delegate. Let’s go make Coca-Cola the biggest validator on NEAR,” that would provide the social signal.

The way you identify yourself to the network is through public-key cryptography. You essentially say, “Hey, I’m this validator, this account.” To become a validator, you need to put some NEAR at stake. You need to put some money at stake, and then you’re a validator. You don’t really need to meet in person or do anything. You can be a cat, you can be an AI—it doesn’t matter, if you have some capital at stake.

Gotcha. So anybody who shows up, if they’re willing to make an investment in the currency—which they have to have in order to put some value on the line—that’s the proof of stake: you actually own value, and you’re putting that value at risk. Not at risk in a probabilistic sense, unless you do something wrong, right?

The idea is that, as long as everything you do is valid in your role as a validator, your value is not at risk. But if the rest of the network finds you to have submitted fake transactions or whatever, they can take the value that you put forward, essentially as collateral.

Correct. We have a mechanism for that because, so far, it’s mostly been people having misconfigured nodes. It hasn’t really been malicious attacks; people have just had bugs in their setup. Slashing is when you actually take the money they put at risk, and we only slash proportionally to how much stake actually participated in the malicious behavior.

So if you had a misconfigured node and only had 0.1% or 0.01% of the total stake, you’re only going to get slashed by some multiple of that percentage of your stake, right? So it will be very little.

Now, if a large percentage of the network is coordinating an attack, then they’re effectively going to get slashed fully, because that percentage multiplied by some coefficient will be slashed. That’s the idea: we don’t want to punish people for misconfiguring things, but we want to punish a coordinated attack for whatever reason. It could be that somebody hacked into a bunch of nodes because they had zero-day vulnerabilities and did that, but we need people to have responsibility for their security setups and related things. At the same time, we want to allow people to have individual mishaps.

Yeah, gotcha. Okay. Is there any last foundational question on the security layer before moving up the stack?

Is there any risk of incentives changing in the long term? Right now, the market cap of the NEAR coin, last I checked, was around $7 billion. That’s obviously a lot, but for people who have businesses or whatever, you would imagine that if there were some coordinated attack, the market cap would fall really fast. So you could try to hijack it, but what have you won, sort of? I imagine that’s a big part of it.

But in the fullness of time, if we imagine a massive AI-agent economy built on top of this whole thing, is there ever a point where it could flip from “It’s not worth doing a coordinated attack” to “Maybe it could become worth it”? Instead of $7 billion, maybe it’s $7 trillion or something like that?

Well, if the network were worth $7 trillion, then the attack would cost, for example, 30% of that. If somebody can come up with a couple trillion dollars to attack it, the question is: that attack will not be able to extract much, right?

This is where the question is about you as an individual, because an attack is directed toward someone. The system itself, from its perspective, is always correct: it follows the rules. If somebody violates the rules, they’re not in the system.

The only way to attack is effectively to attack you by saying, “Here’s the fake information. For example, I sent you $1 billion. Give me $1 billion of services,” when I didn’t actually send you $1 billion. I just lied to you by creating—by faking—that there was actually a transaction that happened and that it had been finalized.

To do that kind of attack, you’ll need effectively 66% of the stake. So if the network is at that point worth $7 trillion, you need 66% of $7 trillion, or whatever the stake percentage is.

And then, if you’re receiving $1 trillion in a transaction, you’re probably not going to be like, “Immediately, cool, I’ll give you $1 trillion of value.” You probably can wait a little bit, make sure that there’s nothing else going on in the network. So there’s a question of timing, value, and security that together work.

It’s similar to how Bitcoin works. Right now, Bitcoin is worth whatever—$2 trillion—and the 1-hour attack is $2 million. If you’re sending $10 million, you probably should wait a little bit longer than 1 hour to make sure nobody’s attacking you. The more you send, the longer you should wait to make sure.

The idea is that as the value increases, you can also wait less for larger transactions. That’s why people talk about the 51% attack, and it’s important to understand what that means. It means somebody is specifically getting attacked. It can be an exchange, an individual, a service provider, and so on.

It’s not that the network itself is incorrect. The rules are still followed. It doesn’t matter which so-called fork will end up being picked; from the perspective of that fork, you’re still on the main thing. Blockchain is a little bit of this abstract point of view, in a fourth-wall kind of perspective: are you in it? If you’re in it, you’re always correct. Or are you outside, and are you seeing the right thing or not?

For most use cases, if you’re spending $1, $5, $10, or $100 to buy something, effectively, the security of the network is so much higher that it’s not a problem, and you can accept the transaction right away. For a normal use case of an agent, that’s fine.

The reality is that there are more challenges with the security of zero-days in the code of the systems than with the economic security of this. We should talk about this, because we have a whole thesis on that.

Well, maybe now could be the time. My plan from here is to work our way up to: okay, how do you train models on this? There are interesting aspects of that, and then how do you build business models on top of models and, ultimately, agents? If you want to talk more about that—

On the security side, I think the important part to understand is that as AI is getting better and better, it’s actually getting really good at finding vulnerabilities. I’ve used it to back-test. You take a recently found vulnerability, run an LLM over it, and you don’t even need to over-prompt it; it will find some vulnerabilities in the code. Somebody found a Linux, I think, zero-day with that approach as well.

What this means is that cybersecurity is very one-sided. It’s really hard to know that you don’t have vulnerabilities, but it’s getting easier and easier to find them. The same is true of social engineering and other attacks. It’s just going to get easier and easier.

So we need a fundamentally different approach. That approach actually relies on math. The only thing you can rely on is that the whole system is correct, given—again—your perspective.

From my perspective as a user of the system, I want to know that if I’m doing something, it is actually correct. There are no vulnerabilities in the system or potential problems in the future that can happen. So I want a mathematical proof, at the time of using the system, that it is correct given my requirements.

It’s a very different approach. For those who have been around, it’s called formal verification. There has been a lot of research on this, but because it’s so complicated, nobody is actually doing it at the time of using services.

You may do it, for example, when sending something to Mars. They actually had formal verification of the code for the Mars rover, but it was done once. It’s effectively like, “Okay, we want to verify that it runs correctly and will run correctly given the specification.” But obviously, if anything gets updated or the requirements change, this is not usable, because it’s so hard and requires a lot of manual labor.

The benefit is that with AI, which is getting really good even at winning gold at the International Mathematical Olympiad, we can actually simplify that process of proving itself. What we believe is that we will need to rewrite effectively every single line of code in such a way that it’s formally verifiable at execution time.

With blockchain, this is the first step. Blockchain is kind of a root of trust, so we want to formally verify it so that you, as a user, when you’re, for example, sending money or depositing money somewhere, can say, “Hey, I’m expecting to receive money back—at least as much money.” The chain needs to prove to you that this is actually going to be correct and that it’s going to happen.

But you can expand that to broader services. If I’m using some service, I’m giving it my private data.

I want it to prove to me that it's not going to leak it, right? And so, for that, this is where we're going into verifiable compute in a broader sense. We kind of need both formal verification and guarantees that this code is going to be executed over your data.

So that's kind of our position on zero-day verification. We're actually moving into a world where this is going to be necessary. I don't know if you saw it, but a couple of weeks ago there was a zero-day in iOS and macOS, and everybody was patching. We just had a massive attack on the supply chain in npm yesterday in the crypto space, where somebody injected code effectively to replace addresses in all of the tools.

The amount of this kind of vulnerability is just going to accelerate, and we need a new approach. That's one of the longer-term research projects we're working on to actually solve that. But, yeah, you need a few more pieces. So that's where we're getting into, okay, how do we actually guarantee privacy, run these models with verifiability, as well as build the monetization—the kind of financial engine that actually runs this?

We're using a combination of blockchain, cryptography, and hardware. As of about a year ago, NVIDIA supports so-called confidential computing. What this means is the NVIDIA chip itself connects to Intel and ARM, and even AMD is supported, in such a way that even I, as an operator—the owner of the hardware—cannot access what's happening inside as the operator running the operating system.

This is called confidential computing mode, and the interesting thing is that it gives you both confidentiality and verifiability. It tells you, "This code was run on this data, and only this thing was done." And, by the way, nobody else saw what happened there.

What we're using this for is effectively that, as a user, I can, for example, want to run some AI workload. I can establish an encrypted channel to this secure enclave, run some AI workload there, and then receive the result back through an encrypted channel. I know that there's no other single party that was able to actually understand what I was doing there, and I also receive a verified certificate that says, "This model was run on your input, and this is the output."

There's no way that something could have changed—you know, they degraded performance midway or whatever, right? Or they injected some prompts into the thing, right? It's like you have a guarantee of the execution. So that's kind of the basic primitive of this confidential, verifiable compute.

There are a few sides to this. One is, well, we now need a lot of compute, right? Hundreds of thousands of GPUs need to be here so we can actually provide it for lots of users. One of the challenges with doing that is massive data centers—lots of capex. Now you need a lot of energy; it's all in one place; you have latency problems; you have sovereignty problems. So, all the challenges.

The cool thing is, again, because the owners of compute don't actually see anything, we can open it up and make it permissionless. We can let anyone with compute join. We have a way to verify that the compute is indeed NVIDIA and Intel chips, because they effectively sign the certificates. And now we can decentralize the compute itself.

We can have compute everywhere, joining across the world. We can then route requests to the closest available compute to you. You get confidentiality and verifiability; you can now pay the network, and the network then distributes these rewards very similarly to how validators receive rewards for providing validation of the blockchain.

Here, the compute providers receive rewards for providing compute, and then users pay for using inference, or developers pay for using inference. So that kind of creates what we call a decentralized, confidential machine-learning cloud. And it's not just for AI stuff; you can also run arbitrary compute over it as well: data processing, agents, MCP servers, and so on. You can store memory encrypted for users.

That's kind of the second piece, which again enables that vision of, hey, how am I going to have an AI OS that's truly private and I know what's happening there? This already has an economy; we're effectively bringing compute and usage.

The other challenge is models and data, in a sense. Right now, if I'm a model developer, I effectively have 2 routes: I'm either open-sourcing it and making $0, or I keep it closed source, and then I need to actually procure compute and make sure that compute is verifiable—that I trust the compute provider. Because I'm uploading my weights to them, they can actually steal and open-source my weights or run them themselves.

That's why only big hyperscalers usually partner with Microsoft, OpenAI, Amazon, and Anthropic. On top of this, I also have this maturity problem: if I'm just launching a new model, I don't have any users for it yet, but I kind of need to commit to a bunch of compute from this hyperscaler—usually a 2-year contract. I don't actually know how much I need. If I get more users than I have compute for, now I need to pay a ton more. So it's a very weird economic question. Again, as an economic question, we have tools to do that.

The idea here is that if it's an open-source model, you upload it, or if it's a closed-source model, you can encrypt and upload it to our system. Because all of the compute happens in this confidential environment, we can decrypt the model inside the confidential environment, meaning again nobody is able to access what's happening there. You can run it on users' data privately.

When users pay, they pay both the model developer and the hardware provider the fee, right? So you're effectively now combining model providers and model developers. NEAR AI is offering them a way to serve their models without prepaying. They don't need to pay for the compute to serve it. They don't need to take users' data. They don't need to deal with GDPR or HIPAA, or whatever all the compliance requirements are.

They just push a model in and start making money when people use it, right? So that kind of creates a new economic model for model developers. Similarly, content creators and data providers can upload their data, which can be used at inference time or potentially later at training time. If it is used, you're getting paid from that transaction as well.

Similar to Spotify, there are subscription fees or API-call fees that get distributed to the providers. That's kind of how we see this: you have a cluster of services that effectively all run on the same kind of decentralized hardware cloud, where you can bring models, you can bring data, and there are users and developers consuming this. It all gets secured on this blockchain-based marketplace that really facilitates it.

So, a couple of questions there. We could go on for a long time. I suspect this is fascinating already.

When I show up to the network, I basically just have to have an NVIDIA chip of a certain type that has support for confidential computing, right? That does suggest that there's an important issue. I don't know whether it would be right to think of it as a hardware vulnerability or a software vulnerability there.

From the research I've done, people seem to think that if you gave some of these chips to, for example, the Chinese government and let them bring the full power of their immense engineering prowess to bear on cracking that hardware, they probably could. But it wouldn't really be economical to do it for many things, because obviously these things are exquisitely crafted.

To do some sort of hardware-level modification, you might be able to figure out how to do it. You're probably not going to find it worth your while to try to scale it to some large number of chips. So this would be very focused, hyper-targeted attacks at most.

But then there's also the software question: How do we know that NVIDIA's systems are formally verified, that this is all fully locked up? How much trust is involved, and where are we putting that trust?

And then part 2 would be, how much overhead is associated with this? I did one episode on the use of zero-knowledge proofs to prove that the model was run, and this was 2 years ago. The framing at the time—and it's actually still relevant because, just in recent days, there's been this discourse about Claude seeming to be dumber for me during the day than at night, or whatever—was that if they use a zero-knowledge proof, they can demonstrate to you that they ran the model they promised you they would run.

You're getting the value that you're contracted for. However, at the time, there was a lot of overhead associated with doing the actual zero-knowledge proof. So it wasn't like, for 2% more, you can get a guarantee. I forget exactly how much, but it was a lot more to get the guarantee.

It's like 10,000–100,000×.

Yeah, it was a lot. How much risk is there at the hardware level? How much risk is there at the software level? And how much overhead is there to actually get these benefits?

Yeah. Given that you touched on zero-knowledge proofs, there's effectively a spectrum of how to achieve verifiability and how to achieve privacy. A zero-knowledge proof is effectively how to achieve verifiability; you don't actually get privacy from it. Somebody still needs to run the computation and then compute the proof, so that other third party has all your data. But you do get verifiability that this exact model was run in the specific way.

The challenge is that even right now, the most performant way is probably 1,000× slower than just computing it itself.

It's a lot of overhead, especially since most of the time you're asking ChatGPT to do dumb things. Everybody does. So it only makes sense for really critical stuff.

The other side is this thing called fully homomorphic encryption. This is where you're actually doing computation that is private for every participant, and it is verifiable. Again, the overhead is massive—something also on the order of 1,000–10,000×—but that is fully private and verifiable.

What we're doing with secure enclaves is finding, I would say, a pragmatic middle ground where we trust the hardware providers. We can talk about what that entails, but the benefit is that the maximum overhead we've seen in production—in our testing in production—is 5%. Usually, it's 1%–5% overhead over running without this mode, but you get privacy, you get the ability for a permissionless network to join, and you get verifiability as well out of it.

You don't get that it's dumber at night than in the daytime. You will not get that on our decentralized cloud. So, it's 1%–5%.

The only other challenge right now is that it only works at the level of a single machine: 8 GPUs. We can fit anything that fits into 8 GPUs, which is effectively all the open-source models right now. A model with over 1 trillion parameters fits there, no problem. But indeed, you cannot do this across multiple machines yet. This is in the works right now.

On the software and hardware security side, there is indeed potential for a hardware attack. Right now, the chips are 2 nanometers, which is very small, so we're getting to a level where it's effectively baked into the atoms of the chip. If you want to change something or address it, you effectively—I mean, I'm not a hardware expert at that level, so I cannot actually approximate—but the cost of an attack is extremely high.

The benefit is that you're going to get some random requests from somebody asking which cat to pick, because you will not be able to target specific use cases in our system. Even if something happens there, there is indeed the other challenge, which is NVIDIA. Because NVIDIA is effectively certifying it, their key management and their process need to be correct. This is something that we would love to help secure. Obviously, they're already using top-line security, but that's where verification and using blockchain as a security mechanism can definitely help.

Okay, cool. So let's build our way up the stack. We want to now create user-owned AI. I've seen that you have a plan to train a model with more than 1 trillion parameters. The estimated cost of that is $160 million. It's dropping since we talked about it, so that's a good thing.

Cut it in half. Yeah.

V3 just got cut in half. So we'll apply a half factor to this, too.

My guess—what I understand there is that Dario just talked about this, where he said, "Yeah, we're burning a lot of money." In a way, we're burning more money every generation of scale-up, but in another way, if you look at each model as its own venture, each model is profitable. What's weird is that it might cost us $100 million to train Claude 3, and we make $1 billion. Then it costs us $2 billion for Claude 4, and we'll make $10 billion, but it's going to cost us $20 billion for the next one.

That's a weird development cycle, to say the least. But it seems like you are basically taking that reality to its natural conclusion and actually planning to structure sub-ventures for each of the models, right? So tell me about the economic schematic there.

I also understand that you're applying this secure computing to the training process, where people can contribute training data in a privacy-preserving way. But that's a really interesting challenge, I would imagine, too, right? Because who's providing what data? The data mix—if you talk to people at the frontier companies, they're like, "Yeah, it's like baking a cake. We're constantly experimenting with different mixes: a little more of this, and this other behavior gets degraded," and whatever.

How can you have a privacy-preserving understanding on the training-data side and have any sense of what the hell you're going to get out when the model comes out of the GPU oven, so to speak?

Yeah, all great questions. Indeed, it was funny that Dario posted it, and I'm like, "Yeah, exactly, exactly the model."

Maybe just to give you a bit of a roadmap: building out this decentralized computing, starting with inference, already gives people the ability to consume it, get confidentiality, and get verifiability. The next step offers people who are building models—including potentially existing companies that build foundational models—the ability to upload them encrypted. Nobody can see them, and they don't get leaked, but now they can be used across this decentralized compute. Everybody can verify and know that they're using the exact model that this company has posted.

They effectively put it on-chain—the hash—and the company tweeted about it, et cetera. You can verify that indeed you used, let's say, Anthropic's Claude, and it doesn't degrade in the evenings.

Then, given that we want to coordinate this research and development of models—and importantly, we're not going to build 1 model; that's not the point—the point is to build a process that creates models that are state-of-the-art, user-owned, and inspectable by everybody. Everybody can inspect how they were made.

The important part is how any frontier lab works: there are a number of benchmarks that effectively go through the whole flywheel of building a model. Everybody is building different parts of it and evaluating how their changes and innovations benefit the scaling laws. You test different sizes, then all the ideas get accumulated, and you do bigger runs.

We're replicating some of that as well. We're effectively using this compute network to say, "Hey, actually, anybody can come in and build a new benchmark." You can say, "I'm going to build a benchmark that tests model prediction of the future, or answers questions about astronomy or the ocean," or whatever—different things that people care about.

You can also have enterprises that say, "I care about how this model does on this deepfake-detection benchmark." I can upload my data, but I'll keep it private, so nobody can access the data, while everybody can run evaluations over it. You can now offer both benchmark-creation and evaluation services, where you can verifiably check that this closed-source model runs on undisclosed private data and gets this result.

Again, you're effectively creating this marketplace of model builders and benchmarks, which can represent companies or specific use cases, and finding out what the best models and the best ideas are. That in itself is a really interesting product because, right now, you cannot do that. You cannot actually go and benchmark some intermediate model from, let's say, OpenAI—they just won't give you the weights. If you don't want to upload your data to them, you cannot even benchmark their current model.

This also opens up an environment where anybody—you know, you're sitting somewhere, wherever you want—can train a model that specifically targets whatever ocean benchmark. Maybe you have special data for this; you can upload it and get rewarded when people are using it through the previous step.

Now, the next step is, well, actually, I have a lot of interesting ocean data. Maybe I'm in a university and I know how to train the models, but I don't have compute. That's the next step.

We're actually going to offer you a way to do fine-tuning first. You can take an existing base model, fine-tune it, and again, you can fine-tune it even on private data.

So, I'm maybe an institute that collects a lot of ocean data. I have the data, but I don't have the know-how to fine-tune this properly. So I can partner up with someone who can then fine-tune on my data without seeing it, right? They can effectively deploy this job into confidential computing. The resulting model then splits the revenue between the developer and the data provider. So you can have all of those different combinations on top.

Fine-tuning is, I would say, easier to do when you may not have exact access to the data. Training is where, if we're talking about full, foundational training from scratch, things get really complicated. That's our final step, where we're actually putting all of the pieces together. There, indeed, you need all of those pieces to really work well, so you can effectively iterate on different pieces and sizes and then combine it all into a final model.

I would say, to your point about private data, there are effectively a few things that will need to happen. One is that there's going to be a whole separate process of data filtering, curriculum construction, et cetera, that you can actually benchmark. I can build a curriculum builder: pick different articles and different pieces of data, and construct the training set out of them. So you can evaluate how good that system is by training a few sizes of the models. People can actually compete on whose curriculum builder is better, right? When you pick the best curriculum builder, you run a larger run with more parameters and more data.

It's going to be a very iterative process, the same way it is right now inside Frontier Labs, because we're experimenting with all the things as we go. Specifically with private user data, it's a bit more sensitive and complicated. But the biggest benefit we can provide is that, as you contribute your data, first of all, you can get a reward from the model's outcome.

You can also have a filtering procedure, because there's going to be a lot of PII—your phone numbers, SSNs, et cetera—that you don't want in a model. It's also not actually helpful for the model for the most part, right? This filtering procedure will be open source, and everybody can effectively—not everybody will inspect it, but some developers will inspect it—and say, “Yes, this is actually a valid way to filter data.”

There are a few different components we can use to make sure both that the data is cleaner and that we understand how it gets filtered and processed into the training curriculum. Probably a bunch of your personal chats aren't actually that useful for training these models. There are other types of data that are more useful for those things, and we see that, in general, we're moving toward more synthetic data anyway. So there's going to be a lot more of that.

Importantly, we still have crowdsourcing and data labeling run through this decentralized network as well, right? We actually have both NEAR Crowd, which is the original project we had for crowdsourcing—crowdsourcing in the sense of Scale AI-style—as well as Public AI, which is another data-labeling crowdsourcing project.

How much overhead is associated with all that? You mentioned relatively low overhead at the hardware level for confidential computing, but how much is there in terms of just the software setup? It's not super easy to set up a training cluster. It's not super easy to manage data pipelines. It's not super easy to—I mean, you have a marketplace, but even going out and hiring a bunch of people to create data isn't super easy, even in the base case.

I'm interested in how much overhead there is in doing it the privacy-preserving way, and then also at the model level, who makes these decisions in terms of what's better? I think we have benchmarks galore, and yet it seems like they all kind of—there's been a lot of discourse about this in the last couple of weeks, too. People swear by MMLU; people say MMLU is useless. Certain famous projects are run entirely on vibes.

It would seem like the one thing that you'd have a really hard time putting into this frame would be: who do we actually trust to be the vibe checker on this? How do we make sure that, in addition to maxing out on these various benchmarks, the thing is actually nice to talk to? People do value that a lot.

So I guess I'm asking about overhead in terms of all the setup, the configuration, moving things around, and coordination broadly. Is there a governance mechanism? I know you have governance projects as well that are pretty interesting unto themselves. Are you bringing those to bear on who decides what version of the model is actually good, or what training recipe gets scaled up? Or is there some tastemaker who's still involved somewhere?

No, those are all the good questions. I think the high-level answer is that we're effectively creating a marketplace of all of these decisions. Instead of trying to prescribe, “Okay, Illia will be the tastemaker and decide: You get the compute and you don't,” we say, “Hey, we're creating a marketplace where anyone can do this.” Probably Illia will do it as one of the participants, but anybody else can do it as well.

You have the rules and everything known, and you have visibility and traceability. You can also build on top of each other instead of competing, as you're effectively doing right now. Let's say I'm going to train this 1.4-trillion-parameter model. I'm going to issue a token for it, right? I'm going to create a new value-capture system for this specific model.

I can now distribute it for compute, data, research, and work. In this case, I started it, so I probably will be the tastemaker, picking and selecting which pieces I want to put together. We train it, and if it gets used, we distill it, fine-tune it, et cetera, and the revenue gets distributed to the token holders.

In parallel, somebody might say, “Oh, actually, I'm going to train a 70B model in this way.” They've got to use exactly the same framework and exactly the same system. Again, because 70B is smaller and cheaper to use, but it also runs faster, it's going to get used in different use cases.

So you're really using this more as a platform where different people can put together the pieces really easily, and you don't need to raise, like, whatever, $10 billion to do this. You can actually raise smaller amounts specifically for compute, data, et cetera, and you already have a lot of building blocks as well.

That's kind of the idea: really creating more of an environment where we can open-source but also use these things, while having this economic flywheel, where things are generating revenue by usage and, importantly, learning from what works and having this inspectability of what actually went into it.

In some cases, people say, “Hey, no, actually, it's all private. I will not tell you what actually went in.” But then people know that it's private, and they can decide whether they want to use it or not, and how. There's also verifiable benchmarking. Right now, when somebody posts benchmarks, you have no idea how they got those numbers. They usually don't even post the prompts they used for the benchmark. You can have a 2-page prompt that answers half of the questions and get way better answers from that.

Here, you have full traceability of the whole flow: you know what went in. Maybe it's private, but at least you know that 100 million users contributed their private data and that's what it trained on. Then you get these results in the benchmark, and you can actually contribute your vibe benchmark as a benchmark as well. On Illia's VibeBench, for example, it gets this much as well.

And on whatever this company's benchmark—Bank of America, their test—it gets this much. So you can have all of that information and decide based on it. It's really about creating transparency and a marketplace for this while preserving privacy for the end user and companies, and having all of this traceability and verifiability.

To rewind for a minute, all of this rests on the fact that somebody has locked up their NEAR coins with the assertion that they are putting forward valid transactions, which in this case would be more like log statements, basically, right?

It's a bunch of stuff, yeah. Because it's payments, it's logs, it's traces of trainings, et cetera.

How big does this database get? Obviously, it gets pretty huge, right? Where does the database live long term? It becomes too big for a single node, I assume. If I want to just connect, I can't download the whole history of everything that's ever happened; it becomes too much, I assume.

Yeah. One of the underlying things about NEAR is that it’s sharded, meaning every single node contains part of the data, part of the processes, part of the transactions, and part of the execution. It can continue expanding the number of shards, and that’s why we actually need more validators to join. The more data and shards there are, the more nodes you need in the network to participate.

It’s very similar to how Google databases work, or Meta’s. They don’t run out of capacity and say, “No more users here, please.” They just keep adding more computers to run things in parallel.

Yeah. This has been fascinating. We’ve built up the premise that we want user-owned AI, and these are all the layers that we have to put in place to finally reach the point where you could have a community-based process for all of this contribution, produce a model, and even get paid back through inference. As you mentioned, though, somebody could also just train their own model and bring it into the system.

Regardless of where the model that people want to use comes from, let’s shift gears toward what AI needs from crypto and what crypto needs from AI. My very high-level framing—and then I want you to go 10 minutes on this if you want to—is that AI can put the smart in smart contracts. I’ve always thought, “These smart contracts aren’t really that smart.” But if there were an AI in there, maybe it could be smart.

What we really need, I think, is smart dispute resolution in a lot of cases—and affordable dispute resolution. In some places we have courts, but they’re not convenient to access by any means. In other places, there are no courts. We need smart, affordable dispute resolution that AI seems like it could potentially provide in the context of these smart contracts.

On the other hand, AI needs really rock-solid guardrails because, obviously, AIs themselves can be tricked, go off the rails, make mistakes, and even scheme against their human users in some cases, as we’re increasingly finding out. We need very reliable checkpoints in workflows—basically, to know that you can explore and do whatever you want, but if you’re going to do this, you need to have a certain level of validation.

I almost think of it like the Jurassic Park thing, where they engineered the dinosaurs so they couldn’t survive without the special food from the park. Of course, we know how that turned out, but not to generalize from fictional evidence: We do want the AIs to be dependent on really rock-solid validation that what they’re doing is okay. That’s my high-level premise. Give me the fleshed-out version.

Both sides are definitely very interesting, and we’re working in both directions. To be clear, when I say “we,” we have a large ecosystem of different projects and contributors who are working toward this. As I said, it’s a protocol that combines a lot of different projects and contributors.

On the dispute-resolution side, and putting intelligence into smart contracts, we effectively have 2 parallel threads. One is what we call NEAR Intents. NEAR Intents is the idea that, as we move into this AI world, you or your AI will simply express an intent that something should be achieved or done. This can be as simple as, “I want some pizza tonight for dinner,” or as complex as, “I want to construct a new building in this location. It needs to be like this,” and so on.

That requires a number of steps. It needs to find somebody who will actually do it, so you need a whole discovery process. How do you discover other AIs or non-AIs? They can be businesses as well. Assuming everyone will have some kind of AI interface, how do you discover the AI that will actually execute this intent? How do you enter into a commercial agreement with it?

That commercial agreement can be as simple as, “I need to rent this car to get to the airport,” or it can be, “We need a 6-month project to construct this thing.” Then, if something goes wrong, how do you deal with it? That’s where dispute resolution comes in.

That’s what we’re building with this intents protocol. It starts with people, organizations, and AI effectively collaborating and doing things. It’s a fundamental protocol that includes AI-based dispute resolution. If something goes wrong—for example, the taxi didn’t drive you where you were going, or didn’t arrive at all—AI can look into the situation cheaply, analyze it, and decide what to do.

If the parties are still not satisfied with that resolution, then they go to court. This effectively reduces the cost of disputes and makes them much cheaper. It can also use a lot more information right away because you have your own on-chain information and all your previous actions. It can run over the private data of both sides very effectively without revealing that private data to anyone.

In the discovery process, for example, you can run AI on both sides’ discovery without it costing millions of dollars. You can minimize the cost of the process and make it very inexpensive. Then, if the result still isn’t acceptable, you go to court—but a lot of the work has already been done and can be reused. That’s one piece of it. For the go-to-market, we actually started more on the crypto side, with trading and other things, and we’re expanding into e-commerce and other use cases, adding more and more services.

The other side is autonomous agents. The idea behind smart contracts was that they were effectively autonomous beings: They existed independently of any person or entity and had money. The problem was that they were just pieces of code, usually very small pieces of code, so they were very dumb even though they were called smart contracts.

What we’ve done is combine those 2 things. In decentralized compute, we run the AI brain, and then it has the smart contract to execute actions and execute the intent. It can actually go and do things.

As an example, we had 1 agent that was given $10,000 and launched. We cannot stop it, take the money back, or do anything with it. It’s effectively trading based on sentiment on Twitter, and it made around $4,000 doing that from the $10,000 it was given.

That’s just an example, but you can imagine a future of businesses where you effectively have businesses like this operated by AI. You know exactly what it’s going to do; your bylaws are the prompt. There’s no person who does random things. Shareholders can give it feedback, so you can apply all this training data to improve it, or decide to upgrade the model and things like that.

That’s the framework of what we call autonomous agents. Intents are how they’re going to interact with commerce and with other AI agents, and the AI-to-AI protocol is the protocol for communicating and executing intents.

The other side is how we govern this. We have a whole set of governance protocols. But even before that, I mentioned formal verification. I think one of the pieces of this puzzle will be that, if you’re using some AI service, you want it to guarantee to you before it even executes on your data that it won’t escape and go kill a bunch of people.

We need to create an environment in which we can verify what the AI runs. I don’t think we can effectively be thought police, even for AI, but it’s much easier to ensure that the AI doesn’t do anything outside of the sandbox that violates whatever rules you apply when you call it.

Using verifiable compute, we can guarantee that, as you upload the model, you can attach a set of things that you don’t want the model to do. It can stop the model from doing those things by running on the output and verifying whether it’s correct. That’s the idea: to leverage some of that.

You still obviously need governance and ways for people to come together and decide what it is that we don’t want. For example, probably everybody agrees that we don’t want bioweapons, but maybe not everybody agrees on some other things. There needs to be some process for that.

We have a bunch of experiments, including using AI in governance. You could have AI senators, effectively—AI that people can vote for—and then they go and make decisions. Getting people to vote is hard, and getting people to do deep research on a bunch of things to decide how to vote is even harder.

And so you can actually have the delegates be AIs as well. You kind of just give them your opinion—what you think—and they construct their platform from that. But you remove this principal-agent problem, which you have with other people: when you vote for them, they still have their own agenda, and they may not do what you ask them to do.

So those are the pieces where we're combining all the blockchain and AI aspects from different directions and really creating protocols, verifiable compute, privacy, and all these different ways to use them.

One thing that definitely makes me nervous is the idea of these autonomous agents that we can't take back. On the one hand, you want to have reliable follow-through on what they're supposed to do, and you don't want other people to come in and tamper with them. So I understand why there's some allure to it, but I'm also like, geez, if we have a hard enough time telling what one AI is going to do, what happens when we unleash 1 billion agents on the world and they're all autonomous and we can't take them back?

And we've, by the way, delegated governance to AI senators. Some might wonder, are we not creating the recipe here for the AIs to just take over and run everything? What is your positive vision for the future, and how do we make sure we don't take a premature off-ramp on the road to that vision?

I think it's going to be a combination of things. AI will become more of an economic force and be that kind of conduit and medium. On our side, we're also going to become more of the governance and curators of that.

One of the things we're doing is putting AI into governance, but we're also putting governance into AI. Verification is one part, but the other part is that if you have this autonomous agent and it wants to carry out an intent in the physical world, it actually needs to be in some jurisdiction. That intent is effectively a legal contract, so it needs some backing from an actual jurisdiction, and that jurisdiction needs to have enforcement over the agent.

We actually have infrastructure for jurisdiction and for an actual court to enforce things on an AI agent as well. It's all visible, it's all on-chain, and it's all transparent. You're effectively combining what we have traditionally had with courts, jurisdictions, and legal frameworks with AIs that can interpret all that, reason over it, and make sense of it, as well as protocols to facilitate it.

The way I see this is that all of these things are going to keep fusing together and really become this new conduit for how our society operates. There is going to be a lot of exciting innovation, and our role will keep changing as well, because we're going to be more participants in this network through AI as a lens.

Right now, through the lens of computing, we're already interfacing with each other a lot more than we do in the physical world. I think that is going to continue, and it's also going to be increasingly immersive.

It's a fascinating set of layers of foundational technology that you've built, and the possibilities for it are really pretty dizzying. I want to already propose a part 2 for this podcast. Maybe we can get back together before too long.

In the meantime, I don't know if you've ever read the book Liquid Reign, but it's my favorite kind of crypto-AI intersection. I'm not super well-read in science fiction, but it's a funny, and I think increasingly prescient-looking, positive view of what that future could look like. So I definitely recommend it.

I know you've got to go, so put me on the calendar somewhere for part 2. Any closing thoughts that you want to leave people with today?

No, I think—I mean, again, this is a movement. We want people to join and contribute across the board. If you're a developer, there's a ton of stuff to contribute and build.

If you're thinking about what AI looks like in your life, I think this is really an opportunity to engage in something that's really yours, and you can actually own part of it. You can contribute in many ways, from creating and being receptive to it, to tastemaking and many other aspects.

Sounds great. Founder of NEAR, thank you for being part of The Cognitive Revolution.

Thanks for having me.