SLINKY ORACLE with Maghnus Mareneck of Skip

Transcript

welcome to the interupt today my guest is Magnus marn co-founder at skip he's back on the podcast for a third time now talking about Slinky it's the first restake Oracle aggregator built for purpose markets and defi protocols today we'll be talking about slinky's architecture and how it enables chains to leverage their validator sets to run highly secure and aligned price feed oracles we'll discuss other possible use cases for S Slinky like antrop ability and mesh security we'll discuss the benefits to defi protocol security and revisit the Lana attack and how Slinky scales I'm also dying to find out why he thinks the current Oracle Market is broken before we get started be sure to

subscribe to get notified when new episodes drop every week and remember none of what we discuss here on the interop is investment advice if you enjoy this content stake with us we're validating on AOS Quicksilver and osmosis just look for interop in the active set my guest Magmar is coming coming up next right here on the [Music] inro I'm here with Magnus marck he is co-founder at skip U we're getting him back on to talk about Slinky which is this exciting new idea that has kind of

been hinted for a while I think when you were last on the podcast in September to talk about um the uh block SDK you know you you hinted at this idea of being able to run oracles on chain and honestly it's a pretty exciting idea and it's uh something I've been thinking about a lot since you've mentioned it so today I'm getting you back on to dive into the details of Slinky what it enables for chains in the cosmos and how it improves you know the usability of applications but also reduces um some pretty significant attack vors um in D5 so thanks for coming back on yeah thanks s excited to cheat so maybe just before

we get started uh you were last ONN in September so that was you know about five months ago what has been the major developments over at skip since then and you know how many chains are now using uh the block SDK and skips API sure yeah so I mean things have been exciting since we last chatted um obviously Cosmos is in a very different place since September I think we were still in the depths of you know the bare market and we didn't really see a way out back then I think since then you know things have gone up in the ecosystem and also we've uh we've had a lot of validation for our initial investment in sticking with Cosmos since

the very beginning um so in terms of just sort of what our products we is and how it's developed we mostly focus on two products now so obviously the skip API which is this uh you know cross chain routing service that builds on top of multiple different Bridges now but especially IBC and uh Slinky which is this Oracle we'll chat about today block SDK is something we still maintain it's a piece of Open Source software uh we are now it's it's very complicated software just because it's sort of very involved in this uh sequencing layer on apci Plus+ but the first two chains that we'll be adopting it are going to be osmosis and neutron um those Integrations are like right around the

corner and that's going to be the first sort of like real live use cases of those things it's also on some chains that are about to launch uh so inisha will go live the block SDK we're still working on getting it into be chain and a couple other folks uh they have some complications with their whole evm system but we basically want the block SDK to be something that's there for let's call it like chains that really require very custom functionality for their sequencing um and something that you know will will support uh as as those chains go Al but for the API it's been you know it's been put in almost you know every major front end that that we've seen uh Kepler is now using it to power all their swaps if you've ever

used that obviously it's behind IBC that fun if you've ever tried that out before and uh now it's integrated into osmosis it's being integrated into demension in um we have a very big road map around how we're sort of executing the go to market for that in Celestia more generally and yeah you can expect to see it sort of pop up in other places cool that's exciting well I mean judging by um how um people are reacting on Twitter to you know this uh this Slinky announcement I think people are generally bullish about it so I'm excited to chat about it today so you you guys announced this about a week ago in Twitter uh post and then there was a really long and interesting uh Forum

post over on the skip Forum uh came out a couple days ago we'll link to those in the show notes so what is a restak Oracle aggregator um how does this work and what does it provide to change that use it yeah so Slinky is from our understanding one of the first major like production use cases of reaking at least a very intentional use case of reaking um um and not an accidental one uh and the the the way that it uses reaking is to do exactly what you said just sort of aggregate not only just one price feed but aggregate multiple different Oracles or or Price feeds for a chain so the idea there basically is that we leverage 100% of the existing

stake of a network which means you know you have let's call it you know $10 million that is actually securing the network we or reuse that to also secure the Oracle operation in a way that ties consensus and correct Oracle operation together atomically which means you can't have liveness without correct Oracle operation and you can't have correct correct Oracle operation without liveness they're one and the same which is very different from existing oracles today so for example if you use pith or chain link or pretty much any other Oracle on the market those are separate chains that are running and operating and the only way that you get that data into your chain is via some kind of

transaction sometimes that process fails right sometimes those transactions don't make it over for whatever reason and we'll probably CH chat more about that with the Lavana Tech um but in those situations the chain keeps on moving right and so all the di5 protocols that were expecting that update you know now have to sort of continue to execute even without it and that's sort of where all the Oracle hacks and attacks happen and so so Slinky doesn't have that it has a guaranteed per block price update um and it is you know a lot faster and a lot more secure and a lot more dependable than something that's based on an external model or an external chain and relies upon the relaying of those transactions coming

over um it's an oracle aggregator because you know basically what it does is it uses the native validator set of the chain to pull in prices from an arbitrary number of sources so right now we have 20 different price providers so basically that's like you know coinbase coin gecko coin market cap all the way to Unis swap osmosis and a bunch of other dexes as well so you can sort of arbitrarily add these in um and then you aggregate across all of this so when when people generally think of reaking you know I think what comes to most people's minds and certainly mine is is this idea of being able to use security to secure the state of another chain so

like I is um is one example where we use eth to re hypothecated eth to secure other chains and so therefore we have all the economic security of ethereum backing the state of another chain um the cosmos Hub and replicated security is another example and here we are leveraging reaking essentially for for security and for the the sort of security of the state of that chain now when you're talking about reaking here it's it's another use case so right so we're using security to we're using the security and the stake of the chain to provide an accurate price feed so we're leveraging

the security of the chain uh to provide that that price feed to the application is is that so basically what we're saying here is that Slinky is is innovating with a new use case for reaking so it's not the reaking that we've sort of like known for and has existed in this narrative for a while it's like a new use case for for reaking which is providing price fee data is that right yeah I mean I I guess there's an important clarification there which is in igen layer right what you're secured by is restake eth you're not secured by ethereum right like ethereum is not going to slash all of its stakers if some user of I layer does something

bad only the restake eth on igen layers abss will be slashed so I think as of now that's about $2 billion but it's you know a very far cry from the whatever it is 200 plus billion dollar market cap of ethereum itself so basically I is a protocol you know it has some amount of money in it and that is what is securing uh you know all the different use cases on top of it so in the case of Slinky we use 100% of the Native STI right so let's say you're let's say you're like osmosis uh you know I for get exactly what the osmosis market cap is right now I think it's about $1.6 billion you're leveraging all $1.6 billion across all of the

validators to secure your Oracle operation and any other kind of reaking service you build on top of that stake right and so now you're deciding between okay well do I use the native stake that I have the native security which is $1.6 billion or do I use IG layers $2 billion right those are pretty close right like that's not a order of magnitude difference except in one case I have to do a lot more work and I have to pay a lot more with parties that I don't understand on the reaking side versus folks that I obviously know very well my own validator set using my own security that I already pay for Via inflation right which is just native to the chain so the other thing to realize I think just on

that is you you can't get better than the like own security of your chain when it comes to Oracle operation right so think about it this way let's say I have a billion dollars of security on my chain if 2/3 of that is compromised right so whatever 666 million 6666 blah blah blah um that means my chain is bantine right like I can't uh I can't do anything anymore because like two-thirds of the state can decide to do whatever they want they could execute completely incorrect State transitions they could trade wallets they could just make osmosis whatever they want and hard fork and have the canonical chain in that

case it's not really relevant for the Oracle operation which will also be malfunctioning that you have like restake on another platform because your own platform is compromised right so basically we tie the Oracle to the same assumptions the same Byzantine assumptions as the chain itself meaning you need the same amount of stake to be compromised to take down the Oracle that you do to completely take down the chain itself when you have obviously bigger problems than just Oracle malfunction so basically we wanted it to be like the the same security properties is the chain itself like it's Atomic with like the correct operation okay so so here we're using the validator set to uh to essentially

we're essentially leveraging the validator set to provide uh some data to the application and so the validators are uh are slack able based on the information that they provide so it could be price feed data it could be data about transactions happening on another chain it could be data um it could be just like any any data source essentially that the validators bring to the to the table they they they submit that data to the block they become slash on that data and so therefore there's an incentive for the data to be accurate correct you know available Etc that's right yeah so there's not only just a

disincentive right which would be some kind of slashing mechanism but there's also an incentive so the way that uh to to post the correct data so the way that we've structured that is like truly like a you know a reaking application um there is some kind of reward when there's correct operation and there's some kind of disincentive when there isn't but I think like one of the interesting things about this is you know this isn't a fully arbitrary separate process right that is completely separate from chain operation where validators are just you know randomly posting data to the network it's fundamentally tied into consensus itself and so what I mean by that is we use ABCI Plus+ and we use a bunch of onchain verification logic to make sure we're guaranteeing that those validators

are provably posting data into the network and that in a way that we can tell and not we as skip but just we the network can tell and that can be you know provably or verifiably tied to incentives disincentives there's no sort of like arbitrary best effort mechanism that's at play here it's fully codified within the actual operation of the chain okay well let's get in we'll get into the the technical aspects here of the architecture of Slinky and and how this actually works but first I'd like to ask you like what are what are the use cases for this I mean obviously like I think Oracle um price data is is an an obvious one and like the Lavana attack I think um is a good example of you know how

this uh how this the slinky could could uh could improve um the security of of chains particularly those that have to provide price feed data but what are some other use cases that um are being you researched and studied within scap and perhaps with them your partners yeah sure so I mean we want to do one thing right first which is posting prices we had a thesis sort of spanning back to a year ago and we first saw the migration of dydx to its V4 on Cosmos that the cosmos SDK would become like this Premier place to sort of deploy specifically perpetuals protocols reason for that is there's a lot of benefit for perpetuals protocols

to deploy on their own chain to have their own L1 and their own validator set um often times they have needs for sort of certain block speed and certain kind of consensus mechanisms that can't be met by the existing infrastructures outside of Cosmos and uh they need to sort of like really be able to control their own Oracle in a way that just wasn't feasible on something like ethereum right and they needed to sort of have very fresh price updates because that's how they competed with other perpetuals protocols so the first use case of Slinky as as is obvious is like really nailed down this self-owned extremely fast what we call like Rolls-Royce of oracles like essentially the best fastest most secure your um

freshest Oracle uh fresh I mean like fresh price updates uh for every you know perpetuals protocol that would want to move to Cosmos in the future uh we sort of see the the the slinky platform as you know generally something that we can build other things onto to make use of the same stake and to add more reaking use cases where validators can do more for their chain for more reward and then also of course more risk so the big one there that we see is IBC reers um right now the IBC relayer ecosystem is uh pretty poorly put together uh basically Rel layers have to operate on shoestring budgets and are not very well paid and often times go down as a result

of that I mean we saw that very recently with the dimension attack we've seen that obviously different cases with osmosis we have this extremely vibrant and popular ecosystem now over IBC and this huge amount of volume that goes through it I think it's roughly $3 billion a month but we don't have the infrastructure to keep up with it yeah the reality is like running an IBC relayer requires two things right it requires sorry it requires essentially uh two nodes on two different chains that have a channel together right and so every relayer has to replicate that infrastructure the reality is all these IBC reers are usually validators themselves you can run sidecar processes on the validators themselves to make this entire process extremely simple and

have IBC reing B built into the chain operation so we don't have to worry about Rel layers more generally and then you can directly incentivize them to do that right so right now like a lot of validators will say hey look I'm relaying trust me uh and because I'm doing that you should delegate to me because you know I'm doing it for charity what if we could actually have that be built in a provable way into the validator where they can like show like look this is how many packets I've relayed in addition to running consensus therefore you know to me like foundations can see that obviously normal delegators can it would be a great way to just sort of like show off all the other things you can do in a very verifiable way as well as sort of like building on top of the existing

Oracle use case so that's all on the road map for Slinky uh price prices first and then after that you know we'll we'll start to experiment with what other things can validators do for these chains I mean I I could also see this being utilized for um for in ility right where you could have let's say for example a contract on ethereum tokens get locked in that contract validators are observing that contract and then initiating some uh some other action on another chain like unlocking tokens in a contract on on a on a cosmos chain for example and like the other way around I mean essentially this can be used in use cases that go far beyond you know like

Oracle price feed data and and these sort of like you know use cases that are serving the application internally but sort of like look outwardly to other chains as well correct yeah I think so um so you're just to clarify you're saying basically you could use it to perhaps like achieve some kind of maybe more Atomic or synchronous interoperability where you can like lock or have outof band commitments to lock things on one chain and perhaps like unlock them on the other or somehow coordinate them together yeah yeah I mean I haven't thought about that super deeply uh but like one thing that's kind of crazy that you can do in the future with Slinky is this idea of like trust

boost or like this like Mega Cosmos chain right which we're not planning on building just as an FYI but it's like a fun idea to think about basically what you could have is in the sidecar validators could run an additional consensus client right and all the validators of let's say you know Neutron and then all the validators of you know you know uh Juno bar chain Etc could essentially vote to like as part of a consensus client for this like Mega chain that spans them all and basically that Mega chain would have the security of all of the Securities of the other chains combined it would be a very slow chain because it would have to be essentially like the lower bound or the upper bound of like the additive block

times of all of the you know child chains but it would be extremely secure and be able to coordinate across the validator sets for all of them I don't exactly know what you would be able to do on such a chain uh at least right now I mean I think you could do things like cross-chain slashing conditions or some kind of like super aggregated you know source of Truth for something so for example you could host like a chain registry on there um but it would have like the these tremendous security properties and be able to achieve something like you know 12 to 15 billion doll of security which would be far beyond almost all other chance that's interesting interesting yeah you could definitely pump a narrative around that that's uh that's cool I mean there

there's there's lots of great thought experiments I think about um how this can be used so it's uh it's it's really fascinating let's let's talk about the architecture and I'll I'll refer my listeners to um check out the link in the show notes to the article that um I believe one of your colleagues Marco posted to on our research team right to um to the skip uh Research Forum it goes in depth here with all the math and uh uh on how this works and also gives a detailed explanation um of the Lavana attack and how uh skip could have prevented uh this attack had it existed and been implemented um but yeah

let's at a high level uh explore you the architecture and essentially how validators are coordinating on like a single source of Truth so there's definitely some technical context here which maybe I'll try to do my best job of you know uh giving a high level of but essentially Slinky relies on two main Innovations in the cosmos SDK which I think I've talked about in the past and you know hopefully I've helped shed some light on this the first one is ABCI Plus+ and the second one is vote extensions so ABCI Plus+ is basically a new way of constructing blocks right so it used to be basically the

proposer right one of the validators selected at random says Hey other validators this is my block and then everyone else says okay like fine looks good they basically check very basic things like okay is it like completely incorrect like did you execute the state transitions correctly are you under the max gas limit things like that right nothing more fancy that changes a lot with ABC ++ basically there's a much more interactive process between validators and the proposer to verify that the block is correct and so this was important to leverage these steps for Slinky where we need to essentially verify that Oracle operation is correct so in this case uh the proposer will gather a bunch of data from the other

validators via this thing called vote extensions use that to formulate a final set of prices for the chain and then that final set will be validated Again by all the other validators so essentially when validators are voting to accept a new block they're also voting that they agree with the new set of Oracle prices so that's how you have the two3 security on consensus and also the two3 security on the correct Oracle operation just to go a little bit deeper into vote extensions so the way that that works is when validators vote on a block right which is essentially their vote to say yes or no they attach additional data that is all also signed with their vote so they're Atomic right

you can't accept the vote without the data and you can't accept the data without the vote they're just one piece so if you want to move the network forward you have to gather 2third of those votes which means you have to gather two-thirds of those vote extensions and inside those vote extensions are Slinky prices right so like you sort of tie the two together in this Atomic way where a chain won't move forward unless Slinky is working right and that's just the way that it is and so that's why it's like this in protocol or census based Oracle this whole model is like completely different from all other oracles today so almost every other Oracle today essentially operates as a separate outof band external system right so you know here's osis and here's

Lana inside of it over here is pith right it's a pith net is a salana based chain that does not have any relationship to osmosis except that there's some party that is in charge of trans transmitting those prices between them right but those prices aren't baked into consensus by osmosis they're not a necessary predicate to actually run consensus so they may come or they may not come in the case of the Lavon attack they didn't come right and so that sort of is what what gets into the attack there basically what happened was the me poool on osmosis was so congested purposefully it was a Spam attack to prevent this update which is in the form

of a trans action from actually getting committed on the chain and so basically what the attacker was able to do was like I know what this Oracle update's going to be but I'm not going to let it happen on osmosis I'm just going to hold it in my you know purse for a second and I'm going to take out all of these long positions and essentially increase my position more and more and more and then finally I'll let the Oracle update hit but I already know what it's going to be so like I have a deterministically profitable strategy to sort of like front run that Oracle up update and that's how they made all the money and they did that a bunch of times over the course of 13 days in December so because they were able to control when Oracle updates hit the chain effectively they

were able to drain Lavana deterministically and destroy all the other Traders because they had knowledge that nobody else did about when these Oracle updates are going to hit the chain Slinky operates completely differently right like there's no decision of when the Oracle updates hits the chain it's coded in consensus that if you have a new block you definitely have the Oracle update at the top of that block there's no way around it it's a consensus rule so in that situation the attacker has no ability to modify anything like all the Traders can know every single block there's guaranteed going to be a price update at the top of the block okay interesting so when when you say that um the validators are

putting their stake behind the the so so in vote extensions we WE Post additional data in the block and the stake of the validator is also um uh essentially like slash for this data but so I think there's a couple things that here that bear is um getting into is one is how do we achieve consensus around the price right so what is the mechanism or the sort of formula that uh allows outliers to be uh removed moved from the final price and you know from the perspective of slashing is is there additional slashing than what is currently implemented in Cosmos uh

comment bft or is it just the sort of standard slashing that we know um because you know from what it seems like here is that there's because we're we because we're talking about pricing data There's an opportunity for validators to potentially maliciously try to um manipulate the price and if the slashing conditions are not sufficient like that you know depending on the trade or the attack that it might be um more profitable to do the attack than to be slashed so um yeah sorry that's a lot of questions but I think they're sort of all tied into each other sure uh so yeah two questions in there the first one I heard was you know how do we aggregate

these prices right so you know let's say you have a a network with a 100 different validators they all post different prices and they're like this is what I saw from my set of providers that I was using right how do you get to the final price that's posted on you um so there's two aggregation steps the first one is on a per validator basis right so a valid like one validator itself when trying to get the price of let's say ethereum in terms of USD will query over 20 different providers to try to get that so they'll first they'll query uh coinbase then like coin Geto Point Market Cap Mexi gate binance and and a bunch Unis Swap and a bunch of others and then they will take the

median across those that is provider weighted which means the network has the ability to weight certain providers a little bit larger than others right so for example maybe binance is weighted heavier than gate which is generally a much lower liquidity exchange than binance so then they take the medi the the pr provider weighted median across those and then they submit that to the network their own individual validator price then the network looks at all of the validator prices that were aggregated that way and then they take this stake weighted median across all of them so uh this has like a bunch of sort of intricate security properties white stake weed versus regular weighted um but basically like we'll we'll line them

up such that 50% of stake is on one side of the price and 50% of stake is on the other side of the price and then we take that median and then that's the final value that is potentially going to be encoded on the network but then there's one final check which is once that final value is selected then 2third of the validators have to once again say okay I like the price and then it's finally encoded so many different steps of aggregation to get the price that eventually lands on chain but all of them have very subtle uh you know uh security properties that are approvable and you know that that you can read more about in in the article that we posted about

Lana um a research team had a lot of fun with that obviously and we think it's like sort of an extremely secure system that exactly replicates the security properties of the chain itself so to go more into that and the the slashing conditions around it and also the incentive conditions around it um we have two things that we're trying to avoid right or Slinky is trying to essentially battle against two things happening the first one is validators is not running prices right so validators you know not contributing their prices to the network but also still trying to sign blocks this is considered to be like a bad event for Slinky because it reduces the overall security of the system and then the second one which is

worse in our opinion is and also for the Oracle Network more generally is if a validator posts an incorrect price right so a price that's completely out of line or malicious or otherwise you know not the correct price according to the network so we have slashing mechanisms that address both the first one we consider to be like an SLA essentially so validators are on the hook for providing prices for a certain percentage of blocks right um so basically the way that that works is you know over a 100 blocks let's say the SLA is 80% then the validator is every validator is expected to post a update 80% of the time or 80 Blocks out of every 100 and every block

that they miss that rolling window SLA they slashed a small amount that is decided by the network so and that's proportional to Stak so basically like we check every 100 blocks as we sort of Move Along blocks and we see like okay over those 100 blocks did the validator meet the SLA or did they not and if they didn't there's like a small tiny slash it's very insignificant but it scales which means as you as you progressively miss that and as your SL gets lower and lower this slash increases linearly the second method or the second slashy mechanism is a lot more serious which is if you post an incorrect price so we don't actually slash when one validator posts an incorrect price the slashing

takes place when there's enough validators to report an incorrect price such that the network overall attempts to publish an incorrect price for this kind of you know situation which we consider to be sort of a doomsday situation uh we have something called the town CER model which which is very similar to it's it's completely based off of chain Link's Town CER system which is how they do their slashing in that situation basically you know the network records this price some permissionless actor on the network says okay that's wrong like that's just not what the price is in reality and so they raise an alert to a higher level Network that basically says guys the whole

network reported an incorrect price and you know I'm willing to put money behind that like the alerter kit some bond to sort of like make this claim and then if the concluder network which is like a trusted set of actors often times a multisig or like a certain set of validators that is trusted concludes that that was an in that was a correct alert then all the validators that participated in that incorrect price are slashed and all the validators that were honest and the alerter himself or herself will be rewarded with that slash and that's a much more um that's a that's a much larger slash first of all usually it's obviously all configured by the network but it's it's also a much more serious

situation okay so just to recap that last part because I think this is um perhaps the more complex and and also very interesting aspect of this so we have an offchain actor that can watch the network and alert on um a significant portion of the validators reporting a bad price now that alerter um that this town crier uh would uh alert a higher order Network so some trusted right like some trusted group of participants so it could be like the foundation multisig for example it could be a group of validators it could be

like some core developers if that turns out to be the case ultimately the decision rests upon this trusted group or could be like single party but this this higher level override if you will uh to essentially slash the validators that were not reporting on accurate pricing that's exactly right yeah you got it okay um yeah doesn't that introduced some form of vulnerability here where you know they're I mean you know assuming that you know we trust this this higher level actor um I mean there is a risk of compromise here is isn't there yeah there's always a risk

of compromise um so first of all this system has never been used on chain link right meaning it it's an it's developed and it is actually functional and ready to be used but it's never actually got gotten to the point where like an alert has been issued accepted and then everyone's been slashed so it's really sort of to to prevent these like Doomsday situations it's like the final kill switch so it's not something that's like regularly going to happen um or if it does then nulear he a bad system exactly it's a nuclear option that's how we see it and so nuclear options as we know are not designed to be used but they're designed to disincentivize because if they are used then the outcome for the people who were involved

in triggering it is devastating right um so in this case like you know all the validators that this would only really be the case if like validators were coordinated and malicious those validators would be punished heavily it is possible that of course the you know tertiary Network can be compromised but we're generally not involved obviously in sort of the creation of that tertiary Network it could be a completely separate chain right so you could have a chain that acts as this tertiary Network perhaps you designate you know the cosmos Hub itself to be the tertiary Network or you designate osmosis or you designate you know an igen layer ABS to be this tertiary Network it can be any signer set that you trust and that perhaps has higher security or higher

honesty or at least not like aligned incentives with your own some credible neutrality is I mean you want to sort tend towards credible neutrality with this this this network exactly yeah and so you know they're generally going to not be involved in the network but then in the off situation they receive an alert they will sort of like do their best effort evaluation of what the real price was at that time using the expected providers and the expected pairs that that network was using to judge like okay was this really maliciousness right and uh you know they would be free to sort of issue that decree okay so the trust assumptions by and large are we trust the network of validators that are securing the chain

to provide accurate price feed data um should those should validators uh either collude or be in a situation where they're providing bad data uh we fall back on some tertiary network uh that will end up like splitting and making the decision um yeah maybe that could be a usage actually now that I think about it for Mega chain that I was referring to ear yeah there you go I mean there there's the mega chain use case you know the mega chain has the final final word on everything I want to I want to maybe switch gears a little bit here so we talked about how the Lana attack happened and how the attacker was able

to manip manipulate the Chain by withholding essentially the price um on the Chain what other kinds of vulnerabilities does Slinky protect against you know other forms of attacks on you know Defi and perpetuals markets generally sure I mean the the the ways that oracles fail um are usually pretty predictable so the first one is they don't have good sets of primary data right so the the places by which from which they pull in prices are unreliable uh in the case of failure and in the

case of like a catastrophic event like the FTX collapse too many of those providers go down such that Network starts to report incorrect prices on chain right so this is one place where chain link has shown right over the years basically they have this extremely high quality set of providers and they have enough diversity in their node operators such that even when a lot of other oracles will fail given their price data they stay live uh and they still report in corrupt prices this has not always been the case I mean there have been failures of chain link but generally the reputation with chain link and I think it's well deserved is that they have very excellent data collection so this is one you know area where if

you get that wrong nothing else really matters so I mean we we've done obviously our best effort to you know find the highest quality data providers that we can unlike other oracles we've implemented all those connections over websocket which means we're able to pull a vast uh a vastly higher amount of prices on a much more frequent Cadence under with a more reliable connection than the apis which are more generally used which was additional work of course at over site and then also we have the ability for to support any provider that a chain wishes so for example if a chain is uncomfortable with the security assumptions around using let's say B in coinbase they can use either their own apis or they can Implement you know

their own adapters if they wish as like fallbacks for all those different ones that we normally Implement so it's very configurable right we have this huge menu option to select from but then you can order things on the side right but validators generally I mean validators that are providing price feed data they're setting up their own infrastructure to get that price feed data right I mean like validators are not relying in upon like skips software or infrastructure to plug into I mean I guess what I'm I'm trying to say his right like we want to have validators uh independently choosing their price feeds um so that we have the most diverse price feed uh set possible

and not having say like one company or like a software sort of um uh dictating which prices or or strongly suggesting by convention which prices they should be pulling from right like yeah no I I totally agree with that um so we do provide the sidecar software right otherwise like I don't think this would happen right like validators figuring out how to build a system to query and aggregate all of these different mechanisms would be probably too high for for 99% of them and so we do build this super sidecar software that basically is modular to the degree that you can plug in what providers you want to use and that is decidable and fully

configurable at a validator by on a validator by validator basis right so we have like I said before like this menu that they can choose from and the chain might suggest like hey we we at least want you guys to run binance or these other places just so that you know uh we can have like some level of quality here but then there's complete optionality for the validators to add whatever feeds they want right and the chain can sort of ask like hey I want you guys to run this set I want you guys to run this set and I want you guys to run this other set just so that there is some diversity in the network so the chain can decide and the chain can have some level of oversight over which because like like one one example would be most validators are getting prices from coinbase coin

Gecko and and binance that probably would not be desirable then uh but but it's it would be best practice for the chain to impose on the validators which price feed uh they should be reporting from in order to have a more diverse set right yeah I mean you can't impose necessarily like I mean you can strongly suggest is to use your word from earlier um and you you can recommend that validators do this and you can make it easy for them right because usually validators have no disincentive to do the right thing especially when you make it very simple for them to do so so you say like hey just you should use this config basically it runs no provider a b and c and then you give to someone else

something that runs D and F right so that generally we believe in like making things easy for validators and then you know usually they'll try their they'll do their best effort to do the right thing um I think more often what what happens when you you know get basically like try to force validators to this position where they're making a lot of independent chain specific choices that require a lot of thought and oversight is they have a tough time keeping up with it so this is what we've seen with like the kajira Oracle which I think has had over $300,000 slashed uh from Oracle operation mishaps where basically vowers didn't feel like they could keep up with the amount of currency pairs that were

being added and they didn't have the required amount of support for their side car um and so we want to avoid that from happening while also giving validators the Independence that they have to sort of choose different providers and then be able to sort of like you know uh Market themselves on that platform being like hey I run these really great providers that are in addition to the ones already suggested by the network you know I should be rewarded for that or I should get more delegation for that and that goes back to the normal sort of social delegation system and reputation system that we have in Cosmos and I assume foundations will acknowledge that for example just quickly on that like you know uh to shout out one validator specific Rhino stake he's been Eric's been a uh a chain link operator for many years right and

so he has all of these incredible subscriptions to these like very high-powered and very excellent uh provider uh provider subscriptions and so he wants to incorporate those in his nodes when he's running Slinky uh and hopefully be able to sort of like sell that to network and say like I'm providing even better prices than what you're asking me to do okay interesting and how much can chains save by implementing their own built-in Oracle I mean of course validators should be remunerated to do this work right so like does does does it work out in the Chain's favor uh to use their own Oracle even if they have to pay their validators to do that versus using pith or chain link or some

other Oracle yeah so to give my best understanding of what these other places charge um piff I believe is something like $500,000 in Native tokens for an integration uh that's paid by the chain or Foundation or some kind of token holder and then you have to pay in for in both pith and chain link on a per update basis right so the last I chatted to Mars they said that they were paying $1,000 a day from their own protocol funds to sort of get these updates across all their different deployments obviously a lot of money and chains who want CH link have to

implement or have to pay a lot more from what I understand usually that price is closer to $2 to3 million and then you also have to pay in link per update right so it's sort of like this massive upfront charge plus sort of like a lot of additional charges and tokens that don't even correlate to your own chain yeah so one of the nice things about having an in protocol Oracle is there's no other token involved right there's no token Network that is not aligned with your own that you're trying to enrich or on the line for enriching so all the Oracle operations is essentially funded by your own security which you're already paying for with inflation the structure that we are suggesting to change for compensating Slinky both the skip team and then also

the validators that run it is some kind of share of the security that is run on top of Slinky so that it scales proportionately with the amount of danger and the amount of operational excellence required to run Slinky on that chain so this could look basically be in in various forms uh it could be a percentage of inflation so maybe you sort of earmark 1% of inflation that sort of goes some kind of split between skip uh and its operations team and the validators that are running Slinky itself or could be a percentage of trading fees right so for example as trading fees grow uh Slinky becomes more and more important it has many more currency pairs it becomes a bigger

operation on that chain and so the percentage of trading fees would obviously also grow and so you could split that between the the two parties involved as well um I think that's much more preferred than sort of this like massive multi-million dollar upfront cost one because it's easier on chains right they're they're sort of like okay like we can start this and also it has like a growth narrative where it's like okay you know there's a bet that the validators and Skip are taking on the Chain um and of course like if that bet turns out to be correct they're going to be rewarded right and if it turns out to be incorrect then there's no reward we like that model in general in terms of how we do business overall cool so how does this so far we've talked about chains that have

valid assets I.E app chains how does this fit in the modular stack and the modular narrative and how would rollups or roll apps um leveraging some other form of rented security be able to leverage this tech for their own applications so it's like a very complicated question um like that's when we're talking about sort of like all the different architectures that are on Celestia um I guess like one architecture talk about is based rollups right where basically the data is being posted directly to Celestia in the order that transaction should should be sequenced the other model talk about are like let's say

Dimension rollups where there's some kind of settlement layer that sits in between you know the rollup and Celestia that manages a lot of things for them like IBC relaying and settlement Etc how Slinky would operate on and and the final model that I think is worth discussing is are the shared sequencers right so like Astria for example I think Slinky would operate a little bit differently on all of these so in the case of a based rollup right where it's basically like there's there's not Dimension there's not you know asria there's just sort of like this Standalone roll up that is deployed on top of Celestia you need some kind of um operator of Slinky that you trust in that situation the ideal situation is it's is run by the Celestia validator set itself then you have the gold

standard of like a secure Oracle operation That Could That Could power all of these different rollups um in absence of that you need to sort of set up your own outof band validator set or operator that you trust so it could either be run on a centralized sequencer so for example roll kit right now only supports centralized sequencers and so you're trusting that sequencer to sequence your transactions but you could also trust that sequencer to execute Oracle updates and run this l side car the more uh decentralized approach to that is to have like a validator set that you trust or a set of node operators that you trust with some kind of stake maybe it's POA maybe it's POS that will run Slinky just for your chain and sort of have some kind of uh

verified connection between them such that it would your rollup would receive those updates and then in your SE onchain sequencing rules you guarantee that that those updates are are being included so if this tertiary Network goes down or this you know trusted Network goes down that's providing your price updates your rollup doesn't actually commit blocks and that's how you get does that make economic sense though because like if you're maybe I guess it all depends on the application and the business model but like if you're a rollup um you know let's assume there's like thousands of rollups many of those rollups are probably like you know not meant to have their own Valor set for economic reasons because like running your own Val set cost um is expensive now if they're choosing the rollup route or the roll up rout um you

know as as a as a cost- effective way to run chain and now we're asking them to have their own validator Set uh for for the price updates I mean wouldn't they just you know also use that validor set to become a sovereign chain um sort of negating the entire idea of becoming a rollup I mean sort of like a circular thing right yeah it doesn't make sense that's the point um okay so yeah so so basically like that would be the design right the only way that this design might make sense is if that validator set that's like actually posting the prices is shared among thousands of rollups such that all of them are looking at it for sort of Oracle prices and it scales

linearly with the number of rollups right sorry it scales you know less than linearly with with the number of rollups that's the only place where like sort of a based version of Slinky uh really makes sense where I think it makes a lot more sense oh sorry yeah no no but I mean what what I think might end up happening is that you know Slinky may end up like there there may end up being like a slinky chain and even though the validators of this chain are not you know intrinsically aligned with the chains that are going to be using that data um the fact that we can use uh Slinky price updates or have Slinky price

updates over IBC which is itself like a trust minimized uh bridging protocol and sort of is embedded within Cosmos might be like a middle ground to providing um a scalable way to provide price updates for lots of chains because like think about it if you have say a validator like uh like course one uh shout out to course one that is providing that is validating many chains and they're provide they're running slink key on lots of different chains and providing essentially the same pricing data across those chains like the price of Bitcoin or the price of ether whatever then wouldn't they have then an an incentive to just um get

together with other validators that are doing the same thing and form a network uh that can be sort of generalized for the entire you know Cosmos SDK IC ecosystem it's a great question and one that we've chatted about a lot internally I think there's a couple things here which is when you build Slinky as a chain and then you use IBC to do the uh Oracle updates for a bunch of other chains you've essentially replicated piff right because then you have sort of a similar model whereby the IBC updates are in the form of transactions on the chain that you're trying to update and so now you have a lot of this the same you know attack

vectors that something like pith and something like chain link has right yeah and the the only way to avoid those is when it's built into your validator set so when we say like we're building Slinky to be the Rolls-Royce of oracles there's some major trade-offs to building a Rolls-Royce it's very expensive right meaning uh it requires something that's very expensive for us meaning it requires a very custom integration to that Chains validator set and it is you know requires a lot of operation and high performance so we can't rep replicate this model for 100 chains which is why we're being very selective about our first set of Partners and we're likely to only support those set of partners for the first year of operation because you know

you can't make a lot of rolls-royces you just can't scale that operation because you know the leather is too expensive and stuff like that um and we're okay with that like we want there to be this we want this Oracle to exist for the top you know best chains that we want to develop relationships with or at least extend our current relationships with as soon as you get into the the world of okay how do we scale this to like th chains or 10,000 chains or 10,000 rollups you have to start to make compromises right so the the the the idea that you had is a great one right basically you could run this as sort of its own Sovereign chain maybe with a collection of validators Set uh validators from all the other chains so it's some kind of Quorum of uh stake that you already trust and then maybe

you could have cross chain slashing conditions across all of these different chains which means if you run prices on Slinky not only is your your sinky Slinky stake uh at you know risk of being slashed but also your stake on the networks where those prices are going right so now you're going back to sort of this like mesh secured reaking system which actually would have very good security properties and would be a meaningful differentiator from something like pith right so for example if you knew that pith had chorus one and pth had pachu and all your favorite validators and you knew that they could be slashed if they posted the incorrect price to your chain you probably trust it more but the fact that it's a bunch

of Salon validators that you don't know and that you know are servicing thousands of other networks at the same time and won't really be have any punishment if they post an incorrect price uh like at least a like something that you a punishment that you can influence you don't really trust it as much as like let's say something that sure of shares your same security assumptions um when scaling to a bunch of roll offs sort of I mentioned this sort of like based idea where you could have a chain that you know has IBC that connects to all of these I think the better opportunity there is actually to integrate with these settlement hubs or these shared sequencers that already have these relationships with the RS built on top of them right so for

example Slinky could easily be built into the existing validator set for demension or the existing validator set for asria and then it could be made natively available for all the rollups that are using those for sequencing for settlement and for you know whatever else they need and so there there you have a much tighter connection and you already have a platform for which to deploy thinking it's Rolls-Royce model okay no I mean this is this is all very interesting and I'm I'm very curious to see how things will will play out here you know when uh Jonathan was on the podcast a couple weeks ago from Lana to of recap you know the whole attack and everything you we we we talked about

this very thing we we we did explore the idea of having like an onchain oracle to prevent the you know the attack that um resulted in one over a million dollars in in value being extracted and his response was I'm paraphrasing here but the the response was essentially um that uh at least for them it probably wasn't viable because it wouldn't scale like if Lana which stands for leverage any asset really wants to have any asset and be a permissionless place where people can launch new perpetuals markets and potentially you have price feeds for just anything you know for the price of rice or you know the price of some option in some you know obscure Market

um that it would be too much of a burden and and a technical lift on validat to provide all that price feed data so when when it comes to scaling when you get to that sort of size and also Lana doesn't have its own value it relies on ether on on osmosis as a as an application on osmosis you know it's sort of limited here because it one has to rely on an underlying Network and two probably you know has in its Vision at least too many uh too many assets for this to scale so you know is there a type of customer that just isn't well suited for this or does does the slinky effectively you know scale to thousands of assets if if necessary so yeah a couple things on

this um the first thing is like maybe to just back up and understand like the the context in which we built sink in like what was the moment at skip where we were like this is what we want to build and this is why we want to build it the original inspiration was dydx so we saw this you know very exciting um awesome team come to uh Cosmos and their stated goal or one of their stated goals in launching their V4 was to launch permissionless markets right and to have I think Anton's posted 500 markets by the end end of the year or at least over some time frame but eventually to a th000 2,000 10,000 100,000 markets right most Perpetual I think the the the highest

number of Perpetual protocol uh of markets on a Perpetual protocol that I've seen has been roughly around the order of 100 so these are all crazy numbers to even think about um sinki was built with that in mind because we we wanted to support that use case and we thought it was exciting right what does it look like to have an oracle secured by your chain not only by the stake but also by the governance set which means the governance set can actually vote in new price Pairs and have them added instantly right and so that's how Slinky operates basically governance or you know there's a permissionless process to add any asset to Slinky and Slinky can itself like under very extensive low test that we've already made and can publish uh can scale to about 2,000

currency pairs right now that required a lot of optimization the layer of comet EFT it also required a tremendous amount of optimization on the layer of Slinky itself and how the data gets encoded into vote extensions and uh you know we had I would say a relatively large hand in helping get vote extensions out the door by doing a lot of bug fixing and a lot of testing uh to make sure that it could support this so for any chain that you know wants to scale to 2,000 or any protocol that wants to scale the 2,000 currency pairs Slinky can do it it's it it can't like it just literally can do it and also those currency pairs can be added same day and what I mean by that is there's you know various different

processes that the chain can implement it could either be governance which is obviously not same day or it could be sort of a more like admin based account or it could be another model that we have that we're sort of chatting about uh DX with which is more called The Oracle of oracles that can allow sort of a set of permissioned actors uh be in charge of sort of like constantly adding these assets with user input nine times out of 10 or actually more like 99% of the time they can just instantly be added to the validators without any configuration changes because they can just be pulled from an existing set of providers that the validator has or some kind of subset of them sometimes you might need a completely new provider right so if you want to pull in the price of or let's

say you want to pull in like sports betting data from your own little private application that you're running uh you will need to sort of like Implement a new provider to actually do that on the validators in which case like price addition takes more like a week these are in comparison to sort of like you know existing oracles which take multiple months and are sort of coordinated with a fully outof band set and shared among a bunch of other stakeholders that you don't control or that don't have any interest in Sharing incentives with you to coordinate like these very long processes of adding currency pairs that can take on the order of months or years right so the whole process is a lot faster that is all to say you know Slinky was was built to support permissionless markets from Day Zero um and so we've done a ton of

work to make that possible very cool um listen I want to thank you for coming on today it's been fascinating chatting once again uh and discovering all the really cool stuff that Skip's is doing and um yeah I'm sure you'll be back on in six months to give us an update on something new that that skips built but until then um yeah working people uh learn more about this and you know perhaps uh also integrate it within their own chains and applications to learn more about Skip you can visit our Twitter page or our website so our Twitter page is Skip protocol all together twopiece and uh the uh website is skip. money um also

you feel free to contact me personally I'm Magmar 100 on Telegram and then also my Twitter handle is Ox Magmar like the Pokemon and uh yeah look forward to chatting or learning helping a little more thank you