Thank you, folks, for the support and such interesting questions. I will try to reply to most of them the best I can.
Generalization of features for Aragon Client users
We will build the software in a way that is easily generalizable in the future, although we may focus on this demo DAO first. Mainly the Tao Voting AragonOS app contract will be usable by any AragonOS DAO, and we will provide an evmcrispr script to install it. Still, we can not give a frontend that will work out-of-the-box for anyone without some customization. Especially it won’t be as easy as installing a Company/Reputation/Membership DAO from the Aragon Client. However, we can keep working on it in the future.
Branding, licensing, and their impact on generalization
In regards to licensing, we have to be very clear. All Gardens and Blossom Labs is producing is open source / free software, as Aragon. This means Aragon can take the code, modify it or not, and rebrand it at its convenience (without asking permission). We have been doing this with Aragon products because their open-source licenses allowed us to do so, and we will be happy to see Aragon merge back some of our code as well!
The code repos are available here:
That being said, we would love to collaborate with Aragon on porting the improvements that make sense to Aragon Client or release Lazuline as an Aragon product. This proposal only includes the release of the MVP that can be used to vote on Voting and Tao Voting, but we plan to expand it to fulfill most of Aragon Client features in the future. More on this when it’s the time.
Why build Lazuline as a separate tool and not implement it directly into the Aragon client?
I tend to think of them as different products:
-
Aragon Client is the reliable source connected to the blockchain
-
Lazuline may be a more convenient way to interact with the AragonOS DAOs, although it relies on the graph to work (that can fail), and it won’t be able to load some custom apps.
Both products have sense, similar to what full node wallets and light wallets are for bitcoin.
Given the latest news on subgraph not having the hosted services anymore, do you see any potential issue and have already thought about which Graph service to use?
For this demo, we can still use the hosted service. However, in the future, we will have to migrate to the decentralized service. I think we still have some months before all the graphs in the hosted service are deprecated, although I have to check. Ideally, we should migrate the subgraph during the following proposal.
Was ever some research done on the delegation topic to build TAO voting?
It was built by the old Aragon One team, and we didn’t do any additional research, although there are many things they got just right.
One of the last projects the team worked on was the Network Dashboard, which was a kind of frontend for Disputable Voting (what we refer to Tao Voting nowadays). We will not build on top of it for this proposal, but it is worth looking at.
would be great if we could get the Product design team at Aragon involved in the discussions for all the UX/UI flows
We are only going to provide a functional DAO in this first proposal. We need to be very surgical to have a product ready on time, so we will only reuse and connect old and battle-tested pieces of code. We think it will look like the good old Voting app.
When we have it working, we will be ready to receive UX/UI feedback on what could work differently and how to improve it. We will not produce new code; for now, we are just recycling what is already there.
why not adapt TAO voting for regular ERC20s - Does Finance and Agent app are super dependent on MineMe as well?
The ERC20Snapshot/MinimeToken interface provided by the Token Wrapper app is only relevant for Voting (and Tao Voting).
It tells Voting the distribution of tokens at the beginning of a vote. Without it, Voting would not know if a token was there from the beginning or if it was transferred so that people could vote more than once.
I do however believe this proposal should be going through the MainDAO and not the Executive Sub-DAO as it is a proposal that should be decided on by the Aragon community, and not a committee of 3 people. Due to its scope, breadth, and importance.
It’s important to say that this is not the main proposal working towards creating the new Aragon Treasury DAO. We will prepare a subsequent proposal that we will probably send to the Main DAO.
This is instead a “low-cost” proposal to put together a demo so the community can discuss.
does that budget include the Audit, or will that be coming from a separate pool.
Aragon must choose an independent auditor team to perform the reviews. We can help by referring some people who worked with us previously.
I’d love to sync with several AA team members asap
There will be opportunities all around the place: AMAs, param parties, forum posts, and, more importantly, a functional demo containing minimal elements for a delegated voting DAO.
I’m also open to answering any questions in DMs related to this topic.
and periodically send funds to another designated DAO
Is this referring to allocating funds from the DAO treasury for subDAO operations (as well as for any other purpose approved through governance)?
I think the “Aragon Treasury” DAO should not do a lot of things by design, just hold the 200M safely and send part of them periodically to another DAO (AN DAO?) to properly manage them. This other DAO can be the current AN DAO, an AragonOS DAO, or an Aragon Core DAO in the future.
I would kindly ask the team to confirm [the design can meet the specs and it is finished by 30th November] is feasible and a ballpark of the additional cost to get us there.
It is early to know. We can only commit to having a functional demo by the end of August, but with lots of missing or clunky features. However, if we do not overcomplicate things and the auditors work fast, it would be feasible to have the final DAO by the end of November. Still, it will depend on which are going to be the final requirements after receiving the feedback from the community on the demo.
I have also specifically tagged Sem at the most relevant bit in the other thread, which is to have some expiration on the delegation (to avoid the “set it and forget it” behavior).
I am also worried about it, and although Tao Voting does not cover it, we may find a solution to this problem. This is the kind of feedback we expect to receive after the demo and having them solved in the final version.
