Dapp Integrations in DAOstack

Dapp integrations into the DAO stack can be largely separated into two categories:

(1) Alchemy / Dapp Service Providers:

Dapp service providers can be thought of as protocols or specific services that add universal value to all DAOs in Alchemy. They are typically more infrastructural, and not related to schemes or voting, and typically do not have adjustable parameters.

Currently no guidelines exist on how these service providers would exist in the Alchemy interface (such as, say, an additional item in the left-hand navigation bar). Generally, though, their suggested implementation should be approached with caution, and well thought out, as they can affect all DAOs within the interface. Service providers interested in integrating into Alchemy should generally contact the DAOstack Technologies development team before moving forward.

A potential proposal that could be of potential value within the GenDAO would be to:

  1. Map out a comprehensive list of providers
  2. Speak with users and identify the highest value or most desired integrations
  3. Inquire into funding or internal resources available for integrations by each provider
  4. Project manage an active integration into the DAO stack by a service provider
  5. Publicize the integration

The team or DAOstack community has spoken with, met, or evaluated the following service providers:

Name Description / DAOstack use For an introduction
AZTEC AZTEC has been discussed as a privacy solution for voting, that is, anonymous voting and/or anonymized voting results. This integration is being actively explored here. @cryptogoth
Limepay LimePay is a SaaS platform that enables end-users to freely execute transactions for decentralized applications (dApps) with fiat money, specifically, a credit card. @pat
Portis Web3 injector with forthcoming Wyre integration. @alexz
Wyre Fiat <> crypto browser trading extension. Currently only supports U.S. verification.
ENS A web3 human readable domain name provider for .eth domains. May be implemented into the DAO Creator by dOrg; that is, DAOs could register a .eth domain upon creation. @pat
8x 8x is a subscription services provider. Supports scheduled, recurring, and batch payments, such as payroll. Could be used for DAOs to make recurring payments, as in the case of recurring proposals. @pat
Gnosis Safe Web3 injector and multisig wallet. Currently being integrated into Alchemy. Gnosis Safe will in the future support gas-free metaTX, that is, users will be able to pay gas fees in the cryptocurrency of their choice. Therefore, the safe will be able to abstract away the need for ETH to use the Alchemy interface. @alexz
Gas Station Network(GSN) The GSN project is a decentralized system which would enable Web3 users to write onto the Ethereum blockchain without needing gas. The R&D of the project was completed last year and while there is a testnet live, it is undergoing current audits. A GSN DAO has been brainstormed by Peter Pan of the Metacartel DAO. @pat
3Box A decentralized profile, identity, storage, and commenting solution. 3Box is currently the DAOstack technology teams’ preferred candidate for replacing Disqus within Alchemy’s commenting section. @alexz
Gilded Invoicing and bookkeeping Ethereum software. @orishim
Kaunto Accounting and bookkeeping software. @pat

(2) Dapp integrations (Generic contract scheme implementations):

The second category of Dapp integrations are largely method based, that is, they consist of calls being made to other smart contracts on the Ethereum blockchain using a DAO. They are different than Dapp service providers as these types of integrations tend to sit within the proposal queue and are actions being actively taken by the DAO.

As has been mentioned in the past, Alchemy will support additional schemes to the familiar Contribution Reward scheme used to assign Reputation and/or tokens from the DAO’s wallet. The support for multiple schemes is a key feature of the dxDAO, as demonstrated in the below mock:

One of the additional schemes supported is what’s called the Generic Action scheme. What does this mean, exactly?

The generic action scheme is used to propose and execute calls to a function or smart contract on behalf of the DAO’s avatar. This means that it allows the DAO to conceivably do anything on the Ethereum blockchain. For those more familiar with Aragon’s DAO OS, it is roughly analogous to Aragon Agent.

@adam’s (CTO) words on the matter:

“…The idea is that an organization can do anything on the blockchain. So for example, we can tweet on Peepeth or it can get some DAI for Ether on the Maker contract. It can do anything… We call it a generic scheme because it just calls the contract. And Alchemy will soon have UI for that.”

However, there are some design decisions the team has taken in relation to the Generic Action scheme that should be known. Taken from a conversation with @alexz, our friendly Alchemy Product Director:

When you hear “generic action” for the first time you automatically start thinking “how will I support all the possible actions that the scheme supports" – it is after all designed to be completely generic. It would require Alchemy to understand the methods that can be called (on the whitelisted contracts), understand the parameters needed to execute it, and dynamically generate a form with all these fields and the correct types needed for them…

…this sort of automated interface creation has been done before, and typically looks like so:

This is approach is indeed very generic and could probably support all the methods a DAO powered by DAOstack would need to call. But it has two major drawbacks: (1) it is complicated to build and (2) it lacks context for each method / parameter.

Context is very important and this is actually very easy to illustrate. If we look at the methods the dxDAO needs to support for the DutchX, we will find a method called ‘updateThresholdNewAuction’ and it receives one numeric parameter ‘thresholdNewAuction’. It would require a very deep understanding of the DutchX contract to know that this numeric value should represent the USD value of a tx, represented as “USD wei”… It would also be impossible for the UI to know that it needs to put a $ sign next to the value when displaying it.

The other option is to create a custom UI for each method we’d like to call using the generic action (the dxDAO requires us to support 7 different methods). This approach is not very generic – in fact, it requires us to manually “whitelist” every method that will be supported by the UI. However, it allows us to solve the context problem since we have complete control over the final UI.

After many discussions about this, and looking at our objectives, we decided to start with a custom UI solution – because context is this important. As we need to add more generic actions to the supported actions list, we will either design additional UI forms ourselves or ask members of the DAO ecosystem to add them (it will be easy and well documented). Yet, in the slightly longer term, we will also build the true generic generic solution to support those esoteric methods we can’t add custom support for.

A proposal that could be of potential value within the GenDAO would be to:

  1. Speak with users to identify the most desired methods to integrate
  2. Inquire into funding or internal resources available for integrations by respective projects
  3. Work together or design directly the interface needed to call the method
  4. Publicize the integration

The team or DAOstack community has spoken with, met, or evaluated the following Dapps:

Name Description / DAOstack use For an introduction
Kleros Proposal arbitration, that is, being able to designate Kleros arbitration protocol for conditional proposals. @pat
Akasha DAO published blogs and other content. @pat
Aragon Aragon has a wide application suite with many potential uses – Aragon Court: A proposal arbitration protocol; That Planning Suite: Bounties, range voting; Survey: Polling or “signal voting;" … and more. An Aragon <> DAOstack bridge could be constructed by assigning control of an Aragon agent to a DAOstack DAO avatar. A scheme has been explored by Doug King here. @cryptodani
MakerDAO DAO leverage (collateralized debt). A MakerDAO CDP scheme has been evaluated by @gh1dra.
Dharma DAO lending and borrowing. Issuance of DAO debt tokens. A Debtor DAO concept has been explored and developed by Bo Hendo here.
Mattereum A legal registrar for assigning ownership of physical assets to a DAO. @pat
Kauri A substitute for Medium to publish technical Web3 articles that are hashed to IPFS. Not yet supported on the Ethereum mainnet. @pat
Pando a remote protocol for git repositories enforcing DAO-based versioning, contribution tracking and governance. @cryptodani