Exploration phase DAO

[tupui]

From the proposal, the full concept:

Projects will have access to their own Decentralized Autonomous Organization (DAO). The community of a project will be able to vote on new features or organizational changes. There are several SCF open source projects we might be able to leverage. The project will have a wallet and the DAO will be used to control the funds allocation. There are going to be mainly two pools. The first pool is dedicated to developers. Funds will be automatically distributed to active maintainers based on specific criteria. The rest of the funds would be managed by the DAO for other purposes such as compensating non-developers, infrastructure costs, or even organizing events. The use of a complex system of redistributions typically used in web3 projects, such as Quadratic Funding (QF), will be evaluated.

Tools will be implemented to add/remove maintainers programmatically based on the on-chain status of the project. To that end, we are already leveraging Soroban Domains and will continue to do so and see how we can extend our partnership. Discussions are in progress to get a standard around metadata for instance.

Other personas will be added on-chain as to give other responsibilities. This will further increase projects' transparency and give all participants some visibility.

Release process on-chain. From triggering the release to registering it.

Add a level of trust per hash. Combining time based rules with additional factors such as voting from maintainers, to mark specific hashes as more trusted: this introduces a finality concept and enables consumers of the contract to use specific trust levels depending on their own risk profile. We will evaluate the possibility to combine this concept with an automatic update of the hash. This would allow a fully trustless mode of operation. Linked to that, we will add tools to reject a hash. As maintainers can get compromised, it is important to have means to indicate that a project and person is compromised.

Finally, users will be able to subscribe to projects to get news about new trusted releases, security related issues and DAO events.

[tupui]

Some initial draft

[tupui]

The proposals will be stored on IPFS.

I reviewed a few solutions and I think that for now https://storacha.network is going to be a good solutions. This is what we use to provide the dApp itself on IPFS.

Storage cost is between $0.03/GB to $0.15/GB per month (0.1-0.25 with CloudFlare). We can think afterwards how to charge project for rent based on the number of proposals they have, etc. This is a longer discussion.

Possible to use our own node in the future, or later on we can also consider moving to xlm.sh's node. @overcat I think that sort of could be aligned with the next phase of your project right?

All projects have their own DAO, so I think they all need their space (DID) to do a proper separation. Every project is linked to a Soroban Domain already, so at registration time I will trigger a space creation as well. Then authorised users can add proposals to the system. Here we use the wallet API to ensure that.

From the dApp, creating a proposal will trigger two things:

1. Send the proposal to IPFS with Storacha to the DID of the project (https://docs.storacha.network/how-to/upload/). The proposal is a markdown file and can have images.
2. We get back a CID. e.g. bafybeidsfg2rfmpgtisfnmk6lur5dmy6j4kwjblh2rhme6nrsvjcaci4jq and we store this information with other metadata on-chain. TBD

[tupui]

Some random notes.

List of DAO concepts https://limechain.tech/blog/dao-voting-mechanisms-explained-2022-guide

I particularly like ragequit mode. https://moloch.daohaus.fun/features/ragequit and https://mirror.xyz/verbsteam.eth/iN0FKOn_oYVBzlJkwPwK2mhzaeL8K2-W80u82F7fHj8

Some papers to finish reading:

https://arxiv.org/html/2406.08605v1#S5 https://www.frontiersin.org/journals/blockchain/articles/10.3389/fbloc.2024.1405516/full#h8

[overcat]

Hi @tupui,

The initial purpose of setting up IPFS nodes for xlm.sh was to improve access speed and make xlm.sh more user-friendly. While it pins data locally, I have implemented a limitation: each site is restricted to 100 MB of space. If a site's data exceeds this limit, it won't be pinned locally by xlm.sh nodes and will need to rely on other service providers for data pinning.

I believe 100 MB is sufficient space for most sites. Since xlm.sh provides this space free of charge, we need to implement certain restrictions to prevent abuse.