right out of the bat I'm having issues.
I can hear you're soft. I can't hear Jay. I'm not sure if he's speaking.
Alright, we've got order man up here now. I think Jay is having some issues with his audio on the secret network account, so give us just one moment.
I'm not sure if Jay is going to get his audio working, so I'll go ahead and get things started. Welcome to another secret spaces. This week we have Ethan Frey from Confio, as well as a soft from Secret Labs and Erdemand from the Secret Agency. You guys want to go ahead and introduce yourselves starting with Ethan.
Hey, what's up, nice to be here. Yeah, I'm Ethan Fry, I invented Cosm wasm. I started up three years ago on that thing and I've been full on it since then before that I've been another three years or so since I've
2017 and the ecosystem working early versions of the Cosmos SDK, IBC white papers back in 2017 and lots of other check out there.
Awesome, it's good to have you with us. I'll see you on the next.
Hi, I'm a sophomore, I'm a Codero Perl Secret Network, working with Secret Labs. Super excited for today. It's an easy person I look up to in the quest
my ecosystem. Wherever I go is there. I always see your comments on all tenderman issues whenever I want to implement something in our chat app. I look to see how
you did it in wasmd and even the other day, the isrlare popped up for me on twitter and when I went inside I saw your name all over the committee story. So yeah really excited.
Hey everyone, I'm Erdogan. I'm one sixth part of the Secret Agency helping them with doing several educational content but also trying to help anyone on Twitter whose lost helping them understand Secret Network.
Work with the solve and secret labs on creating certain seconds, which also includes the developer documentation. So do you ever have any questions about the secret tech stack, the functionalities of IBC, then hit me up on there?
Awesome, great to have all of you with us. Before we get started, I want to mention we are distributing a secret badge for tending the secret space as usual. If you check the pen tweet, you should see it in the space. There's a
link in there to stash and that's where you can mint it. All you need is the claim code which is IBC, just three letters IBC and with that I'll hand it over to a soft and we can get started
Cool. So, it and you've been called like the father of Cosm was in. So maybe just to start I would love to hear like how Cosm was in Canterbie, like for me all point of view.
Sure, yeah, I actually think me thang my song for that one that that now my cherry was like the founder inventor She's father and thought that was awesome. So um, so yeah, it was a hackathon. We I mean it was a hackathon in 2019 pre pandemic right after causes hub has launched You know, there's nothing that really
And also like just the design of Cosmiles and the actor model being able to integrate how you abstract the rest of the chain all these design decisions you're making discussing and I thought it was great because you had really like a bunch of architects together in the room and it was really more like this SDK on a build. You know I worked on the region on SDK back like 0678
I went on my own as a called Weave, which was like full part of a first and you know, whatever, like, like, proof of some stuff in JavaScript clients, you know, before Cosm.js and everything, it was this, you know, written out in 2017, 2018, 2019, which I liked and was practical, but it's still, you know, I felt like Cosm was for me, even better, for composition.
It was really a beautiful composable mechanism. I enjoyed it very much as infrastructure, as design, as building it secure first, but super composable and modular. I really just enjoyed it and just have gone full in that and dedicated myself, although my job and said I'm using Build This, even if there's no funding and eventually funding came.
Wow, that's really cool. So, like in the end, at the end of the hackathon, what was there for Cosmasm? Like what was working, what was not working?
Well, we could compile a contract. We were a contract in Rust. It was able to receive tokens and send tokens. It was a simple escrow. You set it up and you set, you know, Arbitr and a recipient and you send tokens with that and then as a
some point the arbiter could either return the tokens to the original sender or give them to the recipient. And so we had that creation of a contract. We had uploaded in the code. The code size was about two to two and a half megabytes at that point. We didn't forget to optimize it. We had we could upload it. We could instantiate it.
multiple copies and we could call this contract and we had a UI for it. So yeah, Yehan from Theo's working a lot on the Rust stuff. I worked a lot on the Go stuff. He much better Rust knowledge and factored out a lot. And Yehan and Pablo from the Connector's also on the team and he was knocking out UI, which is awesome. And then we even like,
You know, after we submitted it before the presentation, we decided to go make another contract, so you're like, modify this contract and upload a second contract. It was just like a cop cut and paste stuff there, but it was cool. It was cool. We did some changes to it, and it was cool to see that you can actually knock out an hour. But it was, yeah, simple Esco contract. It was able, it had lots of functionality#
built CW20 with that stuff we had basically. Everything was raw storage, like we didn't have any, there's fancy wrappers around storage, anything, but we had the raw byte storage. We had no queries, couldn't call it the modules. And the only thing you could do was basically call other contracts, I believe, and move tokens.
But yeah, that's plenty to start.
That's really impressive. I know the internals and there's a lot of code with memory management and stuff like that, but came into that and show. And in just a few days, that's really impressive. And also, it's funny because we are
I was still using the SQL contract in our testing. Like, I'll see how I use that SQL contract for some tests. So yeah, that's funny. Yes, my hack was some contract added on there. The hack item contract. It's, yeah, it's there. It's going to save everything.
It's the basis, the basis of everything kind of. And I mean, the reason we caught corners there, there's no gas meter and infinite loops in our code, right? There's no restriction anything. It was like, you know, it worked, but you know, I didn't get a brick of change so easily with that one. The main
The thing we did is we didn't have our own FFIs. Later we had to build our own kind of Rust library with lots of custom callbacks and do integration to much nicer and have gasminating their determinism checks. All the other checks in there in the Rust code, tying and customizing the Wasmer VM. At that point we used a simple go binding as a head and it worked.
It works somehow. There's some remeber leaks in there. There's no customization. There's no gasmeering on it. But yeah, I mean it ran. So it was definitely really go a lot further to to productionize it over the next year. But I would say even by, you know, I was dibbling in a little bit for the
I think it may be October, Cher had an September and you had an October, I think, or September. And that was pretty impressive for me. Like, see these two chains actually go live within a year, basically. Yeah, we had it on September. I'm then tell like when they think two weeks after us, like I don't even
know if they did anything. They just I think imported your code. But here we rewrote the was a engine to walk inside SX. So yeah, it was a lot of work and was very cool when it finally worked. So
Yeah, thank you for that. Yeah, totally impressive, totally impressive. So what you're doing now is this one zero. I'm very excited about this one. So I know you guys like the OGs in the space. In fact, by the last man standing, I think in the cause of awesome space, I know you customize your own VM there and using wasm I and stuff like that.
It's cool, but you're actually compatible with Cosmos and Contracts. All these other contracts out there can use it the same as decay. The contracts themselves run the same way I think mine is iterative feature, which is optional a lot of these things. It's really cool. It's really cool that it's like actually is compatible as possible. It's spent so much time to actually
And now we have on zero, just like all these new contracts out there, basically opening up to using these out there. So I'm curious about you. Like, is it fully compatible? I can just basically take my, do you need to change anything? I can, and like a little bit, I can just take my Cosmolzon contract from Juno or from Stargaze and stick it on secret and something to private clients.
contract. Yeah, it's just a work just like that. And yeah, what are you excited about seeing coming over the secret? Yeah, so we do have a was a my instead of was now and we tried to keep like all the APIs the same. But I think like
There's one thing that we couldn't hide from the contract, which is when you call another contract, there are sub-messages, you also need to know the code hash of that contract because we use that in the encryption scheme.
like the call hash of the receiver needs to be used in the encryption in order to make sure that the receiver contract is the only one that can decrypt the message. So when you call another contract, you also have to specify
the code hash and then there's no iterators which I think was a mistake and we are going to implement it soon after the V1 upgrade and then there's also no contract integration which we are also going to implement soon but at
than that yeah I think you can take like a Juno contract and maybe with minimal alterations right on secret like obviously I think iteration is a big like feature and a lot of libraries use it so that might be challenging
to like port those libraries without the iterations. But yeah, it's like I think 98% compatible, 99 maybe. Cool. Yeah, I mean the iteration, if people know I'm listening in, what is this right now, you can just read in a view of
key, you can read the value, right? Like if you say show balance, there's person you can find it. But if you want to walk over all balances of all people, for example, that's a iterator. And some things, and you can order a descending order, a descending order, scan it is basically a prefix scan in a database.
So anything that was not generic blockchain, we kind of left this feature flag, you could turn on or off. So by defaults on, you can turn off iterators, blockchain projects don't need it. So CW20 doesn't really need it. When you transfer tokens from A to B, you just need to buy balance and you're balancing adjust them.
check one single time with the config. So those are the things that don't need it. And there's a nice query showing on my tokens. There's more complex contracts out there like the Dowda voting contract. That's actually one of the coolest ones I think out there. I'd love to see you guys playing. Jane, and what it does it takes
snapshots often of the balance. If you want to say, hey, what is, we can put a lot of very, very powerful features using it readers, for example. If I want to say, show me the historical balance of this address at this time. Well, I could go through it at time. I say, I'm going to take a snapshot. I could take a snapshot.
and copy all the balances of everyone over to another data structure and keep that for the future. That's really expensive. It can be thousands or millions of reasons. Depending on how people, that's like you can't allow arbitrary blockchains, you can't order anything. Only order one, constant type. What we did and how we input to that was it wouldn't do anything. It would just mean
from that point of the death. So if you change, so you take a snapshot time X and if I change that value after time X, I will store a diff there. Say at height, you know, 17, you know, height, why it changed, right? And then I want to find the, the,
the value at time x basically I say I will iterate through those changes from my current height backwards to that height. I will find the most recent change if there was one which is the new value right or if there was not or no I said the
the first change after that height between mine. And if there was no changes since then, then it was actually the current value. Right? I find the first change, and if it wasn't one, there's the current value. So we actually have to use iterators to get. So it's a very lazy snapshot, I call it. I think it's a very, very
powerful data structure, but it does require iterators. And so you're not either as you think of it under the hood completely, but it's actually think very powerful one for voting. So yeah, I'd love to see that. I don't know if there's possible iterators here, but that's really like that one thing, a snapshot map. And second, indexes, which time do you need it?
So yeah, it's totally possible our logic like back in 2020 was that Using iteratals the contract can expose like data of other users and
But that logic I think was flawed because like if you're the contractor, if you're the contractor, there you can implement it however you want. So, so yeah, we're gonna implement iterators. I think the major issue right now.
that are encryption scheme, did not take that into account, so maybe it's going to be harder to implement ordering of keys and stuff like that. We'll figure it out. But yeah, it's not very possible on Secret.
Or you could come up with another implementation of snapshot map that doesn't require iterators. You have another trick that doesn't use iterators and then you can just drop that in like some paddled map and then other people use it because that's really I think the biggest user error seen there's a lot of
help requires, a lot of help requires that use it, which is totally optional query helpers, right? Like show me all of these people, right? You know, over them all show me all the proposals, which is not needed to be done in an off-chain database. It's not actually needed for the logic, it's needed for clients.
But snapshot map and secondary nixes are the ones I see that actually used for the main logic. And so the other way of just basically implementing other implementation to those using a contribution scheme. I feel like once you have those snapshot map and the secondary nixes,
Even the different implementation of them that has the same API, you'd be able to really get a lot of those contracts out over there. I mean more powerful ones. So the simple ones don't need all and the more powerful DeFi ones and those Dow contracts really do seem to use them.
And that's a good feedback. My thinking is that we wanted iterators because we want to use library data written for Juno and Terra without writing them without iterators.
to reach feature parity with them. But that's a good feedback while I'll take a look at like snapshot map. Thank you. Basically, you have to change the code anyway a little bit. The change is going to state.rs and you change it from import, causal and plus snapshot map.
to import secret plus snapshot back. Right. And suddenly it's one that doesn't use your readers. For example, if you, that might be an easier way, right, just not. You won't allow everything. You won't allow some, some, some helper functions, but a lot of the stuff is niche of clients anyway in like back ends. Um, but anyway, I only go over to IBC. So I
I think it is one thing, I see that you know, I really see like with that your full feature parity with those things. But I think IBC is really cool because so far you've basically had a token IBC right? So I think one of the biggest use cases secret as I know is
I will have a token on my chain, Juno is most is Adam ever and I say I want to swap it with privacy. So I'm going to send it over to secret and then there's a SNP 20 I think and then when you're SNP 20 you can stick in a deck right and so maybe you can
go into that one, how you see now it seems like right now is you can kind of take assets from other chains, put them in secret and then some kind of secret network and then kind of like, like, like, like, so maybe you can explain how that's working now and maybe how you're just evolving the future.
Yeah, so SNP 20 is like our version of CW 20. It's a token with private balances and transfers. And up until now we had only the IBC
transfer up. So you could send like a journal or small this or atom to secret and then wrap it as a 20. And then you get like private transfers and
and balances on your like the general atom, Osmo. And then we got like that feedback from different groups around the Cosmos ecosystem that they're using it to do payroll.
and like the employer will pay employees using the secret token version of like a Juno atom Osmo to not reveal their salary so that's cool.
That's a bit of cool use case actually. A lot of things are like if I'm trading on a deck, I don't really that worry about privacy and stuff like that a lot of places. But yeah, if you're paying on employees and generally people are saying, hey, we don't some place are free to transparent. Sometimes our love companies don't want to show this out because if you want more employee who everybody's like fighting over salary kind of
So if you do pay your employees in crypto, it's completely transparent. Maybe you want that, but maybe you don't. And so there's no other way of like, obviously all the employees know your address. They see who's sending to who when they see all the other employees salaries. So it's actually cool that everyone can pay privately and make them withdraw when they want to, whatever size they want to. And yeah, that's a really cool use case.#
Yeah, thank you. And then there's also like we have Dexas on secret and you can trade on them. And the first I think version of Dexas on secret didn't really have privacy.
but mostly font-time resistance because inputs are encrypted. But I think we're getting a second version of Dex's like in a few months.
couple of Dexes coming with good privacy features like I'm not sure I'm qualified to go into details but yeah on secret you can implement like privacy features for Dexes and that's gonna be really cool I think
Yeah, front running existence is a big one too. Definitely. You know, one thing is to keep it known who's trading what but another one is saying basically the no-no-till after the block is committed. Who will trade what, right? I'm so known as running your stuff. I think for me, I be see country
So if you saw me at Seoul or you've talked to it in Korea, you would have probably seen me just blathering on about IBC from explaining how to build a contract and how they're built to the future of the interchains, to how to compose and what multi-chain composition means for the future of the interchains.
for new protocols and competition in the interchainspace, a belagia, for example. So I've been really, really hot on this. I mean, I got Red Pill and IBC to end of 2016 and I've been kind of waiting for that one. And now this has really come out there. So it's not just ICS20, it's really like interchains accounts, interchains queries, and
Cause on contract so I'll just give you a brief overview of where I'm coming why things amazing so Right now you can move tokens is pretty cool their bridges to right with this allowing arbitrary contract calls so energy accounts less you like calling the contract another chain Basically, right, so you have another account. So I have a you know either it's
A Dow, for example, my chain or even a liquidity dex maybe wants to do something else and maybe the dex decides to, you know, whatever balance is protocol by swap again different decks. I don't know whatever it can do something another chain, right? Any any any account and the contract can control an account of the chain and it was in a message
So the chain over in chain accounts and it will be executed over there and get a result back. So there's some issues you need to be able to, it's worked. It's implemented. There's issues usability, especially in composing it. It works well for the state where you're doing like manual governance on it. But if you want to compose it and actually stick in the workflows as a prunive in higher contracts, it's some issues like lack of#
You don't know if it failed, you see it on the chain. You actually have an off chain client watching it to see if it failed or what it just did. So it works fine for like the governance values case maybe, but not for these other more complex ones. So I was going off and like how do you make this better, right? And so I've had discussions with the
teams technically, but also is imagining how you can iterate it. And I found the problem with IBCs, they've been very methodical, they've been very good primitives, they're very, very solid building blocks, it's a wonderful foundation work, but they're not product team. So the IBC teams built these amazing foundation projects just
super stable and strong and built on top of them is not going to fall down under you. Not like the other bridges that fall and get hacked. It's like the super stable foundation and they build pieces as super stable foundation, not as products and not product life cycle. But if you say, hey, they do 95% of the work. I actually only want to do the last 5% on top.
So we can do an app logic that's a whole other speed development. And I really think that's the future for multi-chain applications. So what you can do with contracts now, and this is, you know, we're able to do this for about a year now. It's only interesting when you have multiple calls on change really.
You can launch a cause of a contract on a chain that speaks IBC directly not like just using ICS 20 times for it speaks on protocol and you can launch a contract on no right now genonus Moses for example and they can have their own protocol own packet format speak back and forth they could talk to each other and so with that I built energy and
account says two contracts. One contract calls another contract, right? And it's a different wire protocol than you can account for the same functionality. And then we said, hey, let's add some stuff to it. And it was really cool to see in solar and the hack item. I showed this to Jake Hartel from Juneau. He thought it was awesome. And in the course of that night, sometime, I don't
I don't know. Three in the morning were looking at stuff that he was, you know, started sometime at dinner time at three in the morning were looking at stuff. He had callbacks working on it, right? So when it returned, the acknowledgement came back at callback to original caller. And he mentioned queries working cross chain also, right? I went through later. It was definitely a late
I went through that latest browser another day on it, cleaning up some stuff and adding the full tests. The thing is really wonderful work. Full JavaScript test case, which is actually bringing up multiple nodes and running JavaScript test cases of actually these whole query stack working in real-known environments. So I got that whole thing properly tested in a little more clean up.
It's wonderful work and you think about it. He knocked out for the first time in a day and I spent another day on it. We have callbacks and we have entertain queries working on top of it. The level of speed, and of course, don't take that code and put in production right now. You want to review it. You need some reviews on it. But the level of speed development is such orders are magnitude faster.
that is meant for products, including need to have reviews, you can understand this stuff and review afterwards, but even getting three people to audit it afterwards is faster than kind of waiting X months until some team, which is really an infrastructure team delivers something for your product, right? The product team is owned that product, right? So I'm thinking
I say build as much as you can on these prunives they give us right use the prunives they give us and if you want to use something product specific you can just you know write your own contract to speak their own protocol. So I'm really curious to see how so this is I'm like this right I think there's a whole lot
of stuff you can do with this. Whether it's just a dow swapping on a different chain to a lending protocol, actually running a different chain, splitting liquidity between the two chains. I think there's lots of stuff you can do there. Now when it comes to secret, you don't just have
just another chain is more or less identical that might have different protocols there, but has actually fundamentally different attributes like the privacy attribute. So actually, maybe I'm detecting some sort of protocol and part of it as well as a bunch of something I want on Geno because
I like their dow stuff and it's part of it while it's Moses because I want to integrate really tight with their decks, their AMM, and maybe part of it I put in secret because I don't privacy with this part of it, right? And I can architect now my kind of application on three different chains and just connect them with my
I think this is like this space, huge space of design, which is opening up now. I'm super hyped on it. I'm trying to help people learn how to build these things. I think it's a huge problem. First, architecting design protocols and implementing it.
relatively quickly, but the whole design architect of it is quite a bit still. So I'm really starting to think one of the big and there is understanding what you can do with it, right? What you can do with it. So I'm curious of how you see secret effects working in this world.
Like what protocol GCN secret working and how do you see them working other chains where like the actual messages sent to the chain is not going private of course. So and how that brown how do you get the what parts go in secret and how that privacy boundary will actually be able to use and compose these multiple chain applications.
Yeah, like what you said really resonated with me. I'm I'm hyped to about IBC contract and like I guess our first use case that we discussed is offering like random number of
worker on secret because you can store like private state, you can store private entropy and generate random numbers on secret and then offer debt to IBC contracts to the interchange.
Same as how a chain link walks on Ethereum. So that's one one use case that we are discussing. Another one is you mentioned it
like offering private voting for example for Dow Dow on Juneau. So how that would work is there will be a private voting contract on secret that just added the votes.
and the ports back. And then on Juneau the user will encrypt the vote on the client side and then broadcasted to the Dowdau contract on Juneau which will
just relay the encrypted vote to secret VIBC and then on secret the contract will tally the vote privately and then at the end of the voting period the Dow the Ocampurton Juno will trigger tally
which will then report back to Juneau, the final result, like yes, no, yes, 60% no 40% of stuff like that. And I think that's a really, really cool use case, especially in cosmos.
And on secret we have pilot voting for the CFI DAO for like over a year now I think and the votes are really more balanced compared to the votes on
like native cosmos chains. It's more like 55 or 45 and less like 98% yes, 1% abstain, half a percent no, all stuff like that.
But yeah, I guess there are a lot more use cases that I'm forgetting. Should I add some? Yes, please. I think just a quick invention like what Ether Air was mentioning is basically it could change
So, I think this protocol, like I imagine, an application which is launching not on the single chain, but it's launching basically on IBC. And we see this coming already with some applications. I think Morris is doing it and some of the liquid thinking protocols are also thinking about launching on every single
chain and then able to see. So this is really going to bring cool things but maybe to get back to some quick use cases one could also think about the private liquid derivatives. So currently the only tokens or only coins actually that you can bring to seek
are native coins, you can bring all small at Juneau, basically all those layer one coins. But after this update, you would also be able to bring in tokens. So CW20 tokens can come onto secret and be their own step 20. So there are two options in
in which we can bring liquids taking the refitists for the entire cosmos, but to thrive it to secret network. Either, for example, Quicksilver or Strides could one-on-one integrate with secret network and say, "Hey, all our derivatives, we will actually issue them on secret." So even though
The entire minting logic is not launched on secrets. What we do is we transfer the tokens immediately to secret network and you can get them there or we will have a separate account for you that controls them on secrets. And that way all your tokens, all your liquids,
the other way would be if something like a shade or polymer finance or another debt on a secret network actually issues their own liquid staking tokens for maybe at a more or Juneau they would immediately inherit all of the SNP 20 privacy details they would
have a private way to stake your tokens, which is not really possible at this moment on any other cost-much chain. So I think that is really a cool use case as well. And I think that myself already mentioned you get private voting, but one that is often I guess sort of
not completely understood or not thought about, an interchained exegregator will be here very soon. I can't imagine the liquidity on those mozes, June or Swap and Secret to be still for much longer, but there will be an app which just simply calls contracts to all
the different chains and uses all of their liquidity at the same time. So I'm really looking forward to chains going, it's not really a per se privacy feature, but to make sure, basically to implement aggregated order books or aggregated pool liquidity across IBC, which will make the trading experience
experience for all of us probably a lot each. Awesome. Actually, it's a nice break down there. I just was like, call yesterday afternoon with a deck aggregator, which is spreading multiple chains and asking me how to orchestrate the intersting accounts. They have like, they're running a multiple
multiple different chains in that chain. But let's figure out how to agree over multiple chains and how to do that. And actually pointing out some issues in the current IBC protocols, they don't work with it, right? Like you probably want a one-packet swap message. You don't want to say, "Move token, wait."
Try a swap, see if it works or not, ask your money back. It's too slow for your Dex aggregator. They might have moved too much. We're discussing various things there. I'm sure multiple projects work on this right now. I'm having orchestrated.
And speaking of native multi-chain stuff, so besides doing the infrastructure, I'm also launching, well, co-launching, one of the founding team of Wind Dow, WY and D, windwithaway.com, and it's
Basically, the Dow and Juno, and we're looking to basically as a Dow that should be controlling many things and many chains. We'll launch multiple, it will launch multiple DeFi products on little chains to connect them and ideally we'll have something as secret as well, right? So I'm looking at how to orchestrate that and how to do that. So we're discussing that right now, and right now it's basically just optimizing the governing
the token distribution stuff so far. And then how to do it if we launch a protocol on the chain, how the governance level one chain, the protocol of another chain, how to handle that, it updates to it, the revenues, how did stuff like that work, how to integrate these two protocols that want them integrated between chains. You move the token and then do it there, do the integrate how. So I'm definitely working on that.
I'm really excited about that. I've seen what Mars is doing with some blockchain accounts. A lot of these are doing that. I see they're doing the first step, basically, of using inter-genic counts to control another chain. I definitely want to go a few levels beyond that one. Also take advantage of these features. It'll be awesome to say, "Hey, this has taken
And how privacy feature on secret and integrate those together into one, and work on that. And if you curious about it, check it out online. We had an air drop. We are launching the Dow in a month or so.
up but it's definitely for me in a way of like applying this theory in the real world and I'm sure a lot of people are applying this theory and I'm talking about the team's doing this so it's really really exciting space. That's really interesting. Like the plan is to have a set of contracts on Juneau that
control other chains. So for example on security you can use interchain accounts and IBC contracts to talk with them and on other chain without causing more than you can use interchain accounts. Like is that the plan? Definitely we're focusing mainly on cause also change first we can write
Custom Protocols both sides. We'd support Adam Legacy and I don't know there's much there except Staking Deutaves really right so there's probably some support for doing that there but there's not much on Adam really. It's like what do you compose with an Adam right it's not running like you're taking off the decks off of it and they'll have ICS which you get an investment so it's taking on it right so there's not many apps#
So we'll probably do that to lower the priority. Everyone else wants to just stick at them, right? But like I'm really interested in Cosmossum. Basically, you can do more interesting when you have Cosmossum both sides and the contracts on both sides of IBC. And you can evolve that protocol. You can do all kinds of interesting stuff. So I've given an example before on the episode center a while ago.
And it's really good decks. So we're not building decks. I'll just tell you straight up. Wind protocol will not build a decks. They're two people building decks is I'm not competing with anyone that deck space. We're not going to build any decks is but if I were to build a decks and I wanted to multi-chain it out there and maybe you know as most is hearing this and goes, "Haha, we're doing this now."#
someone else. If you have a debt on a chain, it has a lot of liquidity. You'll launch a second debt on a second chain and it has very little liquidity. You have your brand name, but you don't really have any liquidity. How do you handle that? The price is wrong. Imagine this. Instead of building an internet calendar, we're going to actually build
a branch, we're just not going to copy it, we're building a subsidiary branch on the Unchain B. And so the parent decks will launch a subsidiary branch. Now that branch is actually controlled, they're the own authenticated protocol that communicates between these two chains. All is between the parent and the child.
Not any arbitrary user, just the parent and child have their thing. They say, "Okay, this contract, this one connection, one channel is made, and we trust this one channel." The parent can then send tokens down that to the child, right? A small percentage of liquidity and price feeds. So while the price is relatively stable, it can move like 1% or 1/2% of liquidity of the parent
on to the child and give a price feed of what the proper price is. And the child can basically trade at the price with a small slippage in that little one and a half. You can calculate basically the parent has X and all just have the little difference on mine. You can do that. As long as you're roughly stable, it will actually work. You would get a slippage of the parent chain.
It will not out every minute or so between the two of them and you will basically get the benefit of using a Dex with effectively super high liquidity on the child chain. But you'll be able to trade more than 1% of the total liquidity in a swap because we have only some
there, but as long as you're trading within 1%, you will get the slippage and the low curves and everything as if you had the huge liquidity. If there's a big run, well, people run, the price drops, will run to 1n, it just runs out of liquidity. And then it waits for the paired updates to new price feed to do something and it will balance the liquidity out later and then get new prices. So you will stop a run#
run because it doesn't have much more money. And so you can do that. And so mostly you will basically immediately be able to say, Hey, I have my dexidylastic quidion chain A. I will make a subsidiary on chain B, which is act as effectively to all the same liquidity I have in chain A. Right? That means that parent will have to trust the child. The child will have to trust the parent. Right? So#
And they're not just two non-trusting protocols actually one protocol that's effectively running on two chains because the trust boundary IBC is not the trust boundary often you say okay I am One account on train a talking no the count chain v and they're they're foreign things right there's a trust boundary is the IBC boundary and this case IBC is inside the protocol right
So there's no trust boundary there. It's actually like trusting other side is me. I am the other side. It's just like if I have a protocol made of three different contracts calling each other, they trust each other. This is the admin contract they can do what they want with me. We're multiple contracts making one Dow. It's clearly with trusting each other. But then these other external ones are not part of the Dow. Well, we don't trust#
So I think there is this huge potential there actually. I think and this is really what I look forward to once we figure out how to go begun token transfers engine account is really saying let's make these protocols are kind of authenticate protocols. So we have one protocol that spans two or three different blockchains and it actually like
Parts of the contracts are calling other contracts are part of themselves, basically, part of one protocol. And the trust boundary, one application basically is running parts of the application different blockchains with the trust boundary not in IVC level, but with the user interactions on different blockchains. And IVC is fully trusted. So I think there's a whole other way of architect applications. Yeah.
Yeah, wow. So as long as you trust both networks, you can say that the app is secure, I guess.
I mean, yeah, if you assume, first of all, that we've audited both contracts on both sides and they're by the same organization makes them both and should audit and both. And that's of course either contract is hacked same ways. If you have three contract year lending protocol and even got
hack your lending protocols hacked. And if either chain is hacked, yes, then you're broken. So you probably do want to show both change or stale chains. But like, you know, those are both the chain hacked is pretty, pretty far fetched. Want to see more more of the code hacks happen.
So yes, you want to be a little careful there, but I think it's definitely, yeah, it's a little bit of risk there, but generally as long as you do a proper auditing and a little more auditing than you would in normal application, I think it can allow a whole new class and whole design frame.
That's a very very cool idea.
like having an AMM with branches on other chains.
Hey guys, let me interrupt real quick. Sounds like a good stopping point. Maybe this is usually the time we open it up for questions from the audience. So if anybody in the audience has questions or Ethan or a soft go ahead and start raising your hands and we'll get through up on stage. But in the meantime you guys keep talking.
I'm really thinking about like this is my framework mental model I kind of explained right so that's why I'm building out there and building tooling for
I'm happy to help anyone build this stuff out there. I'm using a window and one thing I'm thinking of is how you build these things, right? This branch models one idea and so I think really
Moving parts of it to the place they belong. So like if I have an application, I don't need to hold in private, maybe only part of it. So I like the idea of the voting app, where I like the idea a lot. I think that's amazing. So if you just have like the voting aspects of it private,
Maybe this is part of it. Maybe you'd actually have a sub-dial, the wind would say, hey, we've a sub-dial, the last private voting on secret network. Then we trust that fully. Basically, we'll have full control of that beside something. It will then be treated as a full vote.
You might be able to delegate some voting modules. This is actually a good thing in the Dowdow stuff. You want to give multiple voting proposal types. We could have a multiple choice proposal.
So you can have a gate proposal and if any of them vote on something they could execute transaction with the same address. So you could have a public vote and a private vote thing that certain aspects we can control private votes, which is very interesting.
You know controlling multi-stake like so if it's not like okay who thinks we should you know launch a stable coin on this channel or who will think she's launched Oracle service or what right like that's maybe it's public is good but especially if it's like censoring someone saying hey
Who's appointing the people to this chain to a subcommittee who things we should withdraw their powers here or like make critical things especially things are like unpopular popular like revoking some permission or moving some protocol or blacklisting something maybe that should be a secret but
So maybe there'll be like, I have one sub voting module that we've done secret for the secret vote. The need is secret. You think with these important things you want to keep secret, put them over there. And I'm trying to wonder what other things you mentioned. The token swap thing, I think that payment is really interesting idea of having like their payment, outgoing payments actually manage and secret.
So I'm trying to think how that would fully work because if you've initially encountered the actual message is not encrypted or how you encrypt it. So I'm trying to architect it. But I think it's definitely cool to say, hey, these fragments of our large application vision should be secret and we just put them on different blockchain. No problem. We have this extra power.
But yeah, I'm not sure. How do you see moving secret stuff across fools? If I have a Dow on, do you know that wants to pay out a bunch of people, like getting secret, those secret payments can happen on secret, but how did you communicate it? It would actually have to like, encrypt the payment instructions.
off chain and then vote this encrypted blob on Juno then cryptoblob they get sent over the wires IBC encrypted blob and then it was received on secret and that one it can basically be decrypt and executed in that trust environment or how that work in your mind. Yeah, kind of.
you just can't have the public the private information on the sending chain. So if you're speaking about Juneau, you can't have like the payment info on Juneau, you have to encrypt it before it reaches Juneau.
otherwise it's not private. So you somehow have to encrypt it off chain and then via journal pass it to secret to fulfill the payment. Yeah. In my mind, Alex.
There are two options, I think. One is what you already proposed, which is what if we make a trusted setup where we encrypt the data off chain, but the contract on secret is in to know what is going to happen or what the encryption key is. So then on the chain, everything would be private.
it, but off-chain there is someone who knows what is going on because they have access to the key. And another way to potentially do it, which is I think something, something but number I is actually working on, which is setting up sort of a batching contract. So you would be able to
If more, even enough users want to pay out people from Juno via Secret, and they don't mind the exact timing on where this payment is done, what you can do is do something... It's not similar to "Tornado Cash", but a little bit different in the sense that
You can send all the info to secret and on secret it will just wait for an arbitrary amount of time or even better, you send a code with the information on Juno to say, "Hey, you can claim your tokens later when enough time passed."
Then, when an off-time pass, an anonymity set grows over time, the user can go back and claim it again on Juno, but it will come via secret. As long as this code never reaches the unchanged situation, which should be possible using a relay or operator structure, you actually gain a transaction
a traditional privacy protocol, which is working on Juno, but it's leveraging secrets. But the timing part is very important, because otherwise chain analysis would reveal that one user on Juno sends something and then another one got something, and you can estimate the amount of time it would take to pass through a secret and you would potentially know what is happening.
So I think when you incorporate privacy features into your app, you have to first think of the privacy model. So for example, if you want to do private payments, you need to decide
First, what's private? Like the amount is private, the recipient addresses private, the recipient identities private. So for example, if a DAO on June 1st wants to pay Bob, I don't know.
10 atoms. So maybe we know the identity of Bob, which is Bob and the amount which is 10 atoms, but Bob can encrypt the secret recipient on the
on June and send it to secret and then on secret you will get that 10 atoms but to an undisclosed wallet. So that's just an example.
But yeah, maybe to also circle back up it, I think like private voting is very very important especially in democracies. Like, up until now on Secret, we could offer
privacy as a service for payments mostly for other chains but now with IBC contracts I think we will see that we like privacy as a service on steroids because the
The velocity that you can develop because it was on contract is amazing. So it's hard to I think think of use cases right now, but I'm sure that in the coming months we'll see a lot of
If we cordial cases with privacy and like a against other chains pop up. So I'm really excited about it and especially the private building. Yeah.
Maybe a quick comment for anyone who's still listening if you want to better understand some of these use cases and see how they work and read that out in a small article or blog you can actually check out the secret labs with their I think that post is three threats over
over the past few weeks on different juice cases, voting, random numbers, and I think while that won all the run, you can quickly just check them out and see if you understand how privacy as a service basically will work over IBC will probably help understand some of the nitty-gritty details if you're interested.
I think the random number of the servers is also pretty cool thing. Longs don't need it, another team doesn't need it right away. But it's okay. We will, you know,
Like, what's the thing? Algrin is using partition or something or whatever. It takes a random subset of 10,000 possibilities and you can take a random subset of 100, right? So you're like, on your right away, we just say at block height, you know, 50,000, we send a message to get a new random number. And when the request comes back,
Whatever that number is, we use that one aside the next group of people. Right. And to sure it might take it a minute to get the answer back. Doesn't matter. But the number could not be influenced by anyone else. Right. No, we're getting influenced what the number is. So that's a really, really cool use case. Actually, you can build. Having this random number of
pinger is a really cool feature too. And the voting is well. And these are things you can't be done by IBS token transfer, right? And if you're really doing it effectively, trust me, multi-sake to give you the random number, which is pre-laying. And with IBC, you can write a simple protocol saying, I, you know, query random. And it's
Basically, the trust boundary is like you have a query contract on chain X, you're receiving contract on secret, and then the values of both chains. So if either chain is forked, they can cheat you.
And the chain of fork of chain is pretty screwed anyway, right? So as long as neither secret nor your other chain is forced and this contract aren't hacked, there's no one else that influenced it, right? So all these other ones like chain like a lava is basically I think just a multi-sign in the end or some conquer oracles, magic oracles is basically just a bunch of staked
people, you know, we have a, however, a weightless system, people, they've staked money on it. So I think having actually IBC protocol delivering random numbers is a very, very powerful thing because it's like the natural secure thing of actually having random numbers in the blockhead itself.
And people really underestimate the amount of applications which use random numbers. I mean, something like a gambling app like Raccoon or a game or I don't know, those are maybe the same for use cases people think.
about, but even on a contract level or indeed randomizing certain inputs or choosing who proposes a block or stuff like that all requires random input. And the random numbers which can come from SQL network are really secure simply because you have this private enterprise. So look if
forward to if it's a very simple solution and it's just as much adoption as a chain link then it would be a really great surface for the entire ABC. Yeah, whenever you want to do a fair decision somewhere in your contact,
need randomness. Like on Secrets it's instant but I think with IBC we can like nail down the chain link UX which I think is the best you can get. If you're not like if you're not getting that
number in an atomic way. So yeah, random numbers are really cool. That's a really cool feature of Secret Network that not a lot of people talk about. But against with gaming on Secret we're going to see that very soon.
Well guys I hate to cut you off but we are at the top of the hour and it's typically where we end our Twitter space. Ethan's is great to have you with us. We might have to have you on for a future space after our Cosm wasm v1 upgrade is live and maybe we start seeing some
these new use cases, take effect. It might be fun to have you back and discuss some of these things again. I love you back. It was a great being here and good talking to you, and happy to be back. And you guys follow me on Twitter if you want to, and I'll be dropping some more knowledge I've been seeing from time to time.
Sounds good. And we'll be back with Secret Space next week. We will be talking about the upcoming Missouri and Cosmoverse conferences. So make sure you're here for that. Thanks everybody for attending. We'll see you next week.
Thanks for having us. See you.