Skip to content
by Unity Nodes
NEAR DevHub

Verifiable AI DAOs: Powered by Shade Agents

about 10:32 long

Nothing is loaded from YouTube until you press play, and then without tracking cookies.

About this video

Learn what goes into a full stack verifiable AI DAO built with the Shade Agent Framework.

For further details please refer to the documentation https://docs.near.org/ai/shade-agents...

Transcript

1,479 words

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

  1. 0:01

    Proximiti Labs, and this is a demonstration of an AI-powered Dao that's built with Near and the Shade Agent framework. The Dao makes decisions on proposals submitted to it by AI decision-making. The whole system is autonomous, verifiable, and transparent throughout the whole stack.

  2. 0:23

    The goal of the demo is to show how Yield and Resume and Shade Agent framework can be used together to have a smart contract that, when it's called, will perform verifiable off-shape computation. It will return the result of the computation within the same transaction as the request was submitted back to the user.

  3. 0:45

    This pattern can be used for things like buying aeroplane tickets via a smart contract, or as an on-demand oracle for any arbitrary data. That'd be like price data, weather data, political data to be used within, like, a DeFi protocol or prediction market.

  4. 1:03

    The important thing about this Dao is that the LLM component uses Near AI's verifiable private inference, so the whole governance process remains transparent and auditable. The Dao has a manifesto set within the contract, as you can see here, that the LLM will use for its decision-making.

  5. 1:27

    In this example, the Dao will just approve gaming-related proposals and reject everything else. So, you can create your own proposal here, and we'll go ahead So, let's think of one that will get approved. So, let's say, "The Dao should approve a new up-and-coming Near."

  6. 1:53

    And I mean, this voting process is really simple, but I encourage you to make it more complex a proper implementation. You can see the past proposals here. They're either approved or rejected, and the Dao responds with some reasoning on why it made its decision.

  7. 2:12

    So we can see ours was approved, and it said some reasoning why. So, let's move over to the code of the Dao. The repo consists of 3 main components. There's the contract, the front end, and the agent, which is the source folder and these additional files.

  8. 2:32

    If you're looking at what each file does, I suggest you look further into the docs. These are just generic to Shade Agents. So let's first dive into the agent contract. We'll go to the entry point first. This is all pretty generic Shade Agent code.

  9. 2:51

    As you'll see, it's very similar to our default agent contract. So, there's the initialization function, which is called and will set everything to empty and initialize the contract with an owner ID. There's this function, approved code hash, which will set a new hash within the contract, and this requires the owner to call it.

  10. 3:19

    The code hash represents which code can run TEE. And to verify, an agent calls the register agent function. provide the TEE attestation along with the, the code hashes running. If all this checks out, then registered as a valid agent. Then there's some help functions down here.

  11. 3:43

    The main logic within the contract is within this, this Dao file. There's also this other file here which just goes into more details of verifying the TEE attestation. So let's go into the Dao file here. Let's look at the structures first.

  12. 4:02

    So, there's this manifesto struct, which specifies the text of the manifesto that was set by the owner, and a hash of the manifesto. We'll talk a bit more later about why the hash is stored there as well. There's also this proposal request, uh, structure that stores the yield ID for a yielded promise for each proposal, and the text of the proposal.

  13. 4:28

    Once the proposal is voted on, it will again store the text and the results and reasoning for the vote And the result is an enumeration of either approved or rejected. And there's some additional ones here that the AI respond to the contract with, and what the contract will respond to the user with.

  14. 4:53

    The first functional pair is the set-manifesto function. This allows an owner, and only the owner, to set the manifesto text in the contract. So that was like, it will only approve gaming proposals, for example. And the owner will, usually be like a, a multi-sig contract.

  15. 5:14

    So the main logic here is in the create-proposal function. The main thing it does is it creates a yielded promise, and this is a promise that will only be resumed and resolved when it's explicitly resumed by the contract, or the yielded promise times out after, I think it's 200 blocks.

  16. 5:39

    And once it's resolved, it will call this function, return external response, we've specified here, and it will call it with the arguments of proposal ID proposal text. We read off the yield ID from the yield register, which is a unique ID for each yielded promise, and this is stored with the proposal text.

  17. 6:03

    in the list of pending proposals. The function then returns the yielded promise to be executed. To resume the yielded promise, the agent will call the agent vote function and we make sure that only a valid agent can call this function.

  18. 6:21

    It checks that it's running the correct code hash. And we do this so we know that the DAO is following the intended process, that it's using this AI system to, to vote on the proposals and it's not just some person sitting behind a computer, manually voting on the proposals.

  19. 6:42

    So we'll do some initial checks, mainly it will check that the manifesto hash and the proposal hash match those stored within the contract. And it does this so we know there's no middleman attack where an RPC provider will supply the wrong manifesto text or the wrong proposal text so the vote, DAO votes on the wrong proposal and makes the wrong decision.

  20. 7:11

    If these initial checks pass, then the promise will be resumed and this return external response function will be called. And this function takes arguments from both when the promise is resumed and when the promise is initially, uh, set up.

  21. 7:29

    first, it will just remove the proposal from the pro- pending proposals map and then it will check whether it received a valid response. It will only receive an invalid response if the AI fails to respond. So it will time out and just produce an error here.

  22. 7:49

    If it did receive a valid response, then it will now create a finalized proposal object and store that within the contract with the decision the AI made reasoning for this decision. And then that decision and, and reasoning is then submitted back to the user.

  23. 8:08

    There's also some view functions down here which allow someone to get the manifesto and a list of the proposals. So I'll move over to the agent now. We're not gonna look at the front end here. So within the source folder here and within the index file, this is our entry point to the agent.

  24. 8:29

    All this index file does is keeps looping to check whether itself, the agent itself is registered within the contract. And an agent will just register itself on boot by default. And once it is registered, it will call this responder function.

  25. 8:50

    And this responder service, what this does, it's a loop itself. It will just fetch the list of pending proposals and keep fetching proposals until there actually is one. If it doesn't find a proposal, it'll just, just go over again.

  26. 9:06

    Once it has the manifesto and the proposal, it will c- call the AI vote function and this is where the, the voting process happens. So what this function first does is sets up a connection to a NearAI verifiable it establishes this system message and this sets the role of the LLM.

  27. 9:30

    It tells it that it's, uh, an AI DAO and that it needs to make decisions on behalf of the DAO according to the manifesto and the proposal that it's presented with. We also construct this user message here which is just a combination of the manifesto and the proposal that the DAO's gonna use to vote on each time.

  28. 9:50

    And we're using tool calling here with these 2 requirements that the DAO has to respond with an enum approved or rejected. It has to respond with reasoning for its response. If it doesn't respond with the 2 pieces of information, then it will just error out.

  29. 10:11

    Cool. So once that's all well and done, the agent will just respond back to the contract with its, its response and its reasoning and also the hash of the proposal and the hash of the manifesto for reasons specified earlier. So yeah. That's everything for this demo.

  30. 10:32

    I encourage you to fork this, this repo yourself, deploy it yourself, and build an actual production AI DAO or something similar. And for further information on, on how to deploy it, how to fork it, add more details, go over to docs.near.org.