Proof of concept Decentralized Autonomous Charity2

From BiblePay Wiki
Jump to: navigation, search

Creating a BiblePay Decentralized Autonomous Charity

Author: Rob Andrews
Date: May 8th, 2019

One of the goals of BiblePay is to create a true Decentralized Autonomous Charity. This is a type of Decentralized Autonomous Organization.
The facets of a DAC include:
No Legal Corporation in any Country (this helps BiblePay from being over-regulated with rules that might encumber BiblePay or cause lack of anonymity to our users). It also protects us from being used by the Enemy of God for his purposes (see 501c3 risk).
No single point of failure. This means that if a single developer or the founder or an operations manager dies, BiblePay continues to function autonomously in the respect that blocks continue to mine, payments transfer, payments are made to charities and revenue is collected by our chain.
Decentralized Resilience. This means that because we have automated decentralized and multiple technical processes completing the operational function, the function will be executed more accurately and efficiently (than a single person could execute the function).
Institutional Investors. The institutions are wary to invest in a one-man-shop that could go down if the sole proprietor is sick. In the case of the DAC, we automate these processes into our code to prevent single points of failure. This opens up BiblePay to exciting investor opportunities for institutions that would not consider BiblePay otherwise.

The goal of this solution is to remove the largest risk in BiblePay and cover both expense (charity dispursements), revenue (orphan fundraisers), and governance decisions. This makes BiblePay a true DAC.

Revenue (Fundraising Activities) BiblePay currently escrows 10% of our Block Chain emissions for the purpose of governance-emitted Charity dispursements. In the current state, members from our governance committee create proposals manually for Compassion, Cameroon One, and SXS to cover the expenses for our orphanage sponsorships. Multiple problems exist in this scenario: Proposals are manually created, sanctuaries manually vote, some of our vendors do not accept BBP payments (requiring a liquidation to be done by a representative manually), records must be entered into a database for accounting manually, and some of our partners question the accountability records (although they are provably accurate now, when reverse engineering the orphan count).

To tackle the Revenue side, we propose to create an instrument called an Orphan Bond. This bond will pay the potential bearer 1% cumulative interest per day until someone buys the bond. At the point it is purchased in the core wallet, the bond will be stamped with the purchase date, the expiration date, the duration, the amount, the interest rate, the orphan ID, the Charity name, the buyers receive address, the governance budget ratios, the starting and ending expense information and any notes about the bond auction from the core wallet. This will all be done automatically inside the core wallet.

The core wallet will scan its internal non-financial transactions for available Orphan IDs who have no bonds outstanding and where the governance budget still fits the new bond in the next budget.

For each day that passes, if a bond is not purchased, its offered interest rate will increase by 1%. So on the 24th day, the bond will offer 24% interest. Most bonds will be 90 days (this gives ample time for checks to be fully cleared).

The buyer of the bond will have the Obligation to mail a paper check to the charity on the bond with the amount in USD. So for example, if the buyer of a bond buys a bond for compassion with a face value of $240.00, the bond buyer must mail a check to compassion for $240 within 45 days with the orphan ID listed on the check. (If the check bounces, or never arrives, the bond will not pay any BBP back to the buyer (see defaulting on a bond)).

With this system in place, our core wallet will automatically conduct fund raising activities by creating bonds automatically - and our expenses will still be tightly controlled because bonds will NOT be created after the budget is spent.


If a buyer purchases a bond, and they are obligated to write a check to a vendor, and that check either BOUNCES, or they fail to write the check, the vendor will not credit the orphan ID with a credit. This means that when that bond approaches its expiration date, biblepay will not issue a payment for that bond to the receive address (its governance vote will automatically become NO) - (See automatic governance voting with partner API).

Replacing BiblePay Expenses with DAC Expenses

We currently liquidate our BBP manually and then one of our team members converts the BTC to USD via Coinbase then forwards the cash to the vendor.

In this new scenario, our bond buyers will be paying for specific orphan IDs for 6 months at a time ($38 * 6 = ~$240.00). In this way, we automate and decentralize the orphan payments.

Requiring the Governance Vendor API DAPP to integrate with BiblePay

To facilitate the automatic integration for the Yes/No decision to pay a bond, BiblePay will develop a Vendor API with our top vendors. This will allow a vendor to post a check automatically, and will allow BiblePay to query a GlobalOrphanID for the current balance. If the Orphan ID is either negative (credit balance) or in good standing, that particular bond will be paid. This will be accomplished by adding code to our Sanctuary that will allow the sanctuary to auto-vote on the particular proposal. The Proposal will have a certain naming convention that allows it to be pulled up (for example: Bond09012019 (meaning : Compassion September 2019 OrphanID 012345 Due 07012019). This will access the governance proposal for the bond issued in July.

Note: BiblePay will also automatically create the governance objects and proposals as bonds are issued in the RPC. In this way no manual labor is required by any biblepay user or administrator.

Example Bond Payment

On June 1st, BiblePays Charity budget is 10,000,000. BiblePay Core decides it has the budget to issue 5 Compassion bonds for $240.00 each. Bond #1 - Compassion001 - $240.00 face value is issued on June 1st. As each day passes and Bond #1 is not purchased, its interest rate increases by 1%, meaning that on day 20 it is offering a 20% interest rate (for 90 day duration). On June 20th, Bond #1 is purchased by John Doe - The BBP price is locked into the bond (.003), therefore the base amount is 80,000 bbp and the interest component (20% for 90 days = 3999 bbp) yielding a 83,999 bond. The transaction is recorded in the chain, a governance proposal for 83,999 is created and a transactionID and full rpc response is given to John Doe (proving that he has purchased the bond), and also instructions for wire or check are emitted in the RPC (Compassion, Compassion Address, City, State, Zip, Orphan ID etc). John Doe mails a paper check #1001 to Compassion on June 25th. On September 19th (1 day before expiration of the bond), BiblePay Sanctuaries check the DAPP output for Bond #1 - and find that Orphan ID 12345 has a $-240.00 credit balance). This causes each sanctuary to vote YES to pay this proposal. During the end of the month governance cycle, this proposal pays out 83,999 to John Does receiving address (recorded in the bond).

Letter Writing
As an additional feature we may also require the bondholder to write (1) letter to the orphan before the bond expiration date. This simplifies our infrastructure. Bond interest may possibly be increased to include compensation for the letter writing activities.