SEDA: Permissionless Oracles for Any Chain

0:00 Welcome back to the permissionless podcast brought to you by the team at Guardian. And of course, as always, we're going deep with DeFi teams building on the edge in DeFi today. And we're getting to learn more about what has their journey been into DeFi. How did they see the problem that they're solving today? How are they approaching it technically?

0:19 And then where do they see DeFi going in the future? And today we had the pleasure of talking with Jasper from SEDA Protocol. And SEDA is solving a problem that became more and more obvious as the future became more and more multi-chain. And there are more and more chains. I mean there are hundreds of chains and networks at this point.

0:38 And they saw a need to have effortless deployment of an oracle that could automatically be spinning up and spinning out data without a ton of overhead to deploy. And so of course this is the problem that they set out to solve. And in the discussion today, we got to talk all about what are the technical challenges for something like this.

0:57 How is their infrastructure laid out to support such an endeavor and minimize overhead and permission of new deployments? And then obviously we discuss what does this mean for the space longterm and what does this mean for some of these newer networks? Of course, how can this speed up the time to ship new applications, new chains, and overall increase the proliferation of ecosystems in the DeFi space.

1:22 But of course, we'll go much deeper on this conversation in just a minute. My name is Owen and over three and a half years ago, I founded Guardian on the premise that a trillion dollars would be housed in DeFi and that we would need a stepwise increase in the level of security processes to ensure that we have confidence to ship in that environment.

1:45 And today I'm happy to say that we have achieved the standard necessary at Guardian with not one but two distinct auditing teams on every engagement accompanied by a world-renowned lead security researcher and a full-time dedicated fuzzing engineer for the scope. We have developed the methodology that gives us the absolute confidence to be able to put up our own funds as a bounty on the scope after our review on behalf of the project.

2:13 And so really at this point it's up to DeFi to catch up. We are ready to handle the TVL. Okay. And so without further ado, let us get into this discussion with Jasper from SEDA. Well, I mean, first of all, dude, appreciate you joining us. And I think to be honest, we can just dive in and get started.

2:36 I'm interested to hear like how did you first get into DeFi? What was that journey like for you? and and then we can use that as a jumping off point. Yeah, of course. So, I started my first company that was in data analytics when I was 19 and we were building this mainly on top of Facebook data.

2:56 And what was extremely frustrating trying to build on sort of like this centralized gatekeeping data set, gate cap data set, was that every two weeks they change API permissions. And so it was really hard to innovate because you were just constantly running around like making sure your features were not breaking instead of being able to release new features, right?

3:20 And that was really annoying. around the same time I got into crypto a little bit mainly just you know I don't know like to Twitter and like friends telling me about about it. And then after like a year and a half of like pulling my hair out with this previous startup and looking into the the this this crypto tech a little bit more, I started to realize that some of the things that were frustrating me so much would actually be solved by back then Ethereum, right?

3:47 So the the idea of these permissionless smart contracts as ways for developers to build on top of existing technology in a permissionless fashion where immutability is sort of like a gift given and a promise seemed to me to be very interesting because my thesis there was this will grow quick because you have this network effect, right? So developers will build on top of things that other developers build and then other developers will build on top of that and you get sort of like this super flourishing ecosystem of devs.

4:20 And so like that's how I figured this this space could gain a lot of momentum. So I was like super fascinated by that started to dive a little bit deeper. Initially I started as an independent researcher. got hired by a team. We got funding from EF to work on plasma back in the day like L2 scaling technology.

4:42 It's like 2018 2019 worked on that for a while and then we were demoing some of our tech at a conference in Berlin and that's where I met my my co-founder Peter and we started building sort of like all the way at the top of the of the stack right we started building sort of like a DeFi Llama at the time it was called EveryDapp and we realized there is some apps but there's really no users so then we're like okay let's build an app that can attract users like what is something that we would want to use that we can build on top of this technology that is like a a net novel thing like what's like what's like a real addition and then we came up with this idea idea called flux

5:25 Markets the idea was to build startup derivatives so being able to long or short startups based on a set of milestones funding rounds etc kind of like prediction markets around around startup milestones that got a lot of traction but while building that we came to the conclusion like hey wait there's this other piece is missing. So we sort of like went down one layer deeper started building like an open market protocol and then we were building like sort of like these derivative markets or like prediction markets and we're like okay how are we going to settle this how we're going to settle these and then we were building on top of another chain at the time near and we're like okay like there's no oracles Chainlink doesn't work here there's just no way to

6:02 Settle these markets in a permissionless fashion and we saw that as like oh [ __ ] that is actually maybe even a bigger problem to solve where the number of chains that are going to be launching is only going to accelerate. There's more and more devs are going to run into this problems that they're trying to build within the ecosystem, but there's not going to be data available within that ecosystem.

6:25 So, hypothetically, would there be a way that we can build a Oracle system that can be accessible from any network and give developers access to any data? that was sort of like the dream and SEDA is the result of that dream. So, SEDA is a generalized oracle layer that allows people to deploy their own data feeds and access them from any chain.

6:53 And yeah, sort of like the the story here is we tried to build many different things and kept running into sort of like holes in the tech that we felt were needed and just fell down a rabbit hole all the way to the bottom to this sort of like unified data layer. Yeah, I I'll leave it there.

7:11 Yeah. It goes down to the bottom of filling in that gap of where the infra infrastructure is just not mature enough or the infrastructure was not built in a way where we expected to go to a future where we have thousands of different chains and app chains and L2s that are settling on to other chains and even like L3s and all this stuff.

7:30 So yeah, I think problems definitely arise when we were building in one direction thinking like, oh, maybe we can just scale one chain infinitely originally and then obviously this has not turned out to be the way that we've gone technically. So we've got to build and and address that with all this different infrastructure on every chain. So it definitely makes sense.

7:52 And then also going back to how you you originally got in, what you're originally working on, it's it's kind of funny. My first software application was actually you know somewhat similar. We were building on top of not Facebook but Instagram and it was it was a different kind of application. We were more like automating interactions with the UI but then they would like go and change the UI every two weeks and you would have to like update that stuff or like their algorithm would change.

8:16 So yeah, I can completely still a meta trap. Yeah, absolutely. And it's just not like you don't want to be building on top of a business that's like moving underneath you. It just makes things very hard. Ideally, you want to own like every area of the stack, which is like you said what Ethereum empowers is you own every every area of the stack or if it is on the blockchain, it's immutable and you can permissionlessly access that.

8:45 So yeah, definitely relate to you on on that level. But so so going back to to SEDA and addressing this problem of access for infrastructure for for developers building on new chains. The way I think about the infrastructure or the architecture that you guys have sort of come up with is kind of like you almost have like proxies that are easily deployable to new chains and then that is a proxy to the SEDA chain and this network of like verifiers that you guys have.

9:14 Could you maybe give us like a high level architecture for like how did you technically achieve this? How do you think about the architecture? Yeah, for sure. So I'd say that there are sort of like three layers and one intermediary. So you have the consumer of the data which is like the smart contract on the destination chains.

9:36 So that could be a smart contract on Solana, it could be a smart contract on Ethereum or a smart contract on base. wherever you whatever chain you can think of they could consume our data. what we do is we deploy what we call a SEDA prover on each of these chains and this prover essentially verifies certain data and certain proofs.

10:00 Obviously what happens is I'm thinking of like the order of what I should explain this. So we have the another layer is the SEDA chain and the SEDA chain is like a economic slash checkpointing layer for data. Mhm. So it's like where there is staking, there is certain issuance of what we call data requests. So when you want a new feed to be pinged or called or updated, what you do is you issue this thing called a data request that happens on the SEDA chain where you say, "Hey, I want the following APIs to be called by X amount of compute nodes."

10:44 Which brings us to sort of like the third layer which is the SEDA overlay network which is a network of sort of like independent query and compute nodes that execute sets of instructions called SEDA programs which are issued on a set of chain. So as a developer if I want a new feed I deploy a SEDA program the data program to the SEDA chain then I can send a transaction to the SEDA chain referencing that program.

11:16 This program will then be picked up by the query and compute layer. The query and compute layer queries the sources specified in the program. It's actually the the the overlay nodes are just wrappers around the a Wasm VM and the program is just a just a set of this Wasm binary. so they blindly execute this Wasm binary and then commit the results back to the SEDA chain where they are aggregated and the magic of our scaling and distribution happens after this aggregation because what happens is all of the data that's finalized within a block on this data chain is at the end of the block is Merkelized and then signed by the validator set which allows you to temperroofly or in a temperproof way transmit this data to sort of like any chain that has

12:05 A prover deployed to it. And that role is filled by what we call SEDA solvers which are essentially independent actors that will update data on your chain or app or fee. Any questions there? So the the prover contract this is essentially a gateway for folks on one chain to interact with data on the SEDA chain. Is that correct?

12:28 Yeah. And then and through that can they update and read or can they just like read state from SEDA? They can read state from SEDA. but the solvers work can work two ways, right? So the solvers can watch SEDA chain update on destination chain but they could also watch the destination chain for maybe new requests that are being issued.

12:49 So so that is how we design the infrastructure. is like you can have sort of like this and with web two development you would sort of like promise type system where you can where you can essentially issue a data request and have it settled asynchronously and then and read the data later. or you can build smarter systems for for for sort of like more for data where it requires low lower latency.

13:13 But in general yeah it can be both ways. So the data can be all the data requests can be issued and read from from these prover contracts. Yeah. And I think a big part of this is obviously module modularizing each layer of the stack. So now all of a sudden you don't care if the implementation of the prover contract is in Rust, if it's on Solana, if it's in, you know, EVM, if it's in Move, if it's in any any of these things.

13:43 All the network cares about is this request and I don't know are you guys listening to events? How are you picking up requests from prover contracts? So the solvers would listen to events on the origin chains in this case, right? So like the the destination chain can also be an origin chain for requests, but it's a destination chain for the data.

14:03 So that's how that would work. if you're building like a derivatives app and you have like we're working with a bunch of RWA projects who require like lower latency and probably a little bit smarter smarter data issuance like they would not issue their data request on their chain. They would just issue the data request through a solver that they specialized solver on on SEDA directly with with a certain heartbeat that they require and then just deploy the or or transmit the data to their own chain.

14:35 Right? So there's sort of like this the solvers is a completely permissionless role like anybody can do it. You can build your own specialized solver. We'll have a framework for it that you can pick up and yeah so so depending on the use case depending on the use case some use cases doesn't really matter right like it's just simplest to use an existing solver that just blindly sends the data to your chain for like a small small spread on the cost.

14:57 What this also allows to do that's quite interesting is solvers can also act as a sort of like a what what do we call it? They can hold inventory and SEDA and use that to pay for the data request but they can take in any token that they are willing to accept in exchange for that which is quite interesting.

15:14 So you don't need to bridge SEDA to end chains in order to access data from those chains because that would actually be a a huge bottleneck and b sort of like a security problem because you like fragment all of the stake that you want concentrated on the SEDA chain. so instead we want solvers to just hold inventory and accept USDC, ETH, whatever they can think of really on the on the on the origin chains of the request.

15:40 And I think that is another selling point which is quite cool. that yeah that that's where intentric design which this really is is actually does well. Yeah, of course like abstracting that totally away for the user. They don't have to pay in like a SEDA coin. they don't have to pay. And like for example, like if LayerZero was only accepting LZ payments like that's not that would not be that would hinder their adoption very much.

16:10 So I've actually I don't think I've ever reviewed anything that used LayerZero with LZ payments on it's always just been native. Yeah. So I mean it's clearly like the product the market wants to be able to pay in whatever token. So I definitely agree with that design decision. If I were to sort of summarize at least like the most basic use case cuz obviously you can do a lot with this when you start to modularize everything and you allow like custom solvers and all this is it's almost like a distributed Chainlink aggregator that really you can you can spin up your own like feed values that you're pushing.

16:49 You could spin up any feed like for an RWA and now you can deploy it across every chain all at once as long as there's a prover contract for it. Is that like somewhat accurate? Entry level day one type of use case for sure. It's like most most on the nose use case is price feeds for any longtail feed you can think of on any longtail chain you can think of without having to talk to anybody, right?

17:14 Like that that is that it really is the selling point. And then from there we can go down a rabbit hole again and sort of like touch on like what what else is possible. Yeah. And I mean I think even even just that base case of like the simplest use case is actually extremely valuable in and of itself.

17:30 Like there's so many teams that work with Chainlink or they work with maybe even like a Pyth or some of these other teams to spin up custom aggregators. Like for example, I know Synthetix, they they spun up a custom aggregator to report their debt across optimism and Ethereum and like aggregate and all this stuff and that was a totally custom like white glove solution for an aggregator that had to be you know run through manually spin up the architecture.

18:00 And you couldn't do something like that without having a connection with the Chainlink team and working with them on that. And you know, I'm not sure how long it took to get that spun up, but like I know that it wasn't like a oneweek thing, right? But we say that this is something that you could spun up.

18:16 Yeah. I mean, custom feeds on some of the incubants that you mentioned are like million plus that have deployed. Yeah. and I think it goes against the ethos of what we're building here, right? Like I mean the idea is to build permissionless systems that allow people to build permissionless applications. And I think historically that's not really what we've seen with any data related products and yeah, we're trying to introduce this.

18:40 Yeah, absolutely. No, I think you guys are hinging on a piece of the infrastructure that's been like it's been neglected and I think in the past it's been neglected because we were in this like chain centric sort of approach and then now it's becoming like more and more of a pain point. So I guess I'm interested like what has been the market demand initially?

18:58 Like what are the use cases that you you guys are seeing right off the bat that people like desperately want to use this for? So I think price feeds on longfield chains is like super super obvious, right? I think another one that really has been resonating a lot is the RWA side of things. definitely where they require like really strange feeds that plug into strange sources and like it doesn't make sense to pay a lot of money before you have product market fit for those, right?

19:28 So, scaling those up with SEDA just makes a ton of sense. Then, the other one which you touched on briefly earlier, wait, let me save that one for for the last one, but I think another interesting one actually is the the rise of AI agents. You can use SEDA as well for smart contracts to permissionlessly chat to LLMs directly without there being a server that runs a ChatGPT API with some private key like you can provably have agentic smart contracts using SEDA which I do think is quite interesting and we hosted a hackathon with with encode that was meant to be a chain abstraction hackathon but actually a huge percentage of the submissions were AI submissions people doing these types of like strange things that I was like, "Oh, so there's like developer demand

20:18 There." Then finally, the other one that we've been seeing a lot of interest is the interrupt side of things. So the idea that you can permissionlessly deploy decentralized data infra to like any chain also means that you can permissionlessly read data from any chain and access that data from any chain. And so you just mentioned LayerZero.

20:46 You have Hyperlane etc. You have all of these messaging protocols that have these things called DVNs or IVMs which are like these modular security programs which are now often multisig because it's just the fastest scale crosschain but it's not very secure. and so I think SEDA is with what we call the IVM is a is oh with the with Hyperlane it's a ISM not an IVM we are building IBM it's like a decentralized more secure version of that that you can plug into these existing crosschain messaging providers right so instead of having a LayerZero DVN that's just a multisig you can say hey it's a multisig but the SEDA network needs to also sign off on So you have like I don't know like three customizable signers that is I don't know some sort

21:42 Of private key infrastructure that you have somewhere and then you have like this I don't know like a veto veto right next to it like hey like at least this decentralized network needs to agree that these three signers are are correct. I think that would just exponentially improve security for these systems and yeah that's that's something we're we're building internally and we'll be releasing somewhere right after our mainnet roll out.

22:06 Yeah. And so obviously with everything being very modular in SEDA. Do you foresee this even being able to be a DVN? Because I know obviously the DVN architecture is very modularized itself. Could this be like a DVN that's used on LayerZero? That's the idea. The idea is to build like this this sort of like as a DVNISM extension or yeah just as a DVN or ISM for sure.

22:32 I think I think that makes a lot of sense like we don't want to build crosschain messaging. We're not interested in that but we think that adding to the crosschain security or verification stack with our already existing infrastructure just makes a ton of sense. Yeah. And then obviously so you mentioned data reading of course with interop. So messaging is one thing.

22:54 You can kind of leverage messaging protocols to read data from all chains. Like I think you probably saw lzRead getting getting released. I think it's been officially out for I don't know maybe like eight seven months or something like at this point but I think they like really started promoting it just recently. What are your thoughts on lzRead?

23:16 Do you think this fits into what you guys are already building at SEDA? What how does that position with you guys? Yeah, I think LC is super cool. I think with these more complex systems, you always developer adoption takes a bit longer because they're more complex to understand, more complex to build with. They will also need more sophisticated DVNs for this.

23:36 And what is actually interesting is that with the programs that we allow you to write, you're actually able to mimic lzRead functionality. Yeah. which actually allows you to build like a decentralized DVN for lzRead even because you can because essentially our overlay nodes I call query and compute nodes that is what lzRead is it's query and compute it's like hey query data from this chain do some computation on it give me the result so that I don't have to do it on chain right or aggregate like these contracts on this chain into like a single swap value or like whatever you can really think of that is what a what a data program does as So I think we are relatively well positioned to to like support them in this.

24:23 I think it still requires some R&D from our side like how exactly that would look like but I think I think the product makes a ton of sense like we we are seeing the demand for this as well but especially so so here's another thing we just talked about like the thousands of chains and for the longest time I have been screaming this off the roof but I think we have overcorrected in Ethereum EVM world like now there's too much block space like there's not not close to enough users to like use all of this block space.

24:52 There's just not enough interest in the applications. So sort of like margin cutting applications like lzRead which is like hey you know how normally it costs 15 cents to like do a bunch of aggregation on data on an L2 now it will be like 2 cents like I think people just can't be asked it doesn't really matter right because like block space right now is not so scarce if we get to a point where block space consolidates because people are like running at a deficit right now and people just need to be more realistic about how much block space is actually needed I think as soon as we get to that stage like then these kinds of products will be like more top of mind for people.

25:29 But yeah, I think that's my thoughts. Yeah, I mean going back to what you said on lzRead DVNs, they are definitely even more sensitive than regular DVNs because like you said like there's all this additional processing and then of course if you have multiple DVNs configured then they had better all come to the same result. and there's, you know, of course the you've got to make sure you're reading from the correct the correct block.

25:55 I mean there's even like I mean we've reviewed a couple lzRead integrations at this point. it's pretty sensitive in terms of like does the read function revert and how does the DVN behave in that case. Sometimes it can literally break the messaging channel if for whatever reason there's some edge case where the read function result reverts and then it's like well your app is your crosschain app is just bricked until you like go in and specifically skip that particular knots.

26:23 So yeah there is definitely like overhead on that case. That's interesting. Yeah I think there's a lot of work in general. Yeah, I'm definitely sympathetic having built what we build like how difficult it is to build like these aggregation products or like compute products. It gets even more annoying with what we're building because we add the possibility of entropy to be added or like at least with lzRead if you read from the same block like you'll get a unanimous answer like if it's not all DVNs have the same answer something went wrong and with SEDA like we allow you to query price feeds and if you're off by five milliseconds maybe the price has changed by some amount And then like how do you handle that, right?

27:09 Like and and we're sort of like allow you to do that as a as a user. You're allowed to build your own aggregation algos. But yeah, I'm very sympathetic to like the the the problem space there. It's really difficult like you get all of these super strange paths in your or in your logic that you wouldn't expect to be taken and then I'm sure I'm sure we have bricked our overlay nodes many many times.

27:33 Yeah. I mean it's I mean getting DeFi applications to work correctly in one chain environment is hard enough and then when you add the aspect of like okay there's multiple chains orchestrating in this and you can think about all these different communication pathways and like if there's a reorg like god forbid there's a reorg now we have to oh yeah be very careful about that and yeah so so it it definitely just adds a whole another dimension to these things but I mean so we've been discussing testing like a handful of different use cases and obviously with something so modularized as SEDA you can attack a lot of different problems in the space that we have right now but how do you guys think about focusing on one like what is most important for you

28:19 Guys what do you guys see as like the central issue that you're tackling right now it's very funny like in the beginning people always ask me like what what can you do with it and I said anything and it's that's a huge trap right like when you when you get into this space where you're building a product that's in like you said so modular that can sort of like be used for any use case more often than not it will be used for zero use cases and so what we've decided to do is just talk to developers talk to our users right go to L1's go to L2s and try to see what their pain points are that are data related and what you'll see is most of them have like so within L2s there's

29:00 Sort of like this this this trillemma which is they want users to create order flow and create value. users need to have something to do which means you need developers and developers need there to be users and they need and then the third sort of like thing is liquidity right so so for a lot of the applications that people want to use you need liquidity so you have like this this trade-off of liquidity users and devs devs have the need for liquidity users and certain infrastructure to be there our offering is like hey we'll deploy SEDA to your chain you'll have developers will have the data infrastructure they need to Dei at the same time we can also help you plug into liquidity using hyperl LayerZero with SEDA as a DVN.

29:45 So now you're plugging into liquidity permissionlessly and into developers have the infrastructure to build whatever they would need to build to attract that liquidity. and then the user should come right like we can't offer them users because that's we're not a userf facing applications our users are devs. so that is sort of like the offering that we've been holding up to people and I think the main thing that interests them because most of the L2s that are popping up today already have interop partners that they work with but then the sort of like Oracle infra is like the most interesting part and then it starts with price feeds then you can later on also offer them like interop services if the chain blows up you don't want to have like two signers for your for

30:27 Your DVN so then we can offer them bridge security and yeah then then from there see what the demand is from the developers on their platform and we we'll be able to to serve sort of like any use case so yeah I think day one it will be just deploying a bunch of price feeds to like tons of chains and from there expand right and also like one of the things is being an unproven oracle is hard yeah definitely right like if you don't have a history of securing billions of of value which actually I forgot to mention but we do have because during the 2021 bull we built Oracle infra that we deployed on a bunch of chains and that's how we tested sort of like this this thesis of like hey what if

31:18 We deploy this Oracle infra to like a bunch of chains early on it was just a first party oracle so we're just pushing data from data providers directly on chain and we were securing $3.6 6 billion within seven weeks. Like we grew in the 2021 we were the second largest oracle after Chainlink. and we also ran into sort of like the headache that scaling that centralized business was.

31:42 We saw like hey either we'll become another Chainlink we'll have to charge like super super high numbers to deploy to like all of these chains and have our developers sleep on their desks. or we can try to go the other the opposite direction and just like create permissionless system where hey if you want us to deploy it for you we'll charge you something but you can also just deploy it yourself right like if you are a dev and you need data you you can just get it yeah and we decided to do that we thought that was more exciting and more of a value ad to the to the ecosystem.

32:15 Absolutely. and like going back to the use cases a little bit you mentioned hosting you know like a hackathon. Is there any use cases on SEDA that you're like incentivizing people to build or like request for for product on your end? Good question. I think most of those we would be building ourselves now, but if people want to jump in, please do, right?

32:35 Like if you can take it off our of our off our shoulders like that would be great. Yeah, there's like there is like ones where like frameworks for agents I think would be very interesting. if you could do some of the lifting of the IBM, that'd be great. Like sort of like interrupt or like a DVN or a ISM for Hyperlane like I'll I'll kiss your feet or whatever you want.

32:56 Like for sure. I off the top of my mind any other ones right now I can't think of. This was like an exercise I was working on a lot a few months ago, but right now we're pushing mainnet and all I can think of is just that's not launch. Yeah. No, I think like framework for agents is cool.

33:16 And then so obviously you mentioned like you don't need to pay for anything with the SEDA token, but I guess I'd be curious to learn more about, you know, what it is, like how it works, use cases and things like that, how it plays a role. Yeah. So, in the end, you do need SEDA token to query data.

33:37 But the way we designed it is you don't need to pay with it on the origin chain necessarily right so the the solver would hold inventory inside the token and would like take a spread on conversion from token A to SEDA on while it does pay for the computation so SEDA token does a few things it's used to secure the network it's used to pay data providers it's used to pay the querying compute nodes and you do that by when you issue the data request you pay in SEDA for compute very similar to ETH we are also working with the I don't know if you guys know the Atlas team working on sort of like application specific sequencing on these destination chains so you have like the idea of like they're building like a modular

34:29 Application specific sequencing framework where you can essentially offer the auction right to back run these oracle transactions as well on the destination chains where some of that value would get captured and either converted to SEDA or would flow back to validators as as a revenue model essentially. I see. So the and also I think I mean with the SEDA model being more like open and anybody can spin this up it definitely makes sense to have more like community contribution like open source contribution like that.

35:03 So, definitely if anybody wants to start working on those projects, that would be really cool. But the way that you guys are monetizing it is not the model where you're charging a lot of money to any of these new like alt L1s and L2s that are spinning up. You're are you mainly monetizing then on like the fees for every query?

35:25 What does that model look like? That that's the goal. That's the goal. Yeah. I mean we are talking to some of the teams and like one of the bottlenecks we're running into is like people don't want to necessarily always deploys themselves especially because it's novel and unproven and then we might charge some fee for the deployment just because we need to prioritize then which is exactly the situation we're trying to avoid long term but for now that is still an option.

35:52 But if teams want to deploy it themselves means you spin up a solver and deploy prover like, hey, I'll I'll deploy the prover for you. You don't need to pay me for it. Like that's not a problem. But like spinning up the solver and holding inventory, etc. If they want to do it themselves, yes. Then they just pay for free.

36:06 Yes. So I mean the offer to the actual chains is like a pretty good offer. It's like, hey, let's get oracles spun up on your network. Let's get a proven contract. And then that can be like the prover contract for the network. And I mean really there's no cost to to you. We solve that issue of infrastructure for the chain and also we make it easier for liquidity to to come on.

36:28 So we're solving like two out of the three for you guys and and really like at little or no cost to the chain itself. Yep. Exactly. And then in that sense would you guys become like the preferred provider on the chain? What does that sort of look like? like do we make that part of the deal? I hope so.

36:45 I hope that result of it. Yeah. Yeah. Yeah. no. I mean, we we I don't I don't think we'd ask that. I don't think that that matches our ethos much like that we would make them like, "Hey, now you have to offer us all of your apps." Like if later on like some incubent launches and they have some features that the app prefers, then they should be able to use the the whoever that is, right?

37:09 Like if we can't offer the best service, then we shouldn't be used. Yeah. Because I mean really the proposition is you are covering the use cases where where an existing oracle that is like completely free to use doesn't already cover or you know it's not on the chain yet or it doesn't cover like spin up your custom oracle.

37:31 So that's really where yeah for sure and also would say that these existing oracles are definitely not free. It's just they charge not the user of the data they charge the chain who needs the developers. It's kind of like a backwards definitely not a sustainable model where yeah it's kind of strange like I I I I'm trying to come up with a metaphor of like how that what this would mean in in in the world like I don't know like some sort of government subsidized thing that then citizens can use.

38:00 Yeah. Yeah. But I I don't think that's sustainable. I prefer like more of a open market type type system where hey listen we we allow you to access data. We we one of the things we've been saying is like we're bringing the internet to smart contracts. Like you'll get full internet access through smart contracts. And that doesn't exist yet.

38:21 At least not in a completely permissionless multi-chain manner. and if you don't think that's cool, you're an idiot. No, I mean how can you not? Like that sounds awesome. So yeah, I think that's a great tagline and I mean no, I think it's it's perfect, but yeah, I mean we can we can cut out anything. Of course, we'll we'll share, but yeah, I think anything that is it's closer to the value creation than anything else is just charging on use, right?

38:54 So like you could deploy a Pyth feed and you could pay x amount of hundreds of thousands or millions or however much it is and then what if nobody nobody even uses it you know what if they you could spin up say on the same chain and people could end up using that I think paying per use is definitely closer to the value that's being provided so it definitely makes more sense on on that sense and then with that in mind what chains are you guys already on or you guys are already on pretty much every chain.

39:25 What are some of the new chains that you guys are supporting? Yeah. What's right now? We're not on any chains. we are sprinting towards sort of like feature complete mainnet launch. So we have been I think we've been on like 20 test nets now for the last few months but we are approaching mainnet launch. so we have a we did a sort of like SEDA chain mainnet launch a while back but that was just to sort of like bootstrap liquidity and bootstrap security for when the oracle actually launches and yeah we're approaching that very soon I'd say I'm not going to give a timeline on my engineer is going to freak out.

40:10 Yeah don't but like in the next two months. Okay. Wow. So so coming up pretty pretty soon then. And then in terms of like initial use cases on launch, what is that going to look like? Can people spin up any custom Oracle they want right away? So it will be completely feature complete. like you can you can c you can spin up any custom oracles.

40:33 We will have examples for the for the most obvious use cases. if you don't know where to start, reach out in our discord. We will help you launch what you need to launch. We'll help you get your data where you need to go. And then of course we have like a backlog of of people that and change that we will be supporting and apps that we'll be working with.

40:52 Yeah, I was going to ask about that. So are there any particular integrations on launch or or maybe a shortfall up from launch that you guys are excited about that maybe you can talk about? Maybe can't talk about a lot of them, but yeah, any cool integrations you guys have queued up? Very cool. Some of them will be announced soon.

41:10 So I can I can touch on and I'm sure that if you go to our Twitter feed, you'll be able to extrapolate some of the partners, but it's it's stuff in the interop space. Yeah. That we'll be working with. there are and that's some of the major frameworks. Then we have some RWA providers, some RWA platforms and chains that we'll be working with.

41:33 And yeah, some some longtail chains that that need feeds. I'll I'll leave it at that for now though. Yeah. So, we we touched on all of the major use cases that that that will see light very soon. Yeah. And I mean really it's just a matter of time and with all these integrations, everybody getting ready on their end.

41:54 You know, of course, when you're ready, other team might need another month or something like this. So, I I can definitely feel the pain point on on that front. but I think another problem that you touched on which is having the track record of security and having the like name brand of having secured like billions of dollars with the same infrastructure and having it back invested.

42:16 So what does the process look like for you guys? You're gearing up for a like a full future complete launch. What is the testing and and verification process leading up to something like this? Yeah. it's brutal. It's it's a ton of stability testing trying to nuke the system constantly. and we just went through an audit and we yeah we we were able to break our system a few times and got a lot of very very helpful feedback.

42:49 And we'll just continue doing that up to main at launch. so far things have been extremely stable since we went through this. So hopefully we'll be able to to make it there unscathed. But yeah, testing wise it's just it's it's brutal. especially in Cosmos, the tools suite is quite poor. So it took us a ton of time to build our own testing suite.

43:10 And yeah, bu build built like a strong strong set of of of integration tests mostly because unit testing a system with this many components is still very important, very very good. But like when you string together this many different sort of like actors within a system, you just need to make sure you have extremely strong integration tests and that just requires a lot of custom work.

43:34 Does that answer it? Like it's it's just a ton of stability testing, fuzzing, like trying to break the thing. So yeah, I mean you're absolutely right. When you add all of these different actors and everything's got to line up like exactly in all cases across all possible state spaces, every new actor that you add that's, you know, part of the chain of interaction is like it just creates like a quadratically increasing amount of things that can go wrong, right?

43:59 Which means that you've got to expend that much more energy to keep the entropy in line and make sure everything's, you know, functioning as expected within the the parameters that you guys basically set forth. and then obviously really every hack comes down to to human error at the end of the day. And I mean we're seeing that even with like a smart contract.

44:24 Well, until very recently, yes. But I don't know if you guys saw the wayfinder bug that was that smart contract was definitely written by an AI. So you also have now computer introduced code that is also creating bugs which in the end is built on top of human created data sets but the still I think yeah it is it is human error even in the sense that like an auditor didn't find it or like one of the team members didn't find it but the the bug was written by a computer that's new human error AI error yeah and I mean really it's about managing human error across an entire development pipeline especially as like I mean you know we get audits today but even audits have human error involved in them right I mean I

45:15 Think even just in the last year there have been like500 million or $600 million stolen from literally just audited contracts so it's like clearly there's something else that you know needs to be done to address human error across the board or AI error I think AI error is going to become an even bigger problem so we'll probably see like up and rate I've got this thesis is that being an auditor will become much more valuable than being a developer in the next like two to three years because being able to quickly audit AI generated code will be more important than writing code because it's going to be AI is writing code and so all you need to make sure is that nothing slips through the cracks which is an auditor's job not a developer's job

45:56 So I actually think that that is a really interesting one I was sort of like philosophizing with a friend of mine who also is running a company on like what the hiring process should look like in sort of like a fully AI AI enabled engineering world like no you shouldn't hire a junior anymore probably because AI can do that so you're mostly hiring seniors and then even then like I think auditors are actually going to be so so so wanted like for for this type of stuff it's it's going to be cool different paradigm absolutely yeah I mean we'll we'll see hopefully the auditors don't get replaced too by AIS we'll see well that will be agentic auditor then and then like yeah it would be wild.

46:38 Who's like yeah who's who's reading all this stuff? What is what is your view on this? Like how do you foresee human error trending down like what what is the what is the what is the way to address system it's got to be addressed from a systems level like you you can't rely on any one piece of the puzzle.

46:58 It's got to be holistically a part of the process. So like for example, you know, you you write the code, you develop the code, you've got your integration tests and and stuff like this and then you go to an external audit. The external audit is in most cases going to have the same sort of human error risk that you know just having an internal team look over it is.

47:17 And then so what is the canonical solution to that? Well, it's just like get like five audits. But it's like that's really expensive and it also takes a lot of time. So I think teams really have to address this in their development pipeline, move up that like feedback loop as much as possible. I mean the best way we've seen to do this has been invariant testing which forces you to really think about Yes, absolutely.

47:46 And it and it it lends itself very well to smart contracts and sort of like a walled off environment. it it just allows you as a developer in the development pipeline to get very very deep coverage of all these edge cases before you go into an audit. And in a lot of cases it's catching stuff that even is missed in audits depending on obviously what kind of an audit that you get.

48:10 And it's something that can be integrated directly into the development pipeline as long as you know you've you've just hit the learning curve of how to write invariants and implement them. And I mean, we've seen it just work absolutely wonders. It gives you a faster feedback loop. You can, you know, like let's say I make a change.

48:29 It's actually broken something very subtly over here with some rounding issue, but you would never know that until you went to an audit and hopefully the audit would uncover it. But with invariance, you can pick it up right away. And I think that's really how we address it at a systematic level is like you got to implement that in your development process and then you've got a systematic sort of like cross check against human error because you've got these invariants.

48:54 If you have the invariance and you have the coverage, you're going to find the bugs. It's not up to like human error of like some auditor finding it or not finding it. So I think that's really how we address it in the long term. If you want to ship structurally over 10 years and you want to not get hacked, that's what you got to do.

49:10 I like it. Yeah. One of some of the stuff we've also have also seen in our team is that we have certain I don't know if it would that would be an invariant, but like we test for certain gas outputs. So if the test all of the sudden hits a new gas limit or like a gas gas burn, it means that some sort of different path was taken or some some value is like greater or smaller or something.

49:34 Than we than we initially expected. And that's a really interesting one. Like if if you have a function that all of a sudden costs like a few hundred units of gas less or more, that means that something changed, right? And then all then it's just like, okay, what changed? And it does that make sense with the code that I touched.

49:51 It's just a it's just a good way to double check it that that that I I saw and I I hadn't seen before and I thought it was pretty smart. Absolutely. you need to be aware of everything that can happen in your application especially and it's easy to do this when you're talking about smart contracts because they're usually not as complex.

50:08 I mean similarly something that I love that you can do with invariant testing is you can assert every kind of revert that happens. So like I can literally whitelist and say like the application should only revert in this very specific scenario with this very specific revert. And then now all of a sudden you start to find all the cases in which it's reverting that are not expected.

50:29 And I mean this we use this a lot in our reviews to uncover like all the little rounding issues and like whenever like my favorite is when you find like a ERC20 balance underflow like you're you're trying to transfer too much out of the contract. that is 99% of the time a logical flaw in the smart contract that you've just found because you found some revert that you weren't privy to and and the fuzzer just found the specific case where it gets hit.

50:58 So it's it's just so powerful for like defining exactly how your application should function and then making sure that across all state spaces it stays within those parameters. That's kind of similar to to what you said about the gassing, but I guess like kind of taking it to the next level and and just covering everything. I mean, the more we can cover everything systematically without humans like looking over everything, I think the better.

51:20 But yeah, that that's kind of my long-winded take on on how we take security to the next level. Makes sense. I like it. But yeah, and I think so, I mean, we've talked about everything that you guys can do today and you're tackling all of the immediate problems that we're facing today. How do you guys see this fitting in long term with Interop?

51:39 Where do you see Interrop going? And how do you guys fit into that niche? Obviously, there's many players there with like a LayerZero across and the list goes on and on. like what's the long term here? Where do you guys fit in? I think that programmab programmable verifiability of crosschain state is just going to make so much sense, especially with the rise of chain abstraction protocols, intent systems.

52:00 You're going to get all of these like complex cross-chain queries that will unlock sulfur funds for example or I don't know like serve as escros I think this is just a really really necessary product for that like having programmable crosschain verification and I think SEDA as a product is uniquely positioned to serve that very very well so within interop that's what I see within sort of like broader multi-chain sort of like where we're going.

52:37 I still foresee that big apps are going to enter the space. You see like some very very big I don't I don't know if this public but there's a lot of very big consumer apps that are trying to launch their own stable coins now like neo banks and trading apps that are all going to be wanting to launch their own stable coins.

52:55 Eventually they're going to want to own the whole stack. So they're going to run their launch their own chains etc. Like like every app that wants to capture value will have to deploy their own chain at some point because they want to be have ordering rights on the transactions or priority rights on the transactions like whatever whatever they can think of as a as a reason for it but if value trickles up to the application then they don't want to pay anything to the validation layer or like as little as possible.

53:20 So I see the number even though we have too much block space now I do see the number of total chains going up and these chains will still need access to the internet and I see us as sort of like the gateway to the internet a permissionless gate gateway to the internet so if you don't want to forgo a lot of the reasons to build a permissionless app or a decentralized application in the first place you'll probably want to have a decentralized gateway to to to any sort data source in my opinion because what you're seeing on what you've seen before or like what you're seeing now is if if you're building a lending protocol or like some DeFi app and you use a centralized intermediary to fetch the data that essentially whitelist or signs

54:04 Transfer rights on a lot of these things you're essentially handing off a ton of almost like es or like I don't know custody to this to this data provider and that doesn't really make sense like might as well build a web two app then at that point right so I think that's sort of like how I see sort of like the philosophical stance of of of where we're going like or or why why we're doing is important and then yeah I just see the sort of like chain landscape longtail increase accelerating at this point and yeah I think we fit right in there.

54:36 Absolutely. And I mean in the we're in an interesting time where it seems like institutions are they have DeFi interest. They're very interested in testing things out at this point and it seems like we're going to start getting more and more institutions coming on chain, but they they need a whole slew of infrastructure that we don't even have yet.

54:54 And I think you guys could potentially be positioned quite nicely for that if it's something that you wanted to pursue with like an AML or KYC. Obviously, it's like a very different type of client. It's a very different type. Not necessarily what I would want to work on, but you can definitely use our system for it. Yeah.

55:10 Well, you guys empower stuff like that, which is that if they want to come in and maybe there's some company that's working to help the space be amendable for institutions, they can build that on top of a Yeah. And I think that's powerful how you guys are building, which is really with the DeFi ethos of composability, which is that you've built the infrastructure layer and now you've made it easy for everybody else to come in and build on top of it.

55:35 But with that being said, is there anything anything else that we should cover? anything we can push folks to? Obviously, we can send them to to the website and we'll have that link down below and the Twitter. but anything else we should cover? No, like website, Twitter, find us on Discord. If you have any questions, if you're a dev that needs something like this, if you're a chain that wants an Oracle partner, come talk to us.

55:58 We'll help you out. Absolutely. All right, dude. Well, I think we covered just about everything. Obviously, if you guys are are interested, the launch is coming up. you'll be able to spin up your own feeds and start to use them on I mean pretty much any chain that you can deploy your own prover to. So definitely go and check out SEDA.

56:15 We've got the website down below and thanks so much for your time, Jasper. Yeah, thanks J. Thank you guys. It was great.