June 12th, 2019
Concept: Proof-of-Orphan-Mining (POOM)
** CLARIFICATION ON WHAT WE ARE VOTING ON, SANCTUARIES:
The "Divert_50_percent_of_GSC_Budget_to_POOM" poll:
We are voting on creating an additional BiblePay GSC campaign called POOM. This 50% poll means the budget would be capped at 450K per day.
(This would lower the POG/healing budget by 450k per day).
Each participant would receive rewards in POOM if:
- They have a credit balance with Cameroon for that Child Hex ID
Each daily reward would be capped at the exact amount of the expense.
The budget will not exceed the max 450K under any circumstances (rewards would be divided equally if we are overflowing with children).
(Please vote on the poll that you like the most - we have 3 sizes in ).
**
This concept has been discussed in various forms in the past, but I believe the reason we had no traction was the variants contained unreasonable expectations. (Our first variation, POOM@Home with orphanstats.com, required BiblePay to know personal information for each user (it required trust, contained collusion risk, and tracked personal info; and the poll indicated it was intrusive). The second variation, asking compassion.com's IT department to create a custom API for decentralized queries, was proposed to Jimmy, CEO of Compassion - and to ciqueue - and all attempts were met with a very high resistance level ranging from not willing to hear the proposal nor have meetings nor nor creating a custom solution for us at this time).
So in light of this, this new concept places a different spin on the idea, and bends both parties a little more, revisiting the idea. The base idea, imho, has such great potential, it would be a disgrace to ignore and drop the idea in its entirety rather than take another fresh look at re-engineering it to meet in the middle.
Some positive things have also changed in the interim; we now have GSC contracts, which facilitate a much more flexible server side environment for validating the orphan balance consensus in a decentralized way without forks. This also provides a mechanism to reward home sponsors.
In this adjusted concept, we promote sponsorship of children at home (rather than through our governance superblock). We do not eliminate our governance superblock; we offer POOM in addition to everything else we already have. This has the added benefit of allowing the home miner to sponsor a home orphan and write directly to the orphan (1:1 relationship is fostered). (Alternatively in the future, we may also allow the home user to Choose whether they want to write to the child or if they want our BiblePay-Web to write to the child- more info on this soon).
Rob has contacted our second largest orphanage, Cameroon One, who is potentially interested in integrating with us.
In this new scenario, we simplify the API requirements, so that we integrate with a simple solution in baby step 1 (in contrast to birthing the complicated baby first, something our vendors do not want to do). In this way we get a green light to became a partner with our valuable vendor, rather than shut down.
The first part of the concept is here:
http://wiki.biblepay.org/POOMPart of the desire to create this pre-proposal discussion now is driven by our initial conference call. I have a soft commitment from Todd, Director of Cameroon, and Shaun, Founder of Cameroon, and Raj (IT/Cameroon), that Cameroon will be on board with BiblePay to go forward with this design, proof of concept, testing and implementation. (I also had a conference call discussing the IT solution, and we have a potential green light to do this).
Therefore, this proposal seeks to authorize BiblePay IT (devs) to work on this proof-of-concept, for three months, test it with Cameroon, and if it works, seeks to deploy this to production, and reward either 30%, 50%, or 70% (depending on specific sanctuary proposal entered this month) of our daily rewards out of the GSC budget, towards the sponsorship of Cameroon One children in lieu of POOM rewards, strictly for children who are sponsored through this program by miners who sponsor personal children at home through this system. (The reason I am seeking approval of the entire program now, is it is a considerably large effort for both companies, and I want to see that we have pre-approval for this to move to production and pay production POOM rewards before we program the lions share of this).
Note, in the security section, we intend to create two rules that make this relationship much more than an oracle:
Rule 1:
When a miner wishes to sponsor a new child, they will enter a command in the wallet (IE 'sponsorchild'). When the sponsorchild command executes, they will receive a Child ID (a Cameroon One Child ID). This will be a distinct global ID that will prevent Cameroon One from giving this child to any other donor! Therefore, we will enforce a rule where an existing Cameroon One home donor cannot come to biblepay with an existing orphan, they must initiate the orphan through BiblePay. During this step, Cameroon will create a childhood BIO URL for the miner, and, a tracking code in their accounting system (allowing BiblePay sanctuaries to track this childs balance as charges, and payments are made to this childs record). We will have daily visibility of each childs balance per miner.
Rule 2:
A public method will be set-up to allow random checks for any orphan sponsored by a miner by a third party auditor (IE a normal end user can check the balance of a child and call Cameroon and check the integrity of the childs status, to ensure the child is with BiblePay). (This is similar to what we have with Compassion), so that it will be 100% provable that sponsored children through POOM are really sponsored to BiblePay.
Payment Mechanics:
So that we can scale to the maximum, I propose that the payment owed to the miner is converted to a daily amount, and awarded as POG points to the miner and paid from the POG GSC budget. This is primarily so this POOM budget is friendly to our existing POG budget (in that people sponsoring children do not abruptly take over their own program budget but instead part of the POG budget).
Example:
John Doe, Miner 001, CPK 001, Sponsors Abraham, Cameroon One Orphan #ABC, for $40.00 per month.
Since this costs John Doe $1.33 per day, (and our wallet knows the current BiblePay Price thanks to QT), this is auto-converted to 4430 bbp per day (via the GSC contract), and this BBP is diverted from the Total daily POG budget (by converting to points) and added to John Doe's GSC CPK for the day. (This reduces the available reward for the rest of the GSC participants).
(We can discuss a separate project for POOM, which GSC certainly supports, but imho it would be better to divert POG -> POOM, more on this tomorrow).
If total orphan payments exceed GSC rewards, they then start to be split equally among all participants.
Electric:
As everyone can see, this concept has a huge potential, because it has the effect of diverting normal mining rewards over to orphan sponsorships.
Unlimited BBP Potential:
One other effect that is less obvious, and I intend to create a model for this and paste my hypothesis, is that I believe if we open up the potential sponsorship of outside orphans (as proposed here, through cameroon one) with home users (miners), via USD payment, with the tax deduction (this was confirmed with Cameroon, that the payment is tax deductible) - received by the end-user, as the BBP is remunerated back, this cycle should technically have a very positive impact on our market cap and price. This is because our mining rewards would change into pass-through rewards (IE reimbursements) for a certain percent of our emissions. Yes, some pass through reimbursements would be liquidated immediately to cover the costs of the orphan, but I believe a certain percent would be held by miners (IE in a sense a tax-deductible buy-and-hold of BBP).
What makes this POOM concept an attractive configuration?
Currently I view BiblePays emissions flow as:
POBH - Security - 25%
Sanc rewards - 25%
GSC (Primarily Staking/Giving) - 35%
Governance Budget - 15%
As you can see, this is a very good configuration already, but with POOM, we can potentially divert some of the Staking revenue over to fully productive orphan reward payments. And, if the test pilot works, once we have chain locks in place, we could also potentially move some of our security budget into POOM (Optional, depending on various factors).
Decentralization:
And one of the very obvious advantages in this idea is it decentralizes biblepay, allowing us to scale (as each home miner sponsors their own personal orphan using their own funds).
Show Posts