DXdao fractalization - DXsquads

DXdao Fractalization

The purpose of fractalization is to distribute risk, ownership, and incentives to create better growth opportunities for DXdao, its members, and the different products, all of this while laying the groundwork for iteration and experimentation.


  • DXdao should be the base layer, DX-products should be Avatars (squads) ‘under it’
  • The more one contributes to a specific squad the more reputation they have within it.
  • This doubles down on decentralization, incentivizes participation, and creates a more focused & scalable organization.


Like ‘a blockchain’ the DXdao base layer should be hard to change, favor security over flexibility, and rarely go through upgrades. Rather than changing the DXdao base layer we should innovate and experiment by fork-copying the DXdao and test, leaving the base layer secure and resilient.

Additionally, The 1% rule / Pareto principle plays a part here, if we want to scale our governance we will have to fractalize, delegate, and give ownership and accountability to smaller, more focused teams.

The user perspective

At the current state, a potential swapr user and contributor does not have much upside when it comes to governance. The DXdao reputation distribution is discouraging to join as any meaningful influence in the DAO will take a long time to materialize. Likely years?

Since we are working on the ownership economy we should thrive to decentralize the ownership and control of DXdao products while still retaining a link to the DXdao mothership. Hyper focused squads could be highly incentivizing for new people to join as contribution could quickly translate to influence in that specific squad.

The argument here is that users who specialize, contribute, and participate in a specific product should have a bigger say in matters related to it. e.g. a frequent Omen or Swapr user should have a lot more influence when it comes to Omen or Swapr decisions. This is not to say that it’s a completely different / separate product. It is still a part of DXdao, and DXdao will still retain control and own the ENS name, but the majority of decisions will (slowly) move to the productDAO/Base.

This architecture will also allow us to experiment with different governance designs, reputation distribution methods, parameters, and faster resolutions for proposals. This same framework can also be used for Bizdev and collaborative purposes with other DAOs / communities.

Lastly, this ‘DAO topology’ could assist in the management of the DAO as a whole. For example – Each Squad will get a quarterly budget and KPIs (OK-R), which will allow us to measure and quantify squads success and effectiveness.


This is not without challenges, but the nature of this ‘Fork-and-experiment’ make the upside far larger than the downside.

1. Multiple Avatars - Single DAO.

  • Resolving this issue is a UX challenge which I believe Augusto’s current voting dapp could resolve
  • The Dapp will get data from several Avatars and present them in a single UI. (see colorful pic below)
  • Each Avatar will have its own color coding for proposals / Each Avatar will appear in his own UI lane.
  • Use of alchemy.io for each DAO is also possible.
    Concept of what this might look like:

2. Representation

*This is means core dev contract work which will take longer, and will fall under one of the few changes to the base layer.

  • Representation of Bases in DXdao - “I’m the most influential person in OmenBase – how does that translate to DXdao voting power?”
    • A parameter that can be set by the DXdao - Balanceof() % of DXdao REP allocated to bases

More info:

This means that INDIVIDUAL DX-Squad rep holders vote in the DXdao and not the whole Squad voting as a single entity. Proposal based Squad-to-DAO interactions are too absolute and won’t represent the DAO, slow to execute to the point of missing the voting time, and difficult to implement (When does a proposal open?)_

3. Co-Ownership

These are a few open questions on the topic of co-ownership with DXdao and squads

  • How does the DXdao delegate ownership of certain elements in the contract to the Base, while retaining control. (DXdao can revoke squad ownership)
  • How is the revenue distribution between DXdao and the base calculated?
  • Is it possible to allow a base to update the ENS but not own it?
    • e.g. Omen base updates Omen.eth.link, but this permission can be revoked by the DXdao?
  • Parameters
    • Revenue share between the DAOs



  • DXdao forks to a base with the same reputation distribution, in a similar fashion to xDAI
    • Possibility to level the ground to incentivize new participation Log(rep), Sqrt(rep)
  • Lower governance parameters

Which bases?

  • Omen – by the looks of it Omen is the most solid and ready team for such an experiment
  • Swapr - About to launch, and while it’s a bit a last minute this could be a very good angle from the marketing side as well.
    • Allow LPs to stake the liquidity token for reputation in the DAO
    • Govern
      • Fees
        • LP fees?
        • Protocol fee?
      • Token list / registry
  • Marketing / Comms
    • Updating DXdao.eth.link
    • Marketing campaigns
    • Using decentralized publishing tools


The DXdao will fractalize to several squads. It will delegate, control, and allocate funds and voting power according to the success and performance of the squads, incentivizing excellence and performance with funds and voting power.

Potential Delegated responsibilities (ongoing)

Permissions / Responsibilities are delegated to the squads but could be revoked at any moment by the DXdao.


  • UI experiments
  • UI promotions (Top Omen market, current Mesa IDO, etc)
  • ?


  • Update ENS (?)
  • Market validity curation
  • Currency curation
  • Providing liquidity
  • Arbitration service
  • Oracle curation
  • Controlling(not the owner) the omen radicle.xyz repository


  • Update ENS (?)
  • Fee setting
  • Token list
  • Liquidity


  • Update ENS (?)
  • Token list

Having thought a lot about how a DAO will effectively scale, I’m really excited to read about this approach, and I honestly think it could set a new precedent for DAO scalability. Some questions/thoughts:

Each Squad will get a quarterly budget and KPIs (OK-R), which will allow us to measure and quantify squads success and effectiveness.

I really like how this allows us to quantify the value of different products by funding in accordance to performance and returns. I also think this would be effective in keeping the group as a whole accountable. +1

A parameter that can be set by the DXdao - Balanceof() % of DXdao REP allocated to bases

Perhaps I’m misunderstanding this, but I don’t see it being fair to provide DXdao REP to workers based on the project they’re working on. Is there any reason why this approach might be better than continuing to offer workers DXdao REP as per usual and simply additionally providing workers with project-specific REP?

In general, I see this opening the door to a lot of possibilities, and if not this approach, something similar seems absolutely crucial in effectively scaling DXdao.

1 Like

@nylon I do like the idea of Fractalization.

A few questions to ponder:

  • How do you start each squad? With what REP distribution?

    • Fork-copying the DXdao and then expanding from there - if you do this (like with xDXdao) you may likely have the same “discouraging reputation distribution”.
    • Start fresh? This could be risky. Giving a product to a newish Squad, unless DXdao has end control.
    • New ideas? Start with the most active contributors to that product/initiative? How big would this be? New ways to distribute REP broadly are hard.
  • Next, do we face the same issue we have with DXdap REP holders and DXD holders? How do we align interests between these groups? How do you incentive REP holders and squadREP holders to govern on behalf of DXD holders in the long run?

    • If the end Vision (as depicted in the displayed pie charts) is achieved, how are incentives aligned? Between who and who? If one becomes a major squadREP holder in the Swapr Squad, how is she incentivized to make decisions?
    • Are Squads still obligated/incentivized to flow revenue back to the DXD curve? How do we make sure of this?

In general, I think we are realizing that there needs to be financial incentives built in to each part of the system in order to drive desired behaviors.

As we know, there is currently a Governance 2.0 Working Group going on, and many of the issues that it is working to address would likely have big overlap with issues in this set-up as well, maybe even more so. I think a major change to the system like this vision would need to become a part of any overall discussions.

I think this idea of DXdao fractalization is very interesting, but I still wonder how it can be implemented and then how this new system would perform. Looking forward to hearing more thoughts and ideas about this topic.


Thanks for the feedback Kaden.
Big +++ for measurements and accountability!

On this comment – You are absolutely right, this is the 'raw’est part of this design, and what would require the most delicate tinkering in order to get correctly. If we’re looking at a long term timeframe, why not have the DXdao reputation contract composed of only DXsquads, each with their own weight? (DXproduct, Marketing, HR, onboarding, etc). The advantage here is that a member could be focused only on a Squad, become the ‘most influential’ in that Squad, and that would directly translate to DXdao Reputation.

In general, governance systems pass proposals with the lowest voter participation possible, it’s by design that a few rep holders are required to pass a proposal. However, when divisive or contentious proposals arise we will see rallying from the squads, campaigning on both sides, and the high voting participation rates.

I think that such a system (given its designed correctly) will more accurately represent the different sides in such cases, while also mitigating them from happening.

At any rate, this is a direction to explore and far from a full fledged solution, I hope we can continue experimenting and figuring this out.

Thanks for the feedback @sky, and yes I believe you touched on the most critical questions that still need far more exploration and in depth thinking.

To answer a few of the questions

Squad rep distribution and issuance:
This is a critical one, because like you said you want to create a more leveled ground for new participants to join.
An experiment we could run is a “level-down” formula on the reputation to make it a bit more equal, something like:

  • SquadREP = SQRT(DXdaoREP)
  • SquadREP = Log(DXdaoREP)

Voting incentivization

This a big discussion of its own, if we want to incentivize, and how. My gut feeling is that the incentivization shouldn’t be directly financial e.g. get paid for voting on proposal, but instead with reputation rewards to those who participate.

Like I said in the reply to Kaden, I think that high vote participation will happen when we have contentious issues. The goal should be to figure out how to distribute REP in the hands of those who contribute so when we have such issues, the decision will be truly decentralized.

Regarding the revenue generation, it should still go to DXdao as that is the treasury. An interesting option could be to reward squads for measured success (Incentives!), and we could even adjust the DXdao Squad Rep allocation according to revenue generation.

At any rate, Incentivization and interest alignment between Squads and the DXdao is a topic of its own which we definitely need to explore.


This is a great proposal and something for which I wanted to create a post this week myself. I have previously shared some of my thoughts regarding this here: Governance discussion Nov 25, 16:00 UTC

As a relatively new user, it has been extremely difficult to navigate individual worker proposals, get an idea of what is necessary for each and what not. The products and requirements are vastly different across DXdao and I would say it has become a part-time job already to at least be able to connect all these dots together - far too much for any individual hobby DAO member to participate or contribute.

Here are a few challenges and maybe improvements to your proposed system:

Why do you think it will be best to have individual squad REP? Since the squad is formed around certain tasks and has a certain budget for it, why does it need its own REP? It sounds like this would make intra-squad coordination much more difficult, especially when expected squad sizes should rarely exceed those of two-pizza teams. I also don’t see why a historic contributor to Omen from a year ago should still have a say in its future development.

This is perhaps the most critical part to get right when defining squads. If DXdao members have to suddenly interface with every individual squad member to form opinions or to extend the budgets, we have gained nothing. It is therefore critical in my opinion, that we need a squad leader per squad. Their responsibilities are:

  • reporting back to the community
  • calculating budgets/timelines and defending them to DXdao members
  • hire & fire individual squad contributors (so far it looks like no tough decisions against a member had to be made, but they’ll eventually be necessary! There is a tendency in DAOs to not get rid of bad actors or to avoid criticism altogether… “Best way to starve a dog is to give it two owners”)
  • be the first touchpoint for external parties
  • be held accountable should the goals not be reached

All of these points are very critical for effective and functioning organizations (not just centralized ones) and I think we should strive to adopt those as well, especially since we have big shortcomings in a lot of these points.

The strongest motivator is not money, but ownership. Therefore I am a proponent of eventually launching project-specific tokens (transferable) for the products that reached strong maturity within DXdao. It is far too early to go into any details here and there are too many unknowns still, but I think long term there is no way around this.

Since this would be an organizational adjustment only and doesn’t require extra development, I suggest we try this with one specific domain first and see how it works before we adopt it more broadly. Maybe Swapr?

Adding a few polls to get some early feedback on these ideas:

Should DXdao eventually adopt squads?
  • Yes, one way or the other
  • No, it should stay as it is
  • Abstain

0 voters

Should we have explicit REP per squad? I.e. Omen-REP, Mesa-REP etc.
  • Yes
  • No
  • Abstain

0 voters

Should squads have single individuals responsible (squad leaders)?
  • Yes
  • No
  • Abstain

0 voters

Should we trial one squad with a leader now?
  • Yes, for Omen
  • Yes, for Mesa
  • Yes, for Swapr
  • Yes, for something else (please comment)
  • No

0 voters


I like the idea of using vertical-focused Squads to move faster and accomplish goals. However, “electing” one person as a leader who then makes decisions for that Squad until that person is removed as the leader and replaced is not how the global decentralized collective that is DXdao functions currently.

To be anti-fragile, it should not matter if one person comes or goes. The ideal system would still move forward towards accomplishing the goals of DXdao, even without specific individuals.

I think trying out a Squad focused on one Product would be a great way to start.


Granted, but we could also just have each person chose a replacement if they would become unavailable. Maybe don’t imagine it so much as a dictatorship within each squad, but more as a spokesperson and organizer.

1 Like

Yes, a Coordinator of a smaller but still decentralized Squad makes sense.

Encouraging users of each product by its REP is an amazing idea.
But this proposal completely ignores the role of investors, It can therefore be seen as part of a more complete proposal.

I agree that hiring / firing decisions, shouldn’t be made unilaterally, but a process could be implemented through review that the squad then comes to a consensus on regarding worker decisions.

Also, want to reiterate that it makes sense to have a coordinator that deals with many of the other elements that @heychristopher mentioned (touchpoint for external parties, product accountability, budgets, and community reporting).This also seems to be somewhat of a semantics issue. The person could be referred to as the coordinator or point person with the same responsibilities.

Just a thought – to ensure power is decentralized with the creation of this position, the role could shift on a bi-annual basis throughout the squad.


As it grows and matures, DXdao will naturally form more structure. In general, I think governance should take its cues from the collective, rather than the other way around.

This means allowing for an emergent structure to arise, but then codifying that to ensure consistency & accountability and prevent power accumulation.

Of course, we - and this process of deliberation - are all part of DXdao’s emergent order.

Regarding squad leadership, there are already certain individuals emerging as leaders for different products and initiatives. We should encourage this development and study how these squads interact - and then put a more formal structure around it. But I think it’s premature to design the formal governance structure at this point.

I think budgeting is the next natural step now that the worker responsibilities are being further defined. We can do this now w/o any on-chain components. I hope to have some more developed thoughts on this before Thursday’s call.

And then, outward-facing communication is also important. Again here, I think we have enough emergent structure now (at least internally) and we need to do a better job communicating to the wider community who to ask and where to find information. I also think the partner funnel concept discussed by @sky on Monday’s Biz dev is an important part of this too.

Lastly, I’m really into the name squads. I wasn’t too hot on it at first but I’ve really come around to it. Omen Squad, Mesa Squad, Swapr Squad - sounds dope. This was also a good read:


“Regarding the revenue generation, it should still go to DXdao as that is the treasury. An interesting option could be to reward squads for measured success (Incentives!), and we could even adjust the DXdao Squad Rep allocation according to revenue generation.”
Here there is an entry point for DXD through staking on Squads to alter allocation. #alignment