FAQ

Disclaimer

The following answers are to provide information on the position of the Bedrock Consortium with respect to various matters. The following should be reviewed by legal counsel of members and organizations interested in joining the Bedrock Consortium, and is not intended to constitute legal advice.

The Bedrock Governance Framework is comprised of two components: 1, Informational Section Provides introductory content that should be the entry-point for all readers. 2. Constitutional Section: Addresses the technical and operational policies of the Bedrock Business Utility (BBU) as well as the legal architecture. All readers should review this section in order of presentment but avoid diving into the Legal Agreements until the last step. Review of the legal agreements should begin with the Participation Agreement and then followed by the Utility Agreements in the order they are listed here.

What is the current Governance Framework that my organization is signing up for if governance will be approved by a Governing Board where no Governing Board has been created yet?

Currently, the Bedrock Governance Framework is maintained in Draft status. Following the formal launch of the Bedrock Consortium the Governing Board will ratify and approve a 1.0 version of the Governance Framework. Upon the effective ratification date, all existing members will have 90 days from the date to resign the agreements. See Section 4g of The Bedrock Consortium Charter (Exhibit B of the Participation Agreement).

Will my organization have the opportunity to review and approve any policy changes or changes to the contracts my organization has executed?

Yes. Please refer to the “Utility Agreements” section of the Participation Agreement, which states:

In addition, the Governing Board of the Bedrock Consortium will have the authority to make changes to the Governance Framework under Section 4.g. of the Bedrock Consortium’s charter.

Which Glossary or Glossaries govern the Bedrock Governance Framework?

The Governance Framework Working Group (GFWG) of the Bedrock Consortium is responsible for the maintenance of the Bedrock Governance Framework which contains the BBU Glossary. The GFWG will collaborate with the ToIP Concepts and Terminology Working Group on the publication of industry terms. The GFWG will leverage the convergence of these terms from existing sources into a single BBU Glossary. Until this convergence is complete the BBU Governance Framework will continue to refer to multiple external sources for terminology. Please see the current Glossary Section of the Governance Framework.

What happens if there are changes to a contract that my organization will be obligated to sign but my organization does not agree with the change or cannot meet the obligations included in any such change?

As described in the “Utility Agreements” section of the Participation Agreement, in the case of any future revisions to any Utility Agreement, and/or Utility Policy or any new Utility Agreement or Utility Policy (collectively, “Revisions”), the Consortium will publish such Revisions at least 90 days prior to their effectiveness. Unless the member, prior to effectiveness of any Revision, resigns its membership prior to the effectiveness of any Revision, the member will be bound by such Revisions at their effectiveness.

What is the order of precedence if a term in a policy or contract conflicts with a term in another applicable policy or contract?

The Governance Framework is referenced by the various Utility Agreements and are intended to operate together. If a direct conflict of language is identified between the Governance Framework and any Utility Agreement by a member, this conflict MUST be raised as an issue to the Governance Framework Working Group (GFWG) which is then responsible for resolution proposal to the Governing Board. Any and all ratified changes to the contracts by the Governing Board will require a 90 day member review and resign period as per Section 4g of The Bedrock Consortium Charter (Exhibit B of the Participation Agreement).

Is a Transaction Endorser required to endorse the transactions of any Author?

Yes. See Legal Archiecture.

If the Authors are the entities writing the transaction and that could be at risk of putting impermissible personal data on the Utility, how is the compliance of Authors confirmed and enforced?

Transaction Authors are required to sign the Transaction Author Agreement. Proof of this signature will be on the ledger. It is the responsibility of the Transaction Endorser to validate that the Author's proof of signature is resident on the ledger. The Technical Steering Committee (TSC) of the Bedrock Technical Project owns the responsibility of ensuring that all Transaction Endorsers have access to TSC approved code for carrying out the responsibilities of an endorser. If an Author signs the agreement and then proceeds to place impermissible personal data on the ledger, the Author is then in breach of its obligations under the Transaction Author Agreement and may be subject to various requirements including the provision of indemnification under the Transaction Author Agreement.

Why does a steward need to sign a Transaction Endorser Agreement and Transaction Endorser Data Processing Agreement?

The Data Processing Agreement may change over time or more frequently then the Transaction Endorser Agreement. Therefore, it is more effective to separate the documents to avoid unnessary downstream signatures.

How will Stewards process node data?

Each Steward will run the same version of open source Hyerledger Indy code. This code has a limited set of transactions that a node can perform. These transactions are described in the Ledger Data Policies.

What is the exact scope of service of a Steward?

A Steward pertains to a governing or operational member that is required to stand-up and maintain the hosting of a compute node running Hyperledger Indy. The business policies and the operational policy requirements of a Steward are outlined in the Operating Section of the BBU Governance Framework, which is pending ratification by the Governing Board and is thereby considered a work-in-progress. The legal architecture specifies that a Steward MUST operate a compute node and MAY operate an endorser.

How will my organization be selected to host a node (e.g. hosting production, testing or other type of node?)

This process may be handled algorithmically or via a manual process. Members MAY be allowed to submit environment preferences. Ultimately, the node selection process is the responsibility of the Technical Steering Committee (TSC) of the Bedrock Technical Project.

What is “impermissible Personal Data”?

Under the Steward Data Protection Agreement and the Transaction Endorser Data Projection Agreement, the following definitions are used:

  • “ Impermissible Personal Data ” means the Personal Data that a Transaction Author writes to the Utility and that a Steward Processes that is not Permissible Personal Data in accordance with the Transaction Author Agreement.
  • “ Permissible Personal Data ” means the Personal Data expressly listed in Schedule 1 that a Transaction Author writes to the Utility in accordance with the Transaction Author Agreement and that a Steward Processes through the Steward Node.

Under the Transaction Author Agreement, “Impermissible Personal Data” means the Personal Data that Transaction Author writes to the Utility that is not Permissible Personal Data. Furthermore, under that agreement “Permissible Personal Data” means Personal Data that Transaction Author writes to the Utility that is permitted under this Agreement and the Framework. Under the Transaction Author Agreement personal data is only allowed to be written to the Utility in conformance with the requirements of Section 3.

What Personal Data is permitted to be included on the utility?

Under the GDPR definition of Personal Data, specifically any information that is related to an identified or identifiable natural person is prohibited to be placed on the BBU ledger. The BBU limits write access to the ledger using a permissioned access policy and the type of data that is allowed to be written to the ledger is limited to the metadata outlined by Hyperledger Indy and our ledger data policies.