# Practical Private DAOs

Written by Sam Hart

This posts briefly describes a private DAO design that incorporates a number of existing social primitives that we typically associate with other product categories, wallets, identity, lending, to form something unique. The Gnosis Safe is incredibly important for institutional custody and on-chain access control, however anyone who has used it will attest that the product is exceptionally cumbersome and confusing. Vertical integration into the core wallet/identity system can alleviate these issues.

The system proposed here is “relational” in that it has no global notion of identity or reputation, but leverages measures of trust that are intrinsic to familiar social actions. Likewise, there is no “proof of personhood,” only an abstract notion of an account who is trusted to take certain actions.

## Forming trust through action
Here are a few examples of behavioral patterns that embed a notion of trust:
- I want to allow a social recovery scheme where ¾ accounts can access my funds. One of these accounts is a hardware wallet I own and the other three are trusted friends.
- Me and my 3 friends have a group account in which all of us can withdraw up to $100 a day, any spending beyond that requires a vote.
- I’m running a business and I want all 5 of my employees to be able to see how much cash we have on hand, but only want my co-founder to see itemized spending.
- I’m a parent and my child is going on a trip abroad. I want to ensure they can borrow money from me without interest if they need, but I’ll ask them to repay the loan from their next paycheck.

There are two things that are common to all these examples:
1. There is no requirement for global identity, I know all the entities involved and can simply ask them to give me their preferred account identifier via a trusted channel, eg. in-person, Signal.
2. The creation of a trust graph is a product of my primary motivation to engage in some real-life process.

Let’s break down that’s happening in the examples above:

__Social recovery__
- There are 5 accounts involved
- There is an account (A) that sets up the social recovery scheme
- 4 other accounts that are conditionally authorized to recover (\R)
- Account A has established a recovery policy that indicates ¾ R accounts can perform privileged actions

__Group money__
- There are 4 accounts involved
- 1 group account G
- 3 member accounts (M) that each have a spend limit authorization and an ability to vote on other actions taken by the group account
- Account G has established a membership policy for general governance and a spend policy for each account M

__Company__
- There are 8 accounts involved
- 1 business account (C)
- 2 founder accounts (F)
- 5 employee accounts (E)
- Account B has established 2 policies regarding its own visibility
- Founder accounts may see all history
- Employee accounts may only see the total balance of C

__Parent__
- There are 2 accounts involved
- Lender (L)
- Borrower (B)
- Account L has established a policy that allows B to withdraw funds from their account, in this case the loan is uncollateralized, however variations could include collateral liquidations or automatically adjusting L’s lending policy toward B in the event they fail to repay the loan within the agreed upon term

What we can see here is that there are a few common primitives, accounts, authorizations, and policies. What we’d also like to find is a set of simple capabilities that compose well, or can be parameterized to build useful systems. Some common traits include:
- Transferring funds (within certain bounds)
- Disclosure of state
- Creating or modifying policies

Some common traits of policies
- Can revoke authorizations after some time period and trigger some conditional action (eg. liquidation)
- Often specify some set of entities that can modify the policy

## Prior work
PGP also incorporates an ad-hoc relational structure with various “trust levels” that can be used for different forms of authorization. PGP is often criticized for being complex and hard to use, in-part due to its relational structure, however subjectivity wasn't necessarily the root of its failings, just poor UX. Modern social media has actually made relational systems much more intuitive to the user, and demonstrated they are technically tractable.

This design owes much to Scuttlebutt, which showed it was possible to take these same encryption principles and combine them with a social network composed of “follows” to create a practical decentralized network with no trusted name server. Scuttlebutt also leveraged a rudimentary pet name system that was functional (though more [sophisticated versions](https://spritelyproject.org/news/petname-systems.html) exist). However, account abstraction, similar to crypto wallet social recovery, was a much-requested feature.

## Private on/off-boarding via P2P lending
One powerful use-case for this system is a decentralized version of splitwise which would allow for trusted groups to create temporary debts that they can later settle. This is particularly interesting because it allows for users to onboard or offboard to the system through this temporary DAO. A new user be represented in the system with a debt that can be settled in cash with their friends later. More advanced versions of the system could be created with transative lending that can be automatically settled. This is a practical use-case for the "liquidity saving" schemes central to CoFi.

## Web of trust
The proposed system creates an emergent web of trust, which can be levereged by other applications. Perhaps a specific application requires a semi-trusted solver to avoid griefing attacks. To accomplish this the application could leverage the trust graph and specify a scoring method that aggregates values along the path from user to the solver.

## Why private DAOs
Our goal is to maintain user privacy, and in order to achieve this it's not enough to have a shielded asset pool. The behavioral patterns and social data closest to the user must also be private. This means creating facilities for communities to live within a shielded environment, and interact with transparent systems only through batched actions that leverage the entire shielded network for anonymity.