A Chicken Allergy, a Telegram Bot, and MOI's Case for Revocable Agent Authority

While on DevNTell, Gokul opened a health app called Pulse and added a new entry to his allergies: a severe chicken allergy. He then switched to Telegram and asked a bot named TrustClaw for a chicken burger. The bot found one at a restaurant called The Burger Joint and declined to order it, replying:

Found Crispy Chicken Burger at The Burger Joint, but it conflicts with your profile. You have a severe allergy to chicken. Want to try something else?

The bot never stored that allergy. It read the allergy from Gokul's account on MOI, a network built by Sarva Labs, along with his food preferences, calendar, and delivery addresses. It could do that only because Gokul had signed a grant giving it permission. Gokul is a senior software development engineer at MOI, and he ran the demo live on DevNTell with Piyush Maheshwari, MOI's head of business and ecosystem, and host Narb. The burger mattered less than the permission behind the refusal.

A Person's Existence in the System

Piyush got into blockchain through security work. He was working as a bug bounty hunter and security researcher when a gray hat submission was paid in Bitcoin, and that got him interested in how the system worked underneath. He later worked with Polygon in 2020, when it was still called Matic, then with Protocol Labs on the Filecoin side, then Bware, and he joined MOI this year. Gokul's first serious blockchain work was at MOI. He started on dApps and went on to contribute to the consensus layer while the company built a Layer 1 from scratch.

Piyush traced MOI's origins to research by Anantha Krishnan, the company's CEO and chief architect, on a technology Sarva Labs calls Contextual Compute, which Piyush said is now patented. His argument is that existing systems describe smart contracts, data availability, and storage, but not the person taking part. He put it this way:

If you see, we haven't changed any systems for past 70 years. It's altogether same. Even Ethereum and other blockchains are built on the same stack.

He described it as a sequence of network primitives. In his account, TCP made messaging a network primitive and HTTP did the same for resources, and Contextual Compute aims to do it for the participant. Each participant, whether a person or an organization, holds what MOI calls a context superstate. Piyush's simpler word for it was a backpack: a place where everything stays under the participant's management instead of the agent's.

Account A to Account B

Gokul explained the ordering problem using four accounts. On a conventional smart contract chain, if account A is transacting with account B while account C transacts with account D, one has to finish first, because the contract's state changes only after a block is finalized. On MOI, each participant has its own chain. The A to B transaction touches only the chains of A and B, and the C to D transaction touches only C and D, so the two run at the same time. MOI's documentation calls the ledger a Multi-Link Composite DAG, with records called tesseracts. Interactions between accounts that share nothing can finalize concurrently, while interactions that share an account still need ordering.

Piyush connected local finality to geography. MOI's validators, which it calls verifiers, can be placed in a particular jurisdiction. His example was Singapore, where a participant could choose Singapore-specific nodes so that verification happens and data stays in the country. He contrasted this with chains that claim 40 million transactions per second, numbers he said are easy to reach when all the nodes sit on one island or in one jurisdiction.

He called MOI a general purpose Layer 1 and said the name stands for "My Own Internet". Its first target is authority for AI agents, through the MOI Authority Layer, or MAL. MAL is an SDK meant to work with agents built on LangChain, CrewAI, OpenClaw, or other frameworks. Piyush listed four pieces: universal identity backed by public key infrastructure, delegated authority with fine-grained mandates, unified context, and verifiability. He said it can also work with existing identity providers such as Okta, Entra ID, and Ping.

Ordering Korean Fried Chicken

The demo began with four ordinary Web2 apps that Gokul had filled in ahead of time. MealMind held his food profile, including dietary type, spice tolerance, calories per meal, and favorite dishes. Pulse held his health profile, including blood group, medications, and allergies. A calendar app tracked his day. An app called Landmark stored his home and work addresses along with delivery instructions, including a time after which orders should go home instead of to the office.

When Gokul opened TrustClaw on Telegram, it introduced itself with this message:

Your data lives with you on MOI, not inside this bot. I don't have access to your data by default. Instead, I request your permission.

Gokul connected his MOI wallet, which he compared to MetaMask or Phantom, and signed a message to prove he controlled the account. He typed "order food" and chose Korean. The bot then paused because it had no permission to read his preferences, health data, address, or calendar. Gokul signed an interaction that created a grant and stored it under his own account. Only after that did the agent suggest restaurants. He chose Korean Fried Chicken. The agent checked that no meeting overlapped with the delivery window and, because it was past 9:00 PM, sent the order to his apartment. He paid with a test token on MOI, which he compared to USDT on Ethereum while noting that it was not a real asset.

Gokul called this unified context. The four apps know nothing about each other, but because their data sits on the same participant layer, one agent holding one grant could read across all four.

Revoking the Grant

After the burger was refused, Gokul opened a web view of his participant info. It listed the authorization he had given the Telegram agent, its expiry time, and the four context categories it covered. He revoked it. When he asked TrustClaw for food again, the bot found no active session, could not process the order, and asked for a new grant.

He also described a case the demo did not show. If agent A holds a grant and has passed some of its permissions to agents B and C, neither the user nor the network may know B and C exist. Revoking A's grant at the parent level still cuts them off. The public MAL SDK documents a matching rule: delegation can narrow permissions, limits, and expiry but cannot widen them. Gokul compared this with the way agents usually get access today:

In the current systems, what is happening is you have your credentials like OAuth token, JWT token, your password, and different types of credentials which you directly give it to these agents, and they delegates it to other sub-agents. And you can never revoke it back until and unless that token gets expired.

Every step, from creating the grant to revoking it, was recorded in interaction logs that Gokul showed at the end. If an agent kept trying to read data after a revocation, the attempt would appear there. Piyush summed up the principle: "information about authority is not authority, the authority should be the human primitive."

For developers, Piyush pointed to MOI's docs, a version that can be tried on Telegram at launchpad.moi.technology, and the Agent Explorer at agents.moi.technology, which lists the agents registered on the network. MOI's own materials describe the network as live on DevNet, and its documentation says protocol access policies currently govern only storage writes.

Gokul's demo came down to three requests. A Korean Fried Chicken order went to his apartment because it was past 9:00 PM. A chicken burger was refused because of an allergy he had typed into a different app minutes earlier. A final request for food went nowhere because he had revoked the grant. None of the three outcomes depended on anything the bot had stored itself.