AI Development on Kite AI, the First Purpose-Built AI Layer 1 | Vikas Pandey - Kite AI

Hello, everyone. I hope you're having a good day. My name is Vivek. I work with Go Kite AI. We are one of the first AI protocols in Web3 working on modifying the EVM machine and building our own Kite VM layer.

And what does that mean? We are trying to add AI as a first-class citizen. We have seen many blockchains adapting AI into their technology stack adapting AI into their technology stack . Today I'll quickly show you what we 're building, why we're doing it, and what changes we'll be bringing to the EVM stack. What can be done about this?

What stage are we at? this? What stage are we at? And what direction are we taking? By saying that we are redefining the AI ​​economy, we have seen many developers deploy their models and agents on platforms without realizing the true value.

What I mean is that if you're a good model developer, you upload it to a platform and people use it, the platform benefits, but the model or agent developer doesn't get any benefit. That's what we want to change with Kite AI, creating an attribution or proof of ownership of the contributor on the chain, using logic similar to what we see in GPT Chats around the world. Depending on how end users use the platform, creators and contributors of models and agents will receive rewards. This consensus mechanism that we are building is also new and different from the participation or work test. We call it attributed intelligence testing .

The more you contribute, the more rewards you could get from the platform. So why do we need this new Layer 1 for AI? As I said, we have always seen execution, settlement, consensus, and data availability as existing in a monolithic world. Then we moved into the modular world, but even there, the focus was always on Web3. And AI data to this day is not recorded on any chain.

So recorded on any chain. So , what we think is that if we start adding AI computing across these layers—whether it's the execution layer, the settlement layer, the updated consensus layer, which is like the AI ​​proof—and also add some of this information into the data availability layer, we can advance the overall web3 ecosystem by adding AI metadata to the stack, to the EVM stack. And based on some of this information, users across these layers could not only benefit, but could also use it for many other use cases, whether it's creating agents, preventing fraud, or implementing many prompt-based solutions. That's also something we built as part of launching our test network. So, the current problem, if you look at it from above, is the state, the transaction, and the new or updated state.

So, when...that's something we see in the EVM ecosystem. So, there is a certain block state, and then a transaction occurs. In this case, it could be an exchange, a withdrawal, a transfer, or a bridge, which mutates the state, and then you get an updated state. In this case, the state only captures information related to transactions that occur on the blockchain without any AI component.

So, as I mentioned, the EVM or other blockchains are not currently designed to capture AI metadata on them. Whether it's what model was used AI metadata on them. Whether it's what model was used , who the model contributor was, what part of the model was used, what agent was employed for that matter, and how much data was used when processing a particular transaction. So, this is something we're updating in what we call Kite VM, the virtual machine, by adding AI computing information as part of the process. So, in the new world with Kite AI , when we launch it around the summer of this year, users will also be able to see what model, what data, and what agent were used as part of the transaction, because in the web3 world with AI, you'll be using data, models, or transactions, but also AI infrastructure to process, for example, a DeFi application, right?

Or to do something related to payments. And depending on which model, data, or agent was used as part of the transaction used as part of the transaction , an updated status is obtained that records this usage and then rewards the contributor accordingly. In the attributed intelligence test, what we do is, as you can see, the top layer, that is, the new block; the existing blocks do not store AI information. The new block also has something that you can see here at the bottom, which is AI computing, and there is a standard developed by Ethereum regarding this. It's called ERC 7001, which currently only addresses NFT use cases, so we're also trying to contribute to the EIP, or standard, which could also cover fungible token use cases .

What it basically does is look at a different set of new data that has been added to the block and, depending on the block in the chain, the rewards will be calculated and distributed to the contributors. As part of the testnet launch we did a couple of weeks ago, we were able to reach one million wallets, which was a very, very interesting and valuable number to experiment with and see how users view it from an adoption perspective. I think we see a lot of interest from different developers and consumers, where we actually created a couple of AI agents that people could interact with as part of the test network. And we also saw a lot of inference calls. We mentioned 25 million here, but it recently reached almost 50 million recently reached almost 50 million .

And these AI inference calls, imagine if these calls were used by a model developer or through an AI infrastructure, and you could assign a weight to them and calculate the value they created, the value accumulation, and then end up using your POAI, as we call it, Proof of Attributed Intelligence, to reward users. We will be able to create an economy that will be more self-sustaining, but that will also create a multiplier effect where, in the Kite AI marketplace, developers will want to publish their AI agents and consumers will want to use a pre-built AI agent, model, or dataset, which is very difficult to find in different technology stacks. And that's something we've also observed: it's very difficult to find a clean dataset or a ready-to-use model, or an agent, so you can build something on it, whether it's a decentralized application (dapp) or a new AI-based agent. And this is the composability we bring to the ecosystem where, as users, they could, for example, choose a dataset they get from, I don't know, a pit network, and have an AI agent built using an EigenLayer framework. And then there's a model that was implemented by someone from Hugging Face but also on our platform.

And in principle, they could combine these three solutions and create a new comprehensive solution that can basically solve or build a new dapp using AI in Web3. And this could be a prompt-based application. So there are options they can take. It could be a prompt-based application, it could be an agent, or it could simply be a data-driven solution that provides them with on-chain proof of the developers' contribution. As I mentioned regarding protocol development, currently the EVM only executes smart contracts, and smart contracts only take information and send it to the bytecode, which does not contain any AI data.

So currently the EVM smart contract does not have any of these opcodes and that is something we are trying to add is something we are trying to add , which will in fact include some of these model calls and inferences in the opcodes. And many of these AI interactions that we do, we simply can't move them directly to the blockchain because it consumes too much processing power. There is a large amount of data, as we know, to process a model or to run an AI dataset. And if they also want to run such a large dataset, that will cost a lot of gas. Which would take us back to the days of 2008, when gas tariffs were a big problem.

So our approach, as I mentioned earlier, is to create a dedicated AI execution layer. In other words, a smart contract that also includes information about the execution of AI. And this AI implementation in this case consists of adding some of the new AI opcodes. And the opcodes in this case could be related to AI models, AI inference, or even AI metadata for a given domain. And for proof of what we're also looking for, there's hybrid execution.

So, we want to process some things on the chain, but there will also be a part that will be processed off the chain. And to process some of these things, there are a couple of recently created solutions that process data in AI format, basically called AI oracles. Hyper Oracle is one of them. Aura is another one. The idea is to see which parts of these existing AI oracles we could use.

But we're also looking at smart, futuristic storage solutions, in addition to IPFS and Arweave, such as Walrus, to name a few. To see what things these new solutions could store off-chain, so that we can use the data when we need to process it on- chain. And we could always create a hash and a pointer to detect which transaction was processed with which particular dataset. Regarding the AI ​​testing consensus, as I mentioned, we will add a validation mechanism where the AI ​​test will verify if the contributor has a specific profile contributor has a specific profile , if it is not spam, and bot prevention, in addition to general security so that it is not easy to manipulate the system. I think it's also very important when adding an incentive structure to a new system.

It is very easy to bypass the system with bots or through a MEV attack. So that's something we're currently exploring something we're currently exploring . Therefore, building something like this is a Herculean task. So we read a couple of research articles. We are working with more than 40 of the world's best universities, and also with some of our main partners in the Web3 industry main partners in the Web3 industry , such as EigenLayer or Avalanche.

We are a sovereign Avalanche chain. That was the decision we made to implement everything in EVM because, first implement everything in EVM because, first , it is an existing ecosystem of developers and projects that can build on us and use the AI ​​value we bring to them. At the same time, it has all the cross-chain compatibility that we require in the EVM world. So, the two options are: either we fork an existing EVM, which is the choice we are making which is the choice we are making , or we build everything from scratch, which is very complex, expensive and time-consuming, and we don't even know if we will succeed at the end of that experiment. So, the approach we 're currently taking is to fork one of the EVM clients, and then we're going to create our own Kite then we're going to create our own Kite , deploy our own Kite virtual machine, which will have some of these changes I mentioned across all layers, in terms of execution, settlement, and data availability, as well as the consensus mechanism.

So, what we've done is contact many researchers to try to develop research papers. Therefore, there will be multiple research projects that will emerge from the Kite ecosystem. One will cover the entire approach to how we are conducting the intelligence test. There will be a protocol document that we also want to distribute within the ecosystem so that they understand how this entire Kite virtual machine ecosystem was developed . As I said, there will be AI-optimized state management where AI models, weights, inferences, results, and metadata will be stored on the chain.

And the storage, as I said, will also use different mechanisms, whether Merkle trees or blobs that can also be stored in storage with a Walrus-type solution. We're going to have a specific bytecode for AI, as I mentioned. For example, you could add the AI ​​model in this case, which model was used and what inference was employed. And we are also looking for a mechanism to add tests, whether they are optimistic tests or ZK-based tests. Therefore, proof will be generated so that people can verify that they were the taxpayers and can derive value from it.

For AI proof consensus improvements, we will add AI-generated information to the consensus mechanism, but also, as I mentioned before, attribution detection based on the contributor, usage, amount of usage, and type of usage of the contribution made to the AI. Another thing we're also analyzing is optimized gas. We want to create a re-layering approach, but also fund some of the gas initially and, at the same time, add AI oracles, as I mentioned earlier, for heavy computing. And also consider off-chain storage for pre-trained AI models, which can be obtained simply from these RVV or Walrus-type storage solutions. So, this is the ERC 7007 that was written earlier this year, which addresses AI-based use cases with AI opcodes in the VM stack.

Currently, this 7007, as I mentioned, is very focused on NFT use cases for ownership, and that's something we'll have for model owners, but we also want to have more non- NFT-based use cases where transactions are also recorded in AI transaction data and stored in blocks. So, if you want to follow us, we're at gokite.ai. We are called gokite.ai and we recently launched our V1 test network.

We'll have a V2 test network at the end of March, and then by summer, we'll have our main network launch. Therefore, we are looking for partners who want to create innovative AI and Web3 solutions. So, if you're interested in building with us, we're also part of Avalanche's infrastructure program. We can help define some novel use cases around AI and Web3 that you wish to develop for different solutions. We are also analyzing a subnetwork architecture similar to what we have seen with bit tensor and others like it.

So, if you're a developer focused on a DeFi use case, or one of counterfeit detection, or if you come with a very strong domain background . There is a completely separate subnet-based approach we have for such contributors, whether a developer or a founder, who can come and build with us. We provide access to the ecosystem, but also development support with our partners in the ecosystem, who are subnetwork partners and Avalanche in this case. A couple of things I could quickly show you. This was the basic agent solution we created as part of our test network, where each of these agents can give you results, interacts with the Kite chain, and the points are stored on the chain, potentially being rewarded as part of the airdrop.

In fact, we built what we call the classic counter dapp. It's back on gokite.ai, and if you go to the Kite counter dapp, you can see the entire test network, all the information, and the technology stack it's built on. Very soon we will also be launching AI templates so you can easily click, fork the template and start building your own solution depending on your use case, much like what we've seen with Vercel's SDKs. Yes, that's basically all from me.

Thank you so much for listening. If you have any questions, I have a minute to answer them. I take that as a no. Thank you so much. Have a good night, everyone.