That a lot

Thanks, Joshua. I will share my screen. Share. Can everyone see this? And let me put it into it's probably good for now. I like to be able to see the what's coming up. So hi. I'm Sam Hart. I really appreciate the invitation. There's a lot of familiar faces here. I actually work closely with or start working closely with the Haifa team on on some of this. And Toby and I are are doing a bunch of of kind of governance related work as part of other Internet, which is kind of not directly associated with Cosmos, but my work here has kind of informed a lot of our thinking. And we recently started collaboration with Block Science, so also really great to see, Zarkum here as well. I was asked to speak about the Cosmos governance module, which will require a little bit of background about Cosmos as a as a project and and protocol in general. So that said, I I'm not gonna give an introduction to, like, blockchains or anything like that. So I I'm kind of assuming a little bit of knowledge there. So, introduction to Cosmos. There's, it so the the kind of timeline, of the Cosmos project, I'm just gonna briefly give, like, a little bit of background on how this started. Ethan Buckman and Jay Kwan founded a company Tendermint in 02/2014, which was centered around enterprise blockchain projects. And they developed a consensus algorithm also called Tendermint at the time. And kind of while they were iterating, they really came to the the conclusion that public blockchains were really much more interesting and novel than private private blockchains or enterprise blockchains. And in 02/2017, they wrote a white paper, Cosmos white paper and did a fundraiser. The the white paper basically outlined a an architecture that in in which a number of blockchains, Tendermint based blockchains or otherwise would be would would run with their own, set of infrastructure, their own validators, and then there would be, a generic message passing protocol in which these chains could connect to one another. And the first of these chains would be the Cosmos Hub. Two years later the Cosmos Hub was launched. It was one of the first proof of stake blockchains. There were several others or there were a handful of others prior. The really the only one remaining is Tezos blockchain. And incidentally, the Tezos blockchain is actually going to be adopting Tendermint consensus at some point. So it's kind of moving closer to the Cosmos ecosystem in some way. The after the Cosmos I'm I'm not gonna talk that much about the Cosmos hub either. I'm happy to discuss that later, but just wanna kind of get to the, you know, the the topic at hand which is the cos Cosmos gov module. But, the kind of last point in this timeline is, the activation of IBC, which earlier this year, starting with the Cosmos hub. And now we have something like nine chains that are online. The so one of the one of the things about Cosmos is that there's a a kind of strong emphasis on on sovereignty of communities. And in one way that this plays out is is that these communities really, like, kind of take on their own identity and and don't necessarily, like, promote themselves as Cosmos projects per se. So, I've just listed a couple of Cosmos chains, on the right here, which you may not may or may not know are Cosmos chains. So Binance chain, crypto.com. There's, like, a bunch of of exchange chains, Polygon, and then there's a number of others that we work very closely with and our key core teams kind of collaborate directly that I've listed on the right as well. So, yeah, when I'm introducing Cosmos, I I try to there's two metaphors that I I try to kind of impart. One is a description of IBC as so this analogy holds up pretty well. This kind of server architecture to the relationship between servers and TCP IP is is very similar to those between Cosmos chains and IBC. And the IBC protocol inter blockchain communication protocol is actually modeled directly after TCP IP. It has connections, channels, ports, and, yeah, the the mess like, the kind of semantics of that protocol will be very familiar to anyone who's knows a little bit about TCPIP. So in this met like, in this analogy, Cosmos chains are literally virtual computers, and they have the ability to send value and and information to one another in a verified way. The other metaphor that I commonly use is IPC as a shipping container system for virtual economies. This is this is something that Sunny Agarwal initially kinda pointed out to me, and I think it's useful for a reason that you'll see in a second. But basically, I I obviously use a kind of standard messaging format. It's very generic, so it looks a lot like a shipping container. And when upon adopting shipping containers, you you really have the ability to kind of interact with a large network of of external entities. So that standardization allows for a a high degree of interconnection between different ports, for instance. So this is a metaphor that we extend to to, like, the to the relationship between or so this this actually, like, imparts a governance relationship in a way. So Cosmos chains are sovereign chains and that they have their own validators and and they run their own infrastructure and they have their own they can kind of direct their own they have their own internal politics effectively. And the this interoperable messaging system allows them to have economic integration without political integration. So this is very, like, similar to the way that nations have their own policy, but they are they're only subject to other nations kind of politics through like indirect means or soft soft power effectively. The kind of general values, this is like off top of my head, but the the general values that the Cosmos ecosystem tends to have in common are localism, polycentrism, the the architecture directly instantiates a a false isolated architecture. So if one chain goes down, the entire network does not go down. And similarly, there's there's also a strong emphasis on the principle of least authority or or really isolation, like security isolation effectively. The way that the Cosmos network scales and but what I mean by this Cosmos network is Cosmos chains connected via this messaging protocol. The way that that scales is, like, in a fractal way. So so ground up, basically. The communities are instantiated and then they start cooperating with one another. And so there's, the kind of era that we're in right now is, like, trying to better understand the cooperative effects between some of these chains as they start to come online and interact with one another. For those familiar with Ethereum, the Ethereum ecosystem, the one place to work from is to start with, cost compound governance. Compound governance the the compound governance smart contract is is very simple. It basically allows token holders to upgrade its own contract. So there's a, yeah, a self updating kind of a nomic game that the that each project can can execute. And token holders have effectively complete control over over what software is run apart from the the Ethereum virtual machine semantics. And Cosmos governance or the Cosmos architecture really just moves that same model into it transforms token holders into, basically, their own validator set. So they're running their own infrastructure instead of running on on Ethereum. But the secured security properties are actually very similar because token holders have complete authority over what software is being run. So materially, the the compound or I'm sorry, the Cosmos governance module let me step back for a second. So the the Cosmos stack, I mentioned Tendermint previously. So Tendermint is the consensus algorithm that we develop. We have a application framework called the Cosmos SDK, which gives you some some basic utilities like accounts and defines, like, a the our equivalent of the RC 20 standard, things like that. And we kind of liken this to Ruby on Rails for developing blockchains. So it's application you can develop applications with it. It's an application framework. The governance module is one of the utilities that you get as part of the Cosmos SDK. One of the other utilities that you get is IBC. So IBC is a similar to a kind of network protocol library that you can plug in just like you would, you know, your your network drivers basically for your own server. And so the cosmos cosmos governance module is is quite simple. It again, those familiar with compound governance will recognize some of these patterns. There's a signaling process. There's so there's three proposal types. One is signaling, one is a parameter change, one is spending from the community pool or the treasury, and the other is a chain upgrade. And and these don't map directly onto how there's there's a lot of similarity to how Ethereum smart contracts are are governed, but, you know, some material differences. All of these are on chain proposal and and and transaction, so signaling happens on chain. The kind of equivalent to a signaling proposal at this point in the Ethereum space is is snapshot voting effectively. Parameter change proposals are modifications of state that don't change the the state machine semantics. So those would be things like the inflation rate, like feedback mechanism or the the minimum quorum requirements. So these are they don't change how the the state machine is like, they don't they don't change the underlying state machine. They just change a a value that's held within that within the state machine. Community fund proposal kind of speaks for itself, but you can pay to an address. There by default, Cosmos chains have a community fund that receives some proportion of, of transaction fees. And then the chain upgrade proposal, which basically includes a source code hash, and an upgrade height, at which point the chain is halted and, and the new binary is is restarted. All the validators do this at the same time. One material difference between Cosmos chains or or Tendermint chains at least and Ethereum is that, Cosmos chains are based on a BFT architecture. They, are safety favoring versus liveness favoring. So, they will halt rather than make an invalid state transition. And this is, yeah, this is in contrast to something like Ethereum two point o, which will which prefers an invalid state transit transition, or a block reordering, rather than the network going down. So kind of a philosophical difference, but it the end result is that we are actually comfortable with a momentary chain halt in order to upgrade the chain. Details of the Cosmos governance module, these will also be pretty familiar. You know, Uniswap voting has some kind of similar properties. So there's a minimum deposit requirement. Anybody can make a proposal, but there's you must reach a minimum deposit. Anyone can contribute to the deposit, but but there's a certain number of you know, on the cosmos hub, there's certain of atoms that are required in order for a in order for the the proposal to enter into the voting period. And and these should probably be reversed, but once you enter the voting period, all token holders can vote on proposal. There's four options. Yes, no, abstain, and veto. Yes and no are pretty self explanatory. Abstain, there's a a kind of a norm in the causes ecosystem that that anyone who has conflict of interest should abstain from voting. And veto is a there's a a kind of specific definition that we are promoting for Vito, which is basically you would leave the network if this if the proposal is passed. And there's a specific reason for that, which is basically to internalize a a kind of censorship vector. I can go into that later. It's, like, a little bit nuanced, but if we didn't have this, then basically people could veto by by colluding with one another. So the one last one thing I didn't mention here is that is that Cosmos uses a delegated proof of stake model or a what we call bonded proof stake model, very similar delegated proof stake. So as a token holder, I will delegate to a validator, and that validator, inherits inherits, my governance rights, with the exception that if I can always override, a validator's vote. So if I disagree with what they're with what my validator you know, the direction that my validator is voting, I can I can override them? Or if I just want to, like, explicitly signal my interest, in something I can override. And one thing that one thing that this delegation system introduces or kind of instantiates is that validators who are, you know, running the infrastructure for the network really are designated as political actors. So they are intended to have an opinion on, you know, on the the kind of governance of each of these networks. So last thing is, these are kind of some of the things that I'm working on right now, what we have in store for the Cosmos governance module in the future. So, the IBC and and the Cosmos architecture more broadly inherits a lot of, I guess, intellectually inherits it quite a bit from the object capabilities community. And we work very closely with Agoric who's kind of the very invested in in basically, one of the the, teams that is kind of included object capability, functionality in the in the ECMAScript standard, the JavaScript standard. And object capabilities for anyone who's isn't aware is is a you can think of it as a as an alternative to an access control system where everything that that's basically based on a a kind of granular model where you're only giving authority to entities in in a very explicit way. So you're trying not to give any ambient authority to any of these entities. And it also kind of meant, like, maps relatively well to, like, human mental models. So the classic kind of object capabilities metaphor, I guess, is car keys. Car key represents a capability, and if you if you're in possession of that capability, then you can drive the car. And that's a very granular model. You don't give someone access to all cars. You just say, this is the key to this car, and if you have that capability, then you can drive. So we're introducing an authorization module that has very similar kind of model. You'll be able to to delegate and exercise capabilities within a Cosmos zone, and you'll also be you'll eventually be able to pass capabilities across across IPC channels. So you can if you have accounts on the other side, you can you can, you know, move your car keys from one zone to another. I mean, you can also move it to the the zone itself. The entire chain could, could be delegated to a specific capability. We're also working on a groups module, which is kind of our answer to, like, DAOs on Cosmos. We already have, like, a a cryptographic multisig, but this is this group's module will have similar functionality to, to the Gnosis Safe if you're familiar with that in the Ethereum ecosystem. There's some some slight differences, but but it basically defines groups and and the group's capabilities effectively. So groups can manage funds. They can they can be delegated specific rights to modify parameters or yeah. They they can basically in addition to to being able to deploy capital, they they can be assigned specific electronic rights. And then we are also developing a we have several virtual machine frameworks, a WASM virtual machine called Causing WASM and an Ethereum or an EVM virtual machine called Ethermint. And and the authorization and groups and governance modules that I mentioned will interoperate with these so you could delegate a capability to a smart contract in Ethermint, for instance, or And then lastly, the the the governance module and the groups module really as currently conceived are are quite simple, And we are so we recently hired Maria Gomez from previously from Aragon to to help us work on this. And we basically want to kind of evolve the groups and governance modules to incorporate additional functionality, additional safeguards, and and we're kind of beginning that product iteration cycle as of right now. And I think this is actually how this whole presentation was started. I I kind of mentioned this effort and if there was interest from the the meta governance community in potentially contributing to that. So that's all I have. I've included a couple links here that I can post the the presentation, the Google slides presentation link, so you have all of these. There's just an introduction to Cosmos and the Cosmos hub. And then if if you're interested in in learning more about the specifics of Cosmos governance, there's some links below here. So I'll stop there and take questions. There's a lot more that I can talk about with with respect to, like, the kind of soft governance within the Cosmos ecosystem and and I don't know the the kind of current development and and where we're going with the Cosmos hub, but we want to keep it pretty focused on the cover Cosmos governance module for this presentation. Thanks.

Yeah. So the Cosmos Hub is unlike the Ethereum blockchain in that, Cosmos Chains don't necessarily need the Cosmos Hub in order to to operate. And so the the Cosmos Hub is will will have a couple different basically, the Cosmos Hub is is going to be designed to help other chains, operate effectively. So the Cosmos Hub will will help to launch chains. We will have a a a shared security model, so you can form a validator set and, and stake using the Cosmos Hub. There's also going to be a number of financial utilities. We've recently launched a decentralized exchange, and and they'll likely be an auction system for for participating in crowd sales. So but the general approach is that the Cosmos Hub is kind of like a service aggregator and discovery point within the ecosystem. So there there should be a registry of other chains that are out there. It should help you kind of get hooked into the network, discover services. So if you if you need a to hire a validator or hire a relayer or find, you know, get access to a specific token so that you can you can then kind of move your attention to that application, that other application within the network. The idea is the Cosmos Hub is a kind of a discovery point and and allows you to kind of bootstrap yourself so that you can you can move further along into the network.

Close it out because I think so what I asked at the beginning was about the compound governance sort of analogy because it tends to be, at least in practice, used far more for sort of, like, the enactment and there's, like, a much wider, set of things that fall under governance. But, you know, the point I made at the end was that when you brought up groups and kinda tied it back up together into, the question of governance, I feel like you kind of addressed the question of zooming out and seeing governance as more than just the the moment where you sort of vote and enact something. So it is a comment now, but, you know, I think the presentation was good and you came back to that as an open question.

Yeah. Totally agree with that sentiment. There's a way more to governance that that's really marginalized in a lot of conversations. Our Discord and our Telegram and forum and what happens on GitHub, and there's a lot of dimensions to governance. A lot of the work that I'm doing with Haifa right now is kinda mapping that out and trying to make it more legible for, for anyone who's looking to get involved. Also, to to, make some of the norms that we have a little bit more explicit, because it took me a while definitely to kind of onboard. It it just you need to kind of encounter them through direct experience at this point instead of kind of reading about them. So, we are trying to work on a a kind of larger map of, you know, things beyond just the governance module, but, like, really the the whole system.

Yeah. That's I actually don't know the answer to that question. I I can make a educated guess. One is there isn't much this if you're gonna have, like, the most government minimal governance system possible, like, it look looks relatively close to what what's involved there you need. I mean, upgrading the chain is is was really, like, the most vital one. And then at the time, I think there was a lot of discussion of of community treasuries and diverting some funds to a shared pool was, like, a kind of novel mechanism, and so that was incorporated. And then the signaling proposal is something that, you know, you don't wanna go through a full chain upgrade in order to to do something like that. And parameter changes are are kind of a way of hedging. I I think there's just a a realistic understanding that, like, we're not gonna get every single parameter correct and and so a slightly more user friendly way I mean, the other way to do that would be to upgrade the entire chain. Right? And we can maybe make it a little bit more UX friendly by by having a parameter change.

There are common sequences. To answer your first question, I don't have numbers offhand, but I can say that there absolute numbers, there have been, I don't know, four or five community spend proposals. There's been a few more than that, like, six or or something chain upgrades, five chain upgrades. And there's probably been the largest number of signaling proposals, I guess. The and we we're still, like, very early in this story. Like, there there isn't a whole lot of, like, user friendly governance tooling. A lot of it's through the command line. We aren't at the level

sophistication just from a UX standpoint that Ethereum is in. I mean, we started started later. But common sequences are and this is something that we're trying to, like, build out better norms around. For a chain upgrade, we that includes, like, a new feature. We might see a signaling proposal early on that says, you know, community, do you want this feature? There might be a community spend proposal if that feature needs to be funded. And then there may be an another signaling proposal to propose a certain date or to kind of, like, make validators aware that this is going to happen if it's, like, a large breaking change, or you might go directly into the the upgrade proposal if it's going to be more of a a kind of routine upgrade. So there was, like, a major the the proposal that included I IBC, we had, like, an additional signaling proposal because there is there's, like we knew the validators were gonna need to reconfigure their setup in a significant way. There's, like, a lot of, operational awareness that that we needed to socialize. So, that was you know, we we took extra care to to make sure that there's an on on chain signaling proposal in preparation for the actual upgrade proposal. So that's a, like, relatively common sequence that you'll see.

It's true. I was asking about sort of proposal life cycles and sort of whether we're seeing or expect to see something emerge even if it's more normatively, where you see sort of propose signaling proposals to identify that, like, something should be at least considered for a change and, like, kind of leading to possibly even funding work to and, Sam, you you and I have talked about this kind of stuff before. Like, how do we deal with, you know, changes that are potentially big and and sort of studying them and evaluating them and giving people the opportunity to, you know, the the data or even the science to have informed decisions, especially as the the infrastructures become, you know, more people are reliant on them and changes our points of vulnerability. So it's maybe a question for the future, but one where, I see, like, norms being important for, life cycles proposals so that it leads up to maybe a proposal for a bigger on chain upgrade or or maybe a parameter change depending on what it is. And, you know, I guess I'm kinda rambling, but the the question was really more like, do you see that happening yet? And, like, in so far as it's not happening, kind of, some of the the UX considerations around governance could could affect people's sort of perception of what kind of life cycle should be available. And and in particular, I think it's important because I want ways for people to surface concerns even when they're not capable of providing proposals. Like, oh, we should change it in this way. Maybe there's just constituents of the system who, like, feel like something's off and wanna be able to help kick off a process that better understands that and makes changes. So yeah.

Yep. So this is definitely something that we're thinking about with future iterations. We'll get some of this with the authorization upgrade. So I'll just focus on, like, two kind of areas that we're thinking about right now. One is, we've gotten a lot of feedback from validators that, they they need to be tracking, like, lots of different things across lots of different networks. And the earlier that they're aware of a proposal, the the better it is for them, just kind of incorporate into their their internal processes. So I've been looking at MakerDAO's governance, which has, like, a successive proposal cycle. I believe Tezos also has something kind of similar. And you would basically be able to so right now, we we draft things on GitHub, like, a proposal, and then we we actually solicit feedback there. But we could kind of signal intent on like, once they get a PR is open, we could basically, like, have a signaling proposal or or initiate a an initial phase that would make all validators aware that that that proposal exists. And then there you could kind of go through different levels of of validation or or security review based on the maturity of that proposal. So that's, like, one direction that we're we're currently researching and and wanna improve. Another that we're thinking about is an emergency upgrade proposal. So right now, an upgrade if if there's a a security vulnerability that's that's detected, that doesn't square well with the current upgrade proposal process, which takes on the order of two weeks, to to execute fully. And, and so if that happens, then we basically need to go out of band somehow to, to upgrade the the chain. And this is just kind of a messy process, and and we would like to internalize that to the extent possible. So we're the current thinking is that, basically, we could have an alternative proposal type or an alternate like, an alternative variant to the upgrade proposal where, you know, like, a higher quorum threshold plus the, like, an n of n sign off by a security group. So having both of those those together would allow for a an immediate upgrade.

And

there's obviously, like, significant security implications to to being able to to upgrade a chain at any point. So that's something that we're still kind of discussing with our engineering and security teams to better understand, like, how to how to do that in a way that is, you know, balances the the kind of security disclosure process and, along with the the the kind of sovereignty that that, token holders have. And there's an additional element to that with or additional complication, which is that our security process needs to, like, extend to other chains. So if there's a bug in Tendermint or there's a bug in Cosmos of Decay that needs to be, like, disseminated in a a graceful way across the network, to projects that, you know, beyond the Cosmos Hub.

The main bulk of the question I asked though is I kind of pointed in the up other direction in frequency domain, like big slow things where the source isn't necessarily, the as technical of stakeholders, where you might need signaling to sort of capture from, the the broader body of users or dependence of the system some sense that something might need to change and how you could kind of again, obviously, future facing because it's early project, but, my one of my biggest areas of concern is generally that those groups, by virtue of their inability to make a technical proposal, are largely disenfranchised. So, like, what's the path to giving them a power to give feedback in this system?

Yep. So there have been nontechnical individuals who have made proposals. They I guess, there's, like, levels of technical capability, but there's a marketing proposal that was proposed to the Cosmos Hub and that passed, and and now they're, like, deploying funds. I, like, don't have a strong opinion about the, like, quality or the, you know, how that proposal is actually carried out. But this is definitely a question that I've been thinking about a lot. You know, what's what does the average Adam holder, like, what say should they have in the network? There's clearly some

just kind of low level technical decision making that they are not well qualified to, to contribute to. So there needs to be an effective method of delegation. That delegation needs to have the correct checks and balances,

and

and we're basically I I do think that the group's module plus the authorization capability, you know, we we get some interesting features there that we can start to experiment with, where we can have kind of technical review committees or or things like that. We can authorize specific things. I really like what you don't have, like, a a concrete answer for you except that, like, it's an area of interest that we want to, like, kind of explore further.

Yeah. And I'm honestly, I'm not poking at it because I'm, like, oh, God forbid, like, you haven't done what you need to do. It's actually just that there's this question of the difference between the technical capability to come to a solution with the, like, the right and the necessity of expressing some, like, preference that something's not right. So, like, even if you are not the person who's going to be capable or even a large number of people who are not, you know, low level technically savvy enough to find the solution. The the issues that they you might need to address might be still sensed from them, from their lived experience within using the things in the platform or within this this space. And, my struggle is to figure out how if I feel like something's off, but I'm not that person, can I even communicate? And then a life cycle that could give rise to a technical solution from a technically savvy person looking to address those other people's observed, you know, issues.

Yeah. At least some of that, I think, should fall more directly into, like, a a product user research cycle. Not all of it, but but when we start to think about, like, the the shared security product or the the kind of, financial instrument instrumentation, like, that's a an interface where where we really can start, like, iterating with users. There are aspects of the governance system itself that that we should also have that same kind of feedback mechanism. There's actually a pretty active I mean, our Telegram, there's, like, a number of telegrams, but the governance working group Telegram is quite active, and a lot of nontechnical people kind of do like to contribute advice or or strategy there. We're kind of limited in what we can what we can focus on just because of our own priorities, but we also have the the benefit of, you know, lots of experiments happening at once within the Cosmos ecosystem. So that's, like, one one way that I would really like to I don't think we have a a a feedback cycle there that's that's really sufficient. I would like to be learning much more from from very active chains or chains that have kind of modified their, their tooling in specific ways and and try to, incorporate the best of of those discoveries.

Yeah. We are so it's a good question. Each repo has its own contributing and and governance documentation. There's also we use GitHub for for all of our repo, kind of permission management, at at least at this point. And, we have a a very new, Cosmos improvement proposals repo that, that has it's supposed to kind of address concerns that are, like, more, you know, span multiple chains. So there's a discussion of, like, the, the address format or, like, the the key derivation or something that affects, like, a lot of different chains, and that was happening on the the CIP repo.

I would say that's so nascent that we're still kinda putting a lot of that in place. And we would like to to incorporate feedback from other chains there, but right now, we're we're trying to just kind of socialize it properly. The the Cosmos hub does exercise a lot of soft power within the ecosystem. You know, IBC was adopted on the Cosmos Hub, and then that kind of signal that it was, like, ready production ready for the remainder of the network. And similarly, like, security releases are are kind of rolled out with the Cosmos Hub first, and then other chains kind of in close succession. So that is one, you know, acknowledged, like, form of of governance there. Yeah. We it's it's a great question, and and it's it's a little bit early to to have, like, a a a kind of full response only because IVC, like, the Cosmos network has has only been live for a matter of months.

I really appreciate the invitation. I will post the the slides mostly because they have the those links to follow-up. And if you have other questions, feel free to to respond to that link and I can try to answer a couple of them. Thanks, everybody. Thanks. Bye.