Problem Being Solved
Presently charitable giving requires the actions of an intermediary. This intermediary selects the funds, controls distribution, controls communication with the people on the ground (actually doing the charitable work) and the people giving the funds. The Giveth platform plans to remove the intermediary, make it easier for individuals to collect funds for work they want to do and enable closer communication between the Giver and the Recipient.
How it Works
To make this system work there are a number of roles and entities which will be described next. If you want to read the actual description from Giveth, it is here.
It all starts with the Giver. This is the person who donates Eth to a worthy cause. The Giver can contribute to a DAC, a Campaign or a Milestone. For simplicity a DAC (described in detail below) might be a charity dedicated to reducing poverty in a country. A campaign would target reducing poverty in a neighborhood. A milestone would be buying books for particular library.
When the Giver transfers their eth, they do not simply transfer the eth to a different account. It is placed in a “vault” and the value transferred into a token called and “MimiMe”. These tokens are transferred through the system. The Eth is not actually transferred from the vault until it is given to a Recipient. This reduces the chance for corruption. The intermediate people are not able to actually access the funds that have been donated.
A DAC is a Decentralize Altruistic Community. A DAC is a greater campaign. In some ways, the DAC is probably closer to the givers (to the money) than Campaigns or Milestones. A DAC can collect funds and delegate them to Campaigns or Milestones. Of course they do not actually delegate the eth to the milestones but the MiniMe tokens. The DAC is run by a Delegate. To start with the Delegate is an individual, but later it could be an Aragon Entity representing a bigger group. Once a Delegate sends MimiMe tokens to a Campaign, the Giver has 3 days to reject the transfer or their funds are locked. Functionaly a DAC is a type of DAO.
A Campaign is close to the ground and making the world a better place. Their participants are head down distributing the funds and changing the world. The Campaign is owned by a Campaign Manager who makes the decisions for that Campaign. Primarily the Campaign Manager creates Milestones and fund them. The Campaign Manager just moves MiniMe’s not real Eth. A Campaign could have many Milestones as each different kind of payment is made.
Milestones are the only way that funds can actually leave Giveth and go to the charitable works. Milestones must be created by a campaign. A milestone could simply pay an amount to the Campaign Manager that allows him to buy library books and donate them to a library. Milestones could pay a supplier. Milestones have a set of details (amount, reason, etc) and a time limit. Milestones are managed by a Milestone Manager chosen by the Campaign Manager. When a Milestone is declared complete then the Eth in the various vaults are transferred to the Recipient, rather than the MiniMe tokens they had previously.
In order to keep the Campaign Manager and Milestone Managers honest there are formal review functions for each task. The Milestone Manager can mark a Milestone as Complete or Cancel it. A Campaign Manager can also mark a completed Milestone as incomplete, cancel an in work Milestone or even cancel the Campaign.
Under the Hood
In one of the Zero Knowledge podcasts (highly recommended resource by the way), Griff Green mentions that the development of Giveth is at least partially a vehicle to test the use of a fund holding DAO within a fixed risk base. He was deeply involved in The DAO hack (July 2016) and realized that high $ DAO’s need to earn their trust back. Giveth allows a vehicle to do this. By keeping the size of individual DAC’s and Campaigns (Not that I have heard of any limits) they can have DAO’s trusting money and test the system in the wild.
Detailed information on the Giveth contracts is available on their website.
Ideal Use Case for Blockchain?
According to Vitalik’s 5 Points how well does this use case suit a blockchain application? Score 13/25, 51%. Good