CosmWasm – The Smart Contracting Platform for Cosmos

 

Brian Fabian Crain: I am Brian Crain, and today I am speaking with Ethan Frey, who is the founder of CosmWasm, the founder of Confio. And we are going to get a lot into what that is and the kind of impact it has had.

Ethan, it is great to have you on.

Ethan Frey: It is great to be here. Thank you for having me. 

Brian Fabian Crain: So, Ethan, we have known each other for quite a while, it has been five and a half years or something. So, we both joined the Tendermint team around the same time at the very start of 2017.

We were something, there were maybe three or four people before us. And then there was basically two of us at the same time. We were both in Berlin and sort of as at the inception of the Cosmos network. And of course, Ethan has gone on to do lots of work, especially in the Cosmos ecosystem that has gotten much traction and much impact as well.

So, I am excited to finally have you on, but maybe we can just hear a little bit about your background, how did you end up getting involved in the crypto space and in the Cosmos ecosystem more specifically?

Ethan Frey: Thanks for that intro, it was cool 2017, remembering those days and thinking about going out to some, meet up back January 2017. The first time I met or second time I met the cafe before that, but with Gavin Wood and Jae Kwon talking about multi-chain Polkadot and Cosmos and Vitalik’s audience, and it was this early day of crypto and Berlin, it was cool times. 

Crypto kind of found me, did not leave me alone. And I remember someone was pitching Bitcoin to me back in 2011 as the new money.

I saw the thing, oh, that is kind of cool, but I do not know, it does not do anything different than gold, which is not cool. I was not looking for an investor. I am like the worst investment mind did not accept any investor advice I give you of what is valuable.

But I was looking at the tech of it and I was kind of looking at thinking about community currencies and post-modern money and what the next generation of information money is when there is no scarcity and concepts like this before that, because it is kind of my hobby.

And Bitcoin for me is like, wow, you can make money on the internet. It is stable and it is real like gold. Gold is a bit old and then I heard Ripple sometime and they are like, oh, 2013 I was some squad in Barcelona and this guy was trying to turn me onto Ripple and they are like, oh that is just a decentralized Iban, swift network, something that goes fast.

And so, you can swap currencies, I do not do foreign exchange trading. I am not a trader, what can I do about it? He is like, you can swap currencies. I did not actually get into that all and it was sometime around, they kept coming back, people kept trying pitch this stuff to me, right?

And believed the technology, I did not see it because I am not a trader. I did not really get it, from the money aspect. And I wanted something new. And so, in 2014 I was at a workshop in Berlin on Sociocracy, which is interesting. And this guy came up to me, the only guy in a suit, in the whole place.

And we started talking and he was trying to invent a new program of money. And it was on blockchains for ground money with the wallets holding all the assets and you could have different community-based rules, the governance creating this stuff, this is stuff that does not exist now, he is kind of this visionary.

And I got intrigued by what he was talking about because he said you could have as a community governed rules on the money, just rules programmable money. The idea in 2014, which is new for me, I was like, oh, that is cool it can behave differently, we can invent our money. 

That kind of got me hooked on the idea of it. And so, he showed me what Ethereum was, around the ICO time, the world computer ideas, and pointing me to Aris Industries which is this incubator of Tendermint somehow.

And I do not really know how this stuff was fitting together, but somehow through that, and then you saw this ghost stuff. Looking at this code I am like, whoa, this has got to make sense. And they started just at some point I could build a blockchain Tendermint. That is a cool idea. 

So, I went and taught myself to get a job program. And sometime 2016 I started trying to build my own app on Tendermint, and there is some little slack group of bunches of other people trying to build apps and tenement.

And I still have that somewhere on GitHub. It is react sign posts, I was trying to make a blog post that would just be whatever you could blog an internet on the blockchain, with a React app and trying to figure out how to do that instead, I started working on this as the first step of building per gallon money on my own Tendermint chain back in 2016.

Because I thought that would be easy, and somehow, I started going on there and filing a bunch of bugs on Tendermint and then patching bugs on Tendermint. Because that is what I did. I was doing web dev for a while and contributed heavily back to open-source projects like Mongo and Postgre and stuff.

So, you just patch bugs and you upstream them. So, I started doing that and somehow Bucky is like who are you? What are you doing here? For whom are you working? I am trying to build my own money. This is cool stuff we got going on, he was like work for us. I am happy with my job right now.

And then two months later, I got anger with my boss. Well, he was making me work weekends and nights and I said I would not do that. So, I said, I am quitting if you make you work nights and weekends. So, then I said, hey guys, I am open. And met them in Zurich in November 2016. And they are basically red pilled me on IVC, on Tendermint, on POS, on everything.

Brian Fabian Crain: I was not actually aware that you kind of found it through Eros Industries, which is the company I was also working for in 2015 and 2016, and maybe talk a little bit about what did you work on in the time when you were, at Tendermint or at the company back then?

Ethan Frey: The first thing I did was really work in the IVL tree and try to speed it up, I did some early benchmarks and tests on it, and then try to speed it up, then things are too premature, we do not need to speed up anymore. So, I guess it is true at the time, early 2017, but now is in these bottlenecks and then moved on to try to build apps.

So, I basically took what was basecoin, which is a little demo app and tried to make a real app, clean it up, I started doing the first prototype of IVC based on the very vague spec and the white paper. I then said, hey, this lap is limited, let us build something real.

So, first person that Cosmos SDK is 06078 is basically me building it out over the summer with help from Rigel a bit, I built that out. I came up with that whole idea of the rest client LCD was we were trying to sign it. I was working with Matt and Judd from Nomic.

Now they are working there trying to build front end apps and they could not actually sign amino transactions. So, I am like, okay, let us make this little, small little rest server app that helps you do the cryptography on the server side until we have a proper JS amino library in six months from now.

So yeah, I did this stuff, so I am sorry sometimes because that got legacy code, but whatever. It was in advance at the time to allow the whole LCD rest server idea. I built SDK out there. And then that was kind of frozen for a lot of internal discussions, the SDK was put on basically hold, to be considered and reconsidered.

And then meanwhile I basically wrote the IVC white paper. So, if you saw anything about IVC in 2017 that was, I wrote a whole spec out of it, which is now ICS20. So, IVC got bigger and bigger, the concept got bigger, but then the news time was basically token transfer. So, I basically specked out token transfer.

With the idea of acknowledgements and timeouts, cleanups, stuff that rather than just having these fire and forget messages. So, I wrote a bunch of stuff, Merkel proofs, ICS 23, the client proofs and stuff like that. And some of that code is still around.

It moved up four times although client proof stuff moved up four times in repos, and I think it is in Tendermint now, if you look way back, once I was the author of that. 

Brian Fabian Crain: And then how do you end up working on CosmWasm?

Ethan Frey: I, little frustrated at the pace in IVC because there is a lot of decisions being made and they are all pretty much made in California time at which is my evening.

By 11:00 AM their time when they are waking up. I was pretty much clocking out work usually, it was 8:00 PM in Berlin. So, I was not really involved in any decision making. And in fact, no one in Berlin was really, and it felt decisions being made somehow, the SDK was basically put on hold indefinitely.

I had nothing I could work on, and a few other things got blocked on working on, so I said, this is kind of boring, I want to build something. So, I found another company that was offering to hire me. I said, cool, I want to build another SDK. So, I basically took the idea I built something called Weave at IOV.

So, early 2018 had pro buff going on there. I had a JavaScript front-end that was talking directly to it, you had basically, cosm.JS talking with no light client directly pro buff signing messages and calling them. We had multi-SIGs in there, in 2018 kind of built out the basic stuff.

Some basic groups governments modules and stuff like that were in there as well. And some basic, swap token stuff in there, that was 2018 and then towards the end of that year I realized that there was not really a business going around with this stuff.

We had a nice team, were building this stuff up. We had a business case maturing. And there is a little internal issue, let us say. And so, I watched SDK go its own pace and then get more in devs.

And, then I showed up at the inner chain. That is an awesome conference there in 2019. I am pretty sure you are there too. 

Brian Fabian Crain: I was at inner chain conversations in Berlin. 

Ethan Frey: Like everyone from the Cosmos came, Cosmos had been launched three months earlier and everyone showed up there, no one even had their own blockchains then. It was kind of all these people had their little projects, small projects, it was an amazing group of people show up there, three-day demos of conversations and discussion and then a hackathon at the end of it.

And in that I met a lot of cool people, and we kind of just come together, let us build something. And I realized that no one is going to take Weave, and I will drop it and they will use SDK again, but I do not really want to hack SDK so much but let us do something.

And, then I am sitting around on this table and we kind of got a bunch of people there floating around it was like me, Aaron from regen, Jehan who is now informal Maltea, Shane who is now at stargaze and then somehow Pedro from Wallet Connect showed up there. And we ended up like let us make a team and let us build Wasm contracts.

And let us build a Cosmos Wasm smart contract in SDK, I was like sure, why not? It is for two days, and there were basically three of us working on it. They also built the groups module kind of in a way, multisig stuff, at the same time Shane and Aaron. And then basically it was, Jehan and me building that and Pedro from Wallet connect on the front end.

So, he just knocked it out on the weekend. I did not sleep. I kind of closed my eyes for an hour, and I learned a lot of rust and Jehan was doing amazing stuff there too with in Rust. And we knocked it out. We got contracts working, it was crazy, we are uploading contracts and running them, so it was like do not push it falls over, but if you do it right it ran, it was amazing for us.

And I got super excited for that. I said, this is awesome, it is the most awesome project I had worked on in years, and this green field of building something new, and it is compatible with everything else people are using already. So that was really what I learned, do not want to fork this SDK and go off my own way or make my own version and compete.

Everyone wants to use this tooling, let us build a tooling and add power so everyone can use it and be compatible with everyone. That was cool, and I said I got a grant from that. One of the prizes, got a relatively small grant, to follow up on it and said, let us all build it guys.

Let us do a few hours a week and everyone else is too busy, they are all CTOs. It was a team of CTOs, and I was the only one that said, okay, I quit my job and started doing this, I did and three years later it is where it is. 

Brian Fabian Crain: Well maybe we can zoom out a little bit because, So web assembly, right?

I think a lot of people have heard of web assembly, web assembly has often been kind of touted as, oh, it is like a powerful platform. Ethereum, I think at one point was thinking of adopting web assembly, there were some other projects that were heavily emphasizing web assembly.

I think especially remember Definity was always web assembly. Can you tell us what is web assembly and what is interesting about web assembly? 

Ethan Frey: I was originally trying to make the web faster, which is called web assembly, but it is nothing due to the web anymore except that it can often run to the web.

There is some project called WASM.JS that Mozilla was trying to optimize JavaScript. They could precompile faster, then they basically made of web assembly, which is a VM. And I think if Ethereum had done two- or three-layers years later, it would have used it.

It is a very simple virtual machine, it is a 32-bit processor with some stack calls that has 150 operations. It is simple architecture, involves no run time, no system, there is way of allocating memory and no garbage collector, just allocate blocks of memory like expand the memory space.

I want to have access to see how much memory space you have access to and expand it linearly, that is all it has. And everything else is added as an optional import or export. If you want to expose something, you make an export. And if you want to call into experience import, and you must assume you have this dynamic that like this system did not have access to files, no access to network, no nothing.

And I think if you consider the JVM, which is the first real popular VM there, Java virtual machine that came out there. And that was basically at a whole runtime, you have the virtual machine which has a third tube architecture with the stack and pushing stuff on it and how it worked.

But also, the system library of how to interact with the system and how to interact with the files and how to interact, it is a whole position client system, an operating system, basically not just a virtual machine. And this defines a processor, nothing else. And anyone can plug in any system they want to.

There is a project called Wasi web assembly system interface, which is kind of a posix like interface. It says if we expose exports into it so they can use it, and then you can say, okay, we only give you access to these 3 files, and that is all you see in the whole world. And you can control the control It somehow. 

Brian Fabian Crain: If you compare it with a VM that people are kind of familiar with in the blockchain context, it is the Ethereum virtual machine.

So, what are the advantages or maybe disadvantages that this virtual machine has versus the Ethereum virtual machine? 

Ethan Frey: So, I said the first thing is this general purpose, which is a good and bad thing, The EVM is built for Ethereum blockchain, or a blockchain, and it comes all these pre-compiles for computes.

And it comes the whole lot of understanding of where things are called and the interactions of calling other functions. And these call methods which require blockchain, the language of VM is tied to a blockchain, you have call functions, create functions like bytecode, it is tied to itself.

It is tied to this concept of the VM, it is not separated from the run time, it is the EVM is not just a machine, it is the run time. The JVM is for one use case, and it is very tailored, which can be very good because it is tailored towards it. The bad thing is you have no tooling around it, and you have no optimization around it.

And I think we see it as being slow, it has issues. And I think what happened with web assembly is it is a very generic one. It is a very general purpose one. And so suddenly a lot of different languages start targeting it. And they said, oh, we can write C and compile that to web assembly, we compile C++, we can compile rust.

There is a project called Tiny Go, they call it Go to Web Assembly. There are a bunch of other projects that are in progress for lots of other languages. And it works best for static type languages, low level languages right now. But a lot of different languages are being compiled at Haskell, there is some Haskell to web assembly thing.

So, you can take all these easy languages, you can compile it to as a backend and they can just run at it. They run on an Intel architecture, they run on a Mac M1 arm architecture, they run on some older embedded CPUs, they can run on a web assembly VM.

I think that fact first allows those whole tooling of lots of different front-end coding, you must build your own language and your own stuff, you can use existing code. And the second thing you do is because of that interface, no one else tries to build. Other people try to build the VMs and so people build just interpreters for it faster and faster, right?

So, there is an interpreter built in your browser. There are probably two or three of them out there, one from Google, one from Mozilla, I think one from Safari. There is Wasi, which is a Polkadot interpreter, which is not legit. A lot of them will take that Wasi code and compile it into optimize local code and run it there, sandbox local code.

So, it makes it much faster, it is an optimization called just in time compilation. There were routes we use sometimes, which are two kinds of competing things, which also do either pre-compiling or just in time compiling of the code, native code and run it to get fast compilation.

There are some other ones out there too. So, there are a bunch of smart people doing it, and you are not tied to one project interpreting it, you’re not tied to one project building tooling around it. You are leveraging five, six different language ecosystems. The entire tooling of rust you can use just out of the box with web assembly.

And then you have five or six different backends you can choose from. And who is going to write the VM who implements a VM that runs this Wasi it is just a standard basically, it is a standard middleware and is not really tied to a blockchain or anything else. People are running Redis in web assembly system interface, right?

So, you can do anything in it and then it allows you to leverage this huge amount tooling and people are working at optimizing it as fast as they can. So, Rust is heavily optimized, amazing a pile of engineers, and in Wasm time they are compiling Wasm to the most efficient bytecode they can, and they gain some impressive stuff.

They are impressive pre-compiler, low level designers work in this full-time that we are not paying for, that multiple people are paying for and top of the line stuff that you are not trying to recruit them as your own blockchain project, you just leverage them. So, I think it is because it is a whole ecosystem and it is so compatible, so generic.

It allows this huge ecosystem of many companies to build, to go elaborate, which makes it powerful. At the time the EVM was launched, it was not around, it was not available, it was kind of in some way an idea stage. It was I understand it would build the EVM, they had to, that was the best at the time they could have done.

But now I see that came out later and they say, hey, this is a whole ecosystem, we can use it. And then we just customize a few things on it, the entry points, we expose the contracts, and we can run it, so PolkaDot is running a web assembly as well. 

Brian Fabian Crain: Now let us talk about CosmWasm.

I guess there is one thing that probably a lot of people are not aware of, and maybe you can talk a little bit about it but is that in cause in the Cosmos SDK. You have this concept that there are different plug-ins, you have these different modules and then there will be a module that is a staking module or a mod, the IVC module.

And you have these different modules and then the different SDK blockchains can say, oh, we use some of them, we develop some of our own, and then CosmWasm basically means like, okay, you are taking this web assembly and you are putting it as a module inside the Cosmos SDK.

Is that correct? And what are some of the consequences of putting the web assembly inside this Cosmos framework? 

Ethan Frey: You are right, there are these modules and so the SDK is an amazing plugin set.

So, you can add different modules, and it is easy to kind of import code from here, add your own code and extend it, it is meant to be extensible. What it does require though, is a hard fork every time you want to change it, if you deploy a new AMM module, and you want to add it, then you must basically get that merged into the main codebase of the code, and then get the entire blockchain to stop, switch out the binaries out there, run subscript, now it is a little more optimized upgrade.

That was a whole dump state restart, three-hour issues. Now it is down to five, ten minutes, but still to accord the entire blockchain is stopped or just restart and come with a new code to add the new module or move module, update it.

And that is a lot better than working on Bitcoin when you are trying to change it, the core logic of Bitcoin or Zcash, but it is still not the smart contract development speed. So, it makes sense for core functionality like governance and staking. But we said, hey, for smart contracts, a lot of things just add them on top.

You want to deploy them quickly. So, what we did is we do not store the WASM inside of it. We store the WASM VM. So, we took the web assembly virtual machine from Wasmer, and we wrapped it with some standard callbacks, it basically explained its place in the world how we can talk to blockchain.

So, a program can also say, hey, acquire this other part of the blockchain or send tokens over here, or call this other contract. We expose some functionality to it in a certain function to it. These are your extra special functions for CosmWasm contract on top of a normal Wasmer contract.

We built the virtual machine in the rust into a library which we embedded in a module, so it is a bit crazy. We built basically a rust library and a dll, and then embedded that into a go binary just running here, and the WASM code is not binary. The WASM code uploaded a transaction just like in kind of Ethereum when you upload code.

So, the virtual machine and the runtime is in this module, which then actually calls into every other module of the system. But the actual WASM code uploads a transaction, stores it in state, of the state, and it just loads that code when needed. 

Brian Fabian Crain: That is an important thing, right?

Because in the cosmos SDK paradigm, somebody wants to modify some plugin, some module, and then that requires changing this code, new binary, all the validators must change it. It is a lot of friction. And here the thing is, I can write a bunch of code, I put it into a transaction, the transaction gets sent, and then this Wasm VM kind of unwraps that and then it has that code, right?

And so, nothing outside must change, but now suddenly you have that code in there. And I guess that is particularly attractive, and then I guess that is also where CosmWasm has found a lot of usage in the Cosmos ecosystem is like, I want to create a general smart contract chain, right?

Where everyone can sort of put their own contracts on that, because that is something that Cosmos SDK without something like CosmWasm does not really support well. 

Ethan Frey: And a lot of things that you move faster, and they do not want the whole chain, a purpose chain to be a deck. I think they built good decks on osmosis.

They balanced their ideas and some curves, and I think it is solid. It is a well understood question, right? But now when you are trying to build stuff on top of it like, okay, a lending protocol and we want to do some leverage option stuff on it, they are like, okay, we actually want the faster CosmWasm on it.

NFTs are moving too fast, people trying to code them go NFT thing. But it is months behind space, I think things that move faster, it is essential. And so, contracts only the privilege of a user account, external account. They have no more privileges than other account than you do what I do.

This is on the code it has their own logics on the blockchain. But they have no more privileges. They can hold tokens, they can move tokens, they have different rules. So, it is great for things which are simple app logic that people want to add. And I think the SDK is amazing for things like, oh, we do not change how fees are handled.

We do not change our consensus works and government votes work. We need to change spam middleware protection and we need to implement IVC as native control, which is totally trusted, a hundred percent trusted verified code on here, which is stable and not changing the foundation for other things.

So, SDK is a great way of composing lots of different projects together to build foundational levels, whereas CosmWasm said, okay, if you want to do just business logic, app logic, not foundational blockchain stuff, let us do it there. And I think that is a great combination, you have five, six different teams composing stuff and adding things in there as modules so they can build this SDK base layer and CosmWasm say, okay, now all those hundreds of devs that want to run on top of a chain or thousands of devs now that want to run on top of a chain, you can just do it. 

You do not worry about that platform, you do not worry about who is paying what consensus and what the gas fees are, you just worry about running your logic. So, I think it allows these two things to live side by side very well.

Brian Fabian Crain: But then you mentioned osmosis does not have generalized smart contracts, it is not anybody can just go and put some stuff on osmosis. But they are also I think leveraging CosmWasm in some ways. Can you talk a little bit about it, because as on the example of generalized smart contract chain, Juno is one example. 

Probably the best-known example is the Cosmo ecosystem, where you have this CosmWasm chain and lots of different people are building lots of different stuff on that. But can you talk about the other example, where you use CosmWasm in a more controlled way, in a more permissioned way?

Ethan Frey: So, several chains have adopted a little more conservatively than Juno has. So, there are no early Adopters, Juno and Bostrom from Cyber Congress. Before that was Terra and Secret, the first ones, as permissionless. But the first one modern IBC one is Juno.

What they done is most of the same thing on Stargaze, which is basically permissioned contracts, it does not mean that it allows you democrat blood code requires governance vote to allow you to use your code, so they basically want to vet all the code on their thing. It is a way of saying, hey, stargaze only wants NFTs on there and stuff.

So, if you want to upload a project with NFT say, hey, I am building a project with the NFT. I am going to launch on your chain, they say yes, okay. And they say, hey, no, this is some defi product you will want on our chain, do not come to our chain. So, they control that first step of being able to upload that contract and instantiate it.

Once the contract is on the chain, it is permissionless, anything you want with it once it is on the chain, you basically just must ask to get in the front door. And after that runs just like any other contract in any other chain, just most of the same thing they kind of wanted, if we can experiment on Juno and do stuff on Juno and we can implement Juno.

They wanted more like a app store feel for osmosis, they wanted to have five protocols maybe on there, the building on there, they can integrate into ecosystem there, slowly allow them in there, which allows them to scale out, not a general purpose, but they say, hey, we can have five different dev teams building different projects and they do not have to get in the core code base.

They cannot break a code, break the rest of the chain. They only can build their own little project, so actually they basically just make agreements with projects beforehand, if you want to run osmosis talk to them. And if they like your project, they say, cool, when you finish it, we will let you go on there more or less, right?

You basically get permission first, and once you do that, you just write your code like you do in Juno. You go through a process to get approved to get on the chain, and once it is on the chain, then it runs anywhere else, except you have a DEX on chain, which actually pretty cool.

So, some people leveraging it for lending protocols, et cetera. I think it is an option we came early on, and we put that early on as an option and it is really being used this year. So, people being like, I want to have CosmWasm, but I want to control an app chain and CosmWasm chain.

They want to have them both best of both worlds on a curated set of applications on my chain but allow third party devs to easily extend it. 

Brian Fabian Crain: And I guess you mentioned Terra, which is important because probably a lot of people were not aware that Terra was also using calls Blossom and all these things that were being built on Terra.

Except for a bunch of foundational stuff that was part of the chain logic. But the applications people were building on Terra were built in CosmWasm. 

Ethan Frey: They were the first adopters of CosmWasm, I want to say though, I want to say one thing. UST was not CosmWasm.

UST was not building CosmWasm and that pre-dead CosmWasm on that they had a chain with UST the UST Luna whole thing treasury. I did not even understand it, but that existed beforehand, but all the other protocols, so Terra swap and even anchor and Mirror protocol, BLuna and then the whole series of Levana and Mars and all these other protocols pumping out, and they were all CosmWasm the older version, the upgrade to recent version, but it was it is own CosmWasm ecosystem except did not have IVC support. 

Brian Fabian Crain: That kind of ties into my follow up question here. CosmWasm, you have this basically kind of separate container where code lives and you can kind of things happen in there and then you have other cosmos modules for instance, there is an IVC module.

Which is sending transactions to other chains. So, I guess the CosmWasm contracts must somehow talk with these other modules, so how does that interface work and are there some limitations around this? 

Ethan Frey: So, we basically expose Submodules, is Json basically, because we saw it is easy to debug and if you complain on Json being they are not pro buff talk to Jehan.

He mentioned Json is the best way because you can easily debug it, dev tooling, but basically passed between that it calls and system with the Json blob says, hey, talk to the bank on it and we define an interface for the contracts. They can call in the bank module to mint and burn tokens. They can call into the stake tokens and delegate and claim the rewards.

They can call into the governance wanted to vote, for example, they call the IVC module to send tokens we also allow custom IVC callbacks. So, you can have an IVC protocol built as a contract and we allow people to have custom callbacks, this thing called custom.

We give you a standard set of things, but change all want to tie their own ones in there, we have an extension point that you do not have to fork CosmWasm, you do not have fork VM, you do not have fork Wasm, anything, you can use a whole framework, and this is an early thing we had early on to make sure people not fork it and said, if you want to expose a DEX osmosis, you can add a special callback to take these, we have a new structure here, which can add embed into the other message called custom.

And our custom type is osmosis message, and it runs here and allows you to talk the DEX. So, it basically defined a Json format that you can use for defining callback to your native module. And then on your blockchain, you basically interpret that to do those things, invent your own message API between the contract and your native blockchain.

And several people have used that, quite a few have used that as extension point, and I want to mention this not just in CosmWasm is not just on Cosmos anymore, it is running on a substrate chain, which I think is an impressive engineering feat, composable finance has launched a pair chain and they have Cosmos running in substrate.

And it is integrated with a bank module, it is not tied to sticky module IVC, but they just run it on. You can run contracts like a CV20 contract, and you can do an NFT on it. You can use the same contracts there, they have a different JS front end, but the back end runs the same.

They uploaded unmodified contracts onto it and run a substrate chain, which is pretty cool. 

Brian Fabian Crain: And what is the benefit of that if as you said that, polka dot already uses web assembly, so why Port CosmWasm onto Polkadot? 

Ethan Frey: I do not know why Polka dot uses a web assembly, honestly.

They use web assembly as a base layer the whole chain is running in web assembly, but the same way everything is written in go, it is rustic composite web assembly, but you to upgrade it in a hard fork of the chain and in theory can hard fork the chain without a restart. Or automatically restarting it.

But it is all permitted, it is a very complicated thing if you recompile the whole thing and then you upload these pieces, and I have yet to see it be done, flawlessly. But the ideas basically allow easier upgrades, but still government permission and basically you have one new web assembly binary, you are switching out to.

Like it is a giant web assembly project, not a smart contract. But it does not allow third party, it is just the chain developers. Same with SDK, they just use it as a target. They also have something called ink, which is smart contracting language, which compiles to web assembly, and they upload that and run that as user-controlled things, but it is not really caught on.

It existed before CosmWasm was dreamed of, I saw demos of it when I wrote CosmWasm and they looked over, I saw they had done something similar, but never really took off. I think it is overly complicated, I do not really know why, the truth is ink has never taken off over three years of the funding of Web three.

And there is a project composable, which is really tied into the Polkadot ecosystem. That had tried ink and were frustrated with it, so frustrated they decided to port CosmWasm into a substrate crate they call it, the VM and talked to us to figure it out and then make it compatible because they thought CosmWasm was such a nicer target than writing ink contracts.

I do not know if those good business choice, but they did it and they are happy with it and they are running their stuff on it and they are trying to work IVC as well, so that is cool. But I think the point was it was designed the same way that the web assembly virtual machine is not tied just to blockchains or Ethereum blockchain.

The CosmWasm virtual machine system we have runs great, we have a binding in the cosmos, and we would love to embed into Cosmos, but they have embedded somewhere else, and it can be embedded in other places well. So, it is a relatively universal target, which I think might hopefully in the next few years extends.

I would love to see an avalanche or near or something like that also running CosmWasm. 

Brian Fabian Crain: Maybe that ties into, the question of kind of where do you see CosmWasm going? What does the development roadmap look like? 

Ethan Frey: Our original goal released 1.0 back fall 2021.

And I think our goal is then to get chains using it, all upgrading to use it as an IVC enabled version of it using Stargaze IVC and all that stuff. That took some months and this springtime, I was amazed we went from four or five chains using it to 13 now it is over twenty chains using this.

Let us get people using it and the second thing we are working on is getting more devs on, and Terra did a great job of getting devs on it, Juno osmosis, they are getting a lot more devs onto this stuff. And we are working on a thing called academy.cosmwasm.com and we want to train up devs.

So right now, what we are doing is basically trying to build the ecosystem, we got the chains running it, you have 20 plus running it now, we are giving free classes, free tutorials, free tooling for devs to learn it, to really build the debug system from several hundred, maybe a thousand devs into far many more like Ethereum. 

We want to build this out and what I really see as differentiator and what I want to work on and what I am working on besides helping people building tools and tutorials for people, is IVC, inner chain contracts, I did this in sales and the hackathon, demoed it and some people hacked on it and Jake did some and some guy from Taiki from Japan did another one.

It is awesome that you can basically deploy a contract on two different chains. They talk to each other with no trusted bridges, no multi-SIGs, nothing can be hacked in the middle of them. Just pure guaranteed message passing, with complete security of IVC. And the contract just told the app logic, if you send a message says Mint Token or not, or make a governance vote or control this DAO, or change the threshold of my LP-pool thing or whatever you want to do.

It is kind of an exchange accounts but so much more powerful because you can write contracts on both sides. And that was not possible until you had multiple important chains running CosmWasm 1.0 and we have been waiting for three, four months ago it was great.

Juno Osmosis is now 1.0 and secrets upgrading very shortly. And I think those are three of the top chains behind the hub on the ecosystem and in terms of market cap at least. And they are all running objective also is another big chain. They are also running it, so a lot of people are running it now.

So, most of the changes has the hub are running CosmWasm, which means you can build a protocol that expands 3, 4, 5 chains using IVC messages and writing the entire, not just your app logic, but the protocol communication there. That is writing your own API servers and talking blockchain and blockchain with no bridge hacks involved.

And that is wise in the future and that is really where I am going to put a lot of work into, not just building up, also documenting, try to explain it, but also tried to build these things out there because hey, I am trying to build something that does not exist yet. So, it is hard to teach people tutorials to something that does not exist.

 So, I got to build this stuff first and then show you how to build it, but I have just built some prototypes out there and it is amazingly fast. 

Brian Fabian Crain: I think one thing we did talk about before on this podcast, maybe some people have heard of or are aware of, is in Cosmos this concept of interchain accounts, which basically you have an account on one chain and then you can control it from another chain.

So let us say, for example, there is a project Quicksilver, and they are doing liquid staking with that, so that this Quicksilver chain can control an account on Cosmos, it can cosmos hop, it can stake atoms, booking governance, claim rewards, do all those things and then, but it is controlled by another blockchain that could then issue a liquid staking token.

So that is an example of interchain account. Now what you are describing goes even a step further, because you have contract code on both sides where it is here, it is kind of let us say in the Quicksilver example, it is kind of contract code on the one side and then the other hand it is just a normal account. 

Can you talk a little bit about use cases, what are some of the things that you would be interested in building, or you can imagine people building these cross chain CosmWasm apps. 

Ethan Frey: So, I think in some theoretical way with token trends for internet accounts, you may be able to build anything, may be able to, and in jQuery’s if you add that, those might be funnel principles, say these are holly principles we can build anything with them, but they are inefficient to build out things.

So, I think for staking is fine because you do not have to stake that often, you can just every 12 hours maybe pull out your money and re-stake it. Does not have to go so much. But let us say I have lending protocol that is liquid, and DEX is in another chain, the existing protocols assuming these all exist, interchain accounts, jQuery’s and token transfers.

If I have a protocol here that wants to liquidate on a DEX over here, first I move one message, move my tokens over here, I will wait to get a response, do not get a call back on the response, you need a DAO to control it, and we are working with the IG team to trigger a callback when it finishes.

Then you say, okay, now make a swap with this interchain accounts to make a swap of the money is sent over here for the other token, it may have succeeded or failed. If it succeeds then I query to see how much I got, the full amount I got. 

Then call over interchain accounts, trends the tokens back to get the tokens back, and that is a lot of make a request, get a response, make a request, get a response. These are all slow requests in here has orders that do whole thing. Now let us say, hey, this is a common use case, this is not something you do once, this is something you do all the time.

Optimize that, I want to deploy a contract here and a contract here, then what they do say is, they have their own protocol, which is move tokens, swap them at this price, and sending all the results back. If you do not make that price, if the money is too low, If the market will not trade this price, they return my original funds back.

That is a simple logic, and a lot of people might want that, but we are not going to wait for go code six, eight months, 12 months to build of new Go Logic with this very specific use case, integrating some DEX on this one chain.

We say, no, we want to launch it now so we could do it now, I wrote a query we could do this very quickly and basically say this now we write these two contracts here, if you trust it, someone can say, okay, here, liquidate at this price. It will send one message back and then you get a callback, whatever one IVC message, it will do this logic and then you get a call back saying, okay, I liquidated this price, great stuff, or I failed to liquidate and here is your money back.

That I think will allow people to do integrations that you could not even conceive of.

This is faster, but then actually under conception of, I am going to give one more. So, I am working at something called WyndDAO. The first one I will throw is a demo, is a prototype and give it to you all. It is free stuff. We are doing this for everyone.

I have a query about using IVC price Oracle Osmosis is implemented. I am waiting for TWAP out there to be finalized. But the next one is the next level of deep integration. So, imagine you have a DEX on one chain, and you want to make another DEX on another chain that wants to launch a sub-DEX on other chain.

The sub-DEX own separate liquidity, it is going to have its own issue of liquidity, and it is going to be small, is not really that popular, but I have all liquidity out of the chain. But maybe I could not make a generic protocol that works for anyone, but I will make a special contract between my sub parent DEX and my child deck, which is a permissioned IVC like an encrypted or authenticated IVC connection that just runs from my parent DEX to my child DEX.

And I will move 1% of my liquidity over here, but I will keep the entire price information of all the rest of liquidity over here, is the reference price. The reference price is here, and you have the full reference price here, and that is what you use. Over here you will assume you have that value, and you can trade a little bit of liquidity very quickly, just like an ATM or a branch bank.

And so, maybe is a minute out of date of the actual price over here, and you have a little slippage here you can maybe, but you only can move a 1% liquidity. You only can pull a little liquidity out here. You cannot pull too much out anyway; you cannot pull too much over here. So, if you run in it, you run in it, and it gets a new price update.

But in the meantime, while things are not moving too heavily, you basically get immediate access. You do not have to call IVC swaps. You get immediate access like a local DEX like immediate swap response right away, immediate responses from a DEX locally, with the same liquidity effectively, as the parent DEX.

So, if they basically shifted this as a branch bank that can provide virtual liquidity and a much higher amounts and still safeguard against bank runs, which I think is amazing and this idea of protocols are not just copying themselves over chains.

We have moved collateral over chains, but integrating operations over multiple chains is a revolutionary concept that no one has really grasped or able to build out yet. So, I think, one project I will be doing besides knocking stuff out, here is how you swap on a Juno osmosis, swap on the osmosis DEX from Juno with an IVC message.

This has been a discussion for a while now, since Lisbon, and besides that kind of stuff, I want to work on basically building out next level integrations of multi-chain applications, that truly multi-chain that live on multiple chains and balance banks between multiple chains.

Brian Fabian Crain: It is just amazingly powerful, that is where you really see the kind of multi-chain, already the Cosmos ecosystem had such an explosion of activity and we have seen IVC be so powerful just with token transfer.

And the thing that shocked me the most with IVC or surprised me the most was just like how actually good the user experience was, I think Osmosis did a great job at that. And, not just osmosis like others, now I think having all these more advanced things right with, more powerful IVC stuff with Cosmos, it is going to be weird and mind bending when DAOs come out. 

Ethan Frey: You were getting multi chain wallets, I think wallets must adjust, there is an amazing job they did in osmosis, and I agree it was an amazing job they did for UX when it came out, they basically listed all your accounts on 10 different chains or 20 different chains.

Like on one little board you hit a pause withdraw, you do not have to go some other account and do something and then sign into other blockchain app over there, go to a bridge wait whatever. No, he is like on osmosis app it shows you when you click the button deposit, it under the hood calls another chain to tell you the transfer.

It signs a transfer message, wait till relay to move over there and 10 seconds, 20 seconds later it is in your account with almost no fees, that is super-fast and super cheap you do not even have to worry about it, all you remember is, oh my ledger, I see a different chain ID on this thing when I am signing it.

but it is so transparent and that was amazing to really make that whole idea, you can bridge liquidity as transparent. So, I think once you build these things, I will talk about behind the scenes and the back ends like this. What are front ends? They are so transparent and smooth.

And I think they did a killer job in UX and love to see what, have those people also involved in these next level discussions and see what kind of UX they can design for this multi-chain world. 

Brian Fabian Crain: One question I have here is one of the big arguments that Ethereum has always made, and that is some other chains like Solana for example, was also emphasizing a lot, was this idea of composability.

And it is such an advantage to have contracts that are in the same medium where you can make atomic transactions, make one transaction that affects different contracts in the same transaction and you know, it all executes, at the same time or it fails.

How do you see that? Because that was often also one of the criticisms of the kind of cosmos IVC concept is because you have a transaction happening on chain A and then it triggers something on chain B, but you cannot sort of make the transaction to triggers something on chain A and chain B simultaneously.

Now talk a little bit about how do you see this issue and what is the impact of that going to be when you have interchain applications the way you described?

Ethan Frey: I think it is a good point and I think, it is basically just harder, it is easy to call it locally and I think the idea of the app chain where every app had one little use case, one is just a DEX and one issues tokens and one is NFTs and one is a lending protocol and one is this other little piece and you actually need five chains to make any useful defi ecosystem.

Is kind of limited, the extension adapts if you are going maximalist and little things hitting the limits, however, a lot of the new architectures are going for these things like near is charting already is asynchronous calls anyway between of it.

And they realize that they cannot scale up and Ethereum the limits and they have RollApps. And so effectively, you can compose Ethereum, but everyone goes to Polygon or Arbitrum or something like that, optimism and Phantom and they are just throwing somewhere else because they cannot, now there is crappy bridges between them that are hacked all the time because composable hits limit.

And then Solana we are virtually scale, but we are centralized VC chain that halts every two weeks. So, they have limits here, and so clearly having not just vertical, but horizontal scalability gives you so much more resilience, the problem is how do you do it?

So, I think you want to have a useful modicum, if you have four apps always working together all the time, they should be in the same chain, they should be composed nicely, tightly integrated. They should integrate into one chain, but there are other apps that we do not integrate with all the time.

We integrate with them occasionally or every few hours, we do not call in all the time, in Quicksilver is on one chain and it stakes on that hub, and it does not need to be there every single transaction. It just needs to know how to deposit, withdraw, handle some stuff it does its own things, but they do not have to be like this. 

They just must be able to securely be able extra operations. So, I think there is a whole class of things they do not need this immediacy of that composability and then it just comes to the point of design, your protocol design, a lot of devs come from JavaScript and have issues with this stuff, but you should not be coming, if you come from JavaScript, do not build IVC straight up.

They come from a serious background in distributed systems or architectures protocol design, you have must have wrestled with actual like, what is a master slave in multiple master database systems or message cues and concepts this, backend concepts that like I do not need PhDs. 

I am just saying that someone is wrestled with a lot of these stuff, they had large-scale backend web systems have distributed natures and you have to learn this stuff anyway, once you have dealt with this stuff, microservices, you kind of get some ideas how to architect stuff.

And these ideas are the same ideas you need for IVC, it is just a different concept, I think a lot of it is training a mindset how to design them, but once designed properly, it just takes more time to design, it should be easy to implement and they can be able to do most things as long as you can wait a little bit and you do not need that, you can even compose it.

I do action, hold it a token transfer, if it fails or returns your money is atomic, it is just atomic over a longer time span so you can build all that functionality, it is just a little harder to design it, that is all. And so, clearly if you want to have things always together in the same chain it is great.

But if they need to be a little looser coupling, you can get very secure loose couplings over multiple chains. 

Brian Fabian Crain: I think the near point was interesting because I did a podcast with Illia and Alexander, recently two months ago or something like that.

And that was this thing we just talked about there as well and I thought was very fascinating how they are chose to do, to have this kind of asynchronous nature even if contracts are on the same chart, because they were like the benefits outweigh having this composability because it allows them to move contracts between different charts and the developers sort of, it does not have to care where they are because they behave the same way, and I thought that was a very interesting, different perspective. 

Ethan Frey: I like Near they are smart guys. 

Brian Fabian Crain: Absolutely. Governance, you wanted to talk about governance as well, what is on your mind when it comes to governance? 

Ethan Frey: I think governance is unexplored territory.

You were also around when you were trying to design, the POS governance for that, and I think in 2017 having some on chain vote control critical blockchain features was this crazy idea of heresy almost, hard forks only way of voting, so it is normal now that is governance doing things switching parameters and releasing funds and controlling upgrades.

That is normal now these days, that was kind of five years ago it was crazy. And POS was this crazy invention that no one trusted would work and POW is only way. So, these have proven themselves and I think you have watched that same evolution, the same way that DAOs have now become mainstream, suddenly they realize, oh, okay, open this up. 

And now people are rusted in full head like let us run everything as Dao, throw tokens on there, lock them, they are great. And I think it is a problem because the same people that were naysay it for years, did not really learn just how governance works, let us use it, blindly copy paste, and are now cruising a lot of bad designs of governance designs.

He never really understood why it worked in the first place, there are some DAOs I think work quite well. A lot of those are membership-based ones where it is one person one vote, and they have kind of trusted ones.

Those can work amazingly well, like Moloch DAO or something. And or even nouns, I think are interesting, a lot of these other ones are just one to one vote, stake it pump and dump things. They flash loan borrowing tokens to take over the governance, this happened before.

And I think you cannot have a flash loan and be able to overrun the governance of your protocol. It is not secure anymore, given up, you have over financialized your protocol. So, I think there are any safeguards there I have been thinking about this since the hub launched and since studied this famous 0% attack, commission attack, attack whatever on the hub.

There are issues with this governance. You can do a lot of things with it, it is very powerful, but it has limits, you must understand the limits, you understand when it works and when does not work right. Really understand this situation and I felt I was doing a voice in the wilderness for a long time, because every said, no, no, its work great, it is just the hub, it works and it works for the hub, it does not work for your little chain that has a 10 million market cap or 5 million market cap.

It might not be secure, insecure for the hub that has a real community, and it is proven a lot of these DAOs have small market caps and are unsecure with their logic.

And I think it was not until I had pushed out a POE at the talk I did at Interchange Foundations without proof of engagement, which was a proof of authority and proof of stake, missing it got no traction and I wrote a white paper in it next year and we built it for T grade. So, if someone wants to learn proof of engagement, look at T grade, have medium article explain technically how it works.

It is proof of authority and proof of steak together, in a mixing function, which I think has interesting privileges. I could go on for a long thing, but it is one piece of experimentation of what you have pure proof of stake, proof of stake authority. 

You can design other systems and I think we really need to experiment, understand the limits of the systems we have, understand where they work well and where they do not work. And it was really Vitalik In summer 2021, he posted beyond coin weighted, token weighted governance, I believe, and remember the d-gov and where the limits are, and it is kind of theoretical thing.

You are talking about soul bound tokens now and for me that is like, okay, sure, that is why I was pitching 2019, that we have soul bound tokens, which are basically proof of authority, which you have engagement, who has reputation put your reputation as token, which cannot transfer, clearly you cannot transfer reputation and sell it.

So, you have your reputation on the chain, which you cannot sell or buy, which is your time in the chain and give your money, so if you are the old time is done stuff, but do not have any money on the game, you should not have any vote. And you have a bunch of money, but no say anything thing, who are you?

So, it is this mixture of having done work and having money on the table and putting your money where their mouth is. So, I think that combination is what experiment and proof of engagement and T grade, and it is just one experiment, it is one experiment here and it is not the answer.

I think it is an interesting space we opened, and I looked at DAODAO, which is a cool project on Juno. So, big how Jcartela for doing that one. They have had no raise self-organized community just doing their things, they have gotten over a dozen devs I believe, without funding.

Just believing in DAOs, which is the most successful non Defi project built on CosmWasm, so DAODAO.zone, and you can launch your own DAO like that. And so, they have multisig type DAOs you vote people in, who knows who, you have DAOs based on tokens just like the standard DAOs just like you see at Ethereum everywhere.

You have DAOs based in NFT holding, you have DAOs with mixed token waiting, we are building a module to extend it for WyndDAO, which is using curve style multi-level token waiting. And I would like to take that one and then you will have sub DAOs workflows between you can partially delegate authority to sub-DAO, which has these people is just put it here overridden.

And these larger stuff like Aragon is building back on Ethereum before they kind of died out or petered out. They are building all these cool tooling out there, it is a great toolkit because they are building a lot of components to allow people to mostly point and click on the web interface, build their own DAOs, but access to all kinds of different models all kinds of different rules.

And I built a lot of these early contracts in 2020, 2021. It was demo contracts and multi-SIGs and voting stuff and they took this stuff and built UI and they just went with it. They have gone way beyond why I built, I am impressed with them. And it shows that Cosmos is not Ethereum, it is Cosmos is really the forefront of governance.

The hub was already cutting edge on chain governance and POS was cutting edge in 2019, In 2017 on believed it would work in 2019 it was launched in main net it was cutting edge. And I think DAO is bringing the next level of this really bringing me new ideas of governance, to a new level.

Brian Fabian Crain: I think that is something I think also, you know, we talked about, mentioned this on this podcast before, but that stands out to me so much. I remember when we were working on Cosmos in 2017. There were others who were basically other blockchains proof of state blockchains.

There were also specifically Tezos and PolkaDot, they also had the kind of governance mechanisms in there and they talked a lot about, oh, how they have this elegant, powerful, complex governance scheme. And I feel for Cosmos it was more, yeah, we are going to have this governance.

But it was not so much at the front and center, and it was also kind of simple in comparison. But I think it has ended up Polkadot governance is just very confusing, and I think too complicated. And I was reading at some point that they were moving to a more Cosmos style model.

I am not totally sure if this is true or not, or if I misread that. Then Tezos big issue was that only validators could vote, which is not ideal. And then, I think the Cosmos model was just very nice, that you have validators rule by default, but then individual token orders can override it.

And what I think has been just amazing is the amount of adoption that has gotten where you have on the cosmos hub, often 80,000 accounts or something like that, voting, same osmosis huge participation, but then of course you are totally right.

Like this is just one form of governance and it makes sense for some forms, but there are obviously also downsides there that you have, okay, someone with a million tokens and there is someone else with a hundred tokens, and the person with a hundred tokens may be super engaged and know a lot.

And so that is a hard problem, but at least I feel CosmWasm has already gotten far and works well and has gotten surprising amounts of engagement and I am excited to see the kind of DAODAO and the other models that can be built.

Ethan Frey: I think that Cosmos model works quite well for most cases. If there is an engaged community, if most token holders care about the chain, you have engaged community and you have a solid market cap, it works well. But those are the ifs, so when you see a chain with not much usage and the market cap drops to one or two million in this bear market, which has happened, it is a problem.

And what happened in Terra, when they invented 5 billion Luna or 5 trillion Luna, I don’t know if five quadrillion Luna, I am not sure how many, they halted voting because it is an attack. Some random people just bought this for zero cent and now own 50% of our governance. They could delegate their things and take over the whole chain.

They realized the limit of it. I am just saying there are failure modes in it, there are failure modes you must be aware of, and that is extreme failure mode. But I think any of these small chains is under 5 million, 10 million market cap and has low engagement, is just waiting for it.

And so, if they ever actually had a higher value at one point and then went down to this level, that means someone is going to snap them up, it means just like the POS works well if you say, hey, token controls are actually engaged and there is a seller market cap, no random shmo hacker can just buy up a bunch of tokens and take over because , you cannot buy them out because people care about stuff. 

Brian Fabian Crain: And I think it works well in the sort of the decision about, oh, should we go there, or should we do this, but what it does not work well for is a sort of organizing work, and collaborating to do stuff.

So, for example, I think the whole mechanism of using governance for funding proposals, I think is not working. I mean, it sorts of works, but it is not ideal because I think when someone proposes something, people are all right, that sounds reasonable, and they then fund it, but was that the best thing to fund?

Or in a different way or someone else had the same idea and, I think that is, for example, one thing where the existing governance I feel is not great. 

Ethan Frey: And I think there is a cool thing DAO is working sub DAOs that can take the staking vote as the basis of who is voting power and have your own different logic on it.

Or subgroups of them can vote on it, they were not having no tokens using the staking token on the native thing and then also allowing sub DAOs, okay, this DAO is appointed by the main governance can now appoint this DAO to do certain things voting funding, with some sort of budget, right?

But the apparent governance can revoke them, hey, this committee is not working very well to get rid of these guys, they just waste their money, so you do not have to have the 80,000 people involved in every funding discussion, negotiations. You can have negotiations with a counterparty, and they can spend a million or two a month maybe on funding projects and the ecosystem.

And if the money is going to bad places, you just basically swap it out with someone else, and that might make sense in a way of more decentralized than saying you have a foundation that is in transparent foundation funding stuff. It would allow a decentralized way of doing things. It is controlled by Unchained governance.

But still, you do not need 80,000 people in discussion when someone is trying to negotiate funding. I will do this feature for your chain and then you are , okay, I am waiting two months in public discussions to figure out whether I get funded or not, I am going somewhere else this a little faster.

But I think you can do it and I think data allows you to add that on to existing governance and kind of just not replace the standard one but extend places with this. 

Brian Fabian Crain: Well thanks so much Ethan and it was great to have you on, you mentioned the CosmWasm Academy.

Maybe that is something some people may be interested in, can you tell me a bit more about that? If people want to kind of get started in developing on top of CosmWasm, where should they go and what is the kind of offering that CosmWasm Academy has for them? 

Ethan Frey: The CosmWasm Academy, academy.cosmwasm.com, you can sign up right now.

We will be opening early September, maybe mid-September. Let us see how the times lines are, slept a little bit. We have been for quite a while, have few videos online, the platform is already online. We are trying to finish up a first version of it. We had a preview already on sale, in a few weeks, early mid-September, we have it going on.

Sign up there, you will get basically bottom and top rush courses explaining how to build contracts in rust from an expert train developer at Confio’s, who is working a year and a half now with us building all kinds of rust contracts and building a CosmWasm and multi-test and a lot of these tooling’s you have used.

Going through how to build contracts, explaining Rust, explaining contract logic, explaining how to build everything up there. So, if you have basic rust knowledge, sign up for that class and it will take you into advanced Cosmo development. I think this is really a way we want to do democratize people, so really get the skills of how to build good CosmWasm contracts out there and complex contracts, how to compose contracts, how to build these systems out there.

It is for everyone, it is free, it is basically us trying to train out a whole new generation of skilled developers.

Brian Fabian Crain: And how long is the course?

Ethan Frey: The course is 10 weeks. It is 10 classes. They are one weeklong, there is some take homework for you to do with them.

You will probably do it faster if you are skilled already, it is a ten long week. 

Brian Fabian Crain: Fantastic. That sounds like a great experience.

Ethan Frey: It should be, it is for everyone it is for the people and feedback is welcome. Please give feedback out there if you have stuff.

We want to make it better. We will have other stuff on CosmJs and front-end stuff coming later as well. Other courses, we have also some full stack courses coming aligned up for you. I also wanted to mention WyndDAO briefly. And so, there is, I mentioned earlier, it is basically a DAO we are launching or have launched on Juno, for doing IVC based contracts.

I think it is going to be the cutting edge of a lot of this stuff, scaling out protocols, both vertically and horizontally. I think it is very interesting stuff we are building out there to reach huge scales and really push what IVC can do and how it can make an actual interchain native protocols.

There is an airdrop out there, I want to say. If you get this before the end of August until August 2020, we have an airdrop airdrop.wynd.daodao.com, and check out more there for all juno Osmosis region stakers. 

Brian Fabian Crain: I will check that out as well. Thanks so much, Ethan, for coming on.

It was great to have you on the podcast. It is amazing all the work you have done and the way you have contributed to the Cosmos ecosystem. I am super excited to see what people are going to build in this next generation of stuff that is going to come with CosmWasm and mixing that with new IVC capabilities and then with all these people, they are going to be trained through CosmWasm Academy.

Ethan Frey: I am excited. I have been dreaming of IVC for five years now, six years now of what we can do. Everything is ready, the tools are ready, infrastructure foundation is ready, and let us just build, build guys.

Check our chat Discord website. Everything is on chat.cosmos.com for discord. Lots of good help there. 

Brian Fabian Crain: Thanks so much, Ethan, and of course we will include links to all of those in the show notes. And thanks so much to our listener for once again tuning in, if you want to support the show, make sure to leave us an iTunes review.