Multiple foundations per blockchain?

Gabriel Shaprio brought up an interesting discussion around whether there should be a single foundation or single source of funding for blockchains, or whether ecosystems would benefit from a multi blockchain model. @chrisamccoy jumped in here:

What’s your take? Should protocols divide treasury responsibilities? Is it more about having competing funding sources for a healthy ecosystem (such as separately organized/managed DAOs vs. core foundations)?

It’s a critique that compliments Angela Walch’s critique regarding decentralization: There are many areas where power is concentrated and the blockchain community has not fully unpackaged those constructs. It’s definitely something worth further investigation. For example, whether fiscal sponsorship for sub-projects might make sense. If set up correctly, a fiscal sponsorship structure would centralized backend operations for cost savings, but allow sub-accounts/treasury, with distinct management teams, while still being publicly transparent.

Rather than a fiscal sponsorship structure, I think of this as hard governance:
A) A branch of governance is awarded Treasury ($USD and/or $STORE) to carry out its mandate
B) If it needs additional Treasury, it needs to lobby for it
C) The power of deciding additional Treasury resides with the Judicial Branch
D) The Judicial Branch is a hybrid of the United States Supreme Court and The Fed EXCEPT there is no unilateral decision making on protocol changes related to monetary policy. Any change to monetary policy that affects the rules of the protocol (the rules of the money) would require an approval from the Decentralized Branch and then an approval from the Executive Director (of the Executive Branch)
E) The Judicial Branch can reach consensus within the branch itself to accept or reject the request for additional Treasury from the other branches
F) If approved, the Judicial Branch transfers the $USD and/or $STORE to the receiving branch
G) The Judicial branch will have its own budget and if it needs to be increased, this would require a vote from the Decentralized Branch (the voters/miners of Storecoin)
H) At the beginning of each year, the Judicial Branch transfers the governance-approved yearly budget to the various branches
I) If yearly budget needs to change for any specific branch, it requires an approval first from the Judicial Branch. Then, an approval by the Decentralized and Executive Branches.

Few notes:

  1. Fiscal sponsorship was just an idea to highlight how different approaches can be taken.

  2. It is worth noting, however, that everything proposed in the hard governance framework can still be executed via fiscal sponsorship umbrella with sub-projects (i.e. branches). That’s just to point out the many opportunities that exist depending on the approach, it’s not an argument for or against fiscal sponsorship.

  3. The question comes down to what are the objectives/trying to achieve. Once those are identified, the best framework to achieve those goals is where there’s some fun infrastructure that can be explored.

On-chain block rewards that are not automatically paid to miners are first routed through the Judicial Branch as a monetary control. The Judicial Branch serves as almost like a CFO function for the protocol. It receives block rewards in a smart contract and then allocates them per governance and/or budgets.

A quick thought and a quick question.

Thought - regarding the chart, it’s confusing that it says “routed through the judicial brand” but then visually it shows the different categories of what the block rewards before the judicial branch icon. This just seems a bit confusing.

Question - what does it mean to be “routed” through the judicial branch in this case? What do they actually do before those reward categories accrue to their ultimate recipients. I’m asking practically, not philosophically? How does this not create a huge bottleneck - particularly for the dWorkers?

1 Like
  1. Good feedback on the graphic. That makes sense. We’ll re-design it.

  2. Onto your question about routing
    Routed is short for the block rewards first being programmatically sent to a smart contract that is overseen by the Judicial Branch (jBranch). The funds in this contract will be public. When a member of the Decentralized Branch (dBranch) or the dBranch as a whole achieves an incentive (i.e. upgrades hardware, compute, storage), the jBranch manually executes the payment to the nodes.

This additional checks and balances over budgets and payments gives the protocol sound financial controls but also mitigates friction between the dBranch and Executive Branch (eBranch). It’s plausible the eBranch – if responsible for distributing incentive-based payments – would have political incentives to withold payments to the dBranch. This flow and control solves for that.

In some ways, the jBranch is similar to the Congressional Budget Office (CBO) of the United States government which provides non-partisan analysis to facilitate Congress’s review of the yearly budget. We haven’t discussed the process of yearly budgeting and how budgets can be modified in detail but I can see a CBO-like function emerging from the jBranch (expanding the scope of the jBranch itself).

In other ways, the jBranch is similar to the role of the U.S. Treasury which executes the budget once it is in effect. This is the agency that makes payments, collects revenues and delinquent debt, and issues reports including Treasury Statements.

I like this and think this is a good start. Particularly, I think points G and H are vital as they ensure checks and balances and provide a halt against releasing funds too liberally.

Because of how some of our block rewards work (the different funds that make up the left side of the rewards) it requires some proof that things were done in order to allocate rewards to miners. I am assuming this proof can’t be automated on-chain, otherwise that would be superior. So, because of an issue such as determining validator setups for infrastructure, there would be someone (jbranch) that needs to ensure that setup did exist and if so they make the necessary payments. I assume the jbranch would run some kind of software to track all of these payments that must be made / what has accrued.

I would worry about how difficult it would be for the judicial branch to review everything, not commit errors, and make sure what happens is what is supposed to happen. This does require miners to trust whoever is running the jbranch, but the number of rewards coming from this will be relatively smaller compared to the larger stake-based miner rewards.

My general thought is it could be a bottleneck and get complicated if the calculations are being handled manually, but if the smart contract does all the work and the branch is just there to confirm/deny something then it shouldn’t be that much of a bottleneck. It really depends on how much manual touch is happening here.

Know-Your-Voter will be applied to this scenario and others where collective “proof” is required. In this specific scenario, miners have to prove to each other they have satisfied the infrastructure requirements. Once the KYV deadline has passed, rewards would be distributed off-chain to the miners that were accredited through KYV. For miners who didn’t upgrade, they can either go through arbitration for a chance to prove they did indeed upgrade. If they win, they remain in the network and receive the bonus. If they lose, they would lose their seat in that particular market.

The Judicial Branch will be allocated block rewards to facilitate governance, budgets, and arbitration. It will be its own entity with its own yearly budget and its own staff.

Per above, the jBranch is similar to the role of the U.S. Treasury which executes the budget once it is in effect. This is the agency that makes payments, collects revenues and delinquent debt, and issues reports including Treasury Statements. Some of these payments are automated with KYV and without KYV. Others will be manual. The jBranch will have its own operating budget to staff this function.

Here’s our next version.