[Proposal] Iterating toward robust governance

Hey all! I’m Matt Luongo, longtime privacy advocate and Iron Fish admirer.

About me

I’m a crypto dev and the founder of Thesis, the studio behind tBTC, Fold, & Taho.

Back in 2019 and early 2020, I got involved with Zcash’s governance debate around the expiring Founder’s Fee, eventually proposing ZIP-1011, which became the basis for Eran’s successfully accepted ZIP-1014, outlining Zcash’s current network governance.

I’ve known Elena since 2017, and am a small angel investor ($10k) in IF Labs.

A modest proposal

Since hearing about the Foundation’s RFP, I’ve been giving Iron Fish governance some thought. Here’s how I’ve been thinking about the network, its stakeholders, and how governance might grow more robust over time.

Before designing a governance structure for a network, it’s important to understand exactly who and what will be governed.


Iron Fish has more stakeholders than your typical payments-focused PoW network… because it has more tokens!

Here are the stakeholders I’ve been considering so far, and a quick summary of their potential motivations.

  • Users of the network.
    • IRON users
    • ETH, BTC, USDC, DAI users on IronFish
    • Users want privacy, security, resilience, and convenience to transact.
  • Holders of network assets
    • IRON
    • ETH, BTC, USDC, DAI holders on IronFish
    • Some holders care a lot about the size and robustness of the anonymity set, while others care primarily about price action.
  • Full node operators
    • If Bitcoin and Ethereum have taught us anything, it’s that full node operators want nodes to be cheap and easy to run.
    • On Bitcoin, the UASF of 2017 showed us that full node operators can be a powerful force governing the network.
  • Miners
    • Miners care about the costs to mine, including hardware, power, and operational overhead, as well as the complexity to mine.
    • Miners are also the most price sensitive of any stakeholder in a PoW network, as the price of IRON dictates whether they can keep the lights on.
    • Over the years, Bitcoin and Ethereum have shown that miners aren’t always long-term aligned governance participants in a network.
  • IF Labs
    • IF Labs is the primary employer of the dev team, and are presumably well-aligned with the growth and success of the network.
    • As a central entity, IF Labs will need to be more risk averse than other stakeholders, which could lead to future governance conflict.
  • IF Foundation
    • The Foundation is newer than IF Labs, and also presumably well-aligned with the growth and success of the network.
    • As a central entity, the IF Foundation will need to be more risk averse than other stakeholders, which could lead to future governance conflict.
  • Independent protocol developers
    • Some protocol developers work on networks for their own personal reasons.
    • These developers don’t work at IF Labs or IF Foundation, may or may not be doxxed, and may or may not be in a similar jurisdiction.
    • For these reasons, their motivations might be more or less aligned with the success of the network, depending on circumstances.
  • Application developers
    • Application developers want to build atop crypto networks. I’m one of these! :wave:
    • App devs might be interested in pursuing their passion, or profit, or both.
    • Because app devs aren’t employed by any network-related entities, and they often own quite a bit of the apps they build, they may or may not be well-aligned with the success of the network. Notably, early app devs in a successful new network often reap outsized rewards, so there is an incentive if the dev believes their efforts can grow the network.

If I’ve missed any major stakeholders or mischaracterized anyone’s incentives, please let me know and I’ll update this list! In the meantime… let’s talk about the stakes.

What can be governed?

Now that we have a list of stakeholders, we can talk about what they might have a stake in… and what could conceivably be governed around the network.

  • The Foundation’s treasury
    • The Foundation is governed by US law as a Delaware LLC, following its partner agreement.
    • The Foundation has been allocated 18% of the IRON genesis supply, and likely has a cash treasury as well.
    • While I don’t know much about the Foundation’s ownership, I hope that its organizing docs clearly align it with the Iron Fish network (eg over short-term profits or other partner interests).
  • The Iron Fish website and trademark
    • Currently controlled by the Foundation
    • I haven’t done a TM search, but I believe the Foundation is the de facto TM holder. If the TM hasn’t been registered in the US and EU, it probably should be.
  • The primary node implementation
    • The node implementation is the infrastructure for a number of social goods on the network, including…
      • A shared anonymity pool
      • Enforced property rights
      • Soundness of the monetary supply
      • Liveness / availability, including ensuring timely access to funds & resilience to DoS attacks
    • It’s unclear to me who controls access to the current repo, or who owns the copyright.
    • Ultimately, miners and node operators can choose to use a different implementation. If an economic majority agrees with them, that implementation could become “primary” through social consensus.

What can’t be governed?

  • IF Labs’ treasury
  • IF Labs’ corporate decision-making

IF Labs is a privately held company, and has taken significant outside investment. They have a board, a CEO, and their own corporate governance. Presumably, investors, founders, and employees all hold and perhaps are partially paid in IRON, aligning their interests with the network.

Nevertheless, they are a private company with a different set of stakeholders and governance. They aren’t going to make decisions solely based on IRON users, voting, or other governance schemes without a contractual obligation.

Principles of Network Governance

There are a few useful principles we can rely on to design network governance.

Voice or exit — Miners, node operators, and users who disagree can always fork off. Using the primary node implementation is consenting to the rules it enforces.

No taxation without representation — Anyone who pays fees or has their livelihood or freedom secured by the network deserves a voice.

Socialized problems require socialized solutions — Growing the ecosystem won’t be done by charitable individuals; it needs collective action and pooling of funds. Similarly, we’ll need things like bug bounties (security) and more independent users (growing the anonymity pool).

Recommended Structure

Every peer-to-peer network has to start with some level of centralization — at a minimum, as an idea in someone’s head. The Iron Fish network has grown quickly since inception, and isn’t a centralized effort today.

Still, the community needs time to bootstrap governance and operating cadence. Here’s a 3-phase plan that I believe can act as the blueprint for Iron Fish network governance.

Phase I — Bootstrapping

In the first phase, we want to lay the groundwork for future governance efforts while keeping operations simple.

  • The Foundation retains discretionary control of its treasury.
  • The Foundation publishes a Mission, Vision, and some sort of “Community Constitution” or “Iron Fish Values”. Ideally, the LLC agreement is aligned with this publication.
  • The Foundation publishes a trademark policy to head off contentious forks.
    • Either the policy should consistently support an economic majority, or…
    • Support by the Foundation’s judgement against its published “Iron Fish Values”.
  • Hard forks blessed by the Foundation should be called “network upgrades”.
  • The Foundation seeks clarification of the copyright ownership of the primary node implementation, ideally taking ownership or negotiating a copyright assignment that will deter close-sourcing in the future.
  • The Foundation forms 3 advisory councils
    • 5 members each
    • Initially recruited by the Foundation and installed directly.
    • Terms are 1 year, though half of the first batch will have an 18-month term to avoid total-council churn.
    • Council constituencies
      • Privacy - Holders & Users
      • Development & Tooling - Application & Protocol Developers
      • Consensus - Miners & Full-Node Operators
    • Councils meet on a regular cadence, and when necessary, make non-binding recommendations to the Foundation with a majority vote.

Phase II — Democratization

Up until this phase, the Foundation has chosen its council members rather than open elections. The reason here is simple — Sybil-resistant voting is difficult, and even sometimes at odds with the other goals of a privacy project.

In this phase, the Foundation brings the community further into its governance process, developing whatever signalling mechanisms are necessary.

  • Each advisory council should now elected by its constituency
    • The Privacy council is elected by IRON holder coin signalling, as well as signalling from the top 3 largest private assets on the network.
    • Mining is elected by miner and full-node signalling.
    • Dev & Tooling continues to be installed by the Foundation, as there’s no obvious Sybil-resistant signalling mechanism today.
  • Advisory council recommendations should become binding, either by commitment from the Foundation, contract, or some other means.

Phase III — Ossification

In the final phase, we aim to build a governance structure that’s resilient to single points of failure, and won’t need to evolve much further.

That means de-risking the capture of…

  • The Foundation’s ability to coordinate funds across the ecosystem
  • IF Labs’ efforts as the primary dev team

We can achieve these by

  • Promoting multiple, independently funded client development teams.
    • The Foundation should recruit an outside firm or DAO to develop an independent node implementation, ideally with sustainable funding.
  • Promoting multiple websites, block explorers, and other necessary user-facing infrastructure.
  • Diverting a % IRON emissions to an autonomous org.
    • This DAO can derisk the capture or closure of the Foundation
    • It can be implemented on an L2, or via a pool of funds that can be unlocked by miner-signalling.
    • The DAO should fund independent protocol and application developer grants, further derisking any issues with IF Labs.

Note that this phase is far-reaching, and also more vague. Getting here will likely take 1-2 years, leaving time for further discussion and refinement.

Further work

I believe this phased approach will lead to a balanced, fair governance process for the Iron Fish network, as well as constrained, thoughtful stewardship of the early network’s growth.

There are a number of open questions, both technically (signalling mechanisms, autonomous organization) and legally (TM and copyright concerns) that deserve follow-up effort, and perhaps a small working group organized by the Foundation.

In the meantime, though… we have this forum! I’m looking forward to feedback from the community, IF Labs, the Foundation, and anyone else who believes privacy is a human right.

1 Like

Before commenting I believe we need a better understanding on how the Foundation and IF Labs are setup.

Agree here. Higher level i get that the Foundation focuses on the development of the ecosystem while Labs is in charge of developing the protocol, but more detail here would be helpful.

1 Like

Do we need ‘holders & users’ to have seperate representation during the Bootstrapping phase? imo, these are basically represented by the other consitituencies and we don’t really have ‘users’ until we have IF bridged to other chains and people using it for day-to-day private payments (in which case we are probably out of the bootstrapping phase). I would be in favor of over-emphasizing builders in the bootstrap phase and having separate representation from application and protocol devs.

@mhluongo thanks for writing this up, largely agree with everything else in the proposal!

1 Like

It’s the same council either way, so I don’t think it hurts! I hear you though, user numbers will be low through bootstrapping.

This is interesting. They both have fairly different needs, and protocol dev is mostly covered by IF Labs until the 3rd phase, so separating them makes a ton of sense to me.

1 Like