Using technical standards alleviates the need for multiple organisations to repeatedly solve the same problems. History has repeatedly demonstrated the value of seeking consensus on technical standards to fuel industry growth through compatibility and interoperability between different businesses. They enable technology to work seamlessly and establish trust so that the wider ecosystem can develop and operate smoothly. 

Standards are sometimes used by regulators and cited in regulations as a tool to demonstrate compliance. They can also serve as a catalyst for innovation and help in anchoring solutions more quickly on the market. Innovations that extend across industries and value chains are becoming increasingly important. Incorporating innovative aspects into standards can prove crucial for market success since the market is then best prepared for the product.

The technical standards programme is designed to promote growth of the Bitcoin SV ecosystem through improved interoperability between systems. The programme aims to enhance the credibility of solutions built on Bitcoin SV from the perspective of auditors, regulators, insurers and clients. It encourages the development of certification schemes, fosters business growth and infers market signalling from proposals.

Technical standards are created by groups of experts in their subject matter who know the needs of the sectors that they represent and of the wider ecosystem. Industry experts are involved at all stages of the standard development process, from deciding whether a new standard is needed, to defining all the technical content and reviewing and monitoring industry adoption once published.

The Technical Standards Committee (TSC) oversees the development of Bitcoin SV techincal standards. They serve as facilitators for the standards development process, offering the platforms, rules, governance, methodologies and access to specialists such as technical writers to objectively address the standards development lifecycle. 

Each standard is developed by a working group that is assigned a TSC sponsor. The sponsors independently oversee the working group and ensures policies and processes are maintained to guarantee high-quality outputs and reinforce the relevance of industry and technology standards.

The standard development process is split into three phases, submission drafting and review, and then the final stage -standardisation. Each phase is made up of several activities. You can watch the standard overview videos or read the TSC processes for all the details.

There are three ways to get involved in developing Bitcoin SV technical standards: 

• Submit a proposal to form a working group.
• Join a working group as a reviewer or author.
• Comment on standards that are at the public review stage.

More details can be found in the Get involved section of the TSC website.

No. Everyone with subject matter knowledge can propose a standard, join a working group and participate in public review. We strive to have a balance of stakeholder views in our working groups and our participants can include (but are not limited to): 

• Individual experts of all ages and backgrounds.
• Seasoned professionals, industry innovators or those at the forefront of their field.
• Nominated representatives of public and government institutions.
• Regulators and representatives of standard-setting organisations.

The technical programme provides access to processes, tooling, guidance, and resources for industry use by participants who, in response to a perceived need, wish to come together to standardise ways in which applications built on top of Bitcoin SVcan interoperate. This includes access to: 

• A defined process that will ensure the quality, impartiality and pertinence of the standard produced.
• Tooling and resources allowing you to concentrate on the development of the standard.
• Dedicated guidance from a seasoned Bitcoin SV professional acting as sponsor for the working group.
• A publication platform for the standard produced that is freely accessible by all interested in developing for BSV.

The standards recommended by the TSC are first-class, professional and reliable solutions that solve real industry needs. Before they are published, the standard proposed to the TSC go through an open, rigorous, and transparent process, ensuring the proposed solution will have positive effects in terms of quality, interoperability, security, and stability. By proposing a standard to the TSC to solves an industry needs of importance to your company, you ensure that your company has a voice in the solution development making sure your views are included in the final specification while avoiding the downfall of working on your own internal solution in a silo which later might not interoperate and limit your business avenues. You will also benefit from an array of different perspectives on the topic from participants within the working groups and via public review so the standard produced is fit for adoption by the industry.

The first step for a proposer is to elaborate on the industry need they wish to solve and to understand the success criteria more fully. When capturing the standard requirements, you must ensure that the problem you wish to solve is in line with TSC criteria of enhancing interoperability through standardisation. When identifying the industry needs, proposers should also consult the standard library and look into the purpose of published standards and those in development, their working groups, their members and their activities. Your proposed working group may be different enough to justify the creation of a new group, or you may want to consider ways to work with existing groups to address your defined problem. 

The submission of a proposal to develop a standard is the next point in the standards process. At this stage, the solution overview should not be too detailed. The solution will be defined by the parties involved in writing the standard once in development if the submission is successful. The TSC will review the submission and if successful, a Working Group will be created to drive the standard forwards to completion. As this will be made public, nothing in this form should disclose key inventions that may be part of the proposal – in order to protect any intellectual property that may otherwise become public knowledge (and therefore prior art).

No. The proposal should be focused on the problem statement. At this early stage, the solution overview should not be too detailed. The solution will be defined by the parties involved in writing the standard should it progress to the development phases.

Getting involved in this process can bring significant advantages to you and to your business: 

• Give your organisation a voice in the development of standards.
• Actively participate in shaping BSV standards community.
• Ensure your organisation’s technical needs are addressed in the development of industry standards in a timely and satisfactory manner.
• Ensure you are building in the right direction to reduce technical debt/waste and allow for maximum interoperability with the rest of the industry.

Time commitment is influenced by the participant role, the complexity of the industry needs the working group tries to solve and of the proposed solution. The time listed below are for indication. 

Time commitment – Authors

The time that it takes to create technical documentation directly correlates with the length of the documents. As a rule of thumb for estimating the creation of technical documentation, it takes about 2 hours per page to write a new document for a non-professional writer. Like any writing project, authors must also allow time for research, outlining, review and coming up with diagrams/images. As a guideline, a typical technical document can take between 24 and 50 hours to complete usually across 3-4 months.

Time commitment – Reviewers

The review cycle will vary depending on the complexity of the technical standard. A common process follows a first draft, revised draft, and final draft/version of the document. Each review will refine and improve the document. Therefore, a lengthier or more critical document will require additional rounds of review. As a guideline, the time commitment to the review process over the expected lifetime of the workgroup are expected to be in the range of 2-3 months and would typically require 5-10 hours of review work split across 2-3 iterations of a draft standard.

There are several benefits to joining a working group and helping shape the standard for topics that are important to you. By taking part in the standard development process, you contribute to building a highly professional BSV ecosystem. 

Being a member of a working group will provide the opportunity to shape the technical content of the standard based on your own interests, knowledge and ideas, ensuring that the standard being recommended integrates with your companies long-term technical needs.

Joining a working group presents a fantastic opportunity to expand your network and meet other experts in the fields. It provides access to information about worthwhile technologies and regulations at an early stage, helping you keep up to date.

Reviewers are full members of a working group. This means they have access to the draft at its earlier stage and actively participate in discussion with the authors which will shape the proposed solution. They can voice their views on the topic from the beginning of the process and can have a significant impact on the chosen solution. Public reviewer comments on a standard that has already gone through multiple iterations internally. Though their comments can lead to significant changes in the document that will be recommended, their contribution can be limited in some cases given the later stage at which they join the process.

The public review is an important stage that can influence the technical decisions made by the working group. It represents an opportunity for industry experts to review and comment on the draft. Providing their opinion on the standard will help shape its outcome and ensure it solves the need of the wider industry. Public reviewer comments on the standard are published in the standard catalogue under public review and do not require you to join the working group or take part in the writing process. This offers participants a chance to provide feedback on a standard of interest and impact its final content with a minimal time commitment. 

Standards at all stages are listed in the Bitcoin SV technical standard catalogue. Published and recommended standards are freely accessible.

A published standard is a finalised specification that has completed at least one internal review and one public review. It is ready for implementation but has not yet been adopted by the industry. To move to recommended, a standard needs to achieve a level of adoption and must show evidence of being implemented by companies and users.

The Patent License Pledge is based on Sections 2 and 3 of the Community Specification License 1.0, which is widely recognized as a standard in open source-inspired collaboration methods.

Under these, the participants retain their patent rights and/or claims in their inventions. However, they authorize the other participants (the licensees) to use that IP to the extent necessary to implement the required portions (including the required elements of optional portions) of the standard that are described in the standard documentation.

The participant may exclude certain patent rights and/or claims from the license pledge. The licensing terms are clearly listed in the heading of the standard document with details of the patent pledge – if applicable- under the relationship section of the same document. You should carefully read the patent pledge before implementing the standard to ensure compliance with the licensing terms.