Difference between revisions of "BiblePay DAO"
(7 intermediate revisions by one other user not shown) | |||
Line 9: | Line 9: | ||
== The BiblePay Foundation == | == The BiblePay Foundation == | ||
− | The BiblePay Foundation is a non-profit Texas Corporation that | + | The BiblePay Foundation is a non-profit Texas Corporation that manages vendor relationships, vendor payments, orphan fundraisers, cryptocurrency exchanges, taxes and legal decisions. |
The Foundation will initially be created with 6 board members invited by the Founder of BiblePay. It will then become autonomous, since its bylaws will have processes that ensure continuity, such as the ability for the foundation to vote in replacement boardmembers and remove non-performing boardmembers. | The Foundation will initially be created with 6 board members invited by the Founder of BiblePay. It will then become autonomous, since its bylaws will have processes that ensure continuity, such as the ability for the foundation to vote in replacement boardmembers and remove non-performing boardmembers. | ||
− | The board will | + | The board will consist of: |
− | + | Sanctuaries | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 47: | Line 41: | ||
The reason we will transition through phases is: There are several risks involved when transitioning to a cross-trained environment that could be used maliciously while the coin is small. It is clear that Rob must have the best intentions since he has a lot of development hours and integrity at stake, so the assumption is while marketcap is between 0-20 MIL, the safest path to preserve the coins life is to trust Rob with sporks and deploys until the size of the marketcap exceeds what is considered a small operation and above the scope of a single dev. From Rob's perspective, the initial risks include: theft of the repository, virus protection, configuration management protection, rebranding risks, repurposing risks and malicious intent or ill will towards the end user. Rob is trying to prevent any of this from occurring in biblepay until the market cap exceeds what is comfortable for continuity. However after 20MIL, it is a common view that the DAO has grown large enough that it has outgrown Robs initial safety layer, and must be allowed to be free. At this point, the keys will be shared as outlined above to ensure continuity. | The reason we will transition through phases is: There are several risks involved when transitioning to a cross-trained environment that could be used maliciously while the coin is small. It is clear that Rob must have the best intentions since he has a lot of development hours and integrity at stake, so the assumption is while marketcap is between 0-20 MIL, the safest path to preserve the coins life is to trust Rob with sporks and deploys until the size of the marketcap exceeds what is considered a small operation and above the scope of a single dev. From Rob's perspective, the initial risks include: theft of the repository, virus protection, configuration management protection, rebranding risks, repurposing risks and malicious intent or ill will towards the end user. Rob is trying to prevent any of this from occurring in biblepay until the market cap exceeds what is comfortable for continuity. However after 20MIL, it is a common view that the DAO has grown large enough that it has outgrown Robs initial safety layer, and must be allowed to be free. At this point, the keys will be shared as outlined above to ensure continuity. | ||
+ | |||
+ | |||
+ | |||
+ | == Controls == | ||
+ | |||
+ | |||
+ | == Currency Exchange == | ||
+ | |||
+ | Vendor Payments exchanged for fiat and paid to vendors: Biblepay currency originating from a superblock payment to a vendor will pass through one of our boardmembers receiving addresses and will be liquidated within 30 days on one of our official exchanges using the BiblePay Foundation Tax ID number. This means our boardmember will not be subject to tax risks. The boardmember will keep a copy of the receipt proving the BBP volume and bitcoin volume. The fiat will be transferred to a BiblePay Organization registered bank, which is registered to the corporation with the same tax-id number. Within 30 days, a biblepay foundation check will be written to the vendor. If the process is violated by a boardmember, a board meeting will be called with the remaining members with a petition to remove that boardmember permanently. | ||
+ | |||
+ | == Spork and Release Signing == | ||
+ | |||
+ | When a developer has access to the spork/release keys, the lead developer will cross-train the co developers on the configuration management and release process. If a co-developer attempts to create an unauthorized release, or is reported for any malicious activity, the remaining developers will notify the biblepay Foundation and a board meeting will be called recommending the developer be stripped of github permissions. If this happens, the foundation will request that new keypairs be made, and the remaining developers will receive the new keys and a new developer will be chosen. | ||
+ | |||
+ | == Vendor Relationships == | ||
+ | |||
+ | When we are approached by a new vendor, one of our boardmembers will be tasked to perform due diligence on the vendor. The boardmember will verify the authenticity of the vendors service and financial information and integrity. If a complaint arises accusing the boardmember of fraud, embezzlement, nepotism, or corruption, a board meeting will be called to investigate the specific case. The other boardmembers will be charged in summarizing if this was a genuine case of corruption. If the boardmember is found guilty by the board, a recommendation to remove the boardmember will be called. | ||
+ | |||
+ | == Taxes == | ||
+ | |||
+ | All revenue and expense transactions will be recorded in a Microsoft SQL Server using the accountability.biblepay.org web pages created for the Foundation. Liquidated BBP for a vendor will be recorded as a transaction, PDF receipts will be stored in the SAN, and checks written to vendors in fiat will be recorded as transactions. All transactions will be recorded with the Biblepay Foundation Tax-ID number. | ||
+ | |||
+ | At the end of the fiscal year, biblepay will pay an accountant to create and file a professional tax return which will be available for public viewing on our accountability web site. | ||
+ | |||
+ | |||
+ | == Data Backups == | ||
+ | |||
+ | Since the Biblepay Foundation will have the need for copies of documents, tax returns, and transactions for years after they are recorded to protect for cases of audit, the data will be backed up and stored offsite in case of catastrophe. | ||
+ | |||
+ | == Disaster Recovery == | ||
+ | |||
+ | In the case of a disaster, a developer will create a new accountability web site and restore the SQL server backup for the Foundation. | ||
+ | |||
+ | == Legal Decisions == | ||
+ | |||
+ | The BiblePay Foundation will be contacted by attorneys to certify the currency is a utility and not a security, to ensure we are not misrepresenting our currency as an investment, to ensure we are not promising cryptocurrency gains as those are uncertain, to ensure all of our payments we state have been made to the vendors stated, to ensure all biblepay liquidated has been liquidated to fiat as stated, to audit our tax returns, and for consultation for new features among other things. Therefore our boardmembers will be expected to understand the entire scope of current cryptocurrency issues and have the ability to assess advanced problems and solutions to the best of their ability. | ||
+ | |||
+ | The bylaws will contain clauses that show that each boardmember must legally make decisions in the best interests of BiblePay DAO, and not in their own interests. It is therefore the boardmembers who will make legal decisions and represent the BiblePay DAO publically. The board will refer to the governance committee for any decisions that affect the entire community that could be discussed as a multiple path problem. | ||
+ | |||
+ | |||
+ | [[Category:Governance]] |
Latest revision as of 07:21, 23 February 2019
This page explains the organizational structure of the BiblePay Decentralized Autonomous Organization.
BiblePay is a decentralized organization composed of multiple layers.
The community itself owns Biblepay as a whole, but the governance committee is the voice for the community that makes steering decisions. The Governance Committee is composed of our 200+ sanctuaries, who may vote on issues. Although it is a right for a sanctuary to vote on an issue, the code that runs in the sanctuary is an asset owned by the Biblepay DAO. Therefore our sanctuaries do not have the right to run modified versions of biblepay, and must run the most recent version. These running sanctuaries are considered Biblepay Assets, and must provide service to the best of their ability, otherwise the Sanctuary will not be paid. One example of code that Biblepay as a DAO has the right to deploy to Sanctuaries is our Cancer Mining Magnitude Assessment process. The Sanctuary is obligated to download, assimilate, compile and vote on the data, and must execute the code because our DAO considers the Sanctuary an asset of the DAO. In contrast, a normal user will not be obligated to run Sanctuary Service Modules.
Contents
The BiblePay Foundation
The BiblePay Foundation is a non-profit Texas Corporation that manages vendor relationships, vendor payments, orphan fundraisers, cryptocurrency exchanges, taxes and legal decisions.
The Foundation will initially be created with 6 board members invited by the Founder of BiblePay. It will then become autonomous, since its bylaws will have processes that ensure continuity, such as the ability for the foundation to vote in replacement boardmembers and remove non-performing boardmembers.
The board will consist of: Sanctuaries
The BiblePay source code is opensource and public and owned by the community members equally (IE every holder of BBP currency).
The intellectual property concepts that are in development but not yet in production are owned by the Biblepay Foundation, until deployed.
The github repository will go through several phases of ownership during the lifetime of Biblepay. Initially, while Biblepay is small (defined below) and co-developers are new (defined below), Rob Andrews (founder) will be the sole person to hold github Release permissions (for security reasons explained below). This is considered phase 1.
During Phase 2, Three co-developers will be given Spork Signing keys and Release Keys. This means it will take two out of three developers to sign a spork or create a release. Also, the Treasurer or the VP of Operations will be given access to an emergency key for continuity in case a supermajority of the lead developers dissapear.
During Phase 3, Five co-developers will be given Spork Signing keys and Release Keys. A supermajority signed spork or release will be required.
Definition of Phases:
Phase | Market Cap | Number of Cross-Trained Developers |
---|---|---|
Phase 1 | 0-20,000,000 | 2 or less developers are Cross-Trained |
Phase 2 | 20,000,001-50,000,000 | 3 or more developers are cross-trained |
Phase 3 | 50,000,000+ | 5 or more developers are cross-trained |
This chart explains that Rob will be the single github release manager in Phase 1 until two things occur: Our market cap exceeds 20Mil and Rob cross trains a minimum of two trustworthy co-devs vital release information and explains how to sign the spork keys and perform releases. At this point, continuity will be achieved in that if all devs dissapear, the foundation will have a backup key. Also, if only one dev dissapears the other two devs will step in and provide releases.
When our market cap exceeds 50Mil, we will beef up cross-training and spork signing to be more resilient as Phase 3 shows.
The reason we will transition through phases is: There are several risks involved when transitioning to a cross-trained environment that could be used maliciously while the coin is small. It is clear that Rob must have the best intentions since he has a lot of development hours and integrity at stake, so the assumption is while marketcap is between 0-20 MIL, the safest path to preserve the coins life is to trust Rob with sporks and deploys until the size of the marketcap exceeds what is considered a small operation and above the scope of a single dev. From Rob's perspective, the initial risks include: theft of the repository, virus protection, configuration management protection, rebranding risks, repurposing risks and malicious intent or ill will towards the end user. Rob is trying to prevent any of this from occurring in biblepay until the market cap exceeds what is comfortable for continuity. However after 20MIL, it is a common view that the DAO has grown large enough that it has outgrown Robs initial safety layer, and must be allowed to be free. At this point, the keys will be shared as outlined above to ensure continuity.
Controls
Currency Exchange
Vendor Payments exchanged for fiat and paid to vendors: Biblepay currency originating from a superblock payment to a vendor will pass through one of our boardmembers receiving addresses and will be liquidated within 30 days on one of our official exchanges using the BiblePay Foundation Tax ID number. This means our boardmember will not be subject to tax risks. The boardmember will keep a copy of the receipt proving the BBP volume and bitcoin volume. The fiat will be transferred to a BiblePay Organization registered bank, which is registered to the corporation with the same tax-id number. Within 30 days, a biblepay foundation check will be written to the vendor. If the process is violated by a boardmember, a board meeting will be called with the remaining members with a petition to remove that boardmember permanently.
Spork and Release Signing
When a developer has access to the spork/release keys, the lead developer will cross-train the co developers on the configuration management and release process. If a co-developer attempts to create an unauthorized release, or is reported for any malicious activity, the remaining developers will notify the biblepay Foundation and a board meeting will be called recommending the developer be stripped of github permissions. If this happens, the foundation will request that new keypairs be made, and the remaining developers will receive the new keys and a new developer will be chosen.
Vendor Relationships
When we are approached by a new vendor, one of our boardmembers will be tasked to perform due diligence on the vendor. The boardmember will verify the authenticity of the vendors service and financial information and integrity. If a complaint arises accusing the boardmember of fraud, embezzlement, nepotism, or corruption, a board meeting will be called to investigate the specific case. The other boardmembers will be charged in summarizing if this was a genuine case of corruption. If the boardmember is found guilty by the board, a recommendation to remove the boardmember will be called.
Taxes
All revenue and expense transactions will be recorded in a Microsoft SQL Server using the accountability.biblepay.org web pages created for the Foundation. Liquidated BBP for a vendor will be recorded as a transaction, PDF receipts will be stored in the SAN, and checks written to vendors in fiat will be recorded as transactions. All transactions will be recorded with the Biblepay Foundation Tax-ID number.
At the end of the fiscal year, biblepay will pay an accountant to create and file a professional tax return which will be available for public viewing on our accountability web site.
Data Backups
Since the Biblepay Foundation will have the need for copies of documents, tax returns, and transactions for years after they are recorded to protect for cases of audit, the data will be backed up and stored offsite in case of catastrophe.
Disaster Recovery
In the case of a disaster, a developer will create a new accountability web site and restore the SQL server backup for the Foundation.
Legal Decisions
The BiblePay Foundation will be contacted by attorneys to certify the currency is a utility and not a security, to ensure we are not misrepresenting our currency as an investment, to ensure we are not promising cryptocurrency gains as those are uncertain, to ensure all of our payments we state have been made to the vendors stated, to ensure all biblepay liquidated has been liquidated to fiat as stated, to audit our tax returns, and for consultation for new features among other things. Therefore our boardmembers will be expected to understand the entire scope of current cryptocurrency issues and have the ability to assess advanced problems and solutions to the best of their ability.
The bylaws will contain clauses that show that each boardmember must legally make decisions in the best interests of BiblePay DAO, and not in their own interests. It is therefore the boardmembers who will make legal decisions and represent the BiblePay DAO publically. The board will refer to the governance committee for any decisions that affect the entire community that could be discussed as a multiple path problem.