@amphiboly: spoke with key dOrg contributor on transition from DAOstack, what metrics best reflect their focuses as an organization, and best practices on treasury management/payments…
Move from DAO Stack
-
Started two and a half years ago on DAO stack. Took a look at Aragon, Colony, Aragon/Colony had a lot of assumptions and constraints built in. Turned out to be very hard to innovate on DAOstack over time. Their needs more complicated; need fast pay out to do payroll.
-
Holographic consensus well thought out from game theory perspective but not a user experience perspective. We are talking about like four/five transactions. Too many transactions!
-
Clients want to pay on Mainnet. You need to make it easy as possible for customers to pay you.
-
Moved to SAFE because you could be on Mainnet and then pay yourselves out without high gas. Gnosis only one transaction (sign/approve are free)
-
Gas can be high — 80-100 bucks per payout
-
Other business reason to move to a SAFE is that the paradigm of a single DAO collecting money and giving out to people doesn’t make sense; now that they’ve scaled, there’s an incredible amount of book-keeping overhead, you don’t want one fuck-up to drain your treasury **
-
Segmented SAFE set up, clients are paying safes per project, we are trusting that those SAFEs send 10% home
-
Ideally primary Treasury would be a DAO, right now there are trustees, “we can’t sacrifice operational efficiency to trustlessly execute on decision-making”
What metrics reflect where you are succeeding / where you can improve?
** need to evaluate different DAO types differently,
-
as client services DAO, (a) cash flow (300k to 1 million, 4 million) / year over year growth in revenue, # of client projects going simultaneously, # of builders engaged, median builder income, how many people do you provide a livelihood for/how good is that livelihood
-
not just looking to scale indefinitely, would rather be a 60 person collective where everyone is satisfied, making a good living, working on super interesting projects
-
need to balance growth w/QA
R Guild / dOrg
-
Don’t know that much about R Guild. They’re more open than dOrg, high engagement, lots of outward facing stuff
-
dOrg is a bit more closed off, people vet, then let folks in
-
R Guild also does cohorts
-
Novel products
-
dOrg does long term deep integration
dOrg
-
Private discourse forum to vet new projects
-
Sourcing incentive to earn a commission for projects they bring in
-
Sometimes more thought needs to be put into vetting / staffing projects, developed more q/a (tech lead & project manager badges), all projects must have one of each to ensure proper staffing/resourcing
-
read the handbook (https://docs.dorg.tech/lifecycle/activation)
Data needs
-
Challenges around filtering/coordinating to get someone who is responsible for coordinating and vetting
-
Need for application of judgment versus new information
-
*** internal knowledge is lacking, knowing what our cash flows are looking at, see if there’s a drop off in member activity, if client payments are slowing day
My Takeaways for Chainverse
- Value added by categorizing type of DAO i.e. client services/dev shop etc, so people can explore related DAOs (i.e. compare dOrg and R guild), and also to make sure proper metrics are used to evaluate them (member payout makes sense for dOrg but not R guild)