What Is The Next Phase of Onchain Crypto? With Predicate

Transcript

gmgm what is going on guys today we have the pleasure of speaking with Nill founder and CEO of predicate formerly Athos welcome to igen layer unlocked an interactive educational Journey Through the Igan lay ecosystem created by technical Founders and builders for the entire crypto Community a special thank you to our partners all Lair polymer authentic skate and lrange for helping to make this happen our goal is to raise the collective knowledge of the Igan Lair ABS ecosystem and unpack the technical designs of the top teams in space welcome to Igan lay unlocked gmgm what is going on guys

today we have the pleasure of speaking with Nill founder and CEO of predicate formerly Athos and today we are going to be hearing about simplifying transaction prerequisites n welcome to the show thanks so much for having me excited to be here absolutely let's dive in awesome so what I'll go through is I'll kind of give an overview of how we think about simplifying transaction prerequisites and fundamentally and foundationally why igen lay is actually critical to that entire component to really build a decentralized system to make that all work so before we do anything I think it's first helpful to talk about so what in the world are prerequisites why do they matter

and before even looking at web 3 it's actually helpful to look at web two so you look in the early internet all major applications pretty much were had some type of custom rules and conditions that they have on the back end and it was crucial for them to scale and I have a few examples here so let's take PayPal PayPal built an entire anti fraud mechanism because they were worried that hey we're about to build this entire payment system and how do we ensure that you know malicious actors people are trying to commit fraud are not actively engaging in the system system and so that way when you and I go and use PayPal how do we ensure that we're not like uh we don't get basically we don't interact with anyone who's about who's trying to fraud us and they built what they call really a policy engine for

that on the back end so it's an entire system of really pre-transaction rules another one is Airbnb and it was a crucial part for Airbnb when we think about hey you're going to have as a homeowner you're going to have people you've never met before stay at your place and how do know that they're not going to they're not really going to trash your place so Airbnb has an entire system to say hey wait look like we can't have certain guests if you don't follow our terms of service and that of course is informed by prior hosts so when you're about to host someone you have some amount of trust that that prior host have said look this person's okay Uber is very different here than you know like PayPal and or BNB sounds a bit like you know blacklisting at the end of the day Uber is very different so

Uber has a policy in they call call it a poliy engine and what they're thinking about is hey you know when I go and request an Uber there's a number of pre-transaction conditions and rules that have to really be be checked right so what type of car am I requesting what's my Uber rating where am I calling it from where am I trying to go what is a type of car that I've requested and then based off of all of those things they need to match me to a driver that you know meets all those different requirements if they match me to a driver that doesn't now suddenly I'm going to a suboptimal experience potentially even end up in the wrong place so in these case that was Uber creating pre-transaction rules crucial for them to actually build their overall

Network and then Netflix is another one I think we've all we all we're all probably very familiar with like Netflix's geolocation uh capabilities right so we normally think of it as just geofencing and that's really part of it but that's not the full story and so I remember meeting the guy who has one of the patents that Netflix uses for geolocation uh this was back in 2011 and even at that time it was very clear there was a clear reason for why Netflix was thinking about geolocation and it's actually a business decision for them it was having these pre-transaction rules these conditions for how one interacts with Netflix which then influences what is the type of content they can see so if I'm in the US I have access to certain content if I'm in India I have different content the whole point is

actually that Netflix is trying to make sure you have curated and custom content depending on where you're at and Netflix of course is setting up those business Partnerships with all those different media companies to make that fully realized so Point here being that prerequisites have been really common on the back end for web two companies and entire teams are dedicated to real really building this it's not just a small kind of side Endeavor it's really really core it's something that you have a lot of that requires quite a bit of lift so then when we look in web 3 you start seeing that same need of pre-transaction logic especially when we think of of crypto as starting to interface with a broader global economy

uh and there's a number of different cases for this but you know like we can look in Trad five for how we can look at all these different cases of how crypto is really trying to shift into the next the next level which is going to that broader economy so this can be of course if you look in trafi you're starting to see companies like Black Rock and bck participate more actively on chain fintech companies of course like PayPal or Robin Hood are also doing things on chain Robin Hood for um purch in assets or you know swapping assets PayPal even all the way out to a a stable coin then of course you have cbdcs where I would say this is still in like depending on the country you're in there's still either exploration or it's being implemented but then of course if you're

starting to think about how a crypto rail is supposed to integrate with the rest of the economy you have to think about interfacing with the cbdc and then lastly of course we're seeing more retail adoption of crypto as well but in all these cases you know like if you're starting to connect with the rest of the world Developers and crypto startups have to navigate the complexity of meeting the requirements for the rest of the world you can't operate in isolation and so this is an entire set of different things you know this could be the one that immediately comes to everyone's mind if you're in the US is regulation right if I'm launching something I have to think about regulation for you know AML for SEC for Securities all those kinds of things that's part of it but then of course you have different business requirements as

well if you're partnering with an institution or partnering with a payment provider or if you're partnering or if you're just simply doing something that requires some type of real world interfacing like there are still business requirements you might have that can go all the way out to you know something like even exploit prevention and then of course you have different local rules and Community rules that you have to navigate it's all increasing complexity and that's really the problem that we face so let's make that even more tangible now kind of give the broad view so let's take an example a web through example so take Alo large privacy blockchain for them they're really worried that what if we're seen as a mixer uh hu like really really big implications if you're seen as a mixer

if you're in the US if you're in Europe basically no one could use it so their ecosystem passed a governance proposal around best practices for all the different bridges for what Bridges should have in place this isn't mandated by the Alo Foundation it's an ecosystem initiative in all of this you see a number of different kind of you know requirements that you need to have in place right these are all pre-transaction rules so you need a time delay you need a limit of 10,000 USD per day of in in value from any address that's being bridged you want to screen against elicit funds and malicious actors if you know someone's participating in an exploit and then trying to move their funds onto Alo to them laer them uh looking at prohibited jurisdictions and you know like

potentially adopting kyc tools uh I think that's probably been something that most people are more hesitant about because of course that changes how the system works but in this case it's saying hey look we as an ecosystem have certain things that we really care about for for our uh for us to be able to thrive a lot of this this is like really complex stuff this isn't really easy stuff to be able to implement And if every different Bridge has to put in something different or every single Bridge has to put in their own implementation of this of course it's all overhead for them and then shiram actually makes it even more Salient I think uh of course he's always like really articulate from a philosophical standpoint but here we can think of it more as like

imately human and natural when we think of our evolutionary history uh in this case he talks about kind of a cell boundary that really what you're doing is you're allowing certain things to come in and not come in and it's the same way we should think about a community right when you're building a community when you're building something that involves any type of biological existence uh an open border is not a border actually it's fundamentally the opposite and when we think of You're Building onchain applications onchain communities communities inherently require some type of preconditions and we do that already today every day in real world you know when we go when we go to a farmers market or we go and shop at a local store we're making

associations based off of who we're transacting with and so when we think of the scaling of web 3 and the scaling of crypto you need those types of pieces in place it it's basically setting the ability to set values for who you transact with and how those transactions are actually done this ensures what we really think of as a thriving Community a thriving ecosystem so this is a state of the world and then the question of course leads to how can we actually power application communities to build and Thrive how do we one you know allow them to exist how do we allow them to express values and then of course how can they scale into reaching the broader global economy so when we start with that

question you start saying okay great so what are we really trying to solve for here so we have applications you know this can be managed by an individual developer it could be managed by a team of course when it becomes decentralized it's managed by a dow or an ecosystem so for them they have specific requirements that they might have for who can participate how transactions are executed what are the requirements there this of course would require some type of information the great thing about a blockchain is you have access to historical onchain information so this could be any type of historical information but it might be offchain information as well so you know this could be we've talked about a blacklist or risk score or it could be you know someone who was involved in an expit you

need to be able to identify that but it could be even something not as controversial as that it could be hey you want to interact with our system because you want to Mint a stable coin do you have sufficient collateral to be able to Mint it that's a that's a that's a rule right you're checking if there's sufficient collateral to be a to Mint and that might be something you're saying that there's offchain data so here you have you have the need for information information that is onchain or offchain to determine whether a specific rule is met or not so you start with those two pieces the last question is how do you actually enforce that those rules are met for every transaction it's a little difficult for an application to do that inherently in their system because you're involving

some type of compute just not possible from a smart contract standpoint at a technical level so now you need some way of issuing signatures the way that makes the most sense is is a network of operators you could have an individual operator that's basically think of them as almost like a notary sort of checking everything and saying hey this transactions coming in does it look good as for the information that's been provided as well as a requirement if so yes great you can have an individual do that of course if you have an individual you're reliant on that one individual and you're saying that I trust that individual to always do this and you know stay awake at all times maintain up time if anything goes wrong they're gonna make sure it's back up that's a

lot of trust because if they go down suddenly now that application is not able to receive any transactions so here you actually need a network of operators it's the easiest way to build this and that they're designed to really issue signatures so overall you're now envisioning a three-sided Network to build and enforce pre-transaction requirements and then these operators what they need to do is they have to do really two things things one is compute they have to be able to do compute as I mentioned accessing any external apis and this could be used for a number of different use cases as well as they have to be able to function as archive notes because they're looking for historical State they should be able to reference

any type of historical information on a blockchain but this is a real problem right because you know building a two-sided network is is difficult building a three-sided network is substantially more difficult so now you're trying to say wait we have to build a three-sided Network which part do we bootstrap first how do we actually get this thing to even work and it's always been a problem of building networks of which is your toughest side and how can you quickly solve for that you always want to solve for the toughest side of your network to make sure everything else works I think of it as like almost like you're a plumber and you're trying to make sure that all the different pieces are unlocked because the moment that one gets blocked the whole thing collapses and it doesn't

operate and this is where I becomes really important IG enables you to bootstrap the toughest part of the network and create a trust minimized set of operators in this way you have an immediate way to launch a network of operators and say hey wait we already have this in any other instance if you want to do this you either start with a centralized system or you know you might be a project and you're like hey I want to use cryptoeconomic security I need to go and launch a token to be able to create an economic a crypto economically secure mechanism that like I there basically pre uh allows you to go ahead and launch a decentralized network without having to go and do all that work and then of course the other solution here would have been to use something with a ZK

type of style the challenge of course with zero knowledge is that it's slower and much more expensive and for something like this in which you're issuing signatures you need it to be as light as possible if it's anything that's not light it changes the user experience fundamentally it changes a way it actually breaks the application experience it becomes expensive it becomes slow it's something you don't want so this is where igen L becomes really important you are able to bootstrap your operator Network to be able to issue signatures and really it solves the toughest problem so now let's go in a little bit on like how we've thought about that design and really that architecture when we think about this mechanism of aiing signatures to enforce transaction prerequisites so what we do here is a

user interacts with an application interface let's take a bridge contra contract for example and we can use we can use the Alo example actually maybe that's the simplest one because we've already kind of talked about it so a user goes and interacts with the Alo uh Bridge U interface the user shouldn't have to do anything different the problem is historically I think in crypto we've always thought about oh like if you try to do something if you want to have some type of free transaction checks it should change the user experience fundamentally generally that's the wrong way to do it the user should actually real should not even realize that something is happening on the back end and this is again why igen lir becomes really powerful so the user you know goes and interacts with the bridge they U they link to it and they're sending

the raw transaction the interface sends that transaction to an aggregator and that aggregator really is just designed to pull all the transactions together and then broadcast that to the operator Network these are the igen layer operators so your igen layer operators is saying okay great there's a transaction that's been broadcasted to us it's for this bridge contract let's let's go and check the specific policy the specific requirements for this contract that's been set by that developer team or by that ecosystem so that requirement is stored on ethereum and in this case you're able to maintain a decentralized and a trust minimized mechanism because you can actually have the owners of that policy be anyone the ones who are supposed to be responsible for it so the operators

go and check to see if the signature um or to see if the transaction meets those requirements so they pull the the requirement and then they say wait we have to do some compute here we need to make a decision of yes or no so they'll pull the relevant information for from onchain when they function as a historical uh or an archive node and they can also of course pull offchain information so this could be anything it could be you know like uh in this case from an Alo standpoint it could be risk data uh has a user been involved in an exploit before um are they a sanction entity so in this case they go and pull that information they make a decision and then if the transaction meets the

requirements they issue a signature so they enforce a policy and then issue a signature that signature is sent back to the user so when they actually hit submit on their transaction the signature is embedded in the transaction object again the user has never realized that this happened they should have all happened subc but the user hits submit and the signature is nested in the transac the transaction object so when the transaction goes through to the actual smart contract and hits a mempool the transaction is only processed because it has a signature from the operator Network IG there essentially here enables that entire structure of pre-transaction check validation issuance of signature and again subsec

latency with the ability of saying look the user experience should never change so why would they do this right and so this again really becomes important they're doing compute and this really feeds into how we think about an overall network if we think of prerequisites so everyone here is now incentivized to participate in a system that becomes decentralized so information providers of course are supplying information and they get economies of scale they say hey look we're going to get paid for this we're providing information that's being utilized applications are saying we have pre-transaction rules we have policies that we need to be enforced so they're putting that in place and this is where

operators and rakers come in operators are responsible for enforcing that a transaction meets the requirements and so they're going to say hey look we are doing a compute here we have overhead you know we're running a machine and then same rakers are providing the economic security to make this all trust minimized and so they're earning yield and they'll they'll demand yield to uh to issue these signatures the important part here is of course the applications of demand for it so there's different ways of thinking about how an operators and rakers make money one is of course a user can have some type of fee that you can have a fee that's imposed on the user depends on the level of compute this could be a few cents this could be a dollar$ two dollars it really just depends on the

type of requirement that's being that's needed and the type of compute that's needed so either you have a fee that's paid and the fee is paid before the transaction is executed so it's the first step in the entire transaction flow alternatively of course an application could subsidize the fees on behalf of their ego EOS system so you can say hey look we'll subsidize it but all this creates that three-sided Network and again going earlier you bootstrapped that network of operators through igen layer and had it that you have a distributed Network as well as the ability for General user for for General uh retail to also be able to participate in supporting that Economic Security through reaking but you can do a little bit more

here as well and this is where it starts getting even more interesting so igen lir provides a foundation as your reaking platform then of course you have different uh forms of Economic Security you have natively Stak e you have uh liquid reaking and then you even have other token projects right you have stable coin projects that might say hey look we want our Economic Security to be used the great part here is you can actually as an application when you're thinking about or a community you're saying hey look what is the source of policy enforcement that we want the pre-transaction check who are the ones who are enforcing this you can start with a wide network of operators and say whoever issues signatures first based off of a quorum that we've set they come first or you can even set an alignment

with specific operators you can say look maybe I really want uh P2P in this or I really really want figment or and a project a community might say hey we actually want our token to be used on the back end because it's alignment for this policy enforcement and so we want oper operators who have specifically our token as well as part of Economic Security this is something for example that m0 might want MZ has a network in which they're saying how do we create a a mechanism for minting stable coins and they have a network of validators so in this case you can actually align that's the the validator network to the minting of stable coins by also utilizing their their core asset as part of it but that flexibility can become

really powerful when you're starting to think about what is a use case that you want and what are certain things that you might actually want in place and that leads here let's take an intense system this is a different use case but again this expressivity becomes really valuable when we think of an operator network uh traditionally in intense uh the user right now you know such as myself Express the outcome that we want of the transaction usually it's like something like I want best price for this swap that's the most common I think of that is like V zero of intense but over time you're going to have more complex types of intents and really at the end of the day I should be able to have expressivity in terms of how are my intents executed because I might

actually care about that I might care that my transaction goes to a route that's not been exploited in the last six months because I'm saying hey look I'm moving a larger amount of funds and you know I've done that before in the sense of like I'm like am I going which front end interface do I use for certain swaps it's because I'm like you know i' would rather use a Unis swof Labs interface versus something I don't know because I'm like maybe this time around I'm willing to pay the fee right there's certain things that I really care about here and we should Envision the same for intense systems so now in an intense system you express your preferences so here it's in this case with this diagram I want to express an intent that I get I do a swap of dgen on base for eth on ethereum but

I don't wanted to go through any routes that have been exploited within the last six months I've expressed that preference from there now that transaction needs to be brought brasted to a middleware that is then broadcasted to an operator Network the operator Network again brings in the relevant external information to say hey these are the routes that in which a transaction or here these are the routes in which you can execute the transaction while meeting this uh this specification The Operators do a compute and then give the outcome and then the uh the transaction is executed through solvers in a traditional intense system but going to here when I was talking about you can actually start specifying what types of operators this

gets valuable right because now suddenly if I have a generalized intent system and I'm trying to set specific operators or I'm trying to set specific routes you also can have specific operators who are the ones who are fulfilling the the checks based off of what assets they're holding you can specify I want specific operators or I want operators who are holding certain collateral for Economic Security because they are now the ones who are incentivized to do this correctly you're able to start doing an entire spectrum of spe spe specifications again without again trying to do this in a more generalized network if you were to do this like without something like I becomes infinitely more complex and more difficult so it's all about the ways of how you can use igen l to align um your

Economic Security and your compute in your pre-transaction checks and really what that enables is a more Sovereign and express expressive transaction Paradigm all while retaining decentralization that's fundamentally never been done we've seen some of these types of executions in web 2 in traditional fintech rails where you rely on centralized interm intermediaries to process validated transactions but having it in a trust minimized decentralized manner to be able to execute all of these things is something that is only possible is is only possible in web 3 and only possible when you use something like IG so that's really kind of how we Invision the world and where I is really powerful when we think of the ability of transaction prerequisites so I'll pause

here thank a bunch that was phenomenal uh yeah great I I do have uh several questions here so uh let's uh let's get into it first of all that that was great I love how General the system is um and and you know using the igen layer operator set the ethereum operator set through igen layer for for quite a robust set of uh potential use cases I want to hop back of um to I guess let's hop back to the intent example first because I I actually I wrote it down in my notes as intent preferences back in slide like eight and

this is slide 14 and then you ended up getting there so oh cool yeah so I I think this was like automatically just a a a really um just a strikingly obvious use case for for this system as we see intents get more and more prevalent um like you said right now the the main lever that people try to pull is best best execution price and then maybe they'll they'll Slide the latency lever you know back right if they don't really care how how quickly they get filled but they really want the best price can imagine you know bigger transactions bigger institutions using that that sort of uh tradeoff um and and you know we can also pull different kinds of levers we've had several conversations with uh

Aran from everle about the way that these solers tend to rebalance positions and so it's not just the intent uh uh submitter the person who's trying to submit the transaction but it's also the solvers that are rebalancing their their inventory and maybe um you know you don't really care if your transa you want the eth right in this example you want to get rid of dejun you want the eth but maybe you don't care if it's eth on ethereum or optimism or arbitrum you can kind of create this set of trusted rollups as long as it's on one of those you know you you would be fine with the outcome and then choose the best parameters for that best price is maybe optimism uh so you go to you take the ethon optimism right and you could and

and what you're saying is you can check those predic those those uh the state of the solers um basically price quotes and and latency quotes you can check that ahead of time and then submit the transaction for the ideal path that's right so it it depends on how you do the flow here but that's right so generally speaking that's right so you have a network you have solvers right and solvers are responsible for constructing the transaction pathway and so then what they'll need to do is say hey we're constructing the transaction pathway what we'll have to do is we should check we need a we need a we need a validation we need to check saying that yeah this meets a requirement and so as they're doing that they're able to basically broadcast to The Operators and

The Operators are pulling the relevant information needed to say yes yes no this one isn't good yes this one's good no this one isn't good um so that way you have that ability to express because otherwise if you try to have all that done by solver it starts becoming more and more computationally heavy you lose you're going to lose the expressivity you're gonna have you're gonna have challenges around latency and so instead I subscribe to the view of solver specialization over time and so in this case you're actually plugging in your operator network with solvers so there's actually and I want to add there's like you know there's actually another Vantage Point here too so here we've talking about the user expressing um preferences for their execution you can also have presumbly solvers will likely have spe preferences for how

transactions are executed and which ones they do and liquidity providers into solvers will may also have preferences for how their liquidity is used that becomes really interesting because when we start going into the world of solver marketplaces like what a group like Kanani is doing um you'll probably have LPS who are saying here's how I want my liquidity user here's certain cases in which I don't want it to be but how do they actually have the ability to express that you still need a mechanism to do that so in this case what we're able to do is we can you know you can it's relevant for user expression for executions but it's also relevant for the solvers or the LPS of solvers or any other participants who saying hey we have specific requirements for how this transaction is executed yeah yeah didn't didn't think about the lp use case there

that that's really cool and very very excited about what Kevin is doing at at colani with solver coordination um awesome okay that that makes a ton of sense and I think it this solution is very powerful for for intent um I originally I that came to mind because the predicate here like I when I was going through English class I always learned like you know subject and a predicate is makes a complete sentence and so you know when I'm when I'm thinking here and I see that these are predicates right what is the subject intents I think fit very very nicely uh in that framework um I W to uh dive a little bit deeper into the architecture here um so I think we'll we'll cycle back a couple of slides to to to here

and so I see the the flow goes bottom up um I think it makes a ton of sense as the client sends the raw transactions with the predicate SDK they broadcast these uh tasks to The Operators that and essentially tasks are are the different checks that the operators are going to sign off on or not and then ultimately and and so the the these checks you know maybe we split those into two different buckets we have the onchain checks that checking different onchain bances account balances Bridge routes etc etc verified contracts potentially the second bucket would be any any data any checks that aren't available to do from these archive nodes onchain and and have to go into the

offchain world y um I let's so I want to dive a bit deeper into this offchain component and how how this is how this offchain data is brought uh into an environment where these operators were able to check it do you do you use oracles can anyone provide this information let you know what is the extensibility of some of these predicates that rely on some some data that's only available in some far off distant land yeah it's a good question so in the case of offchain calls really what you're trying to do as an operators really determine a yes or no for some requirement and so maybe the simplest

example here uh would be like a group like trm so trm as you might know provides risk scores for transaction data a lot of front-end interfaces used trm but you might also use it for backend for your smart contract to say hey we just really want to avoid any address that's been uh a sanction entity like a North Korean entity who's trying to facilitate terrorist financing so all right great so we know trm has our data offchain in a database it's highly private data they're never going to make that public right that is their data mode but what you need is you just really need a mechanism to just say hey there's this address does this address fall on your highrisk or severe list of addresses based off of um your your sanctions list so that's a decision

you're trying to really make now the question as an operator is how do you actually get that so what we do here in this case and anyone could do it but at the moment we have our middleware so the middleware here is something that's designed to broadcast the transactions to the operator anyone can anyone would be able to spin up their own middleware not yet but that's B basally where we get to but at the moment The lab's Entity for us has built a public good which is a middleware all it's doing of course is broadcasting transactions but in the case you have an API call that needs to be made or an external information provider the middleware holds the API key so what we've done is we have let's say a partnership with trm where trm is provided an API key so when the transaction is broadcasted to The

Operators what's included in there is also an API key so the operators can say okay great we can use this API key to go and make the call to trm and say all we're doing is sending this transaction tell us yes or no that's all we need to know so trm will uh return a thing saying uh yes this transaction is not high risk you're good to go they issue that back the operator has that as part of their compute and then they say okay great we've gotten a response from trm we're going to issue the signature now the important part to note here right is like for anyone who is using offchain data you are of course trusting that offchain data provider to be good right you're you're trusting that their data is clean you're trusting that their data is accurate you're trusting that it's up

to dat and that the information provider the external information provider here is actually going to be responsive let's say you set a rule that uh we have to have a trm check and for whatever reason trm goes down you actually your transaction won't go through it because your operators are going to be like hey we need to we can't issue a signature until we tell until we get TM to tell us something so there is a trust mechanism that is happening here when you use external information providers so that's an important thing to note here but that's generally how the flow works now of course we could have different groups that spin up their own middlewares and might have different API keys and things for different external data got it and I I I think this comes into play with the previous example on around intents as well because a lot of

intents uh excuse me a lot of solvers have their inventory off chain maybe centralized exchanges and such so um got it and so the information providers you know are are access through API keys do you provide those API keys to the operator so that the operators can go and fetch that information that's right so what happens is the middleware basically sends the API key to um in this case it depends on how many operators are needed uh and how many API keys are provided so with trm it's just one but with some of them they might say hey look we'll give you three like here's three API keys in case you doubt like any one of them so it really just comes down to the information provider and uh whether they're like look like

you're going to get the same exact result with any of these we're a large trusted entity trust us with one API key that of course comes down to the application and how comfortable they are but in some cases you might want to do you know more than one um that gets interesting or let's say when you start thinking of like like I think trm is a different use case versus let's say you're doing offchain collateral calls to say there a sufficient collateral to be able to Mint a new asset then you might want to have more than one call for that right and so that's when you start having this complexity of how what type of API like how like how many API keys are sent how many operators do you need to go and check to say Yep this is valid this is good very cool yeah I I

see this potentially extending into the the one there's probably more than one but one of the use cases that everyone sees on the horizon but has not been accomplished yet which is under collateralized loans uh onchain and if we have access to banking data or some some offchain data source that is able to provide those checks in order to Mint some some uh debt onchain with some offchain collateral we could potentially we could potentially get there yeah it's a really good point that's actually one use case we have been looking at because when you when we talk about prerequisites and the complexity of that if you're doing offchain or if you're doing you know under collateralized lending there's a ton of information you

have to work with and it also depends Market by market what type of loan you're doing uh what is all the different data pieces what are the regulations the requirements all those things so like if you're like one group that we've been looking like one example I can kind of from like prior work experience if you're trying to do like under collateralized lending in let's say Kenya uh that requires you know pulling different offchain information such as like credit history things like that but then also like phone data because a lot of things also happen through Mesa so you have to think about that type of information potential payroll provider information you're trying to pull all that stuff and then there's probably going to be some onent things you want to pull as well all of that is a lot of complex work that you're trying to aggregate together and

I imagine that most crypto projects that are trying to say we want to do under collateralized lending don't want to have to spend the time building all of that they want they really should be focusing on loan origination like that's their business model they make money by originating loans and earning some type of yield off of that but if they spend most of their resources building the backend system they're basically blocked from going and doing all the other work that they really need to do and that's again like how do you offload that complexity yeah would would love to see that built out um cool so completing the flow here um the information providers provide that that info to The Operators who enforce uh that policy by checking the data and returning a signature um

and then ultimately they they uh uh they make that signature and and uh uh the user's transaction uh goes through after passing those checks um cool so that is the workflow I think that makes sense and then I I have a couple more questions um mostly on on like igen layer specific uh and so cool yep um now you mentioned one one element uh of choosing specific operators for specific tasks and I was generally curious because I haven't heard a lot of abss use this framework yet um is this something that's available for anyone

that's using IG um and and if you don't mind dive a little bit deeper into how this works you're you know how you're able to coordinate and and basically choose a particular set of operators for certain conditions is that up to the user is that up to to you as the predicate as the ABS yeah if you could if you don't mind explaining that a bit further yeah so this is something we don't have up yet like this isn't live yet or possible through our system but that is what we're getting to is the ability to actually be able to select your specific operators it's not that we would do it right now the way we have it is you know we have General operator Network we're thinking of actually starting with a proof of authority model that then shifts to a proof of stake model so

you're able to do that but then of course the idea is that we it's not that we shouldn't be determining this like as an application or as a as a generalized kind of infrastructure provider we shouldn't be making opinionated decisions on which operators but an application might and so for them it's actually giving them the ability to do that this hasn't been built yet but that is where we get to because we think there is a world and a need for those kinds of things as you start thinking different types of Integrations different types of prerequisites what types of assets might you want in there maybe some that are looking at a bit more of like institutional use cases might say we want certain institutional operators as part of this we want or maybe they want specifically only their signatures you're able to do those kinds

of customization yeah yeah I can imagine potentially deals with between applications and operators as well like preferred operators for certain applications um and then you mentioned the bridge uh use case with certain paths validated by by a specific set of operators yep that's right cool um and then uh you answered a couple of these questions already um okay so uh in terms of kind of the more generic Ian layer questions um I I think you may have hit on this but just to expand a bit um could you talk us through like slashing conditions

and slashing rules you know why might an operator uh or a Staker be slashed um and I you know I I can kind of guess but I'm sure you would explain it explain it a bit better in terms of the checks and and passing legitimate signatures um and then the flip thought of that is the apy and how that's how that's generated you you spoke to the fees but maybe we'll we'll touch on that but yeah let's start with the the slashing and uh talk us through how that works yeah so the way we think of slashing and I will say on day one we don't have um slashing so instead some more of a proof Authority model but uh so there is no slashing but here's why slashing does matter um the main things to think about slashing the

the biggest question of course of like the biggest okay I think it's start taking a step back it's like okay so what could possibly go wrong in this system right so why do you have a distributed Network you want it's because you want to maintain you want to address certain things that might go wrong the biggest thing what what what could go wrong is an operator goes Rogue an operator says you know what I'm going to enforce my own requirements I don't really care about what these guys want I'm going to set my own requirements and so that could be you know uh stolen funds go through that's that could be one thing or sanction funds or it could start becoming a bit more precarious right they might say oh you know what there's not enough collateral here but I still want this to happen I want this

thing I want this loan to happen I want this asset to be minted um I want this specific transaction to be executed in an T system even though it shouldn't be because now an operator has basically uh partnered with someone who's planning to take advantage of an exploit that happens later and they're going to take advantage of that exploit through that transaction route those are the things that could go wrong here so what you really need to think about from an econom from a slashing standpoint is operators need to be enforcing the specific requirements that are set and it's not this isn't opinionated it's deterministic because really what they're doing here is they should be checking the the specific rules that are set by that application the the actual rules are stored on ethereum and it tells the operator here is the data you

should be using here is the offchain data here's the onchain historical data it's is it's meant to be deterministic this isn't something that they're like oh let me think about what's the best way to do it it's like no this is the right way so given that world you want the operator to behave the way that they're supposed to do the other risk too right is if you don't have um if an operator decides to do their own things they can also send an application they could say we're not going to allow certain transactions to go through even though they should be that's a big problem for an application because now you suddenly have a centralization you now have a censorship vertical that's happening or a censorship exposure so that's where this becomes really important is ensuring that operators issue signatures when they should be and don't issue

signatures when they when they shouldn't be you could have slashing I know there's been discussions like we've thought at one point about do we need slashing for um uptime we're not sure yet and that's because you have a distributed network of operators so in this case it's the first signatures that are issued or the ones that are included the application sets the Quorum so maybe they'll say we want three signatures so it' be the first three signatures now that might be enough of an incentive you may not need slashing if an operator isn't uh responsive so this is something we'll probably have to figure out over time we don't have the I don't have the clearest answer yet but our current hypothesis is we won't need slashing for that quite yet and and so the the flip side of that being the py and sort of

the rewards you know I I think the demand speaks for itself right and those monetize and charge some fees based on that the demand for these checks and pre prerequisites but when you're when you're getting into Distributing those rewards and the fees you know are you kind of mentioned you know the first three operators maybe you need three checks you know do you distribute that to The Operators who are making these calls and then and then kind of what's left over you pay to the stakers or how are how are how should we think about this in terms of the system um of Distributing the fees that are paid by the applications with demand for policies yeah so this in terms of the

the fees what happens is the fee would probably be paid in some type of native the native gas asset or some type of native asset now there's different ways we haven't like built out a token or anything so there's a lot of different ways to think about your token model but fundamentally you have a fee that's coming in at the start from that that native gas asset now it's the question of okay cool how do you distribute it to operators uh the way we've thought about it is the fees should be going to The Operators who are issuing signatures right so the ones that are being used in that system so the first operators that are issuing signatures are the ones who are earning the yield they're incentivized to be as quick as possible then when we think about basically that cash flow waterfall uh the way we've seen it so

far is operators either have their own Economic Security that they have you know someone runs an operator and they're like cool I have you know a large amount of eat that I'm going to put into the system or they'll work with lrts and so in that case what the yield needs to be is proportional to the amount of Economic Security that they have so in that case once that goes through operators might have Partnerships with lrts and they'll figure out how much do they keep versus how much of it goes to the resters and then other operators who don't work with lrts they of course can keep it all to themselves so it just depends on that structure and who is a provider of Economic Security and we kind of leave that up to them we're not uh we don't have to make determination all we do is

we say as what we just want to make sure is that you have a diversified U basket of or Diversified set of operators with a diverse set of Economic Security ideally not from just only one LRT for example yeah yeah that makes sense and you mentioned uh you know a couple of precarious situations when when you know why it's so important to to make sure that these operators um are are acting in good faith and and your mechanism to enforce that is Slash in but you know in the case of let's say this this uh solver check we're going to make sure that this intent passes some checks it and you know maybe the the operator says like oh yeah it's fine because they want to make some sort of

exploit is it enough to to retroactively or react to that by slashing the operator after the effect you know in in my mind it's like you know we're gonna they're GNA take the money and go run away with it and then they're and then we're gonna slash them yeah right so how how do you kind of how do you think about slashing in in the reactive sense versus the preventative sense yeah it definitely becomes more complex when you start thinking of the proactive versus reactive uh in this case then you'll have to really start thinking about what is a quorum of signatures that you want uh so in that case it's not you can probably have a smaller Quorum of signatures if you have let's say a uh uh

kind of that um that reactive type of model but in a proactive setting your number of signature issuance your sign your your Quorum becomes really important your diversity of operators becomes really important you might then at that point and this is still early because a lot of these intent systems aren't up but then at that point you probably will also want to think about making sure you have certain requirements for having a distributed network of operators so it's that like you can't have only your your Quorum can't be 10 like five or 10 operators all from the exact same IP address that'd be a problem right and so you'll have to actually probably require a diversity of operator signatures before a transaction can actually be executed through an intense system so it starts becoming a bit like you know running a blockchain almost right like and like

when you start thinking about those things is what's your network of validators you're processing transactions so how do you have a distributed set there how do you know that they can all behave appropriately even if someone behaves maliciously or a set of them behaves maliciously how do you ensure that that doesn't wreck the whole system then you start looking at you know the tried the tested tried and true models of cryptoeconomic security as we've seen for L1 uh and the good part here is you're using something like eth as economic security if we were using our base asset if we were just you know an L1 now of course we're having to think about how do we ensure the value of our L1 token whereas in this case you say look eat is eat this presumably more robust here than anything else these are all the fun

choices and decisions that application builders get to make um yeah I have a feeling that and this is where it starts getting really it starts getting super complexer I have a feeling that you'll start seeing some consolidation of okay cool here's what we'll do you'll see a few projects spend a lot of time figuring it out and then everyone else will sort of adopt it but the question of course is can we stay unopinionated or if you have like or like at least promote some type of best practices or some uh some kind of lower boundary for Best Practices yeah I I tend to agree I think we'll see some shelling points and convergences around certain slashing rules slashing contracts certain operator quorums and operator decentralization sets of operators um to

enforce certain diversity requirements um and we'll we'll start to see that come out but it's still we're still on the precipice of all this slashing isn't even live yet so it's it's very exciting times uh n this was a a great presentation could you uh I guess just end off by telling people where they can find you um you know H how they uh if they want to stake uh into predicate how they can do that um and ultimately how how to get involved yeah so if they want to get in touch we're on Twitter at zerx predicate uh predicate doio is our website there's a contact form there I'm also really active on Twitter so if you want to get in touch there I think my uh handle is up here at the front uh so that's my Twitter handle at pumper nickl uh so in

this case that's probably EAS way to get in touch and then if you're interested in like staking or a system running an operator or something like that we are on IG layers like dashboard and all of those things so that's probably the easiest way to go take a look and be able to St with one of the operators that is in our Network or you know spin up your own operator and if you're interested in that feel free to reach out and we of course can get you added to our telegram group of operators amazing thank you so much n thank you appreciate it