Category: pieces

  • Prosocial Crypto Protocols: PoolTogether and HaloFi

    Money-focused crypto projects tend to fall into one of three categories. Extractive ones like pump.fun are almost always moving resources toward a small number of people, usually from latecomers who don’t know better to insiders who prey on them. Neutral ones like Uniswap are simply infrastructure, they can be used in extractive ways, but can just as easily be used to help. There’s also a third category, that I think of as prosocial projects, ones that are actively trying to do something useful for people outside the system.

    There’s been a lot written on the first category, less on the second, and almost nothing on the third. I believe that’s in part because the projects that fit into this category aren’t focused on speculation, which tends to drive attention in the crypto space. That speculation is driven by the desire for asymmetric upside, which can be tempting for anyone, but especially for people who don’t have resources to work with in the first place.

    A lot of people play the lottery. The standard advice is to put that money in a savings account instead, but that advice doesn’t work in reality. A high-yield account right now gets you around 3 to 4% in yield. Someone spending $10 a week on lottery tickets isn’t going to be moved by the math that says if they save for 10 weeks they’ll earn $3 more a year. The number is too small and the psychological appeal isn’t there. The lottery is appealing because it’s one of the only ways someone can realistically see themselves getting an outsized outcome from where they are.

    Two examples of projects that I think fit into the prosocial category are PoolTogether and HaloFi (formerly known as GoodGhosting). Both took direct aim at this problem, in different ways.

    PoolTogether was a project designed around the idea of a lossless lottery. Participants deposit money into the protocol in exchange for raffle tickets. The lottery still happens, but the pot that the rewards are paid out of comes from the collective interest on the entire pool of money deposited into the protocol. At a large enough size, the interest that communal pot generates is significant, and you still have a chance at winning a portion of it. Meanwhile, your tickets aren’t used up week to week, and your money can still be removed from the principal at any time by swapping your raffle tickets back, so you can’t ever lose the money you put in.

    PoolTogether was doing this, and had real momentum. At its peak, it had just over $230 million in deposits generating interest that was given out in weekly lotteries. There were real success stories too, with one user who deposited $74 winning just under $40,000 on their deposit, which they could still get back afterwards.

    HaloFi took a different approach. Instead of a lottery, it tried to focus on building steady savings habits by making saving competitive. Challenges would be set with savings goals and time periods. For instance, one might be to save $100 over 10 weeks, with weekly deposits of $10. Similar to PoolTogether, any money deposited would go into a communal pool used to generate yield. At the end of a challenge period, if you kept up with your deposits, you got your entire deposit back, along with a proportional share of the yield generated. If you didn’t manage to make each payment, you still got your entire deposit back, but the yield that you would be entitled to is instead distributed evenly to those who did complete the challenge. You could also withdraw your money at any point before the challenge was over. The mechanism worked, people didn’t want to give up their yield, and kept coming back to make their deposits. There were success stories here too, with more than four million dollars being saved.

    Unfortunately, neither of these stories end well. PoolTogether was taken to court by a man named Joseph Kent, who alleged they were running an illegal lottery that was hurting its users. His standing for the case was that he deposited $10 in the protocol, and transaction fees during the deposit had already outpaced any expected returns. What wasn’t mentioned was that he intentionally used the least efficient method of depositing his money, choosing to pay the maximum amount he could. While PoolTogether offered ways to deposit into the protocol for fractions of a cent, Joseph simply did not use them. The case was eventually dismissed, but it took community fundraising to pay the fees for years of a protracted legal battle, from 2021 till its dismissal in 2023. By this time, the protocol had lost its momentum, and along with the volatility in the overall market, it faded from prominence.

    Something worth noting here is that Joseph Kent is not your average user. He was the technology team lead for Elizabeth Warren’s presidential campaign in 2020, and Warren has made opposing crypto a consistent part of her political platform. I can’t say for certain that this was coordinated, but the people most motivated to see this project fail had direct ties to the lawsuit that did it.

    HaloFi’s end was quieter. The mechanism worked, and the users were there, but there was no viable path to funding the business itself. Any fee they could take from the generated yield was too small to matter operationally, and would have come directly out of what users earned. In late 2024, they announced they couldn’t secure another funding round and were shutting down. This brings us back to the problem with a space so heavily driven by speculation. It isn’t just everyday people chasing asymmetric upside, venture capitalists and investors are looking for it too. A prosocial project designed to slowly and safely build wealth for its users doesn’t offer a 100x return to early investors, which makes raising money to survive as a business in the space incredibly difficult.

    These were two projects trying to do something useful for people outside of the system. HaloFi is gone, and while PoolTogether technically survived its legal battle, it exists as a fraction of its former self. But the underlying mechanisms worked. A $74 deposit winning $40,000 and four million dollars saved are real-world benefits. If there was more interest from investors and less hostility from regulators, there’s no reason ecosystems like this couldn’t thrive.

  • 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.