The Hyperledger Besu community would like to request graduation for the project to be moved from incubation to active status. Below outlines an assessment of the requirements of graduating from incubation status to active status and how Hyperledger Besu meets each requirement. From a high-level, we believe we believe the project is ready for active status because:

  1. Diversity of Community and Contributors: Besu has built an extensive and active community around its project. Some data points around the community include:
    1. Since Besu was approved and joined Hyperledger, there have been 29 contributors from the PegaSys team and 20 contributors from outside of the PegaSys team. Since Besu was initially launched in November 2018 (as Pantheon), there have been 42 external contributors to PegaSys while there have been 37 PegaSys contributors.
    2. There have been over 120 community-raised issues on the project since November 2018, when the project was launched. This demonstrates the engagement and excitement around the project.
    3. The project has a diverse maintainer group with 4 organizations being represented. They include, PegaSys (ConsenSys), Chainsafe, Web3Labs, and Machine Consultancy. These teams are major contributors using Besu and providing feedback on the codebase. Additionally, 50+ companies (that we know of) are building blockchain applications have tested out Besu, provided feedback, and demonstrated its usability for their application. Additionally, there are four organizations as maintainers of the project currently. 
  2. Besu has demonstrated success using Hyperledger tools and processes:
    1. Public / Community Driven Releases: Each release planning is done during bi-weekly contributor call. Additionally, all releases are announced in our contributors’ RocketChat channel.
    2. Bi-Weekly Contributor Calls: We have had bi-weekly contributor calls to discuss different bodies of work. We are focused on teh 
    3. Public Issue Board: We have all issues published on Jira board (Hyperledger’s), but we have recently switched to GItHub issues (under Hyperledger’s account)
    4. RocketChat: While we have struggled with adoption of Ethereum community members on RocketChat, we have been operating successfully on RocketChat with public q&a, feedback, release annoucements, and general community engagement.
  3. Besu is Meant for Production: Several enterprises are building permissioned networks to use Besu in production. It is also a fully compatible client that runs in production in mainnet Ethereum with its 1.0 Release occurring in April 2020.
  4. The Besu Team Is Heavily Involved in the Hyperledger Community: Since being accepted as a project in August 2019, the Besu team has been participating in the following activities:
    1. Announcing Hyperledger Besu 1.4 (Feb.27)
    2. How Hyperledger Besu will Help Solve the Pharmaceutical Waste Problem in the U.S. (Jan. 28)
    1. Added support for Besu in Caliper (Oct. 20)
    2. Participated in the CI/CD working group conversations and sharing our project’s research and best practices (Sep .- Oct.)
    3. Attended the Maintainer summit in Minneapolis (Oct. 8-9)
    4. Presented a talk at the Hyperledger booth at Sibos (Sep.23-25) 
    5. Submitted several talks for consideration for the Hyperledger Global Forum and participated in planning of agenda (Sep. - Oct.)
    6. Attended the Hyperledger meet-up at Devcon in Japan (Oct. 9)
    7. Presented privacy solution at Architecture WG - Privacy Confidentiality track (Sep. 20)
    8. Continuing to work on Besu’s support of Caliper (ongoing Oct. - March)
    9. Presented on supply chain SIG (Jan. 23)
    10. Attended the Hyperledger Global Forum and presented several talks (March 9-12)
    11. Attended Hyperledger meet-up in Phoenix (March 9)
    12. Presented at Hyperledger Korea meet-up (Jan. 16)
    13. Provided proposal on DCO process for Hyperledger 
    14. Approved to be Co-mentor with Mark Wagner on Hyperledger mentorship project to implement OpenShift on Besu (Mar. 19th)
    15. Published a couple of blogs on Hyperledger’s site:

The assessment against the requirements can be found here:



Besu Community Response


All code has been made available under the Apache License and is free of incompatible dependencies


Project name has been checked for trademark issues


DCO check

Besu Repo:

(lftools) user@dev > ~/Projects/besu > (master) $ git id
(lftools) user@dev > ~/Projects/besu > (master) $ lftools dco check
Checking commits in branch origin/master for commits missing DCO...
(lftools) ✘ user@dev > ~/Projects/besu > (master) $

Besu Docs Repo:
(lftools) user@dev > ~/Projects/besu-docs > (master) $ git id
(lftools) user@dev > ~/Projects/besu-docs > (master) $ lftools dco check
Checking commits in branch origin/master for commits missing DCO...
(lftools) ✘ user@dev > ~/Projects/besu-docs > (master) $

Run by David Huseby

License check

Notes for besu scan 2019-10-24:

  1. The Gradle check-licenses file at /gradle/check-licenses.gradle in lines 139-152 appears to list license choices for a few third party dependencies (to be separately provided and not checked into the source code repo). Two of those listed are for licenses other than Apache-2.0: * - CDDL-1.1 * org.checkerframework - MIT Is besu using these dependencies? If so, then under the Hyperledger IP Policy these should likely be included in a license exception request to the Governing Board. I expect it is likely that the GB would grant exceptions to use these as build-time dependencies.
  2. Hyperledger's documentation license is Creative Commons Attribution 4.0, CC-BY-4.0. None of the files in besu contained CC-BY-4.0 notices. Consider adding notices to any Hyperledger documentation files, such as: SPDX-License-Identifier: CC-BY-4.0 Most of these documentation files should be listed in the "No license found" tab of the license scan report spreadsheet.
  3. Although virtually all besu source code files contain Apache-2.0 license notices, there are a small number of files with no license information. In the "No license found" tab of the spreadsheet, the files with "No license found" do not contain license notices that were detected from our scanning. Where possible, for those that contain Hyperledger code, Apache-2.0 comments should likely be added. This can be done by adding a comment with an SPDX short-form identifier, such as: SPDX-License-Identifier: Apache-2.0 Note that any files in this tab labelled as "third party directory", "excluded file extension" or "empty file" likely do not need to have these notices added. More information for #2 and #3 can be found on the Hyperledger wiki, at

Scan report:


Community Support

The project must have an active and diverse set of contributing members representing various constituencies

Hyperledger Besu has active community. We have 217 users on RocketChat. There have been 38 non-PegaSys contributors since the projects’ acceptance into Hyperledger in September 2019 with 191 non-PegaSys contributions total.

Prior to entering Hyperledger the project had 55 contributors (31 from PegaSys, 24 external) with over 100 external commits and over 200 members of our public Gitter channel.

The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)

While PegaSys is the main organization that is contributing to Besu, there are several organizations and contributors contributing to Besu, including web3labs, Chainsafe Labs, and Machine Consultancy. We have maintainers from 4 organizations: PegaSys, Web3Labs, Chainsafe labs, and Machine Consultancy.  The ETC Cooperative has also been funding major feature additions, namely Ethereum Classic Support and Keccak256 PoW support.

Release plans are developed and executed in public by the community.

The releases of Pantheon and now Besu have been in a public forum available on the GitHub and the Gitter channel, and RocketChat. We also have set up a bi-weekly contributor call in which release activities are discussed. Meeting minutes and agendas are posted publicly on the Besu Wiki.

Finer grained details are managed via Jira. Epics, and stories are maintained in Jira, and tracked against versions.


Sufficient test coverage

See below.

The project must include a comprehensive unit and integration test suite and document its coverage. Additional performance and scale test capability is desirable.

Currently there are comprehensive unit, integration and acceptance tests with Besu. Merges to master are prevented if there are failing tests.

Performance and scale testing is under development through a partnership with WhiteBlock.


Sufficient user documentation

Hyperledger Besu team maintains a robust documentation site here. 

The project must include enough documentation for anyone to test or deploy any of the modules.

Done. See above.


Requirements fulfillment

Hyperledger Besu team maintains a robust Documentation site that provides details on requirements, use cases, and other expectations for the project.

The project must document what requirements and use cases it addresses.

Hyperledger Besu team maintains a robust Documentation site that provides details on requirements, use cases, and other expectations for the project.

The project must document how it fits within the Hyperledger Architecture

Besu’s architecture can be seen in this blog post. Because it's a mainnet Ethereum client, Besu represents some new considerations and opportunities for the Architecture Working group which require further discussion.

Compatibility with other Hyperledger projects

This is a work in progress that we are excited to continue to engage with the community on. Our team attended the maintainer summit Oct. 8-9 to begin exploring these options.

Where applicable, the project should be compatible with other active projects.

This is a work in progress that we are excited to continue to engage with the community on.


Release numbering: the project should use the Hyperledger standard release taxonomy, once that is agreed upon.

Besu uses the appropriate naming taxonomy.

Project must make a release, even a “developer preview”, before graduation.

The past releases and the respective documentation for Hyperledger Besu can be found here.


Gerrit or Github repo has been created

Done and code has been moved.

Mailing lists have been created and are archived


Other communication means used, such as slack channels, are set up


Project is set up with Continuous Integration


All information necessary for someone to join the community and be able to start contributing is duly documented (location of repo, list of maintainers, mailing lists addresses, slack channels if used, etc) following the Hyperledger Project standard practice (, MAINTAINERS.txt,, etc)

We currently have documentation in the current Docs and Wiki site referenced above.

CII Badge

A team seeking to graduate from incubation shall have started the CII Badge application and be nearly complete with incomplete badge requirements referenced in their graduation proposal. 100% of the applicable criteria for the CII Badge is a requirement for releasing a 1.0 of the project. That does not mean the project must have 100% of all criteria, just 100% of the applicable criteria. This is to allow for projects such as test harnesses, that have “N/A” answers for questions that don't offer that as an option.

CII Badge was completed. Seen here.

Other Considerations

Sufficient real world use

The project should be used in real applications and not just in demos. Because not all real applications may be discussed publicly, in such cases statements providing as much detail as possible should be made.

Sufficient scalability

The project must demonstrate sufficient scalability and document its scalability over various dimensions such as:

  • Maximum number of transactions per second
  • Maximum number of transactions per chain
  • Maximum size of a block

Minimum test code coverage expected, such as, for example:

  • Minimum coverage for Security & cryptography
  • Minimum coverage for other functionality
  • Minimum coverage for Business logic/smart contract

Besu has several real world use cases. There are several that are not public. Here are links to a couple of public real world applications being developed using Hyperledger Besu:

  1. LiquidShare
  2. IoBuilders
  3. ZarX

There is also notable downstream use of Besu code:

  1. 41North has created a plugin to export to data to enterprise systems.
  2. Web3J uses the EVM to provide CLI Debugging.
  3. Rootstock is porting their Unitrie to Besu code.

Scalability - PegaSys has performed several monitoring and benchmarking assessments of Besu.

PegaSys also has a research & development team fully dedicated to the long-term scalability of Ethereum and Hyperledger Besu.

Reviewed by

  • No labels


  1. I've left a number of comments inlined, above (as has Tracy).

    1. Thank you! Will respond over the next day or two.

  2. Have any 3rd party security scans, penetration tests, etc been performed?

  3. Gari Singh The codebase has had a security audit performed in 2018 when it was named Pantheon. You can find the assessment report here:

    We are also currently working with David Huseby with RFPs being sent out to begin another security audit on the codebase in the coming weeks. We are in the process of selecting the appropriate vendor before we kick off the work.

    1. Perfect ... thanks

  4. From the project description, I don't get if the EEA-like private transactions are already supported. Is it the case?

    1. Angelo De Caro Yes, EEA-like private transactions are supported. There is a private transaction manager, Orion, that manages sending private transactions. You can also create privacy groups. Orion, however, is a separate codebase from Besu and still housed within PegaSys' repos.

      1. Is it the case that in order to use Besu for permissioned use case, a user would need to integrate with Orion? If so, please help me understand why Orion was not also submitted.

  5. While I appreciate the desire of the Besu team to quickly move to Active status I must admit not to have expected this request to come so soon. I quite frankly think it is materially impossible for a team to fully integrate an organization so quickly and I think there are several signs of that showing up which have already been highlighted by others.

    I'm especially interested to see the response regarding the affiliation of the maintainers. As I pointed out in a comment on Besu's HIP, “having 26 full time developers from the same company on this project isn’t going to make it easy to create a really open community and move to Active status quickly as it is hoped for.”

    I will also note that the stated governance of the project is totally at odd with Hyperledger and if nothing else makes the project unsuitable to move to Active status:

    “This project is led by a benevolent dictator (PegaSys) and managed by the community.”

    The Incubation Exit Criteria clearly states that one requirement is that:

    "The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)"

    The reason that all other projects, even those that were well established before coming to Hyperledger, spent several months working within Hyperledger before applying to move to Active status is because it actually takes time to get there. Not that it is a requirement to wait for some time but simply because what is required takes time to achieve.

    Of course you could quickly change the governance document – and you should! – but making the actual change in how the project is run will take longer. The fact is that it takes quite a bit of effort for a company that has been the primary driver of a project to build a community and relinquish control and share it with the community. Other projects have struggled with this and often still do. In fact, I think it is always the one criteria that stops projects from moving to Active status because unlike other criteria this is not something that is easy to control. So, you're not alone!

    Just keep working on it and I trust that given the demonstrated eagerness of the Besu team you will eventually get there.

    If nothing else, going through this application process should help you identify areas that need improvement and help us clarify our documentation if needed so that what is expected is more clearly stated. Your feedback here would be much appreciated.


  6. Hi Arnaud and TSC,

    Thanks for your thoughtful review of the proposal. We’ve tried to respond to some of the themes we’ve seen in the comments and provide additional context to the project’s efforts and processes:

    Diversity of Project:

    The Besu project is committed to diversity of its project and has many instituted best practices for OSS (discussed below). We would welcome working with the TSC on this matter and discuss recommendations on how other projects have successfully grown their contributor and maintainer base. Currently there are two organizations dedicated to Besu. We understand if the TSC wants to see a third organization prior to approving active status. 

    Implemented OSS Best Practices

    Besu has implemented best practices for running the project to be as community-friendly as possible. We use these best practices when running the project:

    • Contributor Calls: We have bi-weekly contributor calls where all are welcome and able to contribute agenda topics.
    • Release Management: First major release was already released as Besu (1.3 Release)
    • RocketChat and Mailing List Activities: All project communication is done on these open channels. We have seen active chatter and questions on RocketChat since moving the conversations there.
    • Maintainer Process: We have a formal and objective process to add maintainers modeled after OpenJDK. This is unlike a subjective processes used by other projects.

    How Besu is Already Engaging in the Hyperledger Community

    The Besu team is excited to be a part of the Hyperledger community and the team has already begun contributing to the community. We’ve put together a list of activities the Hyperledger Besu team has participated in since being approved as a Hyperledger project:

    Note: I’ve also added this list to the proposal above.

    • Added support for Besu in Caliper (Oct. 20)
    • Participated in the CI/CD working group conversations and sharing our project’s research and best practices (Sep.-Oct.)
    • Attended the Maintainer summit in Minneapolis (Oct. 8-9)
    • Presented a talk at the Hyperledger booth at Sibos (Sep.23-25) 
    • Submitted several talks for consideration for the Hyperledger Global Forum and participated in planning of agenda (Sep.-Oct.)
    • Attended the Hyperledger meet-up at Devcon in Japan (Oct. 9)

    Thank you for calling out the governance page and it’s outdated information! We are in the process of updating it.

    Asks from the Besu Team to the TSC: 

    In the case the TSC doesn’t choose to approve the project into Active status at this time, we would like to see the TSC provide a clear list of the targets we need to hit to be approved into Active status. We hope we’ve already demonstrated our eagerness to address challenges raised by the TSC to date and we look forward to continuing to work with you on this matter.

    1. Why the rush?  What do you actually think "active" status does for you?

      I actually think that people confuse/conflate project status with the actual quality/state of the code.  Project status is about where a project stands in terms of meeting the governance policies of being a Hyperledger project; it has nothing to do with the actual "production" readiness of the code.

      I also think somehow people believe that Hyperledger projects are actually products.  They are not.  For example, Fabric is a project.  Oracle Blockchain Platform, IBM Blockchain Platform, SAP Cloud Platform Blockchain service, etc are products which are built from/incorporate the Fabric project codebase.  For Besu, Kaleido would be a product which uses Besu and of course PegaSys could product supported products based on Besu as well.

      I believe that too much importance has been wrongly placed on project status and it has been conflated with product readiness.

  7. For a third organization it will likely be Chainsafe labs and/or ETC Cooperative, they really want our client working on the ETC network.  They are working on patches here but it looks like they are preferring the giant functional patch approach rather than the small PRs approach Web3Labs and ConsenSys prefers.

  8. I'm still looking for a response to my question about Orion, above. Why was it not contributed to Hyperledger?

    1. Sorry for missing that one. The PegaSys team wanted to focus on a seamless transition of Besu/Pantheon first prior to moving other codebases over. We did not want to complicate that transition with multiple codebases. We are looking to move Orion to Hyperledger in the next couple of months. 

      1. Well, I can appreciate that, BUT, the whole premise of Hyperledger is about developing blockchain technology for the enterprise. Mostly, this has been about permissioned networks. Now we have Besu which in its current form requires a 3rd party (PegaSys) module to operate in permissioned mode. This seems awkward at best. I'd personally really like to see Orion brought over sooner rather than later. I don't know how other TSC members feel.

        1. Orion is not required to run in pemissioned mode.  Those are covered by the IBFT2 and Clique consensus protocols which are already a part of Besu.  Orion handles "restricted private transactions" where the private transaction is not stored on the blockchain.  "Unrestricted private transactions" are already handled in besu via smart contracts.  The unrestricted part means that there is no change to the core blockchain operations like is needed for restricted privacy.

  9. Based on comments to date (Nov 14) there is still some administrative work to do (migrate Jira) and more substantially the contributor diversity does not yet seem to pass the litmus test (i.e. if one company goes away will the project continue). 

    I do appreciate all the work that I see so far in the rest of the items and the thoroughness in this report itself. Continuing that proactive effort will no doubt soon close the main gap with contributor diversity.

  10. Just as a quick update: 

    -The Jira migration was completed last week to Hyperledger's Jira. The PegaSys one remains open to ensure a smooth transition, but will be frozen in a week or two.

    -The third organization, Chainsafe, is currently in the process of merging their commits for the ETC work Danno mentioned above.

    We can discuss further in the TSC meeting. Thanks!

  11. So, I realize the discussions on the TSC calls may have left the Besu team with the feeling that the TSC is failing to give them a clear goal to aim for. And I know we have discussed how the exit criteria document may not adequately convey what is expected from those of us who've been in this project for years and have come to expect. However, looking back at the document, which is actually quoted above, I see: "The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)".

    My understanding is that there currently are 20 maintainers/committers, 19 of which are from Consensys. Isn't that correct? If it is, independently of whether "there is no single company or entity that is vital to the success of the project" which admittedly will always be somewhat subjective, we don't have "at least 3 legally independent committers", right? As far as I am concerned this most clearly capture the sentiment I've heard expressed by various TSC members.

    With regard to voting on the proposal, historically we've always had pretty broad consensus on issues before we held any vote. I clearly don't sense any consensus here so that's why I've been reluctant to holding a vote. The fact that no one would second Mark's motion to vote on yesterday's call tells me others feel the same way. I might be wrong on that but my view is that it doesn't really help to have the TSC vote no. I think it is already pretty clear how the TSC feels and I'd rather the TSC help the Besu team get to the point where it can say yes instead.

  12. Thanks for the follow up Arnaud.

    Regarding the three contributors, we currently have Edward Mack, of Chainsafe labs, progressing through our maintainer addition process.  Greg and Edward are two devs that ETC Cooperative have financed to add and maintain Ethereum Classic support in Besu.  This window closes on 10 December and so far there is no objection to adding Edward.

    The 19/21 number will get passed around.  If there were fewer ConsenSys maintainers would that make a difference in deliberations?  Or is the concern that enough organizations were represented?  With Ivaylo and Edward as maintainers they can easily post and approve each others commits.  They also can also approve commits that are not their own, such as their co-workers (Josh and Greg, for example).  

    That being said, is this the only objection that the TSC has to active status or are there other requirements we need to work on?  We would much rather have all concerns present than have to go back and find out what the new objection is each time we feel we are ready.

  13. I agree. As far as I can tell the only issue is the lack of diversity - which, again, is no surprise to me: I predicted it when you guys first made the project proposal and, as I stated before, this is always the requirement which is the most challenging for projects to fulfill.

    I will ask the TSC to confirm that there isn't anything else so you know where we stand. That's only fair.

  14. As was stated on the TSC call, diversity can be subjective.  For clarity, there are three things I'm looking at:

    1. Will Besu survive if ConsenSys were to stop contributing to Besu?
    2. Is Besu "welcoming" to new contributors?
    3. Is Besu "welcoming" to new ideas?

    My current answers:

    1. No.  There are not enough other major contributors and at the moment I see no compelling reason for some other group(s) to carry the torch if ConsenSys were to abandon the project.  This is a young project - over time I'm sure adoption will grow
    2. Yes seems like it
    3. I have no reason to think this is not the case but will be good to monitor for a bit
  15. Congratulations!