My long form position

Open letter to the cosmos community

Hi this is Jacob you may know me from my Twitter account and others of you may know me from my GitHub account, faddat.

Some of you might not know me at all and that’s fine too I hope you’re doing well. All right so I really want to lay a few points hopefully as clear as possible concerning the recent discussion about cosmwasm on the hub and my experience with cosmwasm and I’m going to try to keep it absolutely as plain and boring and technical as possible.

I basically have the role that I currently have in Cosmos because of various mentors that I’ve had, and these people include Jae Kwon, Jack Zampolin, dev, Alessio, and to be real, countless others. I have been known to have great appreciation for Zaki’s one-liners. Not one liners as in bash script, but his statements that compile huge amounts of knowledge into a single sentence. It’s impressive. It was Jae who initially pulled me in in 2016, and it was Jack who taught me IBC.

I want to have a Frank an open conversation about CW on The hub because I’m not exactly opposed to it in the same way that my teacher Jae is, but he makes some valid points and these get lost in the Twitter noise. Furthermore, Jack, Billy, Zaki, are all making valid points as well and they are getting lost in the Twitter noise as well. So I decided to write long form even though I really do prefer to communicate in tweets.

I’m really happy to work in Cosmos. Honestly it’s probably the only place that a freak of my level could work at the level that I’m working and I really really enjoy it. If anybody is reading this and wondering if they should get involved, if they like to express themselves using software then Cosmos is probably a very good place to do that. I guess that the way that things are looking right now GNO is not going to be Cosmos but you know what I’m very interested in that too.

I don’t think that the Cosmos hub is going to die without CW. Part of me did not like the veto vote that I put on Billy’s recent governance proposal because it was a technicality, I was a no. But at notional labs we have come up with a way of carefully going through governance proposals, very specifically we look first at the software and then we look at the accumulated set of governance proposals over time. What this gives us is a more or less objective way to judge governance proposals.

The veto was used specifically because the description text on the veto option did not match what veto actually does. Here is what veto actually does, if we use the notional labs method for determining the purpose of veto well what we can find is that Cosmos hub proposal 6 proposed by the Sikka labs team defines no with veto as follows:

We instead propose that the deposit be returned on failed votes, and that the deposit only be burned on vetoed votes. If a proposal seems to be spam or is deemed to have caused a negative externality to Cosmos communninty, voters should vote NoWithVeto on the proposal. If >33% of the stake chooses to Veto a proposal, the deposits will then be burned. However, if a proposal gets rejected without being vetoed, the deposits should be returned to the depositors. This proposal does not make any change to the current behavior for proposals that fail to meet quorum; if a proposal fails to meet quorum its deposit will be burned.

Okay so what we can see there, is that the way that Billy defined no with veto in 69, is simply not what it does and it’s my personal opinion that freestyling governance options is a path to harm. Much more serious than the type of harm that could occur if we put CW on the hub by the way. So I vetoed because the description did not match either the code or the previous proposals.

Now, this gets technical and there’s nuance, please, for my own sake and for the community’s sake please hear me out here.

The hub lacks any clear definition of itself. Because of this I do not have the same issues that Jae does concerning cw on the hub. I realize that he has a vision surrounding the hub and that his vision differs from other people’s vision. But did you know that I wrote the readme file for the cosmos hub? Yes others have since rewrote it but at one point I wrote it because I thought it really wasn’t good enough.

When I wrote it I made really sure to mention that it was a cosmos hub not the cosmos hub. Currently I suppose that it is the cosmos hub but let’s be real there are a huge number of chains that began with Gaia’s code base. These include to the best of my knowledge osmosis, ki, every single starport scaffolded chain until the introduction of SPM and CosmosCMD, we owe that fat lady a lot in fact I think that we owe her the best possible treatment .

So one of the things that I’m going to hold really steadfast to is that notional would execute what I mean is we would operate, a governance mandated implementation of CW. Because the chain lacks any constitution or mechanism banning it, we absolutely would accept governance decisions that implement CW. But at this time we would not vote for them and I’m really trying my best to sort the concrete facts from the noise because all of us including me generate some noise on Twitter.


  • Validating CW chains on arm is untested but maybe possible and we may be the ones to test it
  • Terra did not die while being attacked and that’s kind of a big deal
  • Chains that implement CW do seem to exhibit some strange block miss patterns, but these seem to be resolved in the latest versions of CW and I don’t know for sure if those are related to the Cosmos SDK or tendermint or CW itself because when we change the version of CW we also change the versions of the supporting libraries
  • All of the performance problems that I am aware of, and they are numerous, can be traced back to the database layer + IAVL which we use to enforce the determinism that IBC relies on.
  • CW has enormous potential and it could replace in many cases the functionality that is expected from other layers of software, for example shared security.
  • Both sides of this argument really do not give one another enough credit and I don’t know how to purge the bad blood and I’m intentionally putting this in the facts category I have suggested and I continue to suggest a Bitcoin mine shipping container cage fight but there could be ethical problems with that approach, and furthermore we do have governance so that we can make decisions.
  • There are real risks to CW but this really is not the most risk-averse business, now is it?


  • In general, I think that we should build chains with glibc not muslc, especially in ci.
  • I’m pretty sure this is why we have forks

Okay so I really like the auditability found in GNO. In my opinion that is some next level stuff. I think that the licensing needs to be worked on to some degree but I think that’s a solvable problem and Lord knows that I have written my own licenses before.

If there’s a problem with the Juno airdrop it’s probably one that’s a little bit counterintuitive, specifically that we did not include centralized exchanges. Ouch, right?

On the cosmos hub front, what we can see is that the hub is kind of an IO port for the finances of the entire cosmos ecosystem. That’s really incredibly important. And I think that 100% of the actors involved in the conversation understand that it’s a critical piece of infrastructure. On the pro CW side, I would say that they’re looking for native CW capabilities directly on the hub where we go in and out of Cosmos because we can create genuinely new and interesting things. By the way, I agree but nonetheless voted no with veto, and would have still voted no on the technology.

Once again, I’m confronted with reality that a fork seems to be the best possible way forward.

Recently I tried to deploy CW contracts onto osmosis and I would like to make clear that I found the governance gating procedure truly painful. I was going to spend more time deploying those contracts onto osmosis than it would take for me to put them together. As one of the early authors of Juno and her current team member of Juno, I also need to say that one of the truly great things that Juno is doing for the ecosystem is absorbing the risk of permissionless IBC enabled cw contract deployment.

Next possible steps

Let’s just say that I found dealing with governance gating to be really unpleasant. I think that one option is a consumer chain, that is a blockchain that uses the security provided by the cosmos hub, to provide an unpermissioned CosmWasm environment. But this has legitimate disadvantages. Probably first and foremost among these disadvantages is that this chain while we can speak speak of it as asynchronous. That means that it does not operate in tune, in sync with the hub. Deploying CosmWasm on the hub directly does have some real advantages.

But there was another poster here, who had the gall, and I am an appreciator of gall, to state that there was a risk of the hub turning into a shitty version of Ethereum. I’ve got to agree with that guy.

You’ll note that I’m describing this as a risk and not a certainty. I don’t know what would happen if we put CW on the hub, I think that no one does. Billy is right when he says that CW would allow for faster code deployment and faster evolution of the code base, kudos to you for that Billy.

I really want to keep this conversation in the realm of confirmable fact only. So if we take all of this information and we try to distill it, it is my firm belief that our best option is to create a second chain with exactly the same token holder scenario as the cosmos hub and then put permission to or unpermission CW on it .

But we really should discuss the competitive issues that are inherent to this because there are many. So first of all, I recently noticed that Sunny had mentioned putting unpermissioned CW on osmosis. Okay so all of the sudden we have created a competitive threat to Juno and we can say that maybe Juno loses its exclusivity as the place to do unpermission to CW in Cosmos. But let’s go deeper, osmosis is implementing code that ensures that CW20 is not needed, instead everything is SDK.coins. oh this is much much better really, and I guess I would just like to see that upstreamed. I don’t know if Juno would or could adopt it and also I think that there are probably second order implications of the lack of wrapping that maybe I’m not qualified to address although I’m learning contract code just as fast as I possibly can.

I do think that we should try to inherit as little as possible from ethereum. Over the years they have had so many security problems and I think that so many of those security problems are kind of endemic, they’re not the things that can be solved and so to the greatest degree of possible we should always try to create our own standards and then follow them. SDK.coins is a good pattern.

I validate the hub and Juno and osmosis and this actually creates some very real conflicts of interest. Basically, my economic interests are best served when all of those chains prosper. Part of this means compatibility. I really want for the contract standards that we deploy to be compatible. I don’t know if the SDK.coins version of CW found on osmosis will end up being properly IBC compatible with the CW20 version of CW found on Juno This is a serious concern to me. I have not done the needed code review yet and if anybody has insight on this I certainly request it.

So basically I suspect that it makes a lot of sense to fork the hub. I said this earlier, and then I sort of back down from my conviction on it but the reality is I think that that is the safest path because we end up with a plain hub and a very safe io port and we can keep that listed in the same places and it can continue to do its job and we end up with a CW hub that adds CW. Whether or not that’s the SDK.coins implementation or the CW20 implementation doesn’t matter a whole lot to me but I think that we should try for full ecosystem compatibility because please thank you so much for reading so long get ready for the next section.

The big deal

Hey guys it’s a big deal and although we printed a big old l with Terra recently, the reality is we are doing amazing and growing in this crazy exponential or even geometric pattern that reflects the design of the internet itself. Everybody every founder, every code contributor every relayer and every validator should be proud of their work. In my opinion our current state is a very low probability outcome and I think that The Cosmos SDK is kind of beginning to resemble Linux kernel development but we have no Linus because he left. But I have heard that Linus does both good and bad things and so now we all have to be Linus.

I know that not everybody knows this, but we are building a compute mesh. I want to see GNO play nicely with CW, and that doesn’t even get into the contract standard created by the brain fellows at agoric.

The smart contracts are just tiny little programs and they can grow in scale and scope pretty much to the same degree as the blockchains themselves and I think that this goes for any of the new contract standards that are being played with in the cosmos ecosystem. I don’t want to lose focus on the miracle of IBC.

I don’t choose my words lightly either, I say miracle because it’s just such a low probability event. It probably shouldn’t have worked the budgets were always too small, and I am very well aware that many individuals and organizations, including what’s now known as ignite, informal systems, the interchain foundation, The osmosis team, our community members, our relayers, our validators, have all contributed to that outcome. In order for that outcome to continue and evolve we need to focus on compatibility. I think there’s a case for redundancy here and that’s why I brought up the fork once again. If I had to guess all of the exchanges would be happy to list a CW enabled hub provided of course that their users received the airdrop, and if I had to guess this would give us a more resilient structure. What the hub has right now that no other chain does is extremely wide listing on centralized exchanges. And you know what guys? That’s awesome.

I know that we like to hate on the centralized exchanges but I need to dial in the message a little bit. I recently reviewed a governance proposal from Huobi. That’s right on the evmos chain they’re going to actually participate in governance. If you know me and you understand my stances you probably know that that has changed my opinion of their interactions with the ecosystem overall. Governance is our way of doing things.

Bullet point summary

  • I think we should fork the hub
  • I think agoric contracts should work to interact with cw and gno and vice versa. Our goal should be compatibility.
  • I voted no because I’m aware of some technological issues, and I voted no with veto on a procedural technicality.
  • Cosmos is a uniquely good platform for developers to express themselves using code and we should strive to preserve compatibility wherever we can.
  • I wrote this document because I saw unimportant matters being discussed on Twitter when we need to focus.
  • I have come to the conclusion that I do not support native cw on GitHub - cosmos/gaia: Cosmos Hub – now or in the future. I think that it would be very reasonable to fork Gaia to support those features, however.

So if we fork the cosmos hub, how about Atom holder? How they can benefit from the fork? How we distribute new token of forked chain, sir? Thank you!

You are voting NO on the 69 proposal because you want to get GNO tokens. When 69 passes, you will probably vote YES on the exact same proposal when there is no economic loss attached to the decision.

Fork of hub is an absolute NO for me. I understand the desire to split of every new functionality into a new process/thread/token (this is how software engineers think) but from investment perspective it really dilutes the offering. People don’t have infinite amounts of money and they can’t follow 20 fkn tokens that have marginal functionality. Each token is a new financial asset with all the bookkeeping work attached to it. It is not a good idea to have endless amounts of financial assets. Investors can’t follow endless amount of things. People have limit to attention span. The word “Hub” means there is something of value there that everybody uses. All I see here is endless proposals to dilute the value of the Hub and split off other tokens. This financial strategy doesn’t make a lot of sense to me. You should bundle in Cosmos Hub whatever you can bundle and only split off stuff if absolutely necessary.

I think the main issue is permissionless CW which is what is perceived as Ethereum’s problem. Permissionless CW is on Juno. The 69 proposal I think is for permissioned CW which I think avoids majority of the “shitty Ethereum” problme. For me permissioned CW is perfectly ok. I also voted NO on 69 to get the GNO tokens. But on the next proposal to add permissioned CW to Cosmos Hub, I will vote YES.

I knew that you’d happen.

Hi, @vixcontango

Where’s your code?

Right, that’s what I thought. Furthermore, if you take issue with how software engineers think, then I do suggest that you please sell all of your cryptocurrency, and your mobile phone, and your car. Go back to a cave somewhere and enjoy.

100% of cosmos was built by software engineers, as was the internet, and just about everything that you use on a daily basis.

If you do not understand this reality, that is not my fault. I guess you should learn to code.

my reply

This does not dilute the offering of anything. What it does is create a second cosmos hub, and holders of atom get exactly precisely 1:1 the atoms that they previously held. I cannot help and will not abide your ignorance, it’s not welcome.

It should be a 1:1 fork, that includes centralized exchanges.

Literally if you have ATOM, you should get these tokens. I do need to name the denom, and rapidly, because I am making the genesis currently.

int i = 0;
while (i < 0) {
Console.Print(“Jacob thinks a guy who knows how software engineers think doesn’t know how to code”);
// this code won’t execute
Console.Print(“The following statement is an oxymoron:”);
Console.Print(“This does not dilute the offering of anything. What it does is create a second cosmos hub”)

1 Like

not bad sir.

Nonetheless, you’re totally missing the point.

And I repeat my statement that if uncomfortable with “the way software engineers think” that you should make with a move to a cave, rapido.

All I am trying to say is that investors having to invest in 3 or 4 tokens in the Cosmos ecosystem to get exposure to the same functionality you get with Ethereum is probably not the best way to add value. For example, if you have 100K, in Ethereum system you buy 100K of ETH. In Cosmos, you need to split into 50K ATOM and 50K JUNO to get exposure to the same interop and permissionless smart contract functionality that ETH gives you. You do dilute the value of the ATOM token when you split off new functionalities into a separate token. As a software dev myself, I don’t think people like you that contribute to open source projects like Cosmos Hub should be doing it for free. I want you to make a lot of money. A lot more money than in traditional industry. So value accrual for the tokens is not a incidental issue or an unimportant issue. It is important. Obviously, it doesn’t have to be the only issue (like it is in the Ethereum system with its maxis), but I just don’t want Cosmos to go to an extreme place in the other direction where every new important functionality/module is split off into another chain/token. I don’t think it is good for the ecosystem if it becomes too difficult to explain and sell to new investors or it earns a reputation for not caring for its investors. It’s the NEW investors that give value to the system. I understand airdrops give current ATOM holders financial exposure to the new tokens but for NEW investors they have to split their money among more and more assets and that is dilutive for the existing assets ATOM, JUNO, etc.

yeah you also said that my vote was profit motivated.

At Notional, we’ve a very strict policy to only vote for the economic interests of the specific chain in question. We think that Gaia will be best served without CW, and do best without CW.

We also see the value of a CW hub that attempts to preserve Gaia’s exchange listings. We think that this is good for ATOM holders, so we’re proposing it. Since it is entirely external to the hub, no gov prop is needed. Since ICF was vehemently in support of cw on the hub, Notional and many of our partners are positively shocked by the lack of response from ICF.

We think that Gaia’s development on a closed discord server is hilariously dumb. Gaia’s validators have no meaningful access to conversations about Gaia’s development. Per usual with ICF, when I pointed out that this was the case, I was told by ICF that actions would be taken to correct the situation. Far as I know, no such actions have been taken.

I figured people would do that, and that led me to do and publish a metric ton of research, and the conclusion of the research I did is that the future of cosmos is very likely multi-chain applications, weather those be cw or gno or agoric or something else.

So now I am headfirst into enabling that.

We will not have eth-like “invest in this one target asset to realize gains from infinity shitcoins” in cosmos. And yes, shitcoins fuel eth. This is reality.

Instead, we will have many high value chains, as well as many high value multi-chain applications, some of which will have thier own chains, and some of which won’t.

Please see my mildly obnoxious thread of tweets on the matter:

Also, I strongly hope that icfistan reads the below memetic content


It is extremely important in this case, that relationships with CEXes aren’t modified at fork-time. Same with whales. I want those cexes so that just for example, burgeoning young highly experimental Juno projects can interact with CW contracts actually launched by the cexes themselves, and build interesting new stuff.

Thus far in my cosmos journey, while it’s very true that Ignite was a place of great learning for me, since then, hasn’t been much. ICF does not even bother to adjust its delegations to match code contributions or relayer activitiy or even validator uptime. ICF chose to push risks on Gai while the entire rest of cosmos depends on the fat lady as an IO port to cexes. I consider Gaia a hard dependency.

So it should be entirely 1:1 – unless there’s no engagement from ICF/TM/Informal. In that case, chop.

But ONLY for them. EVERYONE else stays in.

the above plan is the profit motivated play. I think that maximum profits will come from a big tent approach that includes the founding organizations. If anything, my vote likely cost potential engagement with ICF, or maybe delegations from ICF. Gno does not yet exist and I can’t be taking factors like that into account on my vote.

That said, did I listen to Jae’s concerns?


Some were valid, and some were not, and this was also true of the “yes” side. I spoke 1:1 with both Jack and Zaki on this topic. I wanted to deeply understand their positions.

And in fact, I came to the conclusion that the YES side – as well as the NO side – were both correct in this case.

Then I did thinking, coding, and research and all of this here is the result of that.

actions that I consider ICF obligated to take:

  1. respond to this concept, and if rejected, defend their position. I think they’d end up in an indefensible place, though.
  2. adjust their delegations or terminate their delegations and then burn the stake that was used to make them in a verifiable manner
  3. ensure that all code contributors and validators are able to participate in all icf-sponsored discussions of Gaia’s development

Of these, ICF has promised action already on 2 and 3 but has not followed through.

On the ignite side a sign of life would be nice, kek