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.
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.
- 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:
*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
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?)_
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?
- 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
- 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
- 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.
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
- Update ENS (?)
- Token list