Category: pieces

  • Progressive Decentralization From a Small Group

    This framework abstracts the governance model I designed for MetricsDAO into a generalized playbook. It is designed for small but growing organizations looking to progressively decentralize without sacrificing operational stability.

    Role-Based Governance Design

    The roles defined here can be expanded by the community via governance proposals at any time. This list is not exhaustive but reflects the bare minimum for governance to function at the outset.

    Roles

    Governance is not run by token weights but by roles. Any individual or entity participating in the community can hold one or multiple roles, as long as they are able to adequately perform their respective duties.

    There are two kinds of roles:

    Operational roles, those involved in day-to-day functions of the organization, and governance roles for those participating in the processes surrounding the organization.

    Governance roles are: Voter, Voter Lead. The Voter community can decide to introduce new governance or operational roles at any time via valid governance output.

    Voter

    Voters are the foundation of the governance system. Voters are active in the organization and community discussions as contributors, researchers, community moderators, communications leads, treasury stewards, working group coordinators, educators, and active governance participants. They publish proposals, comment on RFCs and participate in polls, so that governance is the most reflective of the will of the community at any time.

    Prospective Voters get appointed after they:

    • Apply with their reasoning to be accepted
    • Have affirmative confirmation from other Voters. Only Voters can approve a prospective member.

    Initially, a seed round of Voters will be designated as the governance system gets implemented, drawing from existing active contributors and expanding to include members of the broader community.

    Only Voters can participate in polls concerning Governance decisions.

    Voters are required to uphold the community’s Code of Conduct and should work towards furthering the organization’s mission. Governance should strive towards ossification and automation as much as possible. The foremost question at the heart of each new proposal should be whether it makes processes easier and more efficient. Governance should strive to make itself obsolete in the long run.

    Voter roles can be revoked at any time by a Voter Lead should the Voter exhibit behavior that is in violation of the Code of Conduct. If other Voters file a complaint about a member, the issue will be brought up as a poll on whether to retain the Voter or begin an offboarding process.

    The Voter community can decide to establish expiration criteria for roles via governance proposals at any time.

    Voter Lead

    All governance roles are managed by one or more Voter Leads, who have sole control over the role assignment system. The Voter community can decide to use a different role management tool at any time via valid governance output.

    The Voter Lead’s responsibilities include:

    • Checking if proposals are correctly formatted, submitted in the venues, and are well-shaped, understandable, and not in violation of the Code of Conduct or organizational purpose
    • Granting Voter roles to those approved by the attestation process
    • Revoking Voter roles in the event of a departure or clear violation of the Code of Conduct, or if otherwise instructed by valid governance output
    • Answering questions about governance processes and aiding proposal authors along the lifecycle of a proposal

    The Voter Leads can be appointed by the Voter community at the start of a new season. There can be multiple people performing this role, with the maximum number determined by the community at the start of each season.

    Should a Voter Lead behave in a manner contrary to the Code of Conduct, they can be replaced via an emergency poll. If a proposal to replace a Voter Lead is supported by community members, as indicated by explicit consent via a reply to the proposal, the Voter Lead may be stripped of their status. The implicated Voter Lead cannot revoke any Voter roles for the duration of the poll.

    Poll

    A governance poll is the culmination of the proposal process.

    Each poll must have at least four options:

    • Yes: In favor of the proposal passing as it is presented
    • No: The proposal should not be implemented in its current form
    • Abstain: The vote will be recorded but will not count towards the result
    • No with Veto: The proposal should not pass, and the Voter has strong objections

    Additionally, Voters can choose to use Instant Runoff Voting, Approval Voting, or Borda Count Voting when multiple options can be selected. Each new voting system must be approved via a successful proposal first. Each voting system must include options to Abstain or to Reject all options, representing a No with Veto. A poll will be deemed unsuccessful if 34% or more of Voters choose to Reject all Options.

    Polls can be created by designated personnel with the appropriate role.

    Each successful poll of an adequately shaped proposal is considered valid governance output.

    Proposal Lifecycle and Voting Process

    A poll of all Voters is the culmination of the proposal lifecycle. This is where Voters decide how the community moves forward and what gets implemented.

    A proposal goes through at least the following stages before it is considered valid governance output:

    Formal submission

    A proposal is formally submitted when it is entered into the Governance category of the community forum. Proposals have a sequential numbering that the author should take into account. Standard proposals have a three day (72 hr) feedback RFC period. Proposals requiring significant structural or legal action require a four day (96 hr) feedback RFC period. Emergency proposals can shorten that period to at least one day (24 hrs), but have more stringent quorum requirements.

    A proposal template should be found at the top of the Governance category in the forum. Proposal authors should publish their proposals so that the RFC period does not overlap with weekends where possible. This ensures maximum participation and respects off-time and family obligations.

    Frozen period

    After the RFC period, the final proposal that incorporates any community feedback the author wishes to address must remain visible on the governance forum for one day (24 hrs). For proposals involving significant structural or legal action, this period is two days (48 hrs). Emergency proposals do not have a frozen period.

    The proposal author must formally submit the proposal to a poll by replying to the original post with a simple declaration of intent, for example: “Submitting this proposal to a poll.”

    Poll

    Polls last for two days and start on a set day and time each week. If the frozen period ends after that time, the poll goes up the following week. Proposal authors should keep the governance cadence in mind when submitting to avoid undue delays.

    Emergency polls can be triggered at any time after a valid proposal has been submitted.

    Each poll must contain at least:

    • The title of the proposal, matching the forum post exactly
    • A sentence summary of the proposal
    • A longer summary, ideally no longer than two paragraphs

    Poll tallying

    At the end of the polling period, a proposal is deemed ratified and considered valid governance output when:

    • A minimum of 33.1% of all Voters have cast a vote (quorum)
    • A minimum of 50.1% of votes cast are Yes (approval)
    • No more than 33.1% of votes cast are No with Veto (veto)

    Abstain votes are to be counted as votes cast for the calculation of percentages.

    Emergency polls pass as soon as they meet the following criteria and do not need to run for the full period:

    • Quorum
    • A minimum of 67% of votes cast are Yes
    • No more than 33.1% of votes cast are No with Veto

    Implementation

    After a poll has successfully passed, it is up to the relevant parties to implement the proposal in a way that reflects the intent and specific declaration of the proposal author as closely as possible. The proposal author should be available to answer questions.

    Should any circumstances arise that would require implementation distinctly out of line with the original proposal, a new proposal must be submitted reflecting the changes on the ground.

  • MetricsDAO Governance

    MetricsDAO was a crypto analytics DAO that provided educational materials and connected crypto protocols with onchain data analysts. I joined in early 2022, brought in to help with governance, and stayed through the end of the organization.

    Where We Started

    When I first got to MetricsDAO, governance was having growing pains. The DAO already had a legal entity and a set of bylaws drafted with outside counsel during its incorporation. The problem was the governance structure those documents described was built around a token that hadn’t launched and had no firm timeline. In reality, decision making was being done through Discord messages and voting with emojis. It worked at the beginning, but was starting to show its weaknesses as the DAO grew and started to do more. There wasn’t much structure, and what existed wasn’t written down.

    Minimal Viable Governance

    The first thing I did when I started was work with other members to establish a constitution. This was a governing document that laid out decision making procedures before a token was released. The structure was built around contributors organized into pods, with elected pod leaders making up a Governing Council that served as the ratifying body. We wanted to keep the founders of the DAO as part of the structure, but realized that many of them had other responsibilities. To keep them involved, we also created a Genesis Council, made up of the organization’s founding members, who held an advisory role and retained their voting power. Seasons operated on fiscal quarters with two-week off-seasons built in for reflection and amendments.

    Since the DAO was still young, the proposal process was built to be relatively lightweight to allow decisions to be made quickly. We used an optimistic voting system, meaning proposals would automatically pass unless enough people actively voted against them. It didn’t make sense to make everyone get involved with every decision, but it was also important that contributors could have a meaningful way to disagree with any direction the org was going. The constitution was ratified through an onchain Snapshot vote, starting a public record of governance for the DAO.

    The Next Step

    About a year in, with a better read on how the DAO was operating, I designed a new governance system in collaboration with other contributors and with review from outside legal counsel. It was encoded into a new set of bylaws. This new system was built around a longstanding goal from the DAO to become increasingly decentralized. However, we had seen other scenarios where decentralizing in a way that wasn’t well planned resulted in a functioning organization becoming too chaotic to operate efficiently. As new contributors join, shared context becomes more diffused, and existing initiatives need to spend resources integrating the new members. The core problem we needed to solve was: how do you expand who has a say in an organization without destabilizing the people doing the work?

    The original constitution had contributors and governors as distinct classes, which made sense operationally but created friction in governance. More importantly, it meant decisions were all made by a small internal group. The analysts and broader community that MetricsDAO existed to serve had no formal voice in decisions that sometimes affected them.

    The new system introduced two membership classes. Core Contributors were the people running day-to-day operations, while Stewards were a new class. Stewards were meant to be analysts and community members who weren’t doing internal work in the organization but had a stake in how the DAO operated. MetricsDAO existed as a bridge between analysts and other entities in the system. Core Contributors were the structural supports of the bridge. But the bridge exists for the traffic on it, the analysts themselves. The kinds of decisions each group should weigh in on aren’t always the same, and having two distinct classes allowed governance participation to be scoped to what was actually being decided.

    The expansion of the Steward class happened through a relatively informal onboarding process. Prospective Stewards applied through a dedicated channel with a short pitch, and needed seven affirmative votes from existing members to be brought in. With the size of the group at the time it was enough to show trust in an individual without requiring everyone to be able to vouch for them. The expectation wasn’t to recruit entirely new members directly into the Steward role, it was to formalize the participation of people already adjacent to the community, analysts and regular contributors who had already demonstrated they cared. The Core Contributor group would keep operations stable while that expansion happened gradually.

    Our proposal process also changed slightly. The original version used a binary Yes and No voting system. It was functional but it lacked the depth needed to signal opinions around complex proposals. We replaced the binary with four options: 

    • Yes 
    • No
    • Abstain 
    • No with Veto

    Abstaining needed to exist as the organization grew, as people would be exposed to more decision making that was outside their domain, and while we wanted to encourage participation, we didn’t want people to feel forced into taking a position they weren’t comfortable with. A No with Veto vote expressed a different signal than a regular No vote. A normal No vote was intended to mean that while the current iteration of the proposal wasn’t acceptable, the voter would be willing to consider a reworked version. A No with Veto vote signaled that someone thought an idea was fundamentally flawed, and that no revisions would be enough to change their mind. If a proposal gathered enough Vetos, spending more effort on iterating would be wasted.

    The membership structure and voting design were both aimed at a longer-term goal that we referred to as governance ossification, governance structures robust enough to need less and less reinvention over time. Complex governance processes only make participation harder, and that becomes even worse when they’re always changing. The concept draws from writing on governance minimization in crypto, the argument that dependable systems tend to govern less over time which reduces potential attack surfaces and the overhead that governance itself creates. Applied to a small DAO, governance that needs to redesign itself every few months is fragile. The right moment to stabilize looks different for every organization, but designing toward it from the start is different from stumbling into constant reinvention.

    Below, you can read the generalized framework developed for small organizations looking to decentralize, as well as the actual legal bylaws we implemented.

    MetricsDAO Bylaws

    Progressive Decentralization From a Small Group

  • DeFi with oranges: Yield Trading

    It’s January 1st and you’re a farmer that is trying to plan your business for the rest of the year. With current estimates, you think your orange trees will produce 50 bushels, worth $5000. However, there was a late freeze last year which destroyed half of your crops. You’re concerned that this could happen again so you want to find a way to hedge your risk. You draw up a contract that represents rights to all of the oranges that your trees have grown by June 30th and look for a buyer. Someone might buy your contract for several reasons. First is that you might be willing to sell the contract for less than $5000 but more than $2500. This would protect you from the kind of downside you faced the year before, while if everything goes as predicted the buyer will make the difference between $5000 and the price of the contract. A second possibility is that the buyer of the contract believes the price of oranges will increase by the time of harvest, making the 50 bushels worth $6000 instead. Similarly, they could also expect the price to remain the same but the trees to produce more than 50 bushels. In all three situations, you hedge your risk by collecting your money up front, while the buyer takes on some risk over a longer time horizon for more benefit. The buyer of the contract can freely trade it afterwards as well, and many trading opportunities can occur as people have different opinions on how many oranges will be harvested and/or what the price of oranges will be in 6 months. 

    A month later, you decide that you want to get out of orange farming all together. You’ve already promised the oranges that will be grown are owed to the holder of the first contract, so you can’t sell your trees immediately. Instead, you draw up another contract, which entitles someone to all the trees in your orchard on July 1st. To make up for the time that they won’t be able to take possession of the trees, you sell the trees for less than they would be worth at current market value. In this situation, you free up capital early to reinvest into something else, while the buyer gets a discount on the trees they want, as long as they’re willing to be a little patient. In this situation too, the buyer can trade their contract as they see fit, and the final holder will be the one that takes possession of the trees on the date of expiration.

    When generalized, you can call the orange trees the principal, and the oranges themselves the yield. Any asset that passively accrues some value can have this framework applied to it, as people use their own assumptions and modeling to determine how much income an asset will generate and how to value both that income and the asset itself.

  • DeFi with apples: Automated Market Makers

    You’re at the market and want to buy some apples. In the middle of the market, there’s a big book that people can record things in. People that want to buy apples write down how many they want and at what price they’re willing to buy, and people that want to sell apples do the same in reverse. A trade happens when a buyer and seller agree on a price and quantity.

    This is the standard central limit order book (CLOB) system that most stock brokerages use. In big markets dealing with popular assets like apples, there are usually also businesses built around constantly filling both sides of the book to keep the market liquid. These businesses require significant capital, and generally only focus on the largest markets.

    So what happens if you actually want to buy oranges, and there isn’t a company willing to be a market maker that fills both sides of an order book? The issue isn’t a lack of buyers or sellers, or that the price isn’t determinable, it’s that trading gets tricky when there aren’t many offers on either side. An orange might truly be worth $2, but if the buy side only has an order for $1 and the sell side only has an order for $3, anyone that wants to buy or sell an orange is going to have to be out a dollar.

    One way to solve this is by creating a marketplace that doesn’t need an order book, and instead lets trade happen at any time by setting pricing according to an algorithm.

    Imagine in this same market, the book in the middle gets replaced with a magic scale. The scale has a spell on it such that the two sides must always be balanced, and that the number of objects must always multiply to a fixed number set when the scale was calibrated. Taking the same example of oranges, let’s say the scale gets set up when oranges are $2. Someone puts 5 oranges on one side, and 10 dollar bills on the other. People can buy and sell oranges at any time, as long as the number of oranges times the number of dollar bills is equal to 50, the scale stays balanced. When you generalize the concept, you can use a formula like x * y = k, where x and y are the units of each asset and k is a constant value. 

    Going back to our oranges, if I want to buy 3 oranges, I take 3 from that side, leaving 2. To know how much those oranges are going to cost, we can do the math of 50 (the constant target) divided by 2 (the number of oranges left). This means that there would need to be 25 dollar bills on the other side to keep things equal. There are already 10 dollars there, so I would need to pay 15 to rebalance the scale. You might notice that the price of the oranges here isn’t 2 dollars, but rather 5. This difference is called price impact. It happens when you try to make a large trade compared to the amount of liquidity available. Since there are only 5 oranges, buying 3 is taking up more than half the supply, which naturally moves the price much higher.

    On the flip side of that, let’s say I want to sell 5 oranges instead. We start with the 5 on the scale, add 5 more to get 10, and then divide 50 by that to get 5. Since there are 10 dollars on the other side of the scale, I need to take 5 to get back to a balance. The same principle of price impact applies here, just in the other direction.

    The effect of price impact is reduced when there are more people willing to add both oranges and dollars to each side of the scale. If the scale had 5000 oranges on it, removing 3 wouldn’t require much change on the other side. The people who add both oranges and dollars to the scale are called liquidity providers, and the assets they provide are collectively called a liquidity pool. When you make a trade through this pool, you pay a small fee, just like you would on a brokerage platform. In this case, the fee is split proportionally between the liquidity providers. This fee gives liquidity providers a way to earn money for keeping the system running smoothly.

    In both of these directions, people can continue to buy and sell oranges to an infinite amount. So, while traditional markets need buyers and sellers to line up their prices, an AMM system lets anyone trade anytime.