Live Whiteboard Series Protocols Powering NEAR AI

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

1. 0:00

   I don't think we've tried this before right we've never we've I guess long time ago first time le as far as I know yeah yeah I think Alex did once uh with Justin Drake like smaller with a smaller group but yeah this is let's just say first time we're doing a live by board uh so you know that said we always do them without preparation anyway and in not one take so this is not that different but uh if you have questions you know raise a hand and we we can we

2. 0:30

   can dive in so today I we wanted to just go over kind of the tax stack we're building because it's kind of getting more more complex uh as there's more and more moving pieces which are also built by different teams um and uh like all of those different teams contributing effectively into like one master stack that we're trying to enable with this Vision but um yeah would be good to actually have like all of this outlined and uh yeah if there's any additional

3. 1:00

   questions we can cover them so I'll just draw the stack and then we can kind of go line by line so actually something that um long time ago when we started near blockchain we were trying to figure out how to do networking stack and we've implemented a version of it um but one of the challenges generally with blockchain has been there's no incentives on a networking level right you're kind of hoping somebody will give you data and uh there's no kind of way

4. 1:33

   to identify if somebody did not give you data or to punish if or to punish yeah if they uh didn't give you data and so one of the protocols we actually released last week uh it's called proof of response and so it's a new primitive that really enables a way to prove when somebody is not responding to you to everybody else so then the obviously we have you know the blockchain itself um we have the chain

5. 2:19

   signatures I'll actually put the tees here uh before intense yeah sure the this is the T Cloud yeah t Cloud we have intent and then we have aitp and I mean there's more things but let's just let's just kind of uh focus on these so uh all of them kind of using stuff underneath or planning to use or uh kind of depend on on what's what's built but also there's kind of maybe indirect dependencies so maybe let's start with proof of response right

6. 3:06

   so one of the again as as I stated the problem been okay I am a I'm Alice right and I want to get some data a very simple you know uh question from another node and that node doesn't respond to me which can be it's offline or it just decided that it doesn't want to respond to me and traditional there's literally no way to prove to to anybody else that this is happening um and so the question was like why is this as

7. 3:39

   important let's start with this well if this node stores your data right so let's imagine this is a data storage protocol like on Machina right and that node like stores your data there's a proof on chain that it stored your data but then when you actually go and reach out to it it doesn't give you the response it doesn't give you the the data like there's no way to tell to the network that like hey this node is

8. 4:05

   not um doing this now for our agentic Internet it's even more important because this node can be running some agent right and this agent maybe even have some private data uh or access to you know some apis and so again if you depend on this agent for your you know for interactions like this is Agent that rebalances your portfolio and it doesn't reply you need at least find some alternative um and ideally also find the cryptoeconomic way

9. 4:39

   to punish it so what kind of pro response introduces is a a network of relayer nodes which are interconnected and so the wi service nodes as well and on each Edge in this network there is some effectively latency and cost and so when I'm when I'm joining the network right as Alice I now specify a path so let's say I'm trying to retrieve some data that uh I want I want my uh request to take and I'm paying a little bit so

10. 5:25

    there's a payment Channel established uh I'm paying a little bit for this request so what are different cases right one case this you know replies back and uh you know the information goes back to Alice she's happy she paid a little bit for the networking now we have a networking protocol for incentivizing actually information uh exchange now it's possible that this node let's say

11. 5:53

    Bob is uh doesn't want to reply to Alice and for example it didn't actually store the data and uh in this case uh again two options one is it replies was just an empty response right like hey uh there is a reply and so Alice like but because it's a cryptographically sign reply Alice can then show to the network hey Bob replied me was nothing for this request you know this is a malicious behavior the other option is he just ignores right and

12. 6:24

    doesn't reply and so in this case the intermediate noes now um are by protocol effectively either break the edge themselves with this node or if they don't do it somebody else will break the edge with them right so the the kind of the idea here is that kind of if somebody in this network is not replying right that can be because of the kind of the node somewhere on the path is not replying there is a kind of edge broken

13. 7:03

    now Edge breaking is not like that bad because uh it effectively means uh you know one connection is broken there's a little bit of penalty from the uh from the here you're assuming like the all the nodes on the passer following the protocol but like it's POS or like at least one node is following the protocol at least one node is following the protocol yes but what if they all not following the protocol cool yeah so we'll get to that we have the you

14. 7:34

    know semi magical solution for for some of this um but yeah at least one notice following the protocol you effectively get a broken Edge U propagated back to Alice and the idea that like if Bob loses all the edges that's effectively a slash condition because that means that like everybody who is communicating to it it's it's not replying to them mhm right so as more you know obviously like initially Bob has a lot of edges and

15. 8:04

    then Alice can continue you know asking on different path and if Bob is really you know adamant and not replying to Alice it will end up effectively losing all the edges with uh with all the related notes and in turn getting slashed and effectively in turn proving that it's uh not replying but you need to prove that it has lost all its edges yeah so the cool thing is we have a blockchain and the blockchain like all of this doesn't work be like without some way to post

16. 8:35

    all of this topography information somewhere right because like all of this right now is you know if you don't have a blockchain it's just a partially observed information for each node now the cool thing is we do have a blockchain where all of these edges are actually recorded as payment channels and so every time you open up a connection you establish a payment channel on chain as well and so you have a full topology recorded in a smart contract and so now now when yeah this

17. 9:01

    condition happens then uh the slashing happens um on chain as well and the Bob loses actual someon chain stake that they have so this is kind of on one side this itself is a networking stack but on the other side it does use blockchain as a you know kind of this global settlement layer which is what blockchain is really good at now the cool thing is then blockchain can use Pro response to

18. 9:26

    effectively maintain its own networking connections because now again if validators for example not replying uh to the data requests um they get they can get slashed not just for like malicious block production but now also for not being available for data requests which is what you know data availability and all the other things uh trying to ensure uh is there a protocol on how

19. 9:51

    much they should stake so that is I mean up to an application and kind of kind of how it's used I think for Block the cool thing obviously is the Val already staking so can reuse that for things like you know AB the stack where you know obviously it's going to be some economic research that we'll need to do uh cool so this is kind of again it's a new primitive like on the you know on on a kind of level of like proof of stake enabling you know networking

20. 10:25

    incentivization and verification do you want to talk a little bit more about blockchain Parts yeah I mean has been talked about a lot including in different uh whiteboard sessions um what should we talk about um I mean obviously we can talk about the general stuff um so uh um so basically we have those blocks and uh uh we have a we have a charts uh and uh uh you know each block contains uh

21. 11:14

    chunks from different shorts and um important thing is that there's only one chain uh makes a lot of things simpler um and um how the the chunks gets verified uh so since the release uh Nate 2.0 release last year is that uh uh now like on each block um so there's uh this uh this like rotation of validator is happening um so uh on each block for every shart uh there's a random assignments of validator to charts uh so they validate the state transition of

22. 11:53

    that given shard in that block uh by verifying the state width winess uh so the widness basically um is like a kind of a kind of a data that says the state um and then uh proof um so state is basically the state that you you touch during the execution and then prove is prove that the state is actually valid it does belong to the state root uh so today this is a this is a mirco proof um but the nice thing about it is that it doesn't have to be MCO proof any proof that proves a state belongs to the

23. 12:31

    state route would work so for example in the future can replace that with the knowledge proof and uh that'll be much smaller and um yeah enable us to have better scalability um okay so uh I guess we can also talk about the the wrong time uh well I I think the interesting thing that we haven't talked much in previous whiteboards is uh decoupling uh execution from consensus yes um okay that

24. 13:03

    is this um so yeah for context Bowen intr talk about it at the presentation today okay but not in a lot of detail yeah um because it's very complex um so it is kind of like a something that's kind already complex on its own like you know things like consensus they're by Nature complex but when you like add sharting to it it just become like complex squared you know um and uh so yeah so so

25. 13:34

    okay let's look at this um so today how it works is like okay you have block you produce and like everyone go and process block including like applying the chunks and whatever um and then they they're basically like dong here like here they just like like like basically like they waight here I mean assuming let's say like a block is pretty empty right the takes like very little time to to apply

26. 13:55

    they wait here until the next block is produced um according to consensus right so what actually happens here is that uh the block producer is sending approvals to the next block producer approving this block and then the guy after receiving all the approvals now he has all the approvals to produce uh the next block uh but there is this delay right so during this period of time the node is basically doing nothing kind of like I mean obviously there's network connection going on it's like sending uh

27. 14:27

    messages to different noes but it's not spending any of CPU time actually doing the uh the block of the work which is like applying transaction and receipt right so if you think about the blockchain is is like it's just like this machine that continuously take like new transactions and and apply them and get the new state but here it's actually not doing that job it's just there's just this delay here that's idle uh and um people have realized that this kind

28. 14:51

    of sucks meaning that we're not fully utilizing the power uh of every every node so instead what we do is that we say well um we want to better utilize this entire thing uh so basically it's split into uh consensus and execution so so in this new paradigm we still uh produce blocks this way it just that um the difference is here is that after a previous block is produced you don't

29. 15:26

    actually wait for the uh block to be applied and for the new state rules to be updated you just like go immediately to the next block trying to reach consensus on what the block is uh so what that actually means is that uh it's basically like every every chunk producer producing some chunk which package the transaction there and they send to the to the block producer they send the header to the block producer and they the block producer produce a

30. 15:49

    block and by doing this um it's basically just like a way to agree on uh what the transaction for like all of the shards are basically just like uh ordering and packaging transactions and this just like goes on now and separately there's like execution uh which is like trying to catch up so let's say uh we have uh just let's say we get everything to work very well you produce block every 200 millisecond uh

31. 16:15

    so this chain would move forward and then on execution basically you're saying like you do the kind of what we do today which is like you take block you look at the uh let's say each Shard uh look at the the chunk and then try to apply it and at some point uh this is configurable but some point you're done with supplying some chunks you can say Okay I want to submit this state state

32. 16:39

    proposal so on on what basically this is like this this is roughly State root uh after Block H so basically this proposal says um here is a state root uh after applying this block and um it submits this proposal and then it gathers this uh valid uh endorsement from the validators uh by doing the same stus validation that we do uh and then if it has enough endorsement then it can be included in a block uh which is part of the consensus chain uh but there you're only validating that it has enough enough

33. 17:19

    endorsement um so that's to certify the statewood has been updated um so this uh uh This Way um the not is constantly doing uh doing work on like applying transaction and receipt and update the state um and uh you get better throughput this way uh another thing that is I think um somewhat unique about this approach in the short shorted setup is that um generally with sharding if you want to have low block time it's somewhat incompatible with a lot of

34. 17:50

    shards because uh the more shards you have the kind of the larger the variance will be between like receiving the the chunks um so if if you have that you have if you have to wait for every block to be applied then it's more likely for some trunk to be missed but here um kind of It kind of solve address that problem because one you don't actually need every single block to include a chunk from uh some sh because it's kind of asynchronous between consensus and execution but also that because you

35. 18:20

    don't actually apply here so it's much easier for like everyone to like keep up with a pace and actually produce a chunk that contains the transaction so it also nicely uh solves that problem um yeah the the other interesting thing is so right now near you have effectively limit like one transaction here can only execute for like 200 milliseconds and that's part partially because I mean even before we're reducing block time like you you need to give enough time to kind of between

36. 18:53

    execution and uh and you know starting to produce next block and so here if you decouple this right now it doesn't matter how long the transaction actually take yeah like you can you know just order have longer running transaction just get updated later yeah and so things like Aurora where you know sometimes like on evm an ethereum transaction actually take you know you know can take 5 Seconds to actually

37. 19:18

    execute of real like crunch time right you can actually now apply this uh and it you know can actually take whatever on near it would probably take like 3 seconds uh but uh but yeah so you can actually have like longer running transactions on top of already all the other stuff we have is with a sync right where you can you know uh do other things so it's really kind of improving fundamentally how yeah like reducing latency increasing

38. 19:48

    bandwidth and uh and in turn also increasing what type of transactions you can do which has already been uh like pretty powerful in there so if I start a transaction like you were just saying that may take two seconds and your block resolution time is faster than it took me to execute and I was using data based on a block that is finalized at the start of the execution is there a method of getting the Delta State changes from the blocks that may resolve in between the start and the end

39. 20:31

    of the execution did that make sense so the idea here is like the transactions are queuing up right so you can think of this like the the consensus part is just feeding the queue of transactions so like every time the block is produced it just puts things into a queue and then this execution just takes it a queue so if there's other transactions touching the same state the same contracts they'll just go

40. 20:55

    into a queue and they'll start executing after so to give you an example like let's say there's a you know uh like Aurora transaction one and then then it will like start executing aora transaction too now because near is parallel you can have like ref executing here yep you can have some nft minted in parallel as well but on on the same contract level which is kind of our level of paration right now you will have them sequenced and so they'll just

41. 21:26

    go into q and wait yeah yeah so indeed really cool I mean it's really nice so solves a lot of yeah interesting uh things for near but also kind of pretty Innovative across the ecosystem so uh let's go to chain signatures y um so this is I guess also connect with Ste so basically um so what this thing is is that um um let's say you have a account or let's just say SM contract uh so it can be it can be a regular account as well right so uh this is a smart contract on year um so today

42. 22:08

    just like regular smart contract and just the thing you can do is within the near ecosystem right um but what this chain signature allows you to do is that now it suddenly have um addresses on let's say Bitcoin uh on on etherum on salana um and let's say base um so it uh this smart contract itself has a account that it controls all of those chains um it's uh it's a very interesting Paradigm because now what it

43. 22:41

    can do is it literally you can have some logic that allows it to sign transactions for each of those chains and then some relayer can go and take the transaction and go and execute on those chains uh so it enables a lot of interesting use cases especially in like cross uh defy you know like for example if you want to like Bridge uh Bridge like uh some some token from like one chain to another chain historically the

44. 23:06

    way you do it is like you prove that something happened on one chain and then you go and and send the proof on the other chain the other CH verify okay uh this there's a proof and then it it like does token meaning or like unlocking but here like what it can do is literally like it can can just like uh release let's say it it has this address on on bitcoin and it hosts on bitcoin you can sign this transaction and release Bitcoin uh or like send Bitcoin from that address to some other address

45. 23:32

    directly and this is both easier to maintain because you don't need to worry about this complex logic of verifying between chains um but also it's actually faster like a native transaction is sent uh the latency is basically the latency of the chain of the destination chain um so this is more like from kind of the uh the use case perspective and uh you know near intense for example is a big use case so of uh of uh chain signatures and in general like there are people building uh uh multi-chain lending uh

46. 24:05

    borrowing um multi-chain Asset Management you can have like one contract that implements some like defi strategy that manages accounts on all sorts of different chains uh and there's like rebalancing uh you can that can even be controlled by like AI agents I can talk about that um yeah so a lot of cool stuff uh can be uh um done from uh from this perim uh should I talk about how it works maybe briefly yeah yeah yeah

47. 24:37

    um like the final state or current final State yeah so like roughly there's uh some set of nodes uh so it's like MPC nodes uh so each of those noes roughly they hold uh they hold a key share and um uh uh and then the keyer doesn't um so you need a threshold there's a threshold you need threshold number of them to participate in a signing request uh in order for to generate signature

48. 25:14

    and the signing request um happens on near so there's like a near it actually runs a near node uh that index the chain and when ass signing request is triggered it verifies that it's actually a uh correct uh signature request by um that's just smart contract logic but here just to verify the state transation is correct so no one is trying to uh maliciously attack uh by generating a a bogus request uh and then after got the request it start this threshold signing

49. 25:45

    process uh which is the threshold cryptography that I won't get into uh but then in the end the signature is produced and then submit back into the broad chain um and the interesting thing here is that uh we want uh this NPC node to also RW inside the te uh to make sure that uh uh the key share can never leak so generally the problem with uh MPC uh is that it doesn't have a good defense against the the long range attack meaning that uh if

50. 26:17

    um if some old set of participants collude they can still recover the uh the root key and um uh and then everything is screwed uh so uh inside te like you have basically you only allow the key share to be held in un encrypted form inside the te and when it needs to be persisted encrypted by the te's uh encryption key so that um even if the node operator is malicious there's no way they can get it out uh so it makes it much more secure yeah so maybe that's a good

51. 26:47

    transition to tees right so um I kind of mentioned this in my talk as well but uh just like on a high level we have the you know Hardware like for example CPU and so there is a specific way uh where you can actually run a full uh operating system image inside of this secure Enclave in such a way that um kind of prothesis outside so this is secure uncl trust ex environment Pro outside are not able to access it right um so traditionally tees

52. 27:25

    have been kind of considered a very hard to use and be very insecure because of two reasons one was that uh the way to run software inside them required to actually write in a special way using very specific API so uh previously it was Intel sgx it effectively required to rewrite everything in C it had very low level apis it didn't have for example uh parallel instructions like SSC um and so it was very limiting what you can do with it plus there was a lot of known side Channel attacks and how to actually

53. 27:58

    extract information from it now since about like March or April last year there's a new uh kind of uh generation of trusted execution environments uh with in it's called TDX trusted domain execution there's a version for irm there's a version for AMD and so those allow to actually run a full operating system image inside this environment and so you can literally prepare you know

54. 28:22

    think of it as Docker you can spin it up there and now what you can get which is really interesting is that when you when some computation is done you get effectively a certificate that this computation was done on this data and importantly only this computation was done there was no other computation done on this data which is really important for a lot of the use cases we just talked about right

55. 28:45

    because if you think of uh you know the NPC that bone described well you want to know that only the calculations that you asked NPC to do was done and nothing else right it didn't try to extract the uh key didn't you know do anything with it and actually maybe even deleted it so that this Shard is not even uh valid anymore going forward because it doesn't exist similar proof of response right this ensures that noes actually

56. 29:11

    following the protocol in the whole network uh of the nodes that following the um te so there's a there's a kind of this concept of quote uh which which T can return and so so on top of this primitive right there uh kind of um there's a few different bits and and pieces that are being built to enable this uh so first of all there's kind of reproducible Docker builds um that kind of uh especially file Network been pioneering on how to like make it really easy to uh

57. 29:44

    distribute uh software in verifiable way so you actually get uh effectively like you can upload a specific Docker container which you know the hash of which is known and it's consistent and so you can actually you know look at source code verify that the source code is not doing anything malicious reproduce the docker compute the hash and when you do some computation it actually proves to you that this hash of a Docker is running inside te right so that's kind of basic primitive you get this Docker container

58. 30:14

    was run inside te on this execution and only this thing was done now kind of uh what this allows to do uh Kendall was talking about is the concept of shading agents right where now you can actually call for example this the some execution and then go back to the blockchain right and post that hey this calculations were done um on this data and this is the outcome right and so your smart contract

59. 30:47

    can effec receive outcome verify on chain that this you know quote is correct that you actually have indeed used done this execution inside te on this data only this thing was done and this is the outcome and now this outcome can be used somewhere in smart contract to give you an example you want to build this rebalancing portfolio you have the chain signatures to hold assets and all

60. 31:13

    chains but who does rebalancing right like what is the logic of rebalancing well you can actually run arbitrary computation for example go read Twitter you know uh fetch data from kaido decide on a new allocation in the index and then return back this new right and then you know maybe it does like some cross checks on a smart contract level and then verifies that indeed uh let's execute that rebalance

61. 31:38

    yeah I think an important thing here to know is that there is a way to verify this ATT a station without going to Intel server basically there's just a database that they publish um that can be put on chain the database of certificate that can be put on chain and then that can be used to verify the attestation which is what uh shade agents do yeah and similarly like if you are a you know our proverbial Alice who wants to do some computation off chain right uh she can connect to this node

62. 32:08

    through TLS so through encrypted connection so this node exposes effectively it's a certificate proving that it runs in the same Docker and so then you can encrypting with this with a certificate communicate some private data that again this node let's say this is our semi malicious bul cannot see whatever the data come coming in what happens inside so some computation is done and then the response comes back again with this quote right so now you have a full intern confidential

63. 32:38

    effectively computation done in on remote server and you know that only this computation was done for example it removed all the data afterwards it didn't save it you know that you know it run exactly as a AI model or a AI agent and uh you get back uh kind of certificate that the answer uh is this right so this enables effec both onchain and offchain actors kind of communicating with a uh this te node to really uh do confination calcul computation in

64. 33:11

    offchain case or verifiable in in the onchain case the uh so kind of but this is like a single node right so okay what what what happens when there's like lots of this nodes how do you actually um how do they actually manage this well this is where um proof of response comes in right because the reality is like there might be some node and when I say like this is you know any arbitrary Docker I mean it

65. 33:41

    meaning we for example spawn up our like pogress like database running inside te right so you can actually literally have a private state for your shade agents onchain agent have private State running inside te that you you know you trigger do some calculation and but becomes public on chain or private of chain right so like it's an arbitrary like complex uh software that runs there and so now you can have lots of these uh te nodes that join the

66. 34:10

    network um they will need to stake something to participate in proof of response and so now you can actually have um an ability when you send a request to prove that one of them is offline or not right so this gives you kind of this livess guarantees from a network of verifiable nodes and so you actually have a fully verifiable live Cloud um obviously like if the node is offline you need to eff reroute to another node uh so there needs to be like additional protocol uh like for uh

67. 34:41

    kind of load balancing the work etc but overall this gives you kind of a verifiable cloud something that you know if you've been in crypto in 2018 everybody was promising you this is actually it offers uh effectively a system to to achieve that by combining proof response tcloud using blockchain and then obviously leveraging chain signatures to go multi-chain yep all right so if you're not bored yet we have more stuff so all of this is

68. 35:14

    cool um the next level of this is the idea of intense so intent is really more from a kind of user perspective and kind of higher level developer perspective if I have some request right and I actually don't want to figure out how it should be done right so this is like hey I want to rebalance this portfolio I don't want to actually figure out exact you know swaps that needs to happen I want somebody else to do that right so you can communicate

69. 35:46

    this request so here you have some way of communicating so for example this can be centralized running inside te with verifiability this can be our decentralized te Cloud where uh with this propagates and so you have other parties which can be either verifiable or not so this can be some you know uh like friendly face and this can be some things that's running inside te that can

70. 36:11

    respond to this saying like hey oh you want to execute this complex procedure I will do it for you and you know this will cost you this much and I'll do it in this long right so the simplest example of this obviously is you know swap one Bitcoin for whatever 100k usdc somebody's like cool I'll do it maybe you know 99 500 somebody's like no no I'll do it 400k and the cool thing compared to

71. 36:36

    usual blockchain where you would submit this request on chain and then effectively now everybody can observe it and and you have minor extracted value uh where people try to front run it here because it's a private request and you're actually getting the quotes you're getting the kind of hey you know how much you would do it so it's an interactive protocol you choosing the best option right so there is no way to front run you because you choosing

72. 37:01

    what's the best option going to be and then you already submitting effectively two like two signatures your signature and the the solver signature on chain to actually set like Sol like to commit to this outcome right now this protocal can be a bit more complex there can be like some escro time uh where you know there may be dispute because because for example you said you know build me build me a

73. 37:30

    building with five floors it said like okay cool it's going to take a year and I'm going to do it for whatever uh $5 million and so this $5 million are actually going into escrow and then if the building is not built there's a way to resolve that and get the money back right so simplifying but that's kind of uh allows you to have this complex offchain negotiation protocol figure out what you want to do submit this start

74. 37:56

    executing and Computing te offers you like additional benefits because now for example uh you know who doesn't like launching new tokens well you can actually launching new tokens inside te itself so you have new token on chain so XYZ token and so all of the XG token is owned by the account inside this te and so when people want to buy it the te is actually Market maker right so you have a fully like confidential and also verifiable you know exactly how it works

75. 38:27

    Market Mak right so this can be as simple as you know your Unis swap formula or this can be as arbitrary as you know have you tweeted today about this token then you're allowed to buy right it can be arbitrary logic that actually runs here as a market making logic that actually responds to requests from users so this actually solves one of the fundamental problems with blockchains where when

76. 38:50

    even however you paralyze it if people are trying like if you know 10 million users are trying to Target the same piece of State because everybody wants to try trade trump it doesn't matter how you paralyze it that piece of data is congested and so this actually allows to have you know you can arbitrary scale this number of tees that can respond to this requests that control the supply and so they can all effectively reply uh

77. 39:14

    to different users so you can actually have a scalable like uh Market making fully verifiable through the te and replying intents yeah I think the the interesting thing here is it doesn't it's not limited to like uh you know trading tokens or like swaps it's it's more General and U it can be extended to things like Commerce and like just like buying a laptop or whatever you want to do and yeah so the example we showed I mean this is more going into ATP already but yeah you can say hey I want to buy

78. 39:45

    headphones somebody's like well here's some options for you right an agent replied you're like cool I'll select this option let's go to the you know process we escort the money and then when the product arrives right we resolve it or disput it if it didn't arrive right so this actually allow us to do like more traditional Commerce in this way and like General payments infrastructure you know think of credit card payments but now and down through

79. 40:08

    those flows um and again because you have guarantees you can have guarantees on some of this uh other side as well you can actually do a lot of new things uh in this way yeah it's also very flexible can do like OTC and like they still use same framework to settle it's not like just like x * y was K flexible this can literally have like you know a Twitter white list it can have you know like arbitrary formula of Market making Etc so but it's also can

80. 40:40

    be like any arbitrary AI code that runs whatever right so that's kind of the idea is like this is we're effectively moving from trying to fit everything into blockchain to effectively have like an ec2 level verifiable compute that you can like inter leave with effectively like arbitrary requests and responses through this network so and so on top of that we build effectively the agent

81. 41:05

    stuff where these agents are now communicating with each other and so ITP is really just conglomeration of all this products right where it allows effectively one party to initiate some communication uh and then parties to exchange you know structured data like okay I want you know request some data from you I want to request signature so let's say this is Agent B this is Agent

82. 41:36

    a and you have maybe like uh user and so kind of the idea of aitp you can have like multiple of this parties in the same conversation and some of this gets replied directly by agent a some gets propagated to the user so you have like a full flexibility of effectively decomposing intent into like any number of participants and kind of exchanging all this in one communication the cool thing is because it's kind of maintain think of it as a thread or a email thread you can then if something like if you have a dispute

83. 42:09

    right let's say product didn't arrive agent didn't do the good job you can effectively add like another dispute agent for example who joins the thread and like okay what happened here like what did you promise what what's the what's the process Etc and this itself you know can escalate to like court because this has like a full like conversations logged as well that is only shared between these parties until

84. 42:33

    New parties are joined so kind of aitp effectively creates like this overlay over all of this to kind of on the on a like agentic level to kind of join all of this pieces together and enable them to trade Converse and interact as well as you know do business do uh kind of transactions exchange private data uis and other other parts so point is all the pieces effective working together uh

85. 43:03

    they all build on top of each other and we're effectively enabling this you know Vision we talk about like how AI is actually going to be your interface through the uh through web 3 and web 2 and all of the pieces are really kind of powering that future yeah very exciting and so so still still a bunch to build but we already see I mean you saw the demos I think we have more demos actually kind of want to show more demos but

86. 43:36

    uh yeah