MobileCoin Foundation Technical Committee Charter
A. Guiding Principles
1. Transparency and Openness
The MobileCoin Foundation (“MCF”) Technical Committee will operate transparently, collaboratively, ethically, and in alignment with the interests of the MobileCoin Community (see A.4). Project proposals, timelines, and status must not merely be open, but also easily visible to and discoverable by outsiders.
This MCF Technical Committee Charter reflects the scope and expectations of the Technical Committee (“TC”), as delegated by the MobileCoin Foundation Governing Board, with the maintainers, the consumers, and the ecosystem of the project. The charter has a simple amendment process – a TC member proposes changes to be discussed and voted on by the full TC (see E.2).
3. Key Technical Domains
Key Technical Domains covered by the TC include blockchain, cryptocurrency, cloud provisioning & deployment, distributed systems, cryptography, privacy & security, secure enclaves, decentralized consensus.
4. MobileCoin Community
The MobileCoin Community consists of MobileCoin core developers, active contributors, technology operators, SDK developers, end users, active community participants, and MobileCoin Foundation member organizations and their communities.
1. Drive Consensus
The Technical Committee is expected to facilitate consensus for the following:
(i) Defining and maintaining the technical vision for the MobileCoin Foundation (MCF),
(ii) Approving new projects within the scope for MCF set by the Governing Board,
(iii) Aligning projects, removing or archiving projects,
(iv) Defining technical practices to be implemented across MCF projects, including coding standards, quality standards, and development process,
(v) Approving changes to technical specifications of MCF projects,
(vi) Mediating technical discussions which have cross-project impact,
(vii) Defining practices for facilitating key technical responsibilities of the MCF, and
(viii) Facilitating implementation and execution of In-Scope Responsibilities (see D.1).
In order to facilitate timely decision making, consensus is sought following the principles and practices of Consensus Seeking Decision Making.
(i) The TC shall be composed of five (5) members.
(ii) The TC members are expected to cover key technical domains (see A.3). It is the intention of the TC to cover the majority of these topics through the diversity of the TC members.
(iii) The MCF Governing Board shall elect five (5) members and shall select the TC Chair.
2. Criteria for Nomination
Nominees for the Technical Committee shall:
(i) commit that they have the available bandwidth to make the time to invest in the TC,
(ii) demonstrate an advanced level of professional experience in the key technical domains covered by the TC (see A.3),
(iii) demonstrate seniority sufficient to access additional staff or community members to assist in their TC preparations, and
(iv) operate neutrally in discussions and put the goals and success of MCF in balance with the objectives of any particular project, community member, or member organization in the MCF.
3. Process for Nomination and Election
(i) Nominations: Nominees shall be presented by members of the MCF Governing Board or the members of the TC. Each nominee must agree to participate prior to being added to the nomination list.
- A nomination requires a maximum one (1) page nomination pitch which should include the nominee’s name, contact information, and supporting statement identifying the nominee’s experience in MCF key technical domains (A.3).
- The Governing Board shall determine the process and timeline for the nominations, qualification, and election of TC members.
- A minimum of 14 calendar days shall be reserved for an Evaluation Period whereby TC nominees may be contacted by members of the Governing Board and TC.
(ii) Qualification: After the Evaluation Period, the Governing Board and the TC members shall vote on each nominee individually to validate that the nominee meets the qualification criteria. A valid vote shall require at least 50% participation of the Governing Board and TC members. Nominees passing with over 50% shall be Qualified Nominees.
(iii) Elections: If the number of Qualified Nominees is equal to or less than the number of TC seats available to be elected, the Qualified Nominees shall be approved after the nomination period has closed. If there are more Qualified Nominees than open TC seats available for election, the MCF Governing Board shall elect the TC members via a Condorcet vote.
(iv) Existing TC members may nominate and qualify, but not vote when their seat is up for election.
4. Resignation, Termination, and Leaves of Absence
(i) A TC member may resign at any time by informing the MCF Governing Board.
(ii) A TC member may be removed at any time by a majority vote of a quorum (two-thirds) of the MCF Governing Board and TC members.
(iii) A TC member may take a leave of absence as approved by majority vote of a quorum (two-thirds) of the remaining TC members, who vote to approve that the TC member’s responsibilities can be managed effectively by the remaining TC members during the leave of absence.
(i) TC members shall serve staggered one (1) year terms.
(ii) TC members may be removed by unanimous consent of the other two TC members.
(iii) Any TC member that misses three (3) consecutive meetings shall be automatically suspended from eligibility to vote until having attended two (2) meetings consecutively. For avoidance of doubt, the suspended TC member shall be eligible to vote in the second consecutive meeting.
1. In Scope
2. Out of Scope
a. Monitoring Rotations
The TC does not monitor network health directly. It is the intent that the TC can set guidelines to facilitate monitoring.
E. Operating Model
1. General Operations
(i) The TC Chair shall set agendas and call meetings of the TC.
(ii) The TC is expected to meet regularly (via telepresence or in person) to discuss key topical issues.
(iii) Issues may be raised for TC Review by:
- any TC Member
- any Governing Board Member
- any member of the MobileCoin Community (see A.4)
(iv) Any decision expected at a TC meeting shall be posted with the agenda.
(v) Agendas shall be posted with reasonable lead time, no less than 24 hours.
2. Voting on Project Issues
(i) TC Issues may be resolved by short discussion and simple majority vote. TC discussions may be over email, or at a TC Meeting.
(ii) A quorum of members (two-thirds) must be present to vote. Members can be present but choose to abstain from a particular vote.
(ii) In the case that less than a quorum of members are available and capable of conducting a vote, the TC may escalate decisions to the MCF Governing Board. In this case, a quorum (two-thirds) of the MCF Governing Board must be present, and a simple majority of votes, including the present TC members, is required for a vote to pass.
(iii) Issues approved by majority vote of the TC take effect immediately. The TC must notify the MCF Governing Board after any such vote has occurred, and the Board may, by majority vote, revoke any TC-issued changes to procedures at their convenience. If the Board wishes to disapprove a release, the TC will follow up immediately by revoking the release.
(iv) In the case where a TC member contributed code for a release, an additional review is required of the code contribution by a MobileCoin Community member, and the TC contributor cannot cast the deciding vote on that release’s approval.
It may be the case that certain discussions and votes will concern embargoed information which cannot be made public prior to the vote, for example in the case of issues concerning certain security vulnerabilities.
a. Reporting Vulnerabilities
Members of the MobileCoin Community may bring vulnerabilities to the TC’s attention via the private list firstname.lastname@example.org.
b. Embargo Policy
(i) The information members receive on email@example.com must not be made public, shared, nor even hinted at anywhere beyond the need-to-know within the MobileCoin Community except with the list’s explicit approval. This holds true until the public disclosure date/time that was agreed upon by the list. Members of the list and others may not use the information for anything other than implementing appropriate mitigations.
(ii) Before any information from the list is shared with respective members of the MobileCoin Community required to fix said issue, they must agree to the same terms and only find out information on a need-to-know basis.
(iii) In the unfortunate event that a TC member shares the information beyond what is allowed by this policy, they must urgently inform the firstname.lastname@example.org mailing list of exactly what information leaked and to whom. A retrospective will take place after the leak to assess how to not make the same mistake in the future. The intent is that the retrospective will be made public after the leak is resolved.
(iv) Leaking information and breaking the policy outlined here is sufficient grounds for removal from the TC.
After all security vulnerabilities, a retrospective will be published.
Appendix A: Example Responsibilities
Example responsibilities that may be delegated from the MobileCoin Foundation Governing Board to be overseen by the TC may include:
a. Code, Binaries, Docs, and Services
- Perform delegated MCF Governing Board responsibilities, such as setting development goals for releases, approving releases, enabling external audits, and setting release dates
- Facilitate and coordinate Enclave upgrades with node operators
- Publish expected live Enclave Measurement values
- Register and publish MrSigner values with Intel
- Coordinate with the Key Management Group for key creation and rotation
- Publish runbooks for node operators
- Publish integration guides for Exchanges, Payment Platforms, and Mobile & Desktop Wallets
- Manage technical project resources, such as source code and image repositories (including membership and hosting), and publishing mobile apps.
- Publish the list of canonical images in the public MCF image repository
b. Network Health
- Provide guidelines for node operators for monitoring own node as well as network health, including
- monitoring quorum intersection in order to prevent forks,
- monitoring network load and block clearing times in order to prevent halting,
- monitoring node catchup state, and
- monitoring Intel Security Advisories and attestation failures.
- Set escalation procedure for node operators to call attention to network health and network failures.
- Monitor Intel Security Advisories and communicate upcoming mitigations to all node operators in a timely manner.
c. New Technologies
- Work with the MobileCoin Community (see A.4) to assess technologies to include in the MobileCoin ecosystem
- Define acceptance criteria for new technologies to include in the MobileCoin ecosystem
- Define the process to ratify contributed technology as a standard API
- Identify immediate gaps that require further investigation
d. Security Response
- Receive, review, and escalate security incidents and vulnerability reports
- Classify vulnerabilities for common public reporting processes
- Handle embargoed information for key stakeholders
Frequently Asked Questions