This is great to see the DAC idea is becoming more concrete. Overall, I think this is a great idea and anything to automate the process into an automate process is really a beautiful solution. As a product, you could really benefit the charity, non-profit industry, and show what transparency is about. Too often, we just don't know where the money goes and it just seems like a giant black hole. It would be easy to advertise especially unique URLs that goes to a specific child on the web site. Also, a CSV or JSON export of data will make nice reports and charts easier.
A few specific questions (not to detract from the overall idea -- just curious):
> - When a charity BBP address changes, the sancs would vote to delete a charity then add a charity (this would edit the record).
What happens to existing children recorded against the previous charity? Or are children and charity not related in that way?
> - Add an engine that is smart enough to allocate funds to a charity based on percentages of costs per sponsored orphan.
How will the accounting work if every child is a sub percentage of 100%? I wonder if it'll create accounting difficulty as opposed to fully funding each child and then the last child would receive what is remaining. Don't charities often have gap insurance to cover any dropped children?
2700 BBP
I'm going to need to create a DAC thread for this as I realize its going not only be cleaner, but I will reply here until I release the wiki for the DAC, as I know there will be a massive amount of design required to make this work (and after thinking about the worthiness, I think it will be worth it).
Q "What happens to existing children recorded against the previous charity? Or are children and charity not related in that way?"
-> The idea of having an entity for the Charity and an entity for the Orphan, is more of an database-integrity decision. It would let us start creating a model where we store numbers of orphans as orphans with their related info, then charity related info in the Charity entity. At this point I think we would actually store the data in the chain, so it can work purely decentralized. This would mean the DAC feature could say, it works entirely within the blockchain and with governance decisions. As far as operations goes, it means if we were to vote out a charity (due to corruption detected), all the orphans would be considered invalid and would no longer get paid. As far as reporting they would just be logically deleted, so you could "see them" on certain reports, but as Deleted. We would no longer have to pay for those orphans if we deleted the charity. So it would be a serious decision. As far as editing the record, we would delete and add the same charity with the same primary key with a different address (thats if say Cameroon ones receive address changed). That would not disturb the children because they would still refer to the same charity by name (IE if the primary key was 'cameroon-one' for the charity).
Q How will the accounting work if every child is a sub percentage of 100%? I wonder if it'll create accounting difficulty as opposed to fully funding each child and then the last child would receive what is remaining. Don't charities often have gap insurance to cover any dropped children?
-> First actually I believe from what Ive learned that Gap insurance is not the standard, Ive only found that compassion has it. I dont think cameroon has it, they might have a pool of money that keeps the child safe but that would be from their goodness not from gap insurance. I believe compassion has an actual insurance policy that pays for dropped children while they wait for a new donor. So I believe its the exception rather than the rule.
Lets break up accounting as a separate process from expense allocation. I think we would have one expense allocation engine for monthly donations, and an accounting process that stores the actual debits and credits in and then a separate report that groups and summarizes them. It would be up to us to write more rpc or pdf reports from the chain data as necessary. But the good news is, all of the data would be in the chain forever, and it could be reported on any way they want.
I do want to say, the big pro of a DAC vs plain vanilla (dashlike) governance is this:
Scenario A -> Plain vanilla governance -> Each month, beggars come begging from around the world, unvetted, and some rich already, some from rich countries, begging for money for causes for everything, and the public (who may not have an orphan but owns a masternode) votes away the money perpetually. Then the money is spent less efficiently.
Scenario B -> A true DAC -> Each month, as we get smarter and smarter because of our orphanage relationships, we maintain only the most efficient orphan charities over time. The actual sponsored orphans are maintained as long term commitments. The random gifts given to our charity addresses allow the sancs to perpetually vote in sponsored orphans and charities who have been proven to sponsor children for the lowest cost per child month- otherwise those charities get replaced with new charities. This gives the casual donor the understanding that when they give to BBP, they are seeing $20 equal to 30 orphan days for example. In scenario A, they would be lucky to see $20 equal to 15 orphan days, half of the time (meaning the true # is $20 for 8 orphan days in scenario A due to waste on half of the other proposals etc). And, I do realize Cost is not always equal to quality! I realize that, and we certainly need to include metrics in for Quality and not just cost, for example, compassion provides school materials, relationships with pastors and leases, food, etc. We would not simply go with SAI because they are cheaper - we really need to vet all of them and score them with multiple facets. We need a bounty for a PDF audit also. It would be cool to see how one scores on 5 facets. The other big pro would be the automatic distribution of donations to our charities by burn-relay. That simply does not exist with plain vanilla governance. (This would enable us to have a global burn address for donations, and let the user know how efficient it is to simply send BBP to one address that helps children!).
So the vision would be to create some type of live metrics also, where we can show quantifiable proof how efficient we are.
Then finally, from other connected services like BiblePay TV, a person on a couch can click Donate $2 in BBP to sponsor an orphan for 5 days, for example etc.
I think to answer the 2nd question, how the funds would be allocated, if say for example we have 50 sponsored orphans, we would have a daily rules engine that sums up the 'whale matches' vs 'sum of donations'. It would allocate those to the monthly pools. Then it would divide the BBP available by allocating it to each of the charities by active orphan sponsor % (IE 80% to cameroon-one, 20% to SAI, or whatever that # currently is). Once it has the allocation, it would convert that amount to USD and make internal accounting entries (IE credits to each charity) and store them - so basically when you run the report later by charity name, you would see the distributed amount as credit per day. The main reason I switched to Daily, is because I have discovered the amount burned per address must be collected daily for chain safety and forwarded in the GSC superblock to the charities (so it does not pile up per month).
So I think the accounting reports would contain daily data, but of course could be summarized to monthly.
As far as changing the rules engine to pay for a certain number of children then let them drop off, I think the biggest hurdle with that is we really cannot estimate how much is coming in randomly from the global donations daily, so I think to handle a day with 10MM donated vs 100K donated, we just allocate the amount across our charities by % owed and make the accounting entries across the board. IE across every child. Then once per quarter, the sancs will decide if they need to drop children or add children.
4300 BBP
