The Peeps DAO “difference” (warning: this gets nerdy)

Want more updates? Come on…sign up.

Last week we talked about our vision and mission for Peeps DAO — a DAO platform to decentralize politics and nonprofits — our tech stack for the revolution. Now, it’s time to get a little nerdy, dig into the details, and explain how what we’re doing is a different from other DAOs out there.

At its core, the Peeps DAO platform is building off the amazing open source work done by MolochVentures, The LAO team, and MetaCartel (plus some inspiration sparked by DAOHaus). We started by “stealing” the Moloch v.2 contracts, which solved some core user / organization mechanism issues (imho) and then we focused on making surgical, strategic changes that would allow our Peeps DAOs to be easily used by anyone with a little crypto and an itch to change the world. Our changes also focused on ensuring that a Peeps DAO could fit within an existing political or nonprofit organization or be in a place to “go legit” and take advantage of a US-based legal wrapper.

In praise of Moloch v.2

Moloch v.2 solves one of the biggest problems of Moloch v.1 when adapting for a political or nonprofit organization — i.e. creating a clearer separation between grants and donations. In Moloch v.1 only members, who had donated and received voting shares, could make proposals for grants. If that member’s proposal passed, they were rewarded with more voting shares in the DAO. They could only access the ETH or other “payment” tokens held by the DAO by quitting the DAO altogether and cashing in their shares for ETH held by the DAO. Not a great mechanism for the use cases we’re trying to address. Moloch v.2 solves this issue and introduces a lot of flexibility by giving people the ability to differentiate between a donation token and claims token and also updating the way proposals work so that a non-member can request payment from the DAO, but no voting shares, which is appropriate in many grant making situations.

From a legal perspective, this separation is also important for tax reasons. Donations, if to a 501(c)(3), are tax deductible and, if to a 501(c)(4) or 527 (political entity), are non-taxable from the organization’s perspective. On the other hand grants for work to advance a cause, like a payment to a venue for a rally, might be taxable income depending on the recipient. Thus, an easy way of differentiating between grants and donations is essential for any DAO operating as a legal entity.

Separating grants from donations also solves a UX problem. Most people who recieve a grant from an organization don’t expect 1) to be required to join an organization or 2) to receive a grants in the the form of membership shares. Again, Moloch v.2 does a good job of solving this issue by allowing members and non-members alike to apply for grants, which works well in the political and nonprofit context where you might want to fund activists or organizations that aren’t a part of your funder group. And v.2 lets grantees receive funds directly without dealing with any shares or lets them receive a separate grant claims token, if the DAO decides to use both voting grant tokens and non-voting claims tokens.

Now to get down to where we had to make some tweaks…

Contract Factory and Front-End

We’ve added a simple contract factory to allow for an easy launch of a Peeps DAO. All you need is Metamask, a little ETH, and a couple minutes to fill out a web form on our platform in order for a user to create a Peeps DAO. Our web form will minimize configuration, so users can focus more on what’s important (i.e. their cause). We will still let them choose things like whether they want to use ETH, DAI or some other token, how much grantees must deposit in order to make proposals (cuts down on spam), and voting period length. But we’ll standardize more advanced configurations that most people don’t care deeply about. The big win, still, is no more forking the Moloch code and deploying on your own to MainNet with Truffle or Buidler.

We’re also adding our own front-end to make participating in a Peeps DAO as easy as possible. We decided to build our own front-end to 1) reflect the changes we’ve made to the MolochDAO contracts and 2) clean-up some design / UX elements to make interacting with the DAO easier when it comes to membership management and proposals. When a Peeps DAO launches it’ll also have its own url on our platform and will show up with other DAOs launched on Peeps so that it can be easily discoverable. Giving every DAO their own url and pre-built front-end is another step towards making DAOs more accessible to crypto novices and the crypto curious alike.

It’s plenty of work to download Metamask and buy ETH, so we don’t want users to have to deploy smart contracts using the command line and then worrying about hooking up their own front end.

Semi-Centralized Membership Management

We admire the level of decentralization embraced by MolochDAO and YangDAO, but we realized that a lot of organizations have pre-existing networks or memberships and need a safety-valve when it comes to the types of proposals that can be funded from that DAO to avoid breaking any laws or organizational guidelines. To this end, Peeps DAOs have a more robust administrative layer to make managing membership easier and maintaining compliance and organizational integrity available.

Membership

Many digital organizations need an easy way for members to be added without going through the proposal process. Peeps DAO creators are the original DAO administrators and then have the ability to add other members as administrators. We expect that in existing organizations these administrators will be employees, officers or board members of those organizations. In more decentralized, new organizations, these administrators are meant to serve the role as moderators and leaders.

Administrators of a Peeps DAO will have the ability to add (or reject) new requests for membership. Applying to be a member will be as easy as inputting how much ETH or DAI you wish to contribute to the DAO. The voting shares members receive will be a function of the donation amount divided by the minimum donation required to join. Leaving DAO admissions in the control of administrators means that 1) there’s no need to clog up the proposal queue with requests for membership and 2) the DAO administrators can determine quickly whether someone is qualified to join (ex. only US citizens or residents should be allowed to join a DAO operating as a registered SuperPAC). Centralizing membership on the joining side supplies greater safety and efficiency for people looking to start Peeps DAOs.

On the other hand, we decided it was important to stick with the original Moloch v.2 code when it came to removing members. All organizations have to deal with bad actors and trolls at some point. Rather than giving admins this power, which could potentially lead to abuses of power — because absolute power over membership corrupts absolutely — we’ve made the admin controls over membership one-way. Administrators can add members, but it takes a vote of the membership to kick out bad members.

Advised Rage Quit

Another one of MolochDAO’s innovations was the rage quit function that allows members to pull out whatever’s left of their contribution if they disapprove of the direction of the DAO or a funding proposal that’s passed voting, but hasn’t been processed (e.g. in the “grace period”). We like this function in theory, because it provides a sort of safety valve for members with strong philosophical beliefs and because a mass rage quit can block a proposal that potentially passed with just a few fringe members’ votes. The problem is that the rage quit mechanic, as-is can create tax issues for donors if the DAO sits within a 501(c)(3) organization where the member may have taken a tax deduction for their contribution. Our solution is what we call an “advised rage quit.” When a member decides to rage quit and, in effect ask for part of their donation back, the ask first goes to the DAOs administrators.

We believe this will give a DAOs admins, who might be employees or officers of a 501(c) organization, the opportunity to discuss any potential tax consequences with a donor before processing the rage quit. To prevent abuse of power, we’re setting it up so that the rage quit will be processed automatically after 7 days, if the administrator still hasn’t approved the rage quit. We realize our advised rage quit probably isn’t a perfect solution, but we felt like it was the right balance between decentralization and working within existing organizational paradigms in the political and non-profit space where the return of a donation is usually completely at the discretion of the organization.

Coming Soon…

We plan on sharing the base PeepsMoloch contract as soon as it’s ready for primetime, so the community has more of a chance to weigh-in on our changes and help us think through how we further evolve DAOs into the primary vehicle for social and political change.

Next week we’ll take a deeper look at use cases for Peeps DAOs. In the meantime, sign up for the waitlist.