Proposed Governance Structure: Legislative and Executive

Here is the proposed two-part governance system: Legislative and Executive branches.

Executive Branch:

  • Multisig
  • Executes contract upgrades and parameter changes

Legislative Branch:

  • TCP token Dao and voting
  • inflation rewards for voting
  • Dao has control over:
    == Where foundation TCP tokens are allocated and distributed
    == Where protocol income is directed
    == Which Executive multisig has power over the protocol
    == What the executive multisig can update

This setup allows protocol parameters to be controlled quickly by those who understand the protocol and can commit their full attention. Token holders do not need to vote on every change. Still, they hold ultimate power over the updates by being able to “fire” an executive multisig and to limit what the executives can change.

Note that there would still be a hardcoded deadline when the executive branch can no longer take specific actions. Still, before that, the legislative branch can limit the range of possible values or turn off the ability to make a specific change altogether.

Thoughts? What are the possible issues with this setup?


It’s a great idea and it could help facilitate the executive branch to carry out important tasks more quickly than under a traditional DAO governance structure, e.g. MakerDAO or Compound. Given its parallels to some governance structures in the “real world”, it seems like an idea that has probably been considered by other DAOs before but I cannot think of any off the top of my head. Maybe others would know.

The first issues that come to mind are how to avoid malicious governance, hostile takeovers, and/or misaligned incentives.

I tend to think that we should get expert feedback on these ideas before risking a DAO governance structure that is uncommon, as much as I like the underlying concept. Have we considered seeking a DAO advisory service that has experience mentoring a large number of DAOs and may have seen something like this before? For example, Aragon has a collection of experts that can be hired for DAO consulting. I also know of Yury Lifshits over at SuperDAO offering similar services. There are probably others.

On a tangential note, I have also been wondering about whether audits, bug bounties, and economic modeling will be happening. I know these services require time and money and don’t guarantee 100% safety, but they would certainly help. Maybe this is better suited for a separate topic.

1 Like

I’m going to wait for Lucas’ detailed thesis before I really weigh in.

1 Like

Tahnks @jaypow! I submitted a proposal to the Aragon DAO experts channel here:

Yes, let’s talk about economic modeling audits, and bug bounties in another topic! Feel free to start that topic whenever you find the time.


I think “Direct Democracy” is a poor form of governance for Defi. It is technically simple (one token, one vote), but the resources required to participate in direct democracy is a burden that vastly outweighs any benefits.

  1. Direct Democracy requires stakeholders to be knowledgable
  2. Direct Democracy requires stakeholders to be present

I own some shares of Apple. Imagine Apple has weekly or daily shareholder meetings during which shareholders call in and vote on every single corporate decision. It would be a disaster because most shareholders do not have the time or knowledge to participate. Rather, corporations figured out that it’s much better for shareholders to be represented by a board that oversees executive decision making.

So direct democracy is a shitshow, and hiring professional decision-makers is better.

Malicious governance takeovers are a result of lazy coding and half-baked incentive structures. If a protocol is designed so that the treasury can be drained by governance, then it’s designed to be taken over. If a protocol is designed so that oracle data can be manipulated, then it is designed to be attacked. Maker is working with banks and using USDC because it is designed to be able to do so. Code is law especially if the code sucks.

The key defense against hostile takeovers is to design the protocol so that there is no benefit to taking over the protocol!

  1. Build it so the treasury cannot be drained.
  2. Build it so that oracle data cannot be manipulated.
  3. Build it so that if somebody has too much control, the protocol becomes less valuable, so that anybody who starts accumulating control is actually devaluing their position. If the protocol is valuable because it’s decentralized, then centralizing it makes it not valuable. If somebody owns most of the tokens, then the sell pressure they would create by attempting to profit would destroy their wealth.

Ok. But isn’t this system not trustless because you are literally trusting people with executive keys to make the right decisions?

Stakeholders also trusted these people to design and code the protocol properly. If the protocol launched immutable, then stakeholders would be putting a ton of trust into the developers getting it right the first time. Giving the creators some time to make sure it works actually dilutes trust so long as the incentives are correct.

Executive key holders should not have access to the treasury or parts of the protocol that would let them benefit without all stakeholders also benefiting.

Imagine a panel of levers that control the protocol. We can put these levers into three categories:

  1. Levers that can never be used by anybody (ie oracle data, access to collateral)
  2. Levers that can be used by the executive branch. Tokenholders can disable and enable these switches, or move them to category 1.
  3. Levers that will be accessible to tokenholders after the executive branch is dissolved.

It would be cool to create a GUI of this panel so the community can see what is happening. It would be useful to create a “heat map” over this GUI to measure what controls are not useful, useful early on, and useful forever.

Of course, the devil is always in the details and these are broad strokes. The more eyes the better. It’s good to be back!

tldr, if you’re buying into the protocol you have already bought into the people who created it. With incentivized constraints on their power, what’s the diff?


i guess its still too early to tell. gonna wait for more views on this matter 1st.

1 Like

I think this is my new favorite catchphrase.

1 Like

Hi there, Anthony from Aragon here. I’ve responded in the DAO Experts channel to Miles, and am happy to make an introduction to a few experts, just need a response. Thanks so much and very excited to see this! :slight_smile:


Hey @Leuts lets make those intros!

1 Like

@Leuts We can have the conversation here:

1 Like

Gm! I made 2 intro’s to Bankless and DAO Craft. Hope you have a fruitful conversation! Please let me know if there’s anything else. :slight_smile:

1 Like

Thanks @Leuts ! Where can I find these intros?

1 Like

Tagged you in the discord channel and sent links there! :slight_smile:

1 Like

Here is an updated “jobs to be delegated” diagram. Thanks to Barto for cleaning up my rough sketch.


very good projekt, I want vote somethinK :slight_smile:

1 Like

My thoughts on this are evolving. When I originally posted this, I thought the best path forward was a centralized design to get everything working, which will “eventually” be decentralized. Given recent events, I now think decentralizing as fast as possible is what everyone wants.

So how do we do that while making sure everything works?

I now believe the decentralization schedule in the whitepaper is the best path forward.

If we do this, and the protocol isn’t working as intended, it can be relaunched. We would have to ensure the shutdown mechanism is rock solid (everyone gets their collateral back from the earlier version, or it can be trustlessly passed on to the next version of the protocol automatically).

Link to whitepaper, see section 2.1: Whitepapers/TCP_Whitepaper.pdf at main · TrustlessFi/Whitepapers · GitHub

Anyway, these are just today’s thoughts. I haven’t made up my mind (and it’s not even up to me - it’s a community project).


Tentatively agreed with everything above, especially the shut down mechanism getting some extra care.