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.
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.