Everything You Need To Launch An AVS With Othentic

Transcript

today's presentation with authentic yarden yarden welcome and uh looking forward to it man welcome to igen lay unlocked an interactive educational Journey Through the igen lay ecosystem created by technical Founders and builders for the entire crypto Community a special thank you to our partners allir polymer authentic skate and lrange for helping to make this happen our goal is to raise the collective knowledge of the igen lay AVS ecosystem and unpack the technical designs of the top teams in space welcome to igen lay unlocked welcome back to Ian layer unlocked today's presentation with

authentic uh yarden yarden welcome and uh looking forward to it man awesome Andy Robbie thank you for having me thank you for hosting authentic and super excited to to kick it off awesome Sam yeah let's Jump Right In looking forward to it uh sounds good maybe a a few words about myself and my background um so my background is inventure capital uh five years before authentic I used to invest in early stage mainly software based companies um based out of Tel Aviv and abroad I did

for five years H from SAS devops enterprise software deep Tech cyber and anything in between before that I used to uh manage an accelerator with Microsoft again early stage software based companies Microsoft and Salesforce um I got into crypto somewhere around 2016 17ish um while working as a business development for a protocol that built on top of ethereum so ethereum was my first dive into this complex and sometimes weird ecosystem um in FS forward me and my co-founder Den we

co-found authentic almost two years ago um yeah so I thought to start with a quick background story about how we got to build the authentic or the authentic stack a quick intro what authentic is what our value um how contribute to the shared security to the AVS ecosystem maybe then breakdown what is an AVS what is this scope of this terms this term what could potential potentially be an AVS um then a breakdown of AVS use cases what is a task a term that uh um we can hear from now and then um the igen scope and the

igen value proposition um and what is missing within this uh within the AVS stack and within the AVS info and then a deep dive into the authentic stack um what we do and of course um some exciting ABS ideas that our Watchers could potentially build using us using I layer sweet cool awesome um so so yeah we started off by building an ABS more than a year and a half ago uh it was the very early days of enen there was no testet no tutorials no guide

books no sample we just forked the code Bas and start experimenting with things uh and we did it for six months and during this time we basically understood all of the complexities uh the difficulties the problems the bits and bites that other builders we have to face while spinning up an ABS and the the the idea is that instead of focusing on our core protocol on our core product we were busy developing all of the underlining lowlevel info component such as consensus on offchain computation peer-to-peer networking message passing mechanism

cross chain messaging where do the operator submit their attestation how does the protocol audit those attestation distribut words in force penalties and slashing and we also need to configure our logic design onto it and of course develop all of the required smart contract and this components this this slow level infra um significantly shifted our Focus away from our core core product um and at some point in time we decided let's let's make it access let's make it available for other builders to use uh let's compile it into into a stack um and this is how we came up with the

authentic stack um so you can imagine the stack or simply put the stack is an AVS development framework which handles all of the low-level infra components where AVS teams can focus on the core product um you can imagine it as as a canvas with all of the essential building blocks to spin up AVS highly configurable and highly versatile in all aspect of ABS development while the underlining complexities around consensus operators and networking

messaging attestations are all abstracted away from the builders which essentially reduce noise and accelerate the the AVS product time to Market um I think that behind all our mission is to enable the creation of noal of emerging computational Services whether it's in infrastructure middlewares Services applications um we want to be able to support any type of use case um today we have more than 30 um great Builders um that using the authentic stack um more

than 10 of them already on igen test net and we just launched our mayet uh last week so this is also an exciting milestone for the the authentic team as a whole okay so we have we had a quick intro what is authentic what authentic is all about I I I now want to to dive into you know just maybe to have more a clear view or um maybe explaining the notion of what what is an AVS what is the scope of AVS what ABS could be um so first AVS is a Computing service that provide uh its services to other

networks to other protocols to other applications to the end user okay it's a decentralized network that run its own validator Set uh and it's not constrained by any underlining blockchain right I would divide it into four main pillars okay first one it's a proof of stake Network because in order uh to op in to validate the ABS to validate the networks operator must take a certain amount of of token right whether it's if it's ether the ABS native token the igen token and so on and so forth but still

they they have to uh be able to to stake um and put their capital in line or in risk of being slashed and also the operators are being incentivized to be truful to be honest while uh validating the AVS task the AVS Services um secondly each ABS has its own offchain exec ution so really aligned with the modeles as you guys love support and and and and promote um ABS execution is um being off chain

um while um while so the execution is being offchain while the validation basically is being done on chain um which is completely aligned with with ethereum road map where uh the computation is being offload to save resources um to save calculation resources um being of on on chain um so this is the the the second pillar third one is each ABS has its own unique computational use case and let's take maybe rollup for example um so rollup also has rollups also have a offchain

computation but the rollup Network the rollup nodes agree on a certain state or a certain state route right so they come onto consensus on on on a certain State whil the AVS networks come onto consensus on a certain offchain computation uh where its own unique service it's own unique comput computation and I will of course will provide some a use cases an example uh and a good reference for for everyone to to have a better understanding what I mean ER the last one is that each ABS has its own um operate validation

semantic operator set um that in charge of executing and validating the AVS service in a distributed H manner um so this is what I see like the the AVS footprint or the scope of AVS and of course guys if you have any questions you know feel free to stop me yeah I mean I uh yeah this is this was kind of getting to be my main uh we I knew that we were coming to task so I I I was curious basically like how are you thinking about the the trade-offs and design space between rollups and avss like I was write a long post about

this and I'm still trying to kind of wrap it in my head like is there a specific use case that you see ABS as being stronger for than rollups or vice versa yeah um so that's the thing I think the the the main differenciation between you know when building a rollup or when building an AVS it depends depending on the uh on the service itself on the execution okay so if the networks needs to agree on a state transition meaning that a certain transaction between Yen and and Andy as being executed as expected okay so this is a good use case for for Alla okay

rather if it's a general purpose or up specific where the networks need to agree that let's say um let's say that um an intent is being solved in the most optimal uh route or that I'm a service that monitor transaction to prevent exploits so this is like a different type of computation right we don't need to agree on state transition we need to agree that uh a certain computation as done as expected um so this is as I see like the biggest differentiation between uh when you should build a rollup or

build an AVS makes sense so uh basically from a for a use case that is uh relying on consensus among State transitions uh like with transactional value per se of the state the rollups are are like the better use case than when you're building a service that almost feels like they're more like they're more helpful to these different uh uh rollups or to different chains themselves uh by by focusing on this offchain computation that can then be effectively validated on chain um those types of of use cases may not necessarily need to prioritize state or

even have state transitions in their in their use cases and so for those use cases there's no need to spin up a rollup because then you just have this other this kind of like uh you get bogged down by all the different things that rollups get bogged down by but that just doing computation offchain and verifying it onchain doesn't get B bogged down in the same type of manner is that like a general mental model precisely and I will uh briefly describe what the task is where we'll also see like an an example that an ABS operation could also be um uh um authorization or approval of user transaction okay but the the mental

model is yeah as you just mentioned uh you describe it very well cool um so what is a task where we often hear these terms uh in the in the ecosystem um a good mental model for test would be transaction on okay but the idea is that AVS is the core service of the AVS okay this is basically the the computational use case this is what the AVS should execute okay um so the Avs go service indeed can be broken down into units called tasks um and again a task could be any offchain Computing

service and maybe this is a good spot to throw to throw out some some ideas or some execution use cases that is being done by the the ABS networks such as um Oracle right so fetching information from data sources uh training machine learning models analyze transaction analyze data to prevent exploit and maybe initiate the circuit breaks one malicious activi being detected um to solve transaction in the most optimal route to automate onchain or offchain a

workflow to index and query different databases so this is all like right this is like offchain Services uh that the execution is being done off offchain but the validation again is being done onchain so it could be any offchain Computing use case and task is also a unit of work to be Carri out by the network of operator so the network execute the task and agree on the the result of the execution H it could be a result of operation like a a model output and it could be also uh request to perform an operation okay some sort of like

authorization for user transaction the idea is that AVS could have multiple types of task with a different corresponding computational requirement different corresponding reward that may be propagated to different clusters of operator based on the AVS rules make sense any questions about yeah quick question is it fair to think about these uh these abs tasks as like intent that are submitted to these abss so intent I would say it's like

it's a it's one use case even though it's a wide use case what is intent right you the end user configure like a a policy of requirement to when X excute a certain action right so in terms of the ABS the ABS continuously monitor you know different sources and see if those conditions being met if they are being met right then uh the transaction is being executed or the action is being executed um so yeah generally speaking Yeah there is like a lot of usability for intents in the ABS uh but but of course we have some other use cases like

um maybe to um optimize the performance of AI moded okay yeah okay a quick yeah a lot what I was kind of getting at quick followup is that like uh I'm I'm starting to see these Services where It'll like let's say you have a few different kinds of intents and then you can kind of break those intents down into sub intents and then route those to the solvers that are most optimized to fulfill it I'm curious if if there's a similar phenomenon here with tasks where we could have some sort of General task that is made that that is maybe very complex but we can break that down into simpler processes and then we can submit

those tasks to maybe a Set set set of several abss and then sort of make an algorithm or automate somehow uh automate which ABS fulfills which tasks based on which one is special Iz for that purpose is that sort of where you see this going um okay so maybe let's divide it into two one what you just mentioned is reminding me um like a general purpose co-processor where you have a a task each task has its different computational resources or requirements right and then you have this General uh powerful machine that know how to

calculate this the service and output the the the most optimal answer right um this is one two what we allow in at authentic and maybe I can dive into it a bit we allow avss to configure different task definitions meaning an ABS don't necessarily needs to have one task right if it's I don't know let's say AI agent is a good example right it's arbit completely arbitrary tasks um so maybe each task should have different uh um corresponding Rewards or each task should be delegated to different class of or of operator some sort of like

subcommittees those subcommittees has a higher computational resources right so they can execute those tasks right um so yes and no and this is super interesting I think you know have this you know like a a powerful main task that can be broken down into like micro task and being a like optimized throughout the output got it um the way that I'm kind of thinking about this is like there's these there's there's a subset of of these of these tasks that basically uh

end up being these offchain verifiable but not necessarily like quote unquote decentralized applications or or or Services um they're stateful in the sense like um like these these abss they they they may not be reliable for for State transition functions like rollups but but they are stateful um services in the sense that they need to contribute to or that they are they're operating within this the um the ethereum uh shared security kind of layer and then also are contributing to um you know what whatever other blockchain or whatever other use case that they are so they're stateful in that matter they're not stateless like code processors are and kind of provs and these types of

things um but there's a lot of these use cases that like aren't inherently verifiable that you're kind of talking about like like oracles like I know that there's quite a few oracles that are building abss you said attestations I think policy engines insurances uh Bridges even like I think bridge bridge insurance is a really good use case right bridges are just not inherently Trust L um we had a really good presentation with togu from scroll kind of bashed a lot of his share security stuff and bridges was one of the use cases that that you know he found appealing for some of this technology like like these RFQ systems Rob that that you brought up I think there's something there because again these are all done offchain they're stateful they're stateful things but they're not they're not inherently uh

verifiable so I don't know it it just seems interesting that we can use these avss in tasks to basically integrate with onchain applications and onchain like uh blockchainbased apps um and you can get this like this next I don't know how to describe it it's like this this this like you just get more utility and more capability as a result of these kind of uh of this addition of these avss so um yeah I mean it that was my that was my chime in I think there is still like um unmet concept that I personally super interesting in and we right now um uh

making some research about it there's a concept we call like a proof of task okay so you know while validating a task uh when you submit a proof that the execution is done as expected so you need to submit a proof right a proof could be deterministic right like ZK proof and it could be indeterministic like re-execution proof okay but the proof could also be a CID on ipfs it could be hush on I it could be a proof of storage a proof of Machin Hood a proof of space a proof of location right so the idea is

how can we generalize the consensus to support any type of of fuse case um so this is just you know this is like just a remind me that uh this is also like a an unfolded concept that definitely super interesting to dig into it sweet well um I think we are on the same page here um yeah awesome and yeah proof of task is it's particularly interesting I I don't have anything to add because uh I haven't done I haven't heard of it so first

time yeah we'll get to it in a bit um okay so we had like the AVS backbone right the AVS skeleton what is a task and what is the scope of task what is this concept maybe let's blend those two concept together with an example right and a price Oracle example right this is one of the boiler plates one of the samples that we provide uh for Builders as like the fundamental as the Cornerstone to start understanding uh the scope of of fs and functionalities and such um so the idea with Oracle right so we have this Oracle price Oracle AVS let's say which is task is to

validate the current price of a certain asset at a certain time point in time right so what would be the flow of a task here right so let's let's have one entity let's call it task performer okay this task performer is the the nodes that contact the price feed API right so the task here is basically API request so the node Conta contact the the price feed API and check the price of a certain asset let's say ethereum at a certain point in time you send back the fetched uh result data

to the network okay to the nodes in the network each nodes contact its own API its own its own price feed endpoint and compare to the reported data and then each node ATT test if the result of the task performer is valid or invalid right and just the task performer here um is this a set of of of offchain computation that's uh enabled through like the restake eth that's distributed by The Operators to this to this ABS that's the

task performer is that is that what the setup is so we'll get to it in a bit but task performer is it's it's a node in a a task consensus in the AVS operators quum that in charge of the execution so it runs a client it runs a container that the container has some execution logic right this is like the AVS business logic this is like its score service the execution logic says um you need to contact the binance API or whatever data source API to retrieve to fetch the price of ethereum okay so this is like the business logic this is the

performer it's it's it's a node that run a container locally got it okay thank you so yeah yeah sure thank you for your question um so the other nodes at aate ATT test that the result is is is valid right um and this is what we called ER validation logic so they they are checking if their result is within a margin of error okay where basically I is the ABS Dev I configure the maybe the threshold or the the the margin that I expect the the result to be so then the nodes they sign

their answer okay and if we get more than 66% of the nodes that approve that this is the price of ethereum okay all good the task is being submitted the result approved okay so this is like just to to get you into like the the mental model of nodes operator attestation a task and how everything Blends in into this uh the AVS concept thank you yeah just just connect all of the tissues Al together yes um okay right cool um so let's now maybe swis side and let's talk

about IG and how how know everything that we just mentioned how IG Blends in um and yeah what what maybe I ask you what do you think like the you know I have my perspective of the value proposition of of f but curious to know how you uh sees the igen layer value scope like what what you think igen brought along and and maybe then I can you know dive into how I sees uh um I yeah I mean I think like the first point is like the main point that I always talk about is like um basically we can instead of having to rely on creating new proof of stake networks that have

the token emission inflationary kind of problem that it comes to bootstrapping consensus for their Network spinning up an ABS is uh like a very a very efficient way to spin up your own kind of network um for a specific use case um and so that is one thing the other thing is like the big thing that shiram always kind of uh puts and when you really zoom out obviously it's very early but the idea of like uh using using Ian L as a means for like massive coordination amongst different people uh and groups uh within uh crypto and without uh when you really kind of zoom out on the use case that's the that's like the big one

that becomes apparent in the long term but in the immediate term I just see it as like a very easy thing for people to not have to basically people don't have to launch tokens if they don't want of course A lot of them are going to just because uh that's like the way to basically get liquidity and returns in crypto um but you don't have to launch a proof of stake token you can you can launch your token in a manner of uh with a different set of parameters and a different set of of use cases or not right um and so I think that but also like that's kind of a property of rollups as well like where you know rollups also allow you to bootstrap your own network uh with you know without having to launch a proof of stake token

and and uh go through that jazz but uh from what I understand it's significantly cheaper uh on the infer side to launch an ABS uh even though it's getting much cheaper to to launch rollups today as well so yeah those are the two main points for me is basically the efficiency of launching networks and then the the coordination at scale awesome um yeah great completely agree um as I see first and foremost Ian um enables the bootstrapping of network or network security while back then while building our AVS or before even we got

to know again we just you know came across this very fragmented manual process of onboarding notes of convincing you know some like um staking as a service and institutional staking providers and validator as a service company uh to bootstrap a node to to stake your token to give you this attention to run your infra um this is like a like a like a completely manual and fragmented process and this is what I think Ian allow us right allow us to to efficiently bootstrapping security for new

networks second thing is Open Marketplace for CPU and GPU now we have you know we have a CPU GPU consumer which are abss and we have the provider which are operators and this is they are meeting in the middle in the marketplace right they have this this open platform where they can meet engage form this relationship evaluate each other other um set some terms and some policies where they want to engage with each other um and this is completely up to them to decide who should work with whom um so this is two and and three I would say that Ian introduces a new economy

giving that you know it started off with reaking where um e validators could opt in to uh validate more networks maximize their um Capital their initial capitals in the risk of slashing of course um and now we have this you know this platform where everyone can just make his own du diligence process and decide if he wants to participate in a specific Network economy and be entitled to the networks rewards um so I would say that I Al introduces a new economy

we call it like the short security economy um so this is how I sees IG I would also argue that some components are are missing to build those networks on top of IG on top of share security so while igen provides the Baseline layer to bootst security for those networks and Builders are responsible for customizing a system that interact with the protocol and they are also required to develop all of the required lowlevel components that fits this new share

security environment that fits easy boot stopping of a distributed system so um the AVS they require to develop a whole new in for whole new layer to execute those computational task right to uh submit and audits the operator work to reach onchain agreement to propagate internal or cross-chain messaging between the different layer to configure their own governance rules H to deploy their own logic design onto the AVS to Define registration policies for the avss um to distribute rewards and Force

penalties and slashing based on the operator attestations right so there are like a gap between um you know the the shared security layer that enable enable this bootstrapping of network and what networks teams or ABS teams are required to to develop um yeah and so is that similar to like U is that similar to like um I mean the the easiest analogy for me is like what a rollup as a service provider or like these info providers provide like basically what you're saying is that it's not just like you can go and launch in ABS today with like a couple clicks you you need to figure out all of these

different things um that you know assumably authentic provides but basically like it's still not the easiest process to do um and so I I think that's that's that's kind of what I understand there but I think like the main question here and you know feel free to give some commentary on that as well I think the main question here is like is it going to get there like like like are have you seen the progression from six eight months n 12 months ago to like now to what to what you guys have built into like the next year like are you thinking that it's going to be very very easy to launch and thus lead to like you know hundreds and hundreds of abss because it's kind of like the rollup thesis that we have is this what we're going to see for for abss you

think as well um Let Me Take You Like A a few years back uh where there was no rollup as a service okay it was just op stack right so companies AF for to use op stack components to spin up rollups right so optimism basically came up with the idea guys let's have those production ready components and let Builders to use it to spin up rollups okay even not getting into the sequencer and stuff but you know this this is like the mental model right Ian um built the hdk which is to some extent

BLS agregation service and the contract that developer needs to deploy to communicate with the protocol such as delegation manager service manager slasher and such right but still some you know critical components such as consensus such as peer-to-peer networking messaging you know Builders they don't want to handle those stuff they want to focus on what they do best right building their core product right selling to to customers expanding the team right they don't need to deal with this low-level info components um and this is exactly where authentic comes into play um and regarding your second

question um um I so essentially AVS right is no it's it's a product so it might it becomes of course easier uh to deploy the first layer of your product right the info layer but still you need to design the logic right the components the governance you know your own rule to your own product to your own protocol right so ABS is is the first layer but how can you apply your the old product scope into the AVS design okay and this is where it comes complex okay so abstracting igen contract this is good

all right this is something that needs to be done but how can you configure your own rules how can you deploy your on design use case on this AVS okay so that's that's the the the idea cool and and this is exactly where Authentics come comes in so first I would say that our primar goal is to support any type of compute use case which mean that we as a team we need to make the stack as agnostic and versatile as as possible to any type of use case and we need to fine-tune our future development and product road map according to teams

preferences to have this you know first interaction first first uh uh Loop closure um so the stack is is a framework to execute and validate any type of computing use case where Builders leveraging a library of production ready components um and they can focus on their Core Business logic okay the the stack is is not a network is not a blockchain so there is zero Reliance on us as a middleware service right so the stock is is a framework is production ready components that handles the lowlevel infra of avss and allow team to

focus on what they do best and and yeah the idea is that we need to make it as configurable and versatile in all aspect of ABS development so all of the components are ingredients which are fully customizable to allow um a unique use cases to being deployed on top got it cool um we divide the stack into two um components categories some of them offchain which is the consensus the peer-to-peer networking the BLS aggregation and some of them on chain like the AVS AVS management stack

validation messaging and other Hooks and customization and yeah before I dive in we'll go quick quickly over over the the architecture design we go quickly over the components happy to you know dig in a bit if something you want to to uh to highlight or to to Spotlight um but the idea here is that the stack is we have those two those two categories right we have the offchain component which is this programable consensus engine and we have the peer-to-peer networking that allows the communication between the different noes a messaging between the AVS IG ethereum L1 we are also using L2 to support high

throughput of of task submission um we have here an abstracted attestation layer that alongside allowing diverse ABS functionalities it enable high throughput and cost effective of a task submission while also serving as a verified data system um and we have pre-built hooks Logics interfaces and customization where the ABS can deploy its own business Logic on top of the the stack and of course all of the essential smart contract ready to deploy then and IG contract obstructed as

well um so this is like a maybe a double click on how it how it actually looks uh here you can see the offchain component consensus and peer-to-peer P2P networks networking and the onchain component um and now I want to quickly go over with you on how the consensus work and I think this is like a funnel to everything that we've mentioned uh throughout this this session from how the AVS works the task igen layer consensus how it everything Blends in into into one um so as I mentioned this is a highly configurable consensus engine okay in the consensus we have a few

participants a few entities um each and every one of them is the AVS operator that act in different role throughout a task consensus or task committee right we have the performer node we have the ATT testers node and we have the aggregator nodes okay the performer node is remember before from the Oracle example so this is the knows that in charge to execute the task and he's doing it according to the execution service the execution logic this is basically a container it's a Docker image that the

AVS submit to its operator H where the operator runs it locally TR okay so the performer is executing a task and send the result together with what we called a proof of task we mentioned this before so we send the result through an RPC call to the network the ATT testers their job is to approve a task or reject a task and they are doing it according to the validation service or validation logic okay as we mentioned before um margin of error right so this is the validation logic again it's a

container they can write it in any preferred con language um cool so the attestors they ATT testate test on the validity of the executed task um they sign it through a BLS signature and the aggregator job is to collect all of the BLS signature compile it into one aggregated a signature and also to calculate the voting power of each and every operator according to its Stak or restak assets on igen Lev okay so for for instance an operator that St one it versus an

operator that St 208 each and every one of them will have different influence over the consensus process if the aggregator gets more than 66% of the voting power of the network that approve a test so we are good the test is being submitted on chain um so everything here is through uh um a peer-to-peer networking and he submitted onchain to something that we called attestation Center and as I mentioned before it's some sort of abstracted attestation Center where all of the ABS food pring is being stored and also um it's act as an auditing l

ER where um it calculates each operator work on a weekly basis and this is or bi-weekly basis and this is basically how the protocols know how much reward should be distributed per operator per operator work um and the idea here is that everything is configurable meaning they AVS devs can configure that the performer is static they can configure any type of leader election mechanism them they can as I mentioned before they can configure different type of task that are delegated to different type of operator based on their computation based on their CPU resources with different corresponding rewards um they

can configure different hooks while the task is submitted it could trigger some other action on other chain um they can configure a policy of requirement of what type of operator should be able to opt in to work for the network and so on and so forth so this is just like a double click on on the the consensus and how it actually allows the execution of any type of use case um and of course everything is staked weight backed by cryptoeconomic security because those are ABS operator this is igen layer operators H which give us the Assurance um

don't think I will get more into details if you want I I can but this is like the overview of how the consensus work and again this is like the connected tissue of how we can have the AVS logic it's the AVS service off chain computation onchain validation and being part of Shar security or using shared security to bootst uh uh uh the the network I will stop here for for a sec yeah um there's a lot going on here um okay so when it comes to the uh Tas validation and these uh these nodes that are running these attestations who gets to be these nodes like who picks

those right so initially these nodes can be WID listed meaning the the ABS Dev can configure a policy of who what type of operators can opt in to work for its Network you you take this amount of ether you should take this amount of my token this is my CPU GPU Ram requir okay so first you configure like a policy who would be able to validate then the operator they opt in to in different roles they can act as performer as ATT testers and aggregator H performer those all of them can be static all of them can be

randomly chosen ABS can use any type of leader election stake weight mechanism meaning the more stake you have the more opportunity you have to be chosen as X role okay and of course the performer which contribute the most CPU resources he is entitled to more rewards um so it completely that's the idea okay and this is why I mentioned that authentic is a canvas we do not set the rules for each AVS they should configure their own right their own requirement their own preferences and this is exactly what we allow them but is there a is there a preferred way to do this

setup or is there a most most common way that you have had teams that you've already worked with choose a certain setup here like is there just a boiler plate that a lot of people do so it's like um training wheels so some most of them most of them start off with a um static performer one node that run the the execution client okay and the testers they are randomly chosen each task task consensus uh some of them start off with one aggregator um and then spin up more aggregators and so on and so forth most

of them start with a static perform yeah got it cool okay those are those are my my main questions from this okay awesome I think this is almost all for Mayan um without getting go QR code use cases yeah exciting yeah but what is the intent solvers use case here what is that idea how RFQ system could be or like this request for in intent solvers because they operate as like market makers offchain basically there's an ABS to

like verify that these Bridges or that these cross chain orders have been filled or provide Insurance on them or uh allow them to be better because they don't have to have as much inventory risk or like what's the idea there did you want to add something yeah I mean just kind of theor theoretical but like what one idea there is like you could fr the cap the stakers could front the capital and then you could verifiably pay them back and so you don't have to take as much inventory risk um whether it's on a on one chain or another uh because you have slashing rules to enforce repayment of capital in regards to solvers in regards

to filling an intent yeah you could borrow the capital from this from the stakers and then slash uh create slashing rules to make make sure that the the stakers get paid back might be there are like I think there are like several use cases for intents they that will you know they're going to be like u 10 15 maybe 20 big companies that going to you know rule the the the the intent word as as I see it um definitely intense you know expanding in terms of capabilities and functionalities um it could be you know I I I'm I'm as the end user this is my my policy when those conditions are met

please execute this action it could be onchain action but it also could be some sort of like um know zapar alike you know if this happens trigger this offchain workflow right so so this is like a you know two main use cases that I'm seeing right now H how did I'm curious does authentic help coordinate amongst these avss and and orchestrate your like automations across mult like let's say there was a task across maybe multiple abss you know what what is the coordination mechanism to sort of split

up that that task and and divert it into the right direction this is not something that we handle okay so maybe I I didn't mention it before so the AVS devs what they require to develop it's those two Services okay the execution service and validation service this is not up to authentic this is right this is their product okay this is their service so what we have here as part of the stack is consensus and peer-to-peer validation of task messaging AVS governance different hooks Logics they take can configure obstructed a layer of of igen contract

operator registry ABS registry okay so that's the idea but what you just mentioned this is how what they should focus on right the logic how it how this magic happens how the their product works I I I agree with you with like respect to their their abs that the ABS Builder is building but when it comes to coordinating amongst multiple different avss is that whose job is is that igen layer's job or will will we have an coordination AVS to coordinate for avss how do you you know how how can we anticipate M more of these AVS is

working together to combine their services so again so let's let's let's think about AVS as a sus right SS has its own customer base right has its own use case selling to different Market segment have different goto Market Str strategy have this different distribution Channel have this different partnership right I think the the use case that you mentioned you you see IVs is like a like this is like a you know a category with NS which I consider as more like a general purpose co-processor for instance where you know you can coordinate a certain task or delegate

this task to different avss I think as as we see it the AVS mental model it's like you know it's it's a software it's it's a sus it's it's a company it's a product has different type of of customer profile um and the ABS itself is the underlining infrastructure of this product awesome um yeah if you want I can quickly go over the cases not making it too long but of course you're all welcome to to scan this QR and and get into our do and see more use cases so yeah keeper

networks where Mays track some collateralized position and detects loan to value ratio and automatically trigger liquidation when thresholds are brid prediction market right Hot Topic right now but also cool use case with with prediction Market that I see so AVS be like they can have this you know offchain and onchain deterministic data sets data sources like what would be the price of ethereum at this point in time what would be I fdv 24 hours after lunch or what would be Amazon revenues forast for Q4 and it could also expand to a cool use case that I see is like um esport let's say you can have like Fast

settlement of bids and ask throughout an ort tournament like a player score wins matches and such and it would also serve as like a like a a very instant prediction Market um order book peer-to-peer order book where PE can trade with each other AI engines is also a cool use case that we see emerge from authorization and liquidation detectors and rebalancing um so yeah just like a very quick overview of potential use cases sweet um Jaren thank you for for coming on it it's been a really great

presentation I enjoyed learning about each each part of the stack um and I'm particularly excited to see uh some some of these some of these ideas come to light and also how the the barrier to entry for launching ABS is just continuously drops um you know as we as we see that drop we we can see more and more Innovation and I think that we'll see more and more people want to come build you know on authentic on igen layer so um yeah thanks thanks for coming out man thank you guys appreciate it had a great time cheers man