...

1. Introduction

The Hyperledger Besu Project aims to achieve an Ethereum client designed to be enterprise-friendly for both public and private permissioned network use cases. The Java-based Ethereum client (Besu) is becoming one of the most used Ethereum clients by enterprises from multiple industries that are actively exploring the Web3 and digital assets space. The increasing adoption of EVM-compatible technology within financial services and the accelerating trend of tokenization of assets are some of the key drivers for enabling a collaboration space for enterprise users of Besu and code contributors of Besu to come together to support and help shape the evolution of Besu.

The interests of these two groups are a perfect match for collaborating on the adoption and success of Besu.

• Enterprise users of Besu in need of tech capabilities that meet enterprise requirements.
• Code contributors of Besu aiming to maximize the value and adoption of Besu.

Naming Convention

The name of this workgroup shall be Hyperledger Besu Financial Services Workgroup (Besu FS WG). Additional appropriate name references shall be:

• Hyperledger Besu Financial Services Workgroup (external, formal)
• Besu Financial Services WG (external, informal)
• Besu FS WG (internal, informal)

2. Scope and Deliverables

The mission is driving working sessions for enterprise users and code contributors to come together for:

• Identifying challenges that enterprise users face when operationalizing and implementing Besu in their business solutions in alignment with standards, requirements, and common practices from the industry.
• Defining new features and enhancements that strengthen the alignment between Besu and the requirements from enterprises adopting Blockchain and DLT (Distributed Ledger Technology) technologies.

The main deliverables expected to come out of this WG include, but are not limited to:

• A prioritized and detailed list of enhancements of existing features of Besu
• A prioritized and detailed list of new features of Besu
• A prioritized and detailed list of technical limitations of Besu
• A list of recommended practices of Besu for enterprise use cases

These deliverables will shape an inventory of use-case agnostic enterprise features and non-functional requirements that code contributors of Besu can use to define a product roadmap for Besu.

The workgroup may form subgroups to support, emphasize, or promote any of those items listed above.

Work Products

The initial work products include a set of working documents describing existing feature enhancements, new enterprise features, and recommended practices of Besu for enterprise use. The WG may host in-person meetings and presentations to accelerate the WG's mission.

3. Working in an Open Community

Hyperledger Workgroups are open and global communities where anyone from anywhere can and should be able to participate, contribute, and access information. The WG adheres to the Hyperledger Code of Conduct and Anti-Trust Policy.

Anti-Trust Policy

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all its activities in accordance with applicable anti-trust and competition laws. It is therefore important that attendees adhere to meeting agendas, be aware of, and not participate in, any activities prohibited under applicable US state, federal or foreign anti-trust and competition laws. Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Transparency

Meeting details, meeting recordings and documentation shall be made publicly available. The following items shall be generated and made available to the community:

• Wiki Page
• Mailing List
• Meeting Recordings

Collaborations

The WG may collaborate with the Technical Steering Committee (TSC), Hyperledger Leadership, and respective project maintainers. It is open to collaborate with parties outside the Hyperledger Foundation and the Linux Foundation if the collaboration supports the scope and deliverables of the WG. The collaboration will be subject to the internal decision-making process.

4. Membership

The membership shall be free and open to members of the community who have an interest in the scope and goals of the WG. The membership is established by subscription to the mailing list. Active contribution is preferred. All participation in the activities is voluntary.

The expectation is for most of the participating members to come from the financial services industry. The target participant is an employee with a technical background and experience DLT & Blockchain technology of an enterprise from financial services that has 6 months or more of experience running and managing (i) permissioned networks and/or (ii) nodes interfacing with public networks using Besu as the Ethereum client for the network infrastructure.

For now, the industry-level focus is considered a plus for avoiding an overload of activity from many actors of many industries that leads to “analysis-paralysis.” It is highly likely that the requirements and needs from the financial services industry overlap or exceed those from other industries, so, even if narrowing focus on financial services, the efforts and results will be beneficial to a broader community. In the future, the WG can become more generic by removing the industry-level limitation (e.g., rename to “Besu for Enterprises WG”).

5. Governance

The governance shall be managed through its membership in accordance with the guidelines and overriding authority of Hyperledger Leadership. Day-to-day management shall be conducted by elected officer(s). Any actions taken on this basis and directly affecting membership shall be reported to membership promptly through established channels of communications.

Leadership

The leadership is comprised of the following office role(s):

• Chair: Carlos Vivas

If more than one office role is available, an officer shall not hold more than one office role at any given time.

Eligibility

For consideration of an officer, an officer-in-consideration must be:

• An active contributor for no less than 6 months within the Besu FS WG

Election

All future Chairs will be selected through an election process where group members vote.

• An officer shall be elected by membership into position through a simple majority vote, and with Hyperledger Leadership approval
• When there are two or more candidates, officer election shall be determined through a plurality vote, and with Hyperledger Leadership approval
• Candidate Nomination can happen by candidates emailing the Hyperledger Point-of-Contact with their statement of candidacy
  • Once all are received, Hyperledger Point-of-Contact gathers all submissions and posts the names and candidate statements in the mailing list all together for the community to review.

Election Process

All members shall have one vote. All membership votes shall be based on a simple majority. Voting will take place via a tool of choice. In a tied vote, a ranking officer shall be granted a tie-breaking vote.

• In the case where an existing Chair is not able to complete their term, an early election can be called
• If a Chair is no longer performing the responsibilities assigned to the office, a new Chair must be elected
• At any time over the course of an officer’s tenure, members may identify whether the Chair is fulfilling the responsibilities
• A new election process can be started by simple majority decision of the members of the WG.

Workgroup Chair

The workgroup chair is responsible for the following items:

• Facilitating the group and helping ensure the mission and goals are observed and met
• Scheduling and facilitating regular General Meetings open to all members
• Developing and distributing meeting agendas before the scheduled meeting
• Ensuring that all group members can participate in discussions and decisions
• Ensuring that all group members can participate and are informed of deliverables and decisions
• Ensure recordings are added to the SIG Wiki Page
• Manage the SIG Wiki Page
• Generate quarterly updates to present to Hyperledger Point-of-Contact
• Serving as a proxy and ambassador for WG membership (as appropriate)
• Enforcing adherence to the Hyperledger Code of Conduct.
• Communicating the Anti-Trust Policy.

The chair serves for one year from the start of the group (for the first chair) or the last election date. An officer may be elected to office for unlimited consecutive terms.

There are a few cases in which an existing chair can be removed:

• If the Chair stops participating in the group without announcing that they are stepping down
• If the majority of members of the WG agree on early election decision by simple majority

If a chair is no longer performing the responsibilities and early election decisions is achieved via simple majority:

• Notify the chair in question, in writing, of all abdication(s) of responsibilities.
• If the chair in question does not acknowledge, in writing and within five (5) days, the initial notice, WG member(s) initiating the notification shall contact, in writing, Hyperledger Point-of-Contact.
• Hyperledger Point-of-Contact shall immediately (as practicable) attempt to contact, in writing, the chair in question.
• If the chair in question does not acknowledge, in writing and within five (5) days, at the request of Hyperledger Point-of-Contact, HBFS-SIG member(s) initiating the notification shall begin a new election process.

Disbandment

Should the scope reach completion, or conversely, the traffic on the various discussion forums, and/or the teleconference activity drop to exceptionally low levels, then the ranking officer may ask Hyperledger Point-of-Contact to disband the workgroup.

6. Subgroups

Subgroups serve to direct membership efforts toward key areas of mutual or themed interest within the larger general membership.

Like the parent WG, subgroups are obligated to serve as a mechanism for productive and demonstrable work products under the guidance of a lead (Subgroup Officer), who is responsible for transparently communicating subgroup status back to the WG leadership.

Creation of Subgroup

Any member of the WG representing enterprise users of Besu with no less than 90 months of active participation in the workgroup may propose the creation a subgroup with the intent to serve a specific need or set of needs not already served through the parent WG or any existing subgroup. Upon approval by simple majority, a subgroup officer is to be appointed, and work with WG leadership to develop a subgroup charter.

Subgroup Charter

An subgroup charter can follow the same template as the WG charter.

7. Amendments

This charter may be altered by a consensus resolution passed at a meeting of WG members. All changes made to this charter shall receive final approval from Hyperledger Point-of-ContactTesting...