This is Epicentre episode 538 with guest Jasper de Hoyer. Welcome to Epicentre, the show which talks about the technologies, projects and people driving decentralisation and the blockchain revolution. I'm Brian Crane and today I'm speaking with Jasper de Hoyer. He's the CTO and Co Founder of SATA Protocol. And SATA is a sort of universal Oracle protocol. So looking forward to getting into that. Before we start talking with Jasper, I just would like to briefly tell you about our
sponsors this week. This episode is brought to you by Gnosis. Gnosis builds decentralized infrastructure for the Ethereum ecosystem with a rich history dating back to 2015 and products like Safe Cow Swap or Gnosis Chain, Gnosis combines Needs Driven development with deep technical expertise. This year marks the launch of Gnosis Pay, the world's first decentralized payment network. With a Gnosis card you can spend self custody crypto at any Visa accepting merchant around the world.
If you're an individual looking to live more on chain or a business looking to white label the stack, visit gnosispay.com. There are lots of ways you can join the Gnosis journey. Drop in the Gnosis Dow Governance form, become a Gnosis validator with a single GNO token and low cost hardware, or deploy your product on the EVM compatible and highly
decentralized Gnosis chain. Get started today at Gnosis dot IO. First One is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Ethereum, Cosmos, Celestia and Dydx. More than 100,000 delegators stake with Chorus One including institutions like Bit, Go and Ledger. Sticking with Chorus 1 not only gets you the highest years, but also the most robust security practices and infrastructure that are usually exclusive for institutions.
You can stake directly to Chorus One's public note from your wallet, set up a white label note, or use the recently launched product Opus to stake up to 8000 ETH in a single transaction. You can even offer high yield staking to your own customers using their API. Your assets always remain in your custody so you can have complete Peace of Mind. Start staking today at Chorus .1. All right. Cool. Thanks so much for coming on Jasper. It's great.
It's great to to have you here. Thank you for having me, Brian. Super excited to be here. Yeah, like, tell us maybe first of all, how did you get into crypto and how did that sort of how did that road lead you to say them? It's a fun story. So I think I bought my first crypto just purely as a speculator.
Some in like my first first year of college, I think in 2016 or second year and I ended up dropping out of college to start this company that was doing data analytics on mostly Facebook data and me and two friends did it. We ended up getting Aqua hired, but we got increasingly frustrated with the way Facebook managed API access.
So instead of being able to like innovate on the product that we were building, we were constantly just like running around with duct like metaphorical duct tape fixing like problems because of them, essentially rug pooling, API access to certain endpoints etcetera. So it was super hard to build a sustainable like business that was able to innovate and instead you were just like fixing the, the, the product that we had. That really sort of stifles innovation from third party developers.
And that's what got me more interested in like the crypto space because I sort of like bought the script. I kept like an eye on the market and then as soon as I the the, the moment I've clicked was sort of like seeing smart contracts as immutable API interfaces. So the idea that you always know that this data will be accessible and you can sort of like as a third party developer have this permissionless composability to build third party applications on existing
infrastructure. The way that empowers developers is what really really sort of like what's the aha moment for me. So I I dove into the space, had a programming background, taught myself Solidity, did some consulting, ended up doing sort of like independent research funded by the Etherium Foundation with a with a few other people. We were researching Plasma which turned into roll ups. So we were trying to build ETH L
twos. That was really cool, learned a lot, surrounded myself with smart people and that was the thing that sort of like kept me in in the beginning because I joined like full time back in late 2017, early 2018, like right before like super brutal bear market. But the sort of like the the level of intellect and like the the people that were in the space was was so like magnetic to me. It was such a it was such a pleasure to work in such a young industry where everybody was
hungry and had a mission. That's really that that that's what's really got me going next to sort of like the initial sort of like interest into into smart contracts ended up meeting my Co founder at a hackathon in 2018. We started building products into space and yeah that's that's that's how I rolled into it. Cool, thanks so much. And then so with SATA protocol, what's what is the vision for
SATA? So how I describe set up is sort of like as a as a as a layer for data that should be accessible to any developer, right. So if you look at sort of like the infrastructure cycle across crypto starting from the beginning is you have Bitcoin as sort of like this application specific L1, right. It just does accounting value transfer, that's essentially what it does.
And then Ethereum popping up and allowing developers to build sort of like arbitrary business logic in the form of smart contracts that then have this composability and people built like a suite of different products on. And when Ethereum was launching, like nobody knew what the use cases would be that actually got get traction. That's sort of like the beauty of it. The beauty of it was that anybody could come in to deploy a smart contract and then any other person could interact with
it, right? And I think that that sort of like permission less creation and permission less access is what created this giant network effect of what became crypto. And we're not seeing that with a lot of the infrastructure today. So a lot of the infrastructure providers that are very necessary, such as data infrastructure like Oracle's for example, or bridges, they still act as sort of like king makers
and gatekeepers, right? Like you have these start-ups or or larger companies that essentially you need to prove to them that you're worthy of deploying to your chain or like allowing access to like a new feed or allowing allowing you to access their data from from a new environment. And it's all has to do with sort of like technological trade-offs that were made and that were necessary at the time because a lot of these projects were built when there was only one chain.
And with Sarah, the goal is truly to build like this entry point to real world data or data outside of a blockchain's own execution environment that can be accessed from any L1 or L2 and where you can essentially spin up your own data feeds, right. So you can deploy a program on the set of network that essentially dictates what data should be queried, where and how it should be computed.
That then gets stored on the set of network and from there it's accessible or verifiable from any smart contract on any L1L2 or or sort of like crypto network. OK, OK, cool. So you said first of all like the the data like you want to have off chain data or or data that's at least outside of this particular chain or this particular context you want to have that accessible. And of course the reason is sort of right or even today right.
A lot of things rely on let's say chain link right, for maybe writing price feet onto onto the chain, right. That like maybe OK what is the USD to ether price or something like that, right. So, and of course, there's a lot of like, yeah, other applications, right. They say like or like, what do you feel like are some of the applications that like you're most excited about that you think would get enabled by having that capability?
Yeah, I think that there's a a a few things to touch on here. I think the first thing and you sort of touched on this is it's it's not just price feeds. I think that when people hear the term Oracle, they sort of immediately think of price feeds as the use case. But I would actually argue that there is like the category of Oracle is extremely broad. I like to say that almost everybody's essentially trying to solve the Oracle problem in this space, right?
Like bridging is essentially an Oracle problem solution, right? It's like an application specific Oracle price feeds, an Oracle rebuild assets, it's an Oracle problem solution. I think that you could even argue that unit swap for example is essentially an Oracle where there's a economic incentive to ARP the price to set price exchange prices right And that that way it reflects sort of like off chain data.
The use cases that I get most excited about are still defy just so price feeds but also interoperability, real world assets, the the things that I sort of mentioned and the thing that excites me the most about what we're building sort of like the permissionless aspects of deploying new things. So just like Etherium launched and had no idea what would really stick, we have a better idea of the things that works of
like the low hanging fruit. But the the new things we enable is where for me the real sort of like mystery still lies, right? Like as soon as there's like fully permissionless data access for any L1, I have no idea what people and developers will come
up with. And sort of like this idea of empowering developers is what really is super interesting to me. And then the second thing is as we are seeing the app chain thesis or modularity thesis or whatever you want to call it sort of play out over the last sort of year and a half and I feel like it's going to go exponential in the next year and a half. There is core infrastructure that's necessary to enable a ton of use cases on these new roll ups and app chains, right.
And I think probably the most core is having access to real world data. So I think that the idea of being able to launch an app chain, let's say we launched SATA today, Tomorrow I could launch A roll up and immediately have access to all of set U.S. data which means that I have base interoperability and access to price feeds and developers can just start building or we as an application specific network have access to the data that we that we need.
You know, like I think that is those, those things are the things that get me the most excited about the product that we're building. OK, cool. Well, let's, let's go a little bit into details into how this works. So you mentioned sedan network, so, right. So my understanding is sedan network is a Cosmos SDK chain you're building, right?
And then is sedan network basically the way I understood it, a developer would go on sedan network and then would sort of almost like create a job there and say hey I want like X data on Y chain and maybe set a few parameters or something like that. That is essentially how it works. Big picture if if we dive a bit deeper that's how it works is we have set a chain which is used for settlements and checkpointing right?
So it's like we're slashing happens and staking happens and where data references and like you said, jobs which we call programs are stored. If we go through the flow of set A chain, I can deploy a program on set A chain that essentially is a set of instructions on how data should be queried, from where and how a final outcome should be computed, right? So for a price feed it could be like query ether USD from six exchanges and then give me a median value right?
That that could be some of the instructions that you give it to this program and then the program is deployed almost like a smart contract, so it's stored on the chain. And then if you want that data to be queried, if you want to get that data answered, then what you do is you ping the chain referencing sort of like the contract address or ID of
that program. And then the chain picks verified secret random committee of a second layer which we call the overlay layer, which is a network of NPC notes that get randomly selected to actually perform that computation. So from like a technical perspective, the program is stored as it wasn't binary, this wasn't binary gets executed by the overlay notes in in a wasn't VM. So they all get essentially some sort of uniform outcome that should be close to the same outcome, and then it committed
back to set a chain. On set a chain. What we then do is we batch all of the feeds or all of the jobs together and we merkelize them and have them signed at the end of the block. Maybe we can walk through this like a bit more slowly. So you mentioned, so let's take
this example right. So, so you mentioned like I in A roll up or someone launches like some chain or we yeah roll up or maybe it's like some, let's just say it's some Cosmos as the K chain or something and they want, they want what you mentioned, right. So they want to have the price speed and they want to have yeah the median of the 6th largest centralized crypto exchanges to write like you know just the
same simple simple price speed. So they you deploy this program on set a chain and and then the chain chooses sort of like kind of like a particular set of notes to then perform this job. Exactly. So we do like, yes, so the chain uses VRFS to pick from like a larger pool of validators. Because tender means validator sets have some scaling. Scaling issues, yeah. OK, but is this the people sort of the notes who write this data afterwards? Are these the validators or these are other notes?
Yeah, so these are not the set up chain validators. There can be overlap, but this is like a second set of of notes, yes? So the second set of notes and then some are basically chosen sort of randomly from that set. Yeah, Yep. And it's like a secret random committee. So they don't know which other nodes have been selected either. It's like to prevent collusion. They don't know beforehand though. They they don't even know at the time or.
So they don't know beforehand and they only know after, sort of like the commit stage, right? So then after they commit to the the outcomes, they know which other nodes were were selected. Of course, because the the chain is now this is public. Is it? Is it like a fixed number of nodes are chosen or it depends on the security requirements of
a particular program? Yes, So the program can set like the replication factor, like how many of the overlay nodes they want to have run this feed and it depends on the, it depends on a bunch of things, right? So that way you can sort of like cater data security based on the use case that you use it for us. If it's for something that doesn't have a lot of risk of if it's something basic or or non D5 related like it's OK Maybe If it's like a small set of overlay notes.
If it's something that holds a lot of value, probably want to increase the replication factor. And then as somebody who creates this program because I want this job, I then for example basically fund. I put some money into this program that then pays the the node operators who. Yep, yeah. So when you ping the chain and reference the program in order to have it executed, you provide some gas fees essentially for computation.
Computation gets done. When you say ping the chain, like who pings the chain and how? Yeah, so anybody can ping the chain to say like hey query this price fee, right. So if you have a price fee that you want to have updated at a fixed interval for example, you can ping the chain at that interval.
And we're working on something. We got continuous data requests as well which essentially sets a for the next X amount of time being every, every, every time essentially within the interval or or set the condition when you want the IT to be what wanted to be ping. That's completely permissionless, right? So anybody can do that. Like you can write a program that pings the chain directly. You could fire the event on your destination chain.
So I I launched A roll up. I fire an event there that's then picked up by I don't know some solver relay that sees hey they want this data so we are going to do it for them and bridge it back. There's like a bunch of a bunch of ways this can be done. But yeah. Right, because the ping happens on, say, the chain. Yes. Right, right. And then and then the result is written to the some destination
chain. The result is written to set a chain first, where it's then batched with any other request that's coming in the same block. And at that point you collect the batch which we do in like a a Merkel tree and then like I mentioned we signed a route. So from there as as as soon as the route is signed with a batch of data, you can verify the signature from our validator set, essentially from any smart contract and verify that the chain is a certain state.
So what's cool there also is if one person or a group of people fund an ease the USD price feed that is updated every minute. Any other chain now also has also has access to that to that data because all of the data is stored essentially in this in this manner. OK, and then you need some you need like on the destination chain you need to be able to verify right that signature. So so you need to keep track of like the validator set or. Yeah, yeah.
And that's that's the great thing about Tender Mint is that the validator set is not does not change that much, right. And we have this. We have a pretty pretty finilla chain I'd say I'd say, but there's one extra condition, which is that if you leave the active set, you're still required to at least sign the the routes the the batch routes for another epoch which is still deciding on it's like next 12 hours or something. Oh, so the epochs are relatively short? Yeah, yeah, yeah, yeah.
It's like 12 hours to two days, we're thinking. Yeah. And and then that's the most often that valid is it could change. So that's the, yeah, you would not have to sort of update on each chain destination chain and more differently. Yeah, no. And what's cool is in the in the batches. In the Merkel tree, there's always we reference sort of like the next validator set, so let's so as long as you have some data pushed within that time frame, somebody can look say hey update, set and done.
OK. One thing I'm curious about, I mean, I know there's been some discussion in Cosmos on, you know, if something like BLS signatures where you basically sort of can aggregate a lot of different signatures in a in a single signature like doing something like that. Is that something that would be very useful here because you could reduce the size of this thing? Or does that matter for you guys? Yeah, for sure. We built ABLS signature
implementation. We built, we built a few because not every smart contract chain has access to the same cryptographic hashes or sorry, the the same cryptographic curves. So we we build a few signatures that that can be applied to the batches so that they can be at least verified with subsidized verification functions on most
VMS. Yeah. What what else is important about what are we missing sort of from this process of like the chain, you know goes there this is program now you have to notes are being chosen. They're right on there. Yeah.
I I think the, the one thing we can touch on is sort of like the, the way that data is then transported, transmit, yeah, transported from set a chain to the destination chain because essentially what you have now is like you're essentially collecting data on our network, right. And yes, it's verifiable, but how do you incentivize people to then bridge the data back to the the chain where the data is actually supposed to be consumed?
And for this, it's almost like an intent based network where there could be multiple reasons why somebody would go there and sort of like bridge the data back to the destination chain and that the first one would be if there's any V exposed, right. So we can essentially run a lending network on an on an L1 that we spin up ourselves or or an app chain that we spin up
ourselves. You set as a data source, and as soon as there's liquidations that's supposed to happen, then solvers can come in and then choose to bridge the data over and perform the liquidations. I'm sorry I'm I didn't totally get this. So OK, I understand right to challenge is that basically now the program is running and they have some price feat and then it now that's written on to say the chain and now the question is I guess how does it get to the
destination chain? Yeah. How do you incentivize somebody to to bridge it over, right. So it's going to either be if we run the lending protocol like we can run our own solver to sort of like bridge this data over and perform the liquidations or you can rely on 3rd party solvers or. Searchers is this solver? Because it sounds kind of like a relay to me. I guess solver is would be in the case if it's like integrated in some, let's say some kind of exchange type thing that relies
on solvers. Exactly. Exactly. So you because it's like permissionlessly queryable, you can just add the ability for solvers to essentially bridge the data or bridge the proof with any action that it would normally do to perform, I don't know, liquidations on perped axis or lending markets. So basically there's like different ways that this can
happen. And I mean I guess one example would be you know I create some application on X chain and I want to say the price feed and I ask the application I I'm just going to run some kind of you know relay and I'm just picking it up and I'm putting it over there and you know I have some external intentive because I want this application to run. I guess that would be 11 model for sure.
Is it also part of the program that I could just say, hey, anyone can do this relaying thing and if they do it, they get paid some fee? Yep, Yep. So that's the bounty idea, right. So you essentially place a bounty on the destination chain that covers gas fees and then some for bridging the data over and that's why you outsource it. And then the final one is like I said, it's like I I just build it as a source for liquidations
for example. And I assume that at some point when a liquidation occurs that exposes Mev. So there's like an incentive for third parties to come in and bridge the data over, right. So it's it's essentially the same thing as a bounty, except like you don't place the bounty, it's just part of your network. When you say liquidations that will be some kind of can, can you walk us through an example?
For this, yeah, of course. So let's say we have a lending protocol and I hold a position of I borrow USDC against ETH or something at at some liquidation ratio. As soon as the price of ETH drops below the liquidation threshold, there's a fee to be made for liquidating that
position, right? So if you can bridge the proof from set out to that chain and prove that ETH was below the liquidation threshold, you now earn that fee without the protocol saying like, hey, it's been X amount of time, so you can claim a bounty essentially, right? So if like other types of incentives to bridge the data over as well, it'd be that that are sort of natural for for certain D5 applications. Right, right. OK so so in this example here. Of course this would only work I
guess if you only need the data. You know if the data is only needed for the liquidation, right? Yeah, yeah. Right. So, so of course then it's only if there's liquidation, only if there's that incentive then someone has can make money. So that's when they're going to and would they then also they would then also potentially pay the to run the to basically on say the chain right, to get the data and and then you take that
and move it over. If the feed has not been updated to reflect the current price that is below the liquidation threshold, then yes, they would have the incentive to also run the one, run the feed, run the program. OK, cool. Yeah, I mean, that's a very, yeah, it's a very power. This field looks like a very
powerful, primitive. One thing I'm curious about, So we we talked about price feeds because it's you know kind of like a known and and and and I'm sure it's probably still going to be or I imagine it's still going to be the largest use case, right. Because in the end like crypto is basically you know people build financial applications, right, and they want to trade and then price feeds are kind of
essential for that. But I guess if you look sort of at other types of Oracle, other types of data maybe also data where there's maybe more of a subjective component. Yeah, I actually say that price is one of the more subjective things that's being pushed on chain today, even actually. Because like there's there's no truth on like what the price of
ETH is right now, right? There's like a ton of algorithms that you could use to get as close to the truth as possible, but it's really hard to figure out what is truly the price of ETH now. So you just sort of like take a bunch and then you you use a bunch of like algorithms essentially to try to get to something that is probably close to the truth, as close as possible.
I think that more subjective data such As for example so, so previously and that's that's probably good to touch on as
well. We actually build an optimistic Oracle as well which is more similar to like an UMA or an auger which essentially allows you to ask practically any question to the Oracle and you essentially have humans coordinate or or some machine programs or or humans anybody could essentially coordinate and come to a conclusion of the what the answer to that question is. I think SETA as a primitive as you call it, which I like a lot is not really fit for that type
of data. It's it's more fit for like API data. But yeah, maybe if you could give an example of like the the sort of like more subjective data sources. I mean, I guess you could, you could be like, I don't know who's, you know, who's the best band in France or what's the best band in France or something like that. Yeah, no, I don't think that unless there's an API for that, it probably would do something else. Yeah, yeah.
Right. Yeah, I mean, but what you could do is you could ask an LLM through setup. OK, to answer that question right. So it it I think that is another use case that I forgot to touch on earlier is the fact that because anybody can plug in data to the system, you can query anything from a smart contract. So LLMS for example become also accessible to smart contracts through through set up. But then how would you verify? Because the LLMS are not really deterministic, right?
So like you ask Chachi PT something and I ask you something and then you know, we get different answers and then so yeah, how how would that work? That's a great point. There's two ways. Some of them have deterministic endpoints that have some sort of a seed that you can prove, like, hey, this was actually generated by this LLM. The second one, which might be a little bit less sexy but still works, is that when the data provider plugs into the network, you have them sign the prompts,
right? So let's say ChatGPT is a data provider to SETA. They signed a prompt, so you can verify that that that that the that the prompt at least comes or like the the response at least comes from. Open AI provides out. For example, they provide like signed, signed out. Well, not yet, not yet. But if they would plug into set out, we would ask them to do that. Yeah, Yeah, yeah. Or or like if if I launch a Chachi PT wrapper on top of
SETA, I would sign it, right? So then you don't have proof that it was actually ran by Chachi PT, but at least you have like somebody to point to as like at the station essentially. You have proof he was. It was run by Jasper, who said he was the. Exactly so that it's not it's not. That's not really bulletproof. Depends on. Depends on who hosts the wrapper, I guess. Yeah, and I mean, I get, I'm sure people are going to have, you know, solved this in some
way, right? Where you're going to have some kind of, you know, deterministic, verifiable LLM outputs. Yeah, mid journey I believe has deterministic prompt to image I I I forgot how to do it. It's one of our engineers build a build a prototype using. I believe it was mid journey. I mean we were talking a little bit about sort of the determinist determinism and verifiability. I'm curious are are like 0
knowledge proof? Something like like how how does 0 knowledge proof sort of intersect with SEDA I think. Fully homomorphic encryption could be very interesting for sort of like keeping the data private before it lands on chain. So essentially what you could do is half these overlay nodes that actually do the querying computation, perform the Korean computation through like a fully homomorphic encrypted service or or or data providers.
I I think the ZK thing I'm I'm not 100% sure how we could use it except for for privacy for CK version of what what were at least like it's not on the road map yet but what I mean it's obviously something we think about I don't I don't I don't see much more than that except for like the ability to query ZK Lite clients and prove chain state like in a more elegant way that that that that's something that makes a lot of sense and then SETA can be used as more of a yeah like a data transport
layer which is essentially designed to do. Right. So, So yeah, that's the other topic I wanted to come back to because I think you mentioned earlier breaching right as as a problem. And of course bridging is something where Interpol is something where we've seen you know, a massive amount of
activities and investment. I mean you have like protocol like IBC that has a lot of usage, right, that basically relies on like you know, light lines in each chain that you know, there's a lot of reason cosmos, but including also a whole bunch of teams trying to bring that, you know, like everywhere like things like Polymer Union and other ones. And then of course you have whole other protocols like wormhole, yeah, things like Axler or Layer Zero.
There's like a huge amount of activity there. How does Seder GG Fiang that Seder would be like a viable alternative or competitive to these existing bridging solutions? Yes, I also think that we can be very complementary to a lot of them, right. So we're talking to some of the teams you mentioned about set up being part of their stack. Some of these solutions still require like oracles or like essentially like somebody to a
test data, right. A lot of them are in the end still some sort of multi sig but you try to like make the multi sigs like for example right layer 0 requires still like an Oracle and a relay as they call them which essentially like 2 to a multi SEC in which an Oracle and a relayer have to agree on the state of something being something.
And they they they use still like a lot of like RPC data for so so OK so how it works with set on is because everybody can plug into the network and provide data and anybody can verify set a Oracle state essentially through some sort of like what we build is pretty similar to IBC. It's just got like a like a one way version light version of
IBC. So RPC providers can provide data to SETA like we're talking to a bunch of them and essentially what they do is they open up their API to SETA and then people that provide these people can write programs to query a bunch of RPC providers to verify chain States and then you query multiple for the sake of redundancy, right.
So you can write a program that queries like I don't know like Infira quick notes and Alchemy to verify the state of East to be a certain to to verify, I don't know like with like block hashes or or or or contract state. And then you have that run through setup stored there and then that can be queried from any L1 that then hatched essentially has access to that piece of state from Etherium,
right. So that could be used by these interoperability protocols as like part of their consensus and that's that's something that's that we were talked to with a bunch of them and it's it seems to make sense and I think that the thing that makes sense most is that fact that as soon as it enters our chain, it's verifiable from any other chain. So you get like this super broad distribution mechanism simply just by having the data come into our network.
And it's very interesting for RPC providers too because they get to monitor that data through on chain traction as well, Not just because right now essentially RPC providers just sell their data to people that want to query chain state from, I don't know like a server or something. But I mean that's a, there's a huge demand on chain to query chain state as well. So we're sort of like allowing them to tap into that as well. Yeah. I mean to open sort of an additional market there?
Yep, exactly. Is is RPC also something that say that maybe I just did the we just did the podcast with Lava Network the other week, right? So I know we're talking quite a bit with them and I mean I think the thing that occurs to me that actually there's a lot of similarity here, right, where you know they also basically I'd have some kind of on chain contract thing, right. That then, you know, requires a bunch of people that they can write, run, basically RPC notes.
Although I guess in their case not the results wouldn't be written like on chain, right? It it stays off chain, right. So yeah. But all they need to do is plug their one of their RPC gateways or whatever they called into the set of network and now they also get to monetize on chain. And I think that that's actually really interesting especially for like the more distributed RPC networks because they have like this sort of like permission is aspect to them as
well, right like that. That's one of the like core goals of one of these more like like I know like the lava networks or the pocket networks of this world is like the allow access permissionlessly to RPCS and have like super high quality service to distribution like low distribution and network distribution. I think that plugging that into a network, like I said is extremely makes a lot of sense and we are in conversation with with some of these providers as
well. Yeah. I mean, I guess this sort of flip side is right that in in the end I guess say that provides this verifiability, right? Because if I'm like OK, I want to ask what's the balance of, you know, this account on Ethereum or something like that, right, Then maybe I want this verified, right, because it's going to trigger something, right? Or maybe I just wanted to show something in the website and I guess say that would be really
good if you want it verified. And something like Lava would be good if you don't need it verified, or if you don't need it verified Unchained. Seta couldn't work without somebody like lava providing that data to SETA, right? Or or or like an infra. So and then the more the merrier because you can create redundancy which increases security even more. So I think that, yeah, that that that will be the main point actually.
Yeah, yeah, basically they just had the the same operators that would serve something like lava could also serve something like SEDA, right? And. Yeah, I think, I think the idea is basically that Lava does the exact opposite for what SEDA does, right? The the exact other direction. So they try to make on chain state through RPC accessible to off chain, right?
We are trying to make all of the RPC data available on chain and we don't want to be build our own RPC network, right like that that that that's a whole different beast to slay. So we would rather have somebody like Lava plug into our network and provide that and be paid essentially to do what they do
already but for smart contracts. So I mean I get that what Seder is seems to be, you know, useful for is, is some degree of interoperability in the sense of, you know, I want like maybe state from something that happens on chain A, it triggers something on chain B, right, like that, that seems like pretty, you know, like that getting that data over.
But then I guess when you look at let's say of course one of the main use cases for intraorability is basically moving tokens from one chain to the others. That means you lock it up in one chain and you create some sort of, you know, asset that can be redeemed for the acid on the original chain. I guess that is something that maybe one could theoretically build on top of SEDA, but it's not something that like sort of SEDA natively will be able to to
do, right? Yeah, so so you need to build it into into SEDA through the form of a program. But what you could also do is plug it into Hyperlane or Layer 0, use it as the Oracle and now you have a super decentralized bridge, right. So if you if you use SETA using like a third party bridge application that's configurable, all of the sudden you create like this sort of like hyper interoperable due to the permissionless expert sort of
like scaling. So that that I think that's really interesting because yeah you you could you could launch A roll up tomorrow, plug your Air PC into SETA and then use Hyperlane configured Oracle to be SETA and now you're interoperable with essentially any of the other chains that also have RPC data available on on SETA. And I think that that is super powerful. It's like like you said it's a primitive and I think that that's where we need to go in the space right.
Like infrastructure need to be sort of like commoditized and accessible to all instead of being gate kept and sort of like acting as king makers. Yeah, cool. So I know you guys have been working on this for a few years. Like what is sort of the like, where are you right now?
Yeah, Yeah. So we so we've been working in the Oracle space for a few years and it's it's actually like I mentioned the optimistic Oracle we built before, before we also launched a first party Oracle. Optimistic or or like what's? What's an optimistic Oracle? Yeah. An optimistic Oracle is essentially an Oracle that you, you, you ask a question, right, like what's the price of ETH and
somebody will answer it right? Or or a group of people will answer it. And then you have like this dispute resolution mechanism that dictates in the end what the outcome was. So the benefit is it's very accessible, You can ask subjective questions. The annoying part is that it's can be incredibly slow. If there is, if it's a if, it's like a a controversial question. Or because you need some challenge period or something.
Yeah, challenge periods. And then if the challenge period, if within the challenge period there is somebody challenged, then it like extends right, sort of like up to a certain point. And it it can take just super, super long. It's cool, but it requires the use cases are not that obvious, right.
You see it with Uma who has built this really cool Oracle, but it's hard to find third party developers that get it enough to build on it. So they end up building a lot of the problem projects that are built on top of the Oracle in house like O Snap or across for example.
So, so, so we were building that and then in parallel we were building sort of like the opposite which was a first party Oracle which is purely API data and we just give essentially software to data providers that then push data on chain themselves directly and that worked really, really well.
So we had like a few data providers pushing price data on chain and the cool thing was that we grew from 0 total value secured to like over 3 billion in total value secured over the span of like two months I believe. So we grew. Like value secured how how? Like what kind of value was secured, if that? So it was mostly like lending D5 but the so, so, so essentially total value secured I say is if our Oracle got hacked, how many money could you steal, right that's sort of like if if it got
exploited, how much money? OK. So these were some D5 protocols that basically dependent on the Oracle you guys. Yes, exactly like the total, like the cumulative total value secured of D5 protocols using flux first party Oracle. So yeah, we grew to the second largest Oracle in the last bull run. Do you know how how big was that number for chain link? Like 60 billion. 60 billion. Yeah, maybe 80, like between 60 and 80 somewhere, yes. So, so we grew extremely
quickly, which was cool. But we also ran into sort of like the horizontal scaling issues, right, Like you have like this. We were the gatekeepers at that point where we're like we're picking where we deploy to and like the monitoring of all of these chains, making sure there were balances in all of these chains, making sure the validators or the OR the data providers were all like happy and pushing and that that everything was going well.
It just didn't scale well. And that's why you see this huge wait times for integrations with sort of like these more centrally run Oracle networks. And that that's really what we were trying to solve and that's why we that's what we that's when we started designing what became Sera. Next up though, at the end of this quarter, we're launching our token migration, so. End of this quarter means like end of March or something. Yeah, like mid to late March.
We just kicked off audits. Because say that token exists today and it's on Ethereum or. Yes, exactly. So with these previous oracles, we launched A token and that's going to be the same token that's going to be securing set a chain. So we need to have some time to migrate. A large part of the tokens are over before we go to like mainnet with the Oracle modules.
So we're launching sort of like a vanilla Cosmos chain with token migration enabled and are looking to launch the first like Oracle modules to mainnet hopefully in Q2. So like by Q2 there should be the first mainnet like data flowing to change through set up. Cool, let's turn in. Do you already know some of the some of the first applications or use cases that people building on top of CEDNA? Yep, Yep, we want to.
So the thing I'm like most passionate about this, I think for the like the next this and next cycle is the idea of chain abstraction. Can you explain chain abstraction? Yes. So right now, when you have all these roll ups popping up right and they're all completely siloed off. And as a user, if I want to interact with it, I have to find a way to bridge tokens to it or get tokens to that instance of a chain that I want to interact with.
They have to go to my wallet, integrate the RPC swap to the swap to the correct chain. And it's it's like if I want to switch from Facebook to Instagram, all of the sudden I have to change my IP settings or something. It's a it's a really, really horrible UX. Or you like have to bridge your account over like your photos or something. I don't know, like statuses, it's like terrible UX. So the idea of chain abstraction
is that you create. So I think there's multiple implementations of it, but to me it's like you create a single layer that people interact with, and then from there there's like in the back end there is actors, solvers that actually perform the actions in your name on the destination chains, so you don't ever have to touch them, but you still own representations of those actions so that you have like, yeah, you're the rightful owner of the positions on these other chains.
And in order to do that, you need primitives that allow you to query state from all of these chains, right? And you cannot rely, unlike some third party actor, to deploy their like interoperability primitive to all of these chains
separately. So I think that that is where SETA has an extreme advantage, Just the fact that you can permissionlessly deploy SETA on all of these chains and you will always be able to rely on sort of like the same standard to query data to verify whether something happened or not on on these destination chains. So, so that is something I personally like focus on to make sure we have like we're working with multiple teams that are trying to solve for this.
And the other ones are like, I mean new roll ups launching that needs need price data, existing roll ups that are sick of waiting for another third for another Oracle to launch on their network and are like can you guys please go live so that we can have access to like price feeds and like base interoperability and such. I think that the yeah that that that's that's the sort of like the lowest hanging fruit for
now. And then we have some more interesting like niche use cases that we're working at that involve some of the like LLM things that that I touched on earlier that I that are that are that are fun but are sort of like to see whether they are going to be core of our business. But yeah that's that's the those sort of like the categories that that we're focusing on internally. Cool. And then are are these here more Are these Flux Oracles still running or those have been discontinued?
No, we we shut them down. We we sunset them early last year or like somewhere, somewhere September last year I think. So the token has sort of been like dormant and kind of waiting for the rebirth of. Yeah, yeah, exactly, exactly. We've been really stealth also because we we had this thesis that this is where the space was going. But until we saw it play out, we weren't really comfortable being loud yet and until we were closer to launching and like confident that we came up with
like the correct solution. But now that we are we, we are a lot more comfortable going on podcast and talking to talking to a ton of projects about about what we're doing. I mean it it to me it sounds like a really logical way of approaching this problem and like something that yeah, can see like a massive market for this. So sounds very cool. Yeah, yeah. We're super excited. We can't wait to get this thing live. It's it. It. We're ready.
Cool. Well thanks so much for coming on Jasper. So I think if people want to check it out, right. So the website is like sedas or SEDA dot XYZ and anything else you wanna sort of. Chill. Yeah. Follow us on Twitter at Setup Protocol. I'm Jasper Flux. On Twitter, check out our Discord. Come hang out, Ask questions.
If you're a builder in the space and you're launching your own network and the idea of finding Oracle providers seems daunting, like reach out, We're happy to spar with you on how to get data to your chain. Talk to you about what data you need, and yeah, make sure we we we're able to support you as soon as we launch. Cool. Well, thanks so much for coming on, Jasper. It's great to have you and thanks so much for listening for tuning in. We look forward to being back
next week. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home Oregon Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv/subscribe for a full list of places where you
can watch and listen. And while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as they're released. If you want to interact with us guests or other podcast listeners, you can follow us on Twitter and please leave us a review on iTunes. It helps people find the show and we're always happy to read them. But thanks so much and we look forward to being back next week.