Alternative ideas - Decentralization as a service

Governance
1

There is this gap, I’ve felt with all our projects - When a project is not ready for a decentralization sale but can benefit from decentralization and the trust coming from it. At first, I thought - can’t I give 3 keys to 3 community developers that will vote on proposals? That would probably be the minimum decentralization possible. The problem is, this would mean each has 33% of the project and the other 2 can theoretically take it over or ask for a large % once it’s ready to launch. Don’t take me wrong, I didn’t lose faith in fellow community members, it’s just that the solution isn’t good in theory and it isn’t trustless. And if you are too close with your fellow devs, enough to trust them with these keys, then the public may not trust your decentralization.

Then this idea came into existence - how about allowing others to help you decentralize while being able to eject if something goes wrong and get full ownership back (after a long delay), or launch SNS directly from where you are? I think this will work well for our projects currently, let me know what you think of this draft.

Basically, non-technical and technical members of the community are selected/elected based on their reputation, contributions, and skills. The projects using the service pay them for their work related to accepting proposals, instead of asking them to do the work because they have a stake. Additionally, once you have a stake, you probably feel like your opinion and taste should be voiced. Here the jury only makes sure that the founding promises are kept and then devs make sure proposal text explanations match the code executed (blackholed contract).

Codename: Alpha DAO

Alpha DAO Structure:

Alpha DAO operates as the primary governance structure overseeing multiple projects. Each of these projects remains under the temporary stewardship of Alpha, subject to Alpha’s governance model until they decide to eject, launch their own governance, or depart.

Setup Phase (Onboarding a Project to Alpha DAO):

  1. Configuration:
    • Project founders define the specific parameters for their project, like the sovereign override timeframe and the required points for proposal approval.
    • Foundational commitments and core objectives for the project are outlined.
  2. Asset Transfer:
    • Project founders transfer their assets (smart contracts, tokens, etc.) to the temporary custody of Alpha DAO.

Eject Phase (Exiting Alpha DAO):

  1. Initiation:
    • Project founders decide they want to retract from Alpha DAO.
    • The decision to eject triggers the sovereign override mechanism.
  2. Sovereign Override Mechanism:
    • There’s a waiting period (e.g., default 15 days, but can be adjusted based on initial configuration).
    • After this duration, the assets are returned to the project founders.

Launch Phase (Transitioning to a New DAO):

  1. Proposal:
    • Project founders propose the launch of a new, independent tokenized DAO (SNS).
    • This proposal undergoes the standard Alpha DAO proposal process.
  2. Establishment:
    • Once approved, the project transitions to its own governance model, separate from Alpha DAO.
    • The assets are transferred to the new DAO.

Proposal Phase (Modifying a Project under Alpha DAO):

  1. Proposal Submission:
    • Only project founders can draft and submit a proposal for changes.
    • The proposal details both the textual explanation and related code modifications.
  2. Evaluation Panel Review (Jury of Alpha DAO):
    • The jury, selected and governed by Alpha DAO, assesses the proposal against the project’s foundational commitments.
    • If the proposal aligns with these commitments, it progresses to the technical audit.
  3. Technical Audit (Developers of Alpha DAO):
    • The technical audit team, also selected by Alpha DAO, evaluates the proposal’s code changes.
    • Developers assign points based on their skill sets and level. A proposal must accumulate the predefined number of points to advance.
  4. Implementation:
    • Proposals that successfully navigate the evaluation and audit are implemented.
    • The changes are executed, reflecting the proposal’s intent.
  5. Compensation:
    • The evaluation panel and technical audit team are rewarded based on the predefined incentive structure of Alpha DAO.

Alpha DAO can also work as a Trust Layer for Established DAOs:

When an established DAO integrates with Alpha DAO, it effectively outsources part of its governance process, ensuring that each proposal is vetted and verified by a neutral and reputable third-party system. A proposal that passed thru Alpha DAO will be more trustworthy.

Key Benefits of Alpha DAO:

  1. Reward & Recognition for Jury & Developers:
    • Monetary Compensation: Active participants, namely the jury and developers, receive monetary rewards for their contribution to the evaluation and execution process.
    • Reputation Enhancement: Alongside financial benefits, they also witness a boost in their professional stature within the community as they successfully evaluate and oversee more projects.
  2. Affordable Decentralization for Altruistic Projects:
    • Low Barrier to Entry: Projects aimed at the common good can attract developers and jury members without offering hefty rewards. The intrinsic motivation to contribute to benevolent causes, combined with Alpha DAO’s structure, ensures that these projects receive the support they need.
  3. Autonomy and Decentralization for Founders:
    • Retain Ownership: Project founders maintain complete ownership of their projects, without dilution.
    • Benefit of Decentralization: While retaining ownership, founders still achieve the advantages of decentralization, leveraging community trust and expertise.
  4. Enhanced Trust & Safety for the Community:
    • Temporal Trust: The community can place their trust in the project’s smart contracts while they’re under Alpha DAO’s oversight.
    • Buffer Time: If a project chooses to eject from Alpha DAO, there’s a built-in response window (e.g., the sovereign override mechanism) that allows the community to take appropriate actions or precautions.
11 Likes
3

I like the idea. Any thoughts on how to implement the process of electing/selecting AlphaDAO members?
It’s too bad the forum isnt onchain to gauge reputation and engagement

1 Like
4

For the election, it shouldn’t be any “automatic” metric / threshold, or it could be easily abused by a “scammer”.

All big open source foundations (python, chromium, many others) have survived for many years with the “self-election” system. Pretty much you do the first “cohort” manually (an easy system could be to ask for who would be interested in joining and then infu and you screen).

And then these members vote for accepting new members, according to their own criteria. Usually it needs 1 or 2 persons to nominate, give a notice of 5(X) days and if no one presents any “reservation”, the person is accepted. Usually on the notice it goes links that showcase past work done by the person.

Think that group could easily have such an election system, no need to wander away from something that has heavily been tested (by the Open Source community).

I will need more time to read the full description, and will try to reply to Infu later today or tmr. But I am very interested in any DeGov topics :slight_smile: , so thank you for bringing this topic here.

2 Likes
5

It’s high effort for a project, for what benefit?

Seems like they are just pretending to be decentralised until they are actually decentralised using this mechanism.

Is it fair to say this is a form of “decentralised” if the founders still have full control?

6

@Gekctek we can select the initial cohort in this forum for devs & the forum and other social networks for non-technical. @tiago89 sounds about right. Users can prove the connection by posting their principal from the app.

@dfxjesse Ejection will work for a lot of projects and for some it won’t. It’s not ‘pretending’, the decentralization is real, it’s just temporary/ time coinstrained. There needs to be such a mechanism, or otherwise, Alpha DAO owns your project.
If it was an on-chain wallet getting decentralized - users would have time to withdraw funds.
if it was an Oracle - apps using it would have time to switch to another.
if it was a DEX or DeFi contract that doesn’t lock your funds - users could take their funds out

That is the goal - to be able to deconstruct the ‘whole package’ into different components. And get ownership != decentralization. I think the draft doesn’t explain it well. A project retains full ownership - it can actually sell %. Maybe a small % to get some funding. It doesn’t need to sell everything right away to get decentralization.

It is also possible to pay proposal fees to contributors with its own future tokens (Something like 500$ in tokens at launch price. But then if it ejects and doesn’t launch it will have to repay those before ownership is returned.

1 Like
7

I think maybe the problem is with the ejection and what that would do here, Some of the benefits you mentioned are about getting help from ‘community members’.

Let’s say i’m a community member and like a project that is governed by Alpha DAO. I decide to contribute and maybe get selected as part of the ‘jury’ or provide technical help. I have put a lot of effort into helping the project and maybe get paid a few tokens or something, And then one week the founders say “Sorry guys we initiated the ejection, project is back in our hands in 15 days, all help is ceased, thanks”.

See where the problem is? This wouldn’t really incentive anyone to help and put in effort knowing this can happen, I know I wouldn’t help a DAO here if they had the power to do that at any time.

1 Like
8

Let me clarify how it works. The ones working on auditing/verifying proposals get paid in liquid tokens by the proposer. The proposal carries for example 1k$ and that is distributed immediately when voting is done to whoever helped. The transaction is done, and if it will eject is not a concern of yours anymore (it’s a concern of the app users and integrators). It could also carry illiquid soulbond future tokens. If it does and has accumulated a negative balance of 30k$. It will need to pay those first, they get distributed to contributors and then the ejection is allowed.

1 Like
9

Hi Infu,

Thanks a lot for writing this, am always excited by the possibilities IC has on DeGov. I could easily write a whole chapter of feedback, but will stay succinct (at expense of more context). Please drop me a DM if you are really interested in carrying this effort further, would love to collaborate with you and think there is already a good “use case” on DeGaming and Boom DAO.

So, my contributions to this draft:

  • as it stands, it wouldn’t work. Jesse already pointed a few: lot of work / too costly, too much founder’s power.
  • I prefer to simplify and see the problem being solved by an ecosystem of services. There are two services, a Law DAO and an Audit DAO. The Law DAO solves any conflicts of interest (founders ejection, asset escrow, proposal review/enforcement, etc.). While the Audit DAO only checks and reviews code changes / technical proposals.

There are more fundamental problems not solved. The Alpha DAO is not motivated to work/care about understanding the domain of the “sub DAOs”, which will result in wrong judgements. Decentralization needs to be given to those that stand the most to lose, and those are the FUTURE users. Shareholders have historically been the closest we have gotten to correctly model their interests.

I have been working (designing) a solution that gives power to “representatives” of future users. Also, decentralization should be progressive, not “given”.

So, in a nutshell, what I am trying to say is that decentralization is hard (but very powerful). U are still missing reputation, training, worker and representational systems/services.

Hopefully we can start slowly but steady on DeGaming and then evolve from there (so any org can confidently become decentralized/open) :slight_smile:

3 Likes
10

Thanks for joining the discussion. So far I am just interested in discussing and designing it.

You are correct. It only makes sure the foundational commitments are kept. A list of commitments - for example, “Don’t mint new tokens more than 5% per year”. That will be easily handled.
A commitment like “Keep all characters balanced for competitive gaming” Is not something Alpha DAO jury, developers, or investors can figure out. It will require these to be checked/tested by competitive gamers and the rest shouldn’t have a say on the matter. If you cram them all inside one token that votes on everything, investors and founders will always have the most power.

Ideally, we will have a lot of organizations specializing in different things, and different proposals will have different acceptance flows passing through multiple decision-makers - creating digital bureaucracy :smiley:
Something like: Proposal → Alpha DAO → Security experts DAO → Competitive gamers DAO → Users union DAO → Execute
But you will need to be able to modify the flow if one of these decides to sabotage your app, or it will be bricked and no proposals will be able to pass. That is what the ‘ejection’ is for.

1 Like
11

Oh boy… :face_with_peeking_eye:

Surely hope we don’t reach such a beaurocratic case :grimacing: haha

Will take the opportunity to introduce a few more concepts. (I do have a point, promise :sweat_smile:).

  • there are decisions that affect all and are long term impactful, like a yearly budget, a Roadmap, a standard approval, etc. Being heavily scrutinized is good, also involving everyone on a change is part of the change process, so this decision making is good to be approved at a DAO level.
  • but there are many other decisions that are not good at a DAO level, will give a visual example. Imagine that we allow a football/soccer team to be coached by a DAO (the club fans). A game is happening and a DAO can actually decide to substitute a player in the match if a proposal is approved.

Do you think this DAO club would win the championship? It wouldn’t, there isn’t long term planning, there isn’t a thorough opponent analysis, deep connection with the players, consistent actions focused on a winning strategy, etc. This decision making is inside a scope of complex context and ambiguous impact.

The best way to deal with these are a team with lots of complementing skills/training, probably headed by someone elected by the team to make the final decision (coach / Team Lead).

  • Last but not least, there are also many, every day decision making for any individual to do / contribute. Like should button be green or red, left or right, etc. In here, Coach/Team Lead trains and progressively trusts the individual (or else Team Lead or worse, DAO would be swamped with these low level decisions).

The design patterns here are:

  • progressive trust (over exhaustive audit)
  • context control (over specific task control)

These are flows heavily battle tested in corporate world, and don’t expect them to change with the advent of Blockchain/IC. But I expect them to significantly accelerate and become way more effective (much faster feedback/consequences). Having money/tokens in these flows, allowing payments to be faster, allowing for escrow, reputation, work routing, service routing, etc.

An “Users” org/DAO can focus on attracting users and budgeting/sharing the costs of Assets maintenance/development. They can then delegate the work itself to other DAOs/Teams/Individuals. Work is published, routed and accepted with the help of smart contracts.

Concluding, it won’t be a “proposal flow” as that would lead to too many dependencies (which cause delays and frustrations), it would be a delegation system (with good compensating systems, like reputation, training, escrow).

I know I significantly wandered off from the initial topic :sweat_smile: But hope it’s still interesting to whoever likes DAO governance :slight_smile:

3 Likes