Hi guys,
After a series of whiteboarding sessions and gathering feedback about The DAO architecture, we are hacking on an integration of SourceCred into an Aragon DAO this weekend at ETHBerlin. We would love everyone’s feedback. The plan is the following:
Merkle-ize SourceCred score to be represented on-chain Deploy a merkle hash to the distribution contract. Create a DAO to vote and pay out the distribution contract. User calls to withdraw.
It seems reasonable in principle, although I have a few questions:
At ETHBoston last weekend I worked on Credao | Devpost (with @cslarson) , which should work reasonably well as a way to bridge sourcecred with an aragon org, and follows the merklized distribution approach.
We created a manual mapping between GitHub usernames and ethereum addresses, and created a basic script to process the cred.json file output by sourcecred into a csv file containing addresses and amounts that can be uploaded to an Aragon app to create a merklized “airdrop” of reputation or tokens.
When a user goes to the app they can claim their tokens/reputation from that distribution.
The process is still fairly rough, but we plan to polish and automate it a bit.
I think ideally users would be able to claim their distribution in the future even if they haven’t registered an address. If we use a process where users must register their address they want to use, if we don’t have their address we cannot include them in the distribution.
The flow that seems most compelling to me (for github especially), is to counterfactually deploy contract wallets for each contributor (assuming we don’t already have an address mapped for that user). The user would then be able to claim this contract wallet by logging in to a server (or perhaps something like tor.us when they support github oauth in their product). Once they have claimed their address they can revoke the oauth, or just use it as a recovery option.
The nice thing about this is that we would not need the user to even know about the DAO or web3 when they start contributing and earning cred. Planning on exploring this solution more, as I think it would be really cool to allow a github organizatiot then to subscribe to a sourcecred-aragon service, and have all this happen in the background.
At the moment though, the implementation assumes that we have an address for a user at the time we are doing the distribution, so users would only start accumulating cred in the org once they have registered an address in some way. It would be possible to do a manual distribution or even just a one time proposal to mint a user tokens/reputation in order to correct for “missed” distributions but that would be a manual intervention.
When a distribution is claimed, we update the state to prevent it from being claimed by or on-behalf of the user a second time.
This is awesome. Glad to see Aragon has the functionality to do this!
The address issue I don’t think is such a big deal. Have seen a couple contests deal with this by the maintainer just telling the participants to message them their BTC address, for instance. If you’re putting in work on a project, and interacting with the people paying, coordinating on that shouldn’t be too difficult. Of course, doing it on a larger scale, or airdropping tokens based on past contributions, is going to be a bigger challenge. One idea I had is to just create burner wallets for everyone, and send private keys to those who come to claim it.
A much more difficult problem is how to integrate SourceCred into a truly trustless system. E.g. a DAO where you show up, work, and the system pays you automatically, no trusted human necessary, in a censorship resistant cryptocurrency. Though that is further down the line and don’t want to get my cred dinged for bikeshedding 