1 of 49

v1.0.0

Welcome

Welcome to the Baseline Protocol Community

The Baseline Protocol initiative was on March 4, 2020 and launched as an open source project on March 19, 2020, supported by fourteen founding companies. More companies joined the effort shortly thereafter and continue to do so. In 2021, the Enterprise Ethereum Alliance and OASIS collaborated to establish the Baseline Protocol and other projects as .

The work of the community is maintained under a public domain.

The Baseline Protocol is a set of techniques that must be implemented in a standard way across different systems. The draft was completed in September, 2021 and submitted to OASIS for review. The current specifications are maintained .

There are lots of opportunities to get informed, get involved, and get value out of developing reusable components, and ultimately deploying the Baseline Protocol in your own offerings. Go to and click "Join the Team".

New Contributors to the codebase and standard: Go for contribution guidelines.

About the Baseline Protocol

The Baseline Protocol is the emerging standard for synchronizing state across different systems of record over the internet, using a public blockchain as a common frame of reference. This applies to traditional corporate systems of record, any kind of database or , and even different blockchains or DLTs. It is particularly promising as a way to reduce capital expense and other overheads while increasing operational integrity when automating business processes across multiple companies.

The approach is designed to appeal to security and performance-minded technology officers.

You can find all the details on the current version of the Baseline Protocol .

The Baseline Protocol Source Code

Version 1.0 of the Baseline Protocol has been released. It is composed of a set of 6 core packages that are available open-source, under the CC0 1.0 Universal public domain dedication. For the full license text, refer to .

You can find more about the source code .

The Baseline Protocol Standard

The Baseline Protocol Standard will be a set of three specifications - CORE, API and CCSM that together, provide the requirements to be satisfied to implement a compliant Baseline Protocol Implementation (BPI).

The Baseline Protocol Reference Implementations

Today, there are demos, prototypes, and production systems being developed in more places than can be tracked, and some have been submitted as public domain contributions to the community.

Baseledger and other Resources

Basics

Introduction

What is the Baseline Protocol?

The Baseline Protocol is an open-source initiative that combines advances in cryptography, messaging, and consensus-controlled state machines -- often referred to as blockchains or distributed ledger technology (DLT) -- to deliver secure and private business processes, event ordering, data consistency, and workflow integrity at low cost. The Baseline Protocol provides a framework that allows Baseline Protocol Implementations (BPIs) to establish a common frame of reference, enabling confidential and complex (business) collaborations between enterprises without moving any sensitive data out of traditional Systems of Record. The work is governed as an EEA Community Project, managed by OASIS.

Why Baseline Different Systems of Record?

Businesses spend hundreds of millions of dollars on ERP, CRM and other internal systems of record. Failure to properly synchronize these systems between organizations causes considerable disruption and waste: disputes, lost inventory, inflated capital costs, regulatory actions, and other value leakage. To avoid these problems, systems require a common frame of reference. But only the largest high-volume partnerships can afford the capital expense involved in setting up such integrations. The baseline approach requires a common frame of reference that is always on, strongly tamper resistant and able to prevent any individual or group from taking over the system and locking companies out of valid operations. These requirements strongly suggest the use of a public blockchain or Layer-2 network anchored to a public blockchain.

Past approaches to blockchain technology have had difficulty meeting the highest standards of privacy, security and performance required by corporate IT departments. Overcoming these issues is the goal of the Baseline Protocol.

Illustrative High-Level Example

An illustrative example of the use of a Baseline Protocol Implementation (BPI) is a Buyer placing an order to a Seller. Normally a Buyer system creates an Order and transmits it to the Seller system through some preestablished messaging system without providing proof that the Order created is correct or even that both parties processed and stored the message consistently. This forces the Seller and Buyer systems to validate the order, often manually. This then leads to a time-consuming and often expensive back and forth between Seller and Buyer to rectify inconsistencies.

A Master Services Agreement (MSA) between a Requester (Buyer) and a Provider (Seller) is implemented on a BPI and contains billing terms, pricing, discounts, and Seller information such as billing address, etc. Once established and agreed upon by Buyer and Seller, the BPI provides state synchronization between Buyer and Seller, since the ERP systems for Buyer and Seller can now refer to mutually agreed-upon data as a common frame of reference.

Based on this mutually agreed-upon state in the MSA, the Buyer creates an Order based on the MSA, employing a cryptographic proof that confirms not only the correct application of business logic but also the correct application of commercial data in the Order creation. This proof is submitted together with the Order through the BPI and then is validated by the Seller. If the proof is validated, the Seller accepts the proposed state change by generating its cryptographic proof, confirming its acceptance of the state change. The Seller then updates the state of the business workflow in the BPI and sends the new proof to the Buyer.

The figure below visually demonstrates high-level Buyer and Seller Order generation and acceptance assuming that an MSA between Buyer and Seller already exists and is recorded on a BPI and that the commercial state has been synchronized up to this workstep in the commercial business workflow.

Figure 1: Illustrative Example of how the commercial state between Buyer and Seller is synchronized and an Order created.

Without a BPI, both Buyer and Seller must assume that the MSA between them and all its values are correctly represented in the other party’s respective Systems-of-Record. Hence, if an order is created based upon the MSA but does not comply with the MSA, it will likely result in extensive manual interactions between Seller and Buyer at one stage or another to resolve the problem to their mutual satisfaction.

Glossary

If you are unsure about any specific terms feel free to check the Glossary.

Architecture

The Baseline Protocol provides a framework that allows Baseline Protocol Implementations (BPIs) to establish a common (business) frame of reference enabling confidential and complex (business) collaborations between enterprises without moving any sensitive data between traditional Systems of Record.

Presented below, a reference architecture that when implemented ensures that two or more systems of record can synchronize their system state over a permissionless public Consensus Controlled State Machine (CCSM) network.

Reference Architecture Layers

A Baseline Protocol Stack Reference Architecture as depicted above in Figure 1 is comprised of the following layers:

Baseline Protocol (BPI) Abstraction Layer: This layer enables accessing all externally available BPI functions through APIs as defined in the Baseline Protocol API Standards document
Middleware Layer: This layer manages all counterparties to an agreement and its associated workflows and worksteps with business rules and business data as well as all counterparty delegates. In addition, it manages all messaging between counterparties to an agreement and instantiation of processing layers based on newly created or updated agreements and their workflows, worksteps, business rules, and business data.
Processing Layer: Manages, properly sequences, and deterministically processes and finalizes in a privacy-preserving, cryptographically verifiable manner all state change requests from counterparties to all agreements represented in the BPI.
CCSM Abstraction Layer: This layer enables accessing all required BPI functions implemented on one or more CCSMs through APIs as defined in the Baseline Protocol API Standards document.
CCSM Layer: This layer manages, properly sequences, and deterministically processes in a privacy-preserving, cryptographically verifiable manner all transactions from the Processing Layer as well as either deterministically or probabilistically finalizes on the CCSM all CCSM state transitions based on said transactions.

Components of each layer

BPI Abstraction layer
- API Gateway: An API gateway that exposes all required functionality to the counterparties to an agreement and enforces all necessary authentication and authorization of API calls as well as properly directs the API calls within the Baseline Protocol Stack
- Application: The application logic which manages the pre-processing and routing of all API requests, as well as the enforcement of authentication and authorization protocols and rules.
Middleware Layer
- Workflows: A Business Process Management engine that allows for the definition, management, and instantiation of workflows and worksteps and associated business rules and data based on (commercial) agreements between counterparties
- Identity/Accounts/Workgroups: A capability that allows for the identification and management of counterparties and their delegates as well as members of workflows and worksteps organized in workgroups that are derived from the counterparties to an agreement.
- Messaging: A messaging capability that allows the exchange of secure and privacy-preserving messages between counterparties to an agreement to communicate and coordinate an agreement on proposed (commercial) state changes.
Processing Layer
- Transaction Pool: one or more transaction pools that hold, properly sequence, preprocess and batch for processing by the Virtual State Machine all requested state change transactions of a BPI.
- Virtual State Machine: one or more Virtual State Machines which deterministically processes and finalizes in a privacy-preserving, cryptographically verifiable manner all state change request transactions.
- Storage: A storage system for the cryptographically linked current and historical state of all (commercial) agreements in a BPI.
CCSM Abstraction Layer
- API Gateway: An API gateway that enables accessing all required BPI functions implemented on one or more CCSMs, and properly directs the requests within the CCSM Abstraction layer to the proper CCSM API application logic
- Application: The CCSM API application logic manages the pre-processing, as well as the proper usage of the underlying CCSM and BPI authentication and authorization.
CCSM Layer is comprised of
- Messaging: A messaging capability that allows the exchange of messages between CCSM nodes that comprise either received transactions or a new proposed CCSM state.
- Transaction Pool: A transaction pool holds, properly sequences, pre-processes, and batches for processing by the CCSM Virtual State Machine all submitted CCSM transactions.
- Virtual State Machine: A Virtual State Machine deterministically processes in a cryptographically verifiable manner all submitted transactions for CCSM state changes.
- Storage: A storage system for the cryptographically linked current and historical state of all CCSM State Objects.

Glossary

If you are unsure about any specific terms feel free to check the Glossary.

Glossary

Baseline Protocol

The Baseline Protocol is a set of methods that enable two or more state machines to achieve and maintain data consistency, and workflow continuity by using a network as a common frame of reference.

Baseline-Bridge

A mechanism for one Workflow to use the proof generated by a different Workflow. to use a proof generated in a Workflow executed by Workgroup A as input to a Workflow executed by Workgroup B.

Baseline-Connector

An interface connecting and synchronizing a baseline stack and system of record.

Byzantine Fault Tolerant (BFT)

Given a network or system of n components, t of which are dishonest, and assuming only point-to-point channels between all the components, then whenever a component A tries to broadcast a value x such as a block of transactions, the other components are permitted to discuss with each other and verify the consistency of A's broadcast, and eventually settle on a common value y. The system is then considered to resist Byzantine faults if a component A can broadcast a value x, and then:

If A is honest, then all honest components agree on the value x.
If A is dishonest, all honest components agree on the common value y.

"The Byzantine Generals Problem", Leslie Lamport, Robert E. Shostak, Marshall Pease, ACM Transactions on Programming Languages and Systems, 1982

Circuit Breaker

The ability of a Party to immediately cease all their active Workflows across all of their Workgroups within a Baseline-compliant implementation, and, if required, exit a Baseline-compliant implementation with all their data without any 3rd party being able to prevent the exit.

Common Frame of Reference

A Common Frame of Reference as used in this document refers to achieving and maintaining data consistency between two or more Systems of Record using a consensus-controlled state machine. This enables workflow and data continuity and integrity between two or more counterparties.

Consensus Controlled State Machine

A Consensus Controlled State Machine (CCSM) is a network of replicated, shared, and synchronized digital data spread across multiple sites connected by a peer-to-peer and utilizing a consensus algorithm. There is no central administrator or centralized data storage.

Electronic Record

Information captured through electronic means, and which may or may not have a paper record to back it up.

Bulletin of the American Society for Information Science and Technology, Electron-ic Records Research Working Meeting: A Report from the Archives Community, May 28‐30, 1997.

Identity

The condition of being the same with something described or asserted, per Merriam-Webster Dictionary.

A concretization of the above used in this document: Identity is the combination of one or more unique identifiers with data associated with this/these identifier(s). Identity-associated data consists of signed certificates or credentials such as verifiable credentials and other unsigned, non-verifiable data objects generated by or on behalf of the unique identifier(s).

Merriam-Webster Dictionary

Interoperability

The ability of a Party operating Workflows on a baseline-compliant implementation A to instantiate and operate one or more Workflows with one or more Party on a baseline-compliant implementation B without the Party on either implementation A or B having to know anything of the other Party’s implementation.

Liveness

In concurrent computing, liveness refers to a set of properties of concurrent systems, that require a system to make progress, despite its concurrently executing components ("process-es") may have to "take turns" in critical sections, parts of the program that cannot be simultaneously run by multiple processes. Liveness guarantees are important properties in operating systems and distributed systems.

Alpern B, Schneider FB (1985) Defining liveness. Inf Proc Lett 21:181-185

Master Services Agreement (MSA)

A legal contract that defines the general terms and conditions governing the entire scope of products commercially exchanged between the parties to the agreement.

Non-Repudiable

Refers to a situation where a statement's author cannot successfully dispute its authorship or the validity of an associated contract. The term is often seen in a legal setting when the authenticity of a signature is being challenged. In such an instance, the authenticity is being "repudiated".

Party

A set of Parties participating in the execution of one or more given Workflows. A Workgroup is set up and managed by one Party that invites other Parties to join as workgroup members.

Portability

The ability of a Party to migrate and re-baseline its existing Workflows and data from one baseline-compliant implementation to another baseline-compliant implementation without any 3rd party being able to prevent the migration.

Privacy Assurance Mechanism

A way of ensuring the privacy of Workflow data represented on a public Mainnet. - permissionless vs public - to discuss and review.

Proof of Correctness

A Proof of Correctness is a mathematical proof that a computer program or a part thereof will when executed, yield correct results, i.e. results fulfilling specific requirements. Before proving a program correct, the theorem to be proved must, of course, be formulated. The hypothesis of such a correctness theorem is typically a condition that the relevant program variables must satisfy immediately before the program is executed. This condition is called the precondition. The thesis of the correctness theorem is typically a condition that the relevant program variables must satisfy immediately after the execution of the program. This latter condition is called the post-condition. The thesis of a correctness theorem may be a statement that the final values of the program variables are a particular function of their initial values.

"Encyclopedia of Software Engineering", Print ISBN: 9780471377375| Online ISBN: 9780471028956| DOI: 10.1002/0471028959, (2002), John Wiley & Sons, Inc.

System of Record

The integrity of the data in data architecture is established by what can be called the “system of record.” The system of record is the one place where the value of data is definitively established. Note that the system of record applies only to detailed granular data. The system of record does not apply to summarized or derived data.

W.H. Inmon, Daniel Linstedt and Mary Levins, "Data Architecture", 2019, Academic Press, ISBN: 978-0-12-816916-2

Trust Model

Collection of entities and processes that Service Providers rely on to help preserve security, safety, and privacy of data and which is predicated on the use of a CCSM implementation.

Marsh S. (1994). "Formalizing Trust as a Computational Concept". Ph.D. thesis, University of Stirling, Department of Computer Science and Mathematics.

Verifiably Secure

Verifiable computing that can be described as verifiably secure enables a computer to offload the computation of some function to other perhaps untrusted clients, while maintaining verifiable, and thus secure results. The other clients evaluate the function and return the result with proof that the computation of the function was carried out correctly. The proof is not absolute but is dependent on the validity of the security assumptions used in the proof. For example, a blockchain consensus algorithm where the proof of computation is the nonce of a block. Someone inspecting the block can assume with virtual certainty that the results are correct because the number of computational nodes that agreed on the outcome of the same computation is defined as sufficient for the consensus outcome to be secure in the consensus algorithm’s mathematical proof of security.

Gennaro, Rosario; Gentry, Craig; Parno, Bryan (31 August 2010). Non-Interactive Verifiable Computing: Outsourcing Computation to Untrusted Workers. CRYPTO 2010. doi:10.1007/978-3-642-14623-7_25

Workflow

A process made up of a series of Worksteps between all or a subset of Parties in a given Workgroup.

Workstep

A workstep is characterized by input, the deterministic application of a set of logic rules and data to that input, and the generation of a verifiably deterministic and verifiably correct output.

FAQ

Is there a token for the Baseline Protocol?

There is no Baseline Protocol token.

The Baseline Protocol is an approach, a set of techniques which requirements are specified in the Baseline Protocol Standard, an Oasis open standard and which technology is available open-source. The Baseline Protocol standard and source code are available under the CC0 1.0 Universal public domain dedication. For the full license text, refer to license.

Being open-source, open-standard means that anyone is free to build any application or service implementing the protocol. Those applications/services may or may not have their own tokens.

I am interested in contributing, where do I start ?

a contributor: Anyone with a Github ID can submit pull requests, create and edit their own Issues. You don't need any special access to the repo to get involved and start contributing. For more information, see here.
a member: Contributors can become members of our Github Organization, which allow them to get invitations to key meetings, be assigned to Issues, and vote for Technical Steering Committee members. For more information, see here.
a core developer : Members can become core developers and have a direct hand in deciding what work is merged to the Main/Master Branch to become official Baseline Protocol technology. For more information, see here.

I want to build with Baseline Protocol, where do I start?

Baseline Protocol v1.0 core: If you want to build with the Baseline Protocol from scratch, you can get started with v1.0 core that provides a set of 'vanilla' packages. You can get started here.

Reference Implementations: You can also choose to build on top of existing reference implementations. We recommend starting with BRI-1. This reference implementation of the core interfaces specified in the v1.0 release has been developed by individuals and companies community leaders including Provide, EY, Nethermind, ConsenSys, and others. It heavily utilizes the core Provide application stack and is compatible with Shuttle, an on-ramp for baselining. NATS and the Nethermind Ethereum client (the first client to implement the Baseline Protocol RPC) are opinionatedly used by default. You can get started with BRI-1 here.

Developer Resources: To help you build with the Baseline Protocol, you can use the implementation guide and other developer resources available here.

My company is interested in baselining, how to start ?

The Baseline Protocol enables confidential and complex (business) collaborations between enterprises without moving any sensitive data between traditional systems of record.

While 'baselining' as a technique is not restricted to commercial use cases, a Baseline Protocol Implementation (BPI) as specified in the Baseline Protocol Standard requires at least two organizations to come together to synchronize their respective systems of record.

A group of companies interested in 'baselining' can either deploy their own implementation using their in-house resources or they can choose to work with third-party partners (product and service providers).

A list of Baseline-compliant providers will be made available in 2022.

Which systems of record can we 'baseline'?

Any systems of record can be baselined without requiring any modification to legacy systems. A Baseline Protocol stack is required to manage all messaging and transactions between counterparties and between counterparties and their agreed common frame of reference.

Does 'baselining' require a blockchain?

Distributed Ledger Technology referred to as Consensus Controlled State Machine (CCSM) is the foundational enabler of a Baseline Protocol Implementation (BPI). A compliant BPI requires conformance to the CCSM specification of the Baseline Protocol Standard. For more information, see here.

Does 'baselining' require Ethereum and/or Baseledger ?

While much of the initial work on the standard and the code was done by companies and individuals in the Ethereum development community, any CCMS that conforms to the CCSM specification of the Baseline Protocol Standard can be used in a compliant Baseline Protocol Implementation (BPI).

Community

Open Source Community

The Baseline Protocol initiative was announced on March 4, 2020 and launched as an OASIS open source project on March 19, 2020, supported by fourteen founding companies. The number of active companies and individuals contributing to the work and using it in products and enterprise solutions grew quickly through the Summer of 2020 and currently is estimated at over 600.

The initiative is strongly aligned with the Mainnet Working Group, a joint effort of the Enterprise Ethereum Alliance and the Ethereum Foundation.

This work is active and open to contributors.

All work in the Baseline Protocol public repo is released under the CC0 1.0 Universal public domain dedication. For the full license text, refer to license.

Leadership

In an openly governed open standards / open source initiative, leadership is organic. One need not be seated to a committee to lead. One need not be the chair to lead the community in a direction. (Indeed, the chair's primary job is to harmonize the interests of others and help the community move to a shared vision, not necessarily to forward their own point of view.)

The way to lead is to start something, help something, fix something...even spellcheck something! The way to lead is to get others to amplify what you are doing (best done by listening deeply to others first). The way to lead is to serve your own (and your company's) enlightened self interest. You should be able to draw a straight line from your time on this work to real impact for your own offerings.

Below are the things you need to know to get informed, get involved and get value out of the work.

Working Together

Anyone can join the Baseline Protocol communication channels (see below), and anyone with a Github ID can view the roadmap (don't forget to log in with github id), fork the repo, and submit pull requests to contribute to the work.

You can also become a regular Member of the initiative, which will allow you to manage Issues and push directly to most repo branches (other than Master). Members who step up to be accountable for projects can become General Assembly members. Members who take on responsibility for maintaining the integrity of the work and merging contributions to the master branch of the repo can become Core Developers. And finally, contributors can nominate and vote-in members to be on the governing Technical Steering Committee (TSC) annually.

Below are the things to know about how to get involved and work with the team.

Meetings and Meetups

There are regular meetings of the TSC, General Assembly, Core Developers and other groups. These are typically listed here. If the times we have don't work for your timezone, we can do 1-1's or make changes to the schedule.

Onboarding: Help Getting Started

It's critical that new contributors have a good idea about what the focal points of the community are and where one can make a real impact. It's hard to beat having a real conversation about how to get started in an intimate setting where you can ask questions and get immediate answers.

We will hold Onboarding office hours once a week. Watch the Calendar for details or inquire on one of the communication channels below. Sessions and other learning material will be posted on our YouTube Channel and on Medium.

Technical Steering Committee

The TSC meets typically once a month to review progress. Members of the TSC receive invitations and you can rsvp to join any meeting by sending a message to the TSC Chair.

General Assembly

The General Assembly meets typically once a month to review roadmaps and set high-level priorities. Members of the General Assembly receive invitations, and you can join any meeting by sending a message to the TSC Chair.

Communications: Connecting with Each Other Directly

Slack / Discord / Telegram

The Baseline Protocol initiative maintains a Slack channel that is moderated but public. Sign up here. It's an active group, and you can directly connect with folks doing the work and coordinate with each other to get the work done.

Thanks to an enterprising member of the community, we now also have a shared Matterbridge-enabled channel between Slack, Telegram, and Discord. You can post -- and read what anyone posts -- on the shared channel, regardless of which platform you are using. In Slack, use the #community-chat channel to broadcast to Slack, Discord and Telegram. In Discord, use the #general channel. In Telegram, just use the main /baselineprotocol thread.

Members Directory

You can sign up to the baseline protocol members list and get access to the Directory. This will show you any members who have elected to be displayed publicly. There are others who will choose to be hidden but will receive group emails.

Group Email

While most communication seems to go through the Slack/Discord/Telegram channel, we do have email. When you sign up in the members directory, you will have the option to get email that's sent to the mailing list or directly from anyone in the group. You can control how that impacts your inbox here.

Forums

The Baseline Protocol initiative is launching soon a Discourse forum. Reddit is also likely. We also actively use commenting on Epics and Issues to conduct threaded discussions on key projects and engineering topics. To View the Zenhub Board for these, sign into Github with your ID, or you can install the Zenhub plugin to your Chrome browser and sign in that way. If you are member of the Ethereum-Oasis Org.

The Baseline Protocol initiative maintains the @baselineproto Twitter account, to which members of the TSC, General Assembly and some maintainers can post. We also use the #baselineprotocol tag.

Medium

The Baseline Protocol initiative uses Medium to post blogs. Here is the publication. Reach out on Slack to the TSC Chair, OASIS team or members of the steering committees, if you want to be a writer or editor.

YouTube

The Baseline Protocol initiative maintains a YouTube Channel. If you have videos that you'd like to add to the Channel or would like to help on Baseline Protocol video assets, use the Slack #comms-and-marketing channel and raise your hand.

Contributors

All work of the Baseline Protocol initiative is maintained publicly on a github repo.

You don't need any special access to the repo to get involved and start contributing. Follow these steps to fork the repo and submit pull requests. Anyone with a Github ID can also create and edit their own Issues, participate in public meetings, and join the various communication and collaboration channels that the community maintains.

There are four ways to contribute:

Write code (Architecture, Spikes, Issues, Tasks)
Write specifications (Epics, Stories, Prioritizations, Use Cases)
Write content and communicate it to more potential contributors, developers and product owners, and other stakeholders -- Join the communications team on Slack
Help prioritize work and develop incentives to get it done by joining the General Assembly or becoming a Core Developer or TSC Member.

There is one other way to contribute, and it's the most important: use the work in the Baseline Protocol to improve your own offerings. The Baseline Protocol is not a product or platform..the product is YOUR product.

Code of Conduct

Here is the link to the Baseline Protocol code of conduct:

Technical Contributors

Technical contributors either are working on architecture or developing code...but even correcting the language of documentation counts as a technical contribution and qualifies you to vote in upcoming TSC elections.

BLIPs

As of October 1, 2021, the baseline community will organize work in a similar fashion to Ethereum's EIPs (Ethereum Improvement Proposal). These will be called BaseLine Improvement Proposals, or BLIPs for short, and they will be maintained here. YOU ARE ENCOURAGED TO SUBMIT IDEAS to the BLIP repo, and we are well-organized to review and act on them in a timely fashion. You never know -- we might decide to raise a grant to pay for your idea to get executed. It's happened before. Try it out!

Issues Organization and Community "Sprints"

Technical tasks are written as Github Issues. Issues will be reviewed, lightly prioritized, and communicated as "hey, help out here!" messaging to the developer community every two weeks. The TSC will periodically review what Issues and communications best succeeded in attracting help.

An Issue should be constructed, in particular, with acceptance tests. All other elements of a good Issue should be known to any practicing developer.

Most Issues should be attached to an Epic (see below).

A good Task/Issue starts with a Verb: "Implement xyz."

Submitting a pull request

Follow these steps when submitting a pull request:

Fork the repo into your GitHub account. Read more about forking a repo on Github here.
Create a new branch, based on the master branch, with a name that concisely describes what you’re working on (ex. add-mysql).
Ensure that your changes do not cause any existing tests to fail.
Submit a pull request against the master branch.

Good practice strongly favors committing work frequently and not loading up a long period of work in isolation. Be brave...let others see what you are working on, even if it isn't "ready."

eCLA and iCLA

Anyone can do a pull request and commit work to the community. In order for your work to be merged, you will need to sign the eCLA (entity contributor agreement) or iCLA (individual contributor agreement). Here are the details: https://www.oasis-open.org/resources/projects/cla/projects-entity-cla

The iCLA happens automatically when people submit a pull request, or they can access directly by going to https://cla-assistant.io/ethereum-oasis/baseline

Core Developers and Commit Rules

Merging to Master requires review by THREE Core Developers. The TSC seeded the initial set of Core Developers. Now, any active Member can become a Core Developer. Core Developers may add more Core Developers by rough consensus, and the TSC may step in to resolve cases where this process fails.

Specifications Contributors

The specifications work of the community can be done by anyone, both technical and non-technical contributors. The focus is on finding evidence for a requirement and articulating it in the form below. The General Assembly is the coordinating body for this work.

Epics and Stories Organization

The Baseline Protocol initiative uses Zenhub to create and manage both specification work and active protocol requirements and prioritization. (Zenhub should be a tab in your Github interface if you are using the Chrome extension. There is also a web-app here.)

Zenhub enables Epics to nest, while Issues don't nest...not really. Therefore, the community will employ the practice of using Issues for engineering Tasks and Epics to contain high level topics, which may have nested within them a set of agile Epics, and in them a set of Stories, and even Stories may have other Stories nested in them. Engineering meets planning where a Story (in the form of a Zenhub Epic) is referenced by an Issue/Task. (This can work very well, but Zenhub's choice in calling Epics, Epics can cause confusion.

A Good Story

A Zenhub "Epic" used as a high-level container for a grouping of work should be in short topic form -- primarily nouns.

A Zenhub "Epic" used as a Story should almost always follow the form: "As X, I need Y so that I can Z." An acceptable variant is the "now I can" form (note the "so that" clause is preserved):

A Party's System Administrator can look up Counterparties in an OrgRegistry (a public phone book) and add them to a Workgroup, so that they can start Baselining Records and Workflows.
A Party's System Administrator can quickly and easily verify a Counterparty's identity found in the OrgRegistry, so that they can be confident in adding the Counterparty to a Workgroup.
A Party's System Administrator can use some or all of the Counterparties and Workflow Steps defined in one Workgroup in Workflow Steps created within another Workgroup, so that Workgroups don't become yet another kind of silo.

Contributors

The active contributors and maintainers of the Baseline Protocol repo can be found on Github. (Note: many contributors work in clones extending the protocol for their products. These people don't necessarily show up in the Github contributors list.)

Members

Anyone with a github ID can be a to the Baseline Protocol, but you can also become a Member of our Github Organization, which will allow you to get invitations to key meetings, be assigned to Issues, and vote for Technical Steering Committee members (provided you make at least one contribution that is successfully merged to master within the ).

What it means to be a Member

Being a Member gives you access to the Github Repo as well as the .

Members can manage Issues in pipelines, assign others to Issues, create Epics and Milestones and push contributions to any unprotected branch other than Master/Main.

It's a good idea to become a member if you are making regular contributions and want to be assigned Issues, be responsible for assigning Issues to others, or both. Members can be technical contributors, contributors to specifications, or people stepping up to be accountable for projects.

How to Join the Org as a Member

Joining the Baseline Protocol as a Member is easy.

Technical contributors should contribute at least one . Then, use the #github-membership-requests to post your github ID, name and company (optional) and a coordinator will ensure that you are added as a member within 24 hours or less. If you do not receive a response in that time, use one of our to contact the and/or any member of the to expedite.

To be a Member, you must of course sign the . This is essential, because you have Write access to the repo, and OASIS governance requires that content be contributed under those agreements.

Non-technical contributors, and in particular those who wish to be on the General Assembly, do not need to submit a pull request. See for details.

Member Guidelines

Trust is essential for members, because any member has the ability to make significant and direct changes to anything other than the Master branch or otherwise protected branches.

Members should:

show commitment by stepping up to contribute to key projects
be reliable in completing issues to which they have been assigned
attend regular member meetings when possible
follow the project style and testing guidelines
show an understanding of the nature and focus of the Baseline Protocol
be welcoming to others in the community
follow branch, PR, and code/docs style conventions

Code of Conduct

Removal

Beyond General Membership

Once you are a member, you can:

Or, just write awesome code, specifications, docs and communications.

Community Leaders

Over 500 people and companies signed up to be notified about the opening of the Baseline Protocol Github repository between March 4th and 19th, 2020. Over 300 of them also signed in as group members. The members represent many of the largest companies in the world, spanning several sectors. They also represent startups, students and talented individuals.

People listed here or appearing on community videos or in the github repos should be assumed to be representing themselves, and not necessarily the companies they work for.*

*(In the mid-1990s, the community amassed thousands of developers from many companies before any of those companies officially sanctioned their involvement. Many of the companies participating in the Baseline Protocol initiative embrace the work, some already adding baselining to their strategic plans. But anyone observing someone's participation in the baseline community should assume that they do so as individuals. Please refrain from making assertions about the intentions of their employers.)

Project Governance Board

The project governance board (PGB) is organized by OASIS and is accountable for ensuring the balance and integrity of the Ethereum-Oasis initiatives, such as the Baseline Protocol.

Community Organizers

OASIS employs key personnel that support all the open standards and open source projects under its domain. In addition, the Enterprise Ethereum Alliance maintains a team that also supports EEA Community Projects such as the Baseline Protocol. And finally, members such as ConsenSys have assigned key personnel specifically to support and organize the community.

Technical Steering Committee 2021/22

The technical steering committee (TSC) is accountable to the Project Governance Board for managing conflicts on merges and Core Dev self-organization. It also governs the allocation of grant money. And it meets regularly to set technical roadmaps and ensure progress of the community toward the ubiquitous implementation of the baseline protocol in systems of record everywhere.

On October 27, 2021, the following people were voted in as the TSC through October 2022 and the date of the next election's results.

Core Developers Team

The Core Developers are a subset of the contributing members of the community who have demonstrated leadership and teamwork and approve all contributions before merging them to the Main branch of the repo.

Standards Team

The standards team worked through most of 2021 to develop a world-class technical specification that implementers and test developers can use to ensure compliance with the baseline protocol specification. The draft will now be shepherded through the OASIS process of review and amendments, culminating in becoming an official OASIS standard. Standards writing is hard, and reviewing the writing is equally hard. This team deserves the highest regard from the community for its hard-toiling service and commitment to excellence.

Outreach Team

The outreach team consists of writers, evangelists, stakeholders, sponsors, events organizers and marketers who work together to develop enablement materials, promote baselining in the media, events and through direct engagement with thought leaders and decision-makers.

2020 Founding Group :

Core Developers

Once you've done some work as a Member, you may wish to become a Core developer and have a direct hand in deciding what work is merged to the Main/Master Branch to become official Baseline Protocol technology and specifications.

Here's a list of .

What do core developers do?

Core developers are people who take an active role in advancing the Baseline Protocol and/or related projects. They are primarily responsible for:

Contributing code or contributing to specification work in the form of PRs that are linked to open and prioritized issues
Reviewing and merging PRs into the master branch
Cutting, testing, and releasing new versions of the related Baseline projects
Working with the TSC and General Assembly to advance the Baseline Protocol

They can/should also contribute in the following ways:

Writing epics and issues to guide development
Setting up and supporting infrastructure (running demos, CI systems, community projects, etc...) that further Baseline
Working with the community to help with adoption
Presenting the project and key technologies to the public (in-person, webinar, videos, articles, etc...)

How to become a core developer?

There are two ways to become a core developer: You are asked by a current core developer, or you make request to an existing core developer to become one.

With either path you become a "provisional core developer". As such you will need to show consistent contributions of code and/or specifications to the project. This can be in the form of pull requests that get merged into master. Or it can be in the form of technical specification, system architecture and related artifacts that guide the development activities of others.

All provisional core developers that focus on code development (over standards) must meet with the existing core developers and demonstrate they are capable of the following:

Running the project locally
Using the testing framework
Explaining the components of the system architecture
Walking through the code and explain the baseline process

Once the provisional core developer demonstrates their capabilities, the existing core developers will vote during the next scheduled core developer meeting to give the prospect full core developer status. Members must vote with 2/3rds majority to add a core developer. Voting that results in a tie or potentially other issue will be brought to the TSC for review.

What is expected of core developers?

In general, a core developer needs to:

be an expert in one or more fields related to the project
be an expert in finding and engaging the advice of other experts
show commitment over time with multiple PRs merged
be reliable in completing issues to which they have been assigned
attend the weekly core developers meetings (with occasional absences allowed)
demonstrate competency in software development or specification writing
follow the project style and testing guidelines
have a high degree of understanding of the project architecture
be welcoming to others in the community who are using the project
contribute in ways that substantially improve the quality of the project and the experience of people who use it
follow branch, PR, and code style conventions

How core developers organize?

Slack

Regular Meetings

There are weekly Core Developers meetings where members can discuss plans and issues related to the project, updates, release planning, and other related topics. Anyone may attend these meetings, but the primary participants are core developers. Core developers are required to produce meeting summaries and document decisions.

Meeting signups are maintained on the "Join the Community" page on https://baseline-protocol.org.

How to stop being a core developer?

Any of the following ways:

You stop reviewing PR's, responding to messages, answering emails, and/or generally ghost the project.
You are disrespectful towards anyone in the community and/or involved in the project.
You are disruptive to the general process of maintaining the project, meetings, discussions, issues, or other.
You notify the other core developers you would like to relinquish your core developer status.

General Assembly

The General Assembly is a regular meeting of community members.

Meeting signups are maintained on the "Join the Community" page on https://baseline-protocol.org.

Identify high-level baseline protocol project categories
Articulate specific projects within those categories for the community to execute
Rank projects by loose consensus so that contributors can spot attractive opportunities to work on

The group meets monthly (or biweekly, as needed) and is convened by the Chair. From an governance perspective, the General Assembly is considered a subcomittee of the TSC, but in practice, the General Assembly and TSC have coequal roles in the community.

Project Leadership

Baseline Community Projects are the General Assembly's way of managing specific objectives for the baseline protocol initiative. General Assembly members commit themselves to one or more of these.

To be an General Assembly member means you are standing up -- alone or with a group of members -- to be accountable for one or more projects of the Baseline Protocol Initiative.

While others may do the development and task-work, a General Assembly member commits to articulating and prioritizing the work, identifying community members and others who can do the work, and using whatever incentive structure is available (or whatever influence one has) to help ensure the work gets done.

General Assembly Members also keep the community of project stakeholders regularly informed of status. This includes cases where milestones aren't being met or when a project should be shut down and the learning recycled into another project.

Projects in Zenhub and General Assembly Member Permissions

Here's a snapshot of the project roadmap in the baseline protocol's dashboard:

Projects can be technical, strategic, or organizational. For example, a technical project would be finding a messaging system that suits the baseline specifications. An organizational project would be developing a powerful and flexible incentive structure for the baseline community. Both are managed and tracked in Zenhub as shown above.

General Assembly Members have Github write permission, which gives them the ability to add and edit Projects, Epics and Issues, and to assign (and be assigned) work to specific Contributors.

How to Join the General Assembly

Unlike the TSC, which is fixed at eleven elected members, the size of the General Assembly is flexible. To balance openness and inclusiveness with the need to keep the team manageable and accountable, there is a single rule that determines membership: Accountability for Active Projects.

Your name, email, company/organization, github ID
A one or two-sentence description of the area around which you intend to help provide leadership

You will receive back an invitation to either a special session of the General Assembly or the next general General Assembly meeting, and you may at that time state your intention to join the team. If no one asks for a further review by the TSC, you are approved as a new member of the General Assembly and can begin working on your Project(s).

New General Assembly Member Quickstart

Within 24 hours of approval as a new General Assembly Member, you will be sent an email with instructions on how to get permissions to the various tools you now have at your disposal, including:

The ability to create and edit projects, epics and issues on Zenhub (Write access to the Github repo.)
The ability to post messages to community members
Invitations to the General Assembly meetings

To prepare for a great start to your time on the General Assembly, review the existing projects and top-level epics. Then get an idea where you want to focus your attention, and if it isn't represented in the dashboard, consider adding a Project or talk with other General Assembly members about it.

Other General Assembly Member Governance Details

Ending a General Assemby Membership

Just as getting into the General Assembly is about stepping up to lead on a project, leaving the General Assembly would be a natural process of ending those projects or cycling off leading them. The General Assembly will periodically do a house-cleaning segment in the regular meeting to achieve loose consensus on whether any projects require pruning.

Rough Meeting Agenda

General Assembly Meetings have these standard agenda items:

Review of new Projects
Triage of Projects that seem to need help
Ranking of "top featured" Projects that will be promoted by community influencers
Celebrate successful Projects and clean up list

GOVERNANCE

Overview

How is the Baseline Protocol governed ?

License and Patent Policies

All repos in the Ethereum OASIS organization, including Baseline Protocol repositories, adhere to OASIS Open Projects and .

In order to ensure clean IPR that allows Baseline to remain an open technology, OASIS rules require an for persons or organizations contributing on behalf of a legal entity, and an for community contributions. You must before your pull requests to the baseline repository will be merged. to see if your company has signed the ECLA.

Code of Conduct

Here is the link to the official .

Charter: Baseline Open Source Project Governance

Ratified on March 18, 2020 by the .

The Baseline Protocol shall be a project within the Ethereum-Oasis project of through at least May 31, 2020. The Project Governing Board (PGB) of the Ethereum-OASIS project, which was established in 2019 and is currently supported by the EEA and the Ethereum Foundation (EF), currently consists of Dan Burnett (ConsenSys), Tas Dienes (EF), and Chaals Neville (EEA) – supported by Jory Burson (OASIS). The Baseline Project shall be supported under the existing contract with OASIS and shall require no additional fees than those already paid by EEA/EF and the parties to the Open Ethereum Project until May 31, 2020. Negotiation to continue the Baseline Project with OASIS shall be conducted between March and May 2020.

License

Contributions to the open source repo shall be under creative commons public domain license .

TSC

The Baseline Protocol shall be governed by a Technical Steering Committee, with 7, 9 or 11 Members, one of whom will serve as TSC Chair. The initial number of seats for the bootstrapping period (see below) shall be 11.

A quorum of two-thirds of the TSC members can conduct any vote required of the TSC during any given meeting. Disputes on whether a matter should be tabled for a different TSC meeting can be presented to the PGB of the Ethereum-OASIS project for a decision. A move to table a matter can be lodged during a TSC meeting, and it shall be tabled and submitted to the PGB with a simple majority vote. If a majority cannot be achieved during the meeting, a minimum of two members that were present at the meeting in question may dispute the matter after the fact to the PGB.

No legal entity (or set of entities controlled by a single party) shall hold more than three seats out of eleven (or two seats out of seven or nine) on the TSC during any given period.

A TSC member is eligible to lose their seat upon missing two consecutive TSC meetings or three total during a period between elections. Removal is completed by a simple majority vote of the remaining TSC members that are not being considered for removal. The PGB of the Ethereum-OASIS project has the option to consider extenuating circumstances and determine whether or not to remove a member, if the TSC itself cannot come to a determination. After removal, a special election of the vacant seat shall be held among contributors. The seat will be up for re-election at the next regular election cycle.

Bootstrapping Period:

In all cases (7, 9 or 11 member TSC), the original three organizations (EY, MSFT, ConsenSys) hold less than 50% of the seats, during the initial six month bootstrapping period.

One TSC Member shall serve as provisional chair of the TSC for six months. On September 30, 2020, all members and the chair shall be open for new elections. Members of the community shall have voting rights based on contribution (see below):

Steady State Periods:

After the six month Bootstrap Period, there shall be a nomination and election period for electing TSC members, typically from the ranks of Contributors and Maintainers. The TSC voting members shall consist of eleven (7, 9 or 11) elected members chosen by Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the Master Branch of the codebase during the prior six (6) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.

Maintainers:

Contributors who have the ability to commit code and contributions to a repo's main branch on the Baseline Protocol. A Contributor may become a Maintainer by a majority approval of the existing Maintainers. The initial number of maintainers required to merge a pull request to master in the github repo shall be three, but may be amended to no fewer than two by a simple majority of the maintainers.

Contributors:

Anyone in the technical community that contributes code, documentation or other technical artifacts to the Baseline codebase or Standards Specification.

Contributions:

The TSC shall determine the number of maintainers required to merge a contribution into the master branch of the repo. This shall be done during the first TSC meeting. Changes to this number require a simple majority of TSC members.

Ratification

This document shall be ratified by the PGB before the public launch of the Baseline Protocol. Changes to this document shall require a simple majority of the PGB.

Details on OASIS and the Open Ethereum Project

TSC Rules for Mid-term Member Replacements

In the event that a TSC Member resigns more than 30 days before the end of their elected term, they may nominate a replacement. The resigning member shall consider the replacement’s active participation in, contribution to, and commitment toward the Baseline Protocol community when selecting such candidate.

The position shall remain open for 30 days or until 7 days after the next steering committee meeting, whichever comes first (the open period). During that period, any other TSC member or Active Contributor to the /baseline github repo, may nominate another person.

If there is only one candidate, the TSC Chair must issue a “call for objections” to the remaining TSC members. If there is unanimous approval (no objections), then the candidate is elected. If there are one or more objections recorded, the position must be put up for a vote of the Active Contributors according to the rules of normal TSC voting as written in this document.

If more than one candidate is nominated during the open period, the position must be run through the same voting process used during normal periodic TSC elections.

The “call for objections” or the vote must be conducted during a live TSC meeting that has a quorum present or must be conducted over a seven day asynchronous voting period via any messaging or voting system approved for use by OASIS. In a “call for objections,” non-responses shall be considered assent. In a vote, non-responses must be ignored. In the event that the number of TSC Members resigning in the same open period reduces the total number of TSC members to below a quorum from the previous number, then a new full TSC must be elected following the standard procedure for periodic elections.

Project Governance Board

The project governance board (PGB) is organized by OASIS and is accountable for ensuring the balance and integrity of the Ethereum-Oasis initiatives, such as the Baseline Protocol.

Technical Steering Committee

The core of the day-to-day work of the Baseline Protocol community is managed by members and core developers. The Technical Steering Committee (TSC) is here mainly to ensure the smooth running of the core developer team and to be accountable to the Ethereum-Oasis Project Governance Board (and to the community at large).

While it is up to any contributor what one works on, the TSC helps core developers and members by organizing planning and review sessions, roadmapping, and highlighting engineering tasks as high-priority for any given period.

The TSC's members are elected annually in September/October, concluding on the last day of that month, with the first elections held in September, 2020. The period for nominations will be announced no less than 30 days prior to elections. The method and management of the nominating process and the elections will be communicated to the community by the various channels in that timeframe.

Technical Steering Committee 2021/22

The technical steering committee (TSC) is accountable to the Project Governance Board for bootstrapping the core developer group, stepping in to resolve any conflicts on merges or core developers self-organization.

On October 27, 2021, the following people were voted in as the TSC through October 2022 and the date of the next election's results.

Source Code

Packages

One or more "core" baseline protocol packages are needed to baseline-enable applications and systems of record.

Modules & Packages

API

@baseline-protocol/api

Baseline core API package.

Installation

npm install @baseline-protocol/api(npm package soon to be published)

Building

You can build the package locally with npm run build.

Testing

Run the local test suite with npm test.

Baseline JSON-RPC Module

An initial set of JSON-RPC methods have been defined for inclusion in the specification. These methods allow easy interaction with on-chain shield contracts (which contain merkle-tree fragments) and maintain full merkle-trees (along with metadata) in local off-chain storage.

Ethereum clients that support baseline JSON-RPC

Nethermind .NET client
Any client supported by the commit-mgr service. These include:

Interfaces

IBaselineRPC

getCommit(address: string, index: number): Promise<MerkleTreeNode>;
getCommits(address: string, startIndex: number, count: number): Promise<MerkleTreeNode[]>;
getRoot(address: string): Promise<string>;
getProof(address: string, commitIndex: number): Promise<MerkleTreeNode[]>;
getTracked(): Promise<string[]>;
verifyAndPush(sender: string, address: string, proof: number[], publicInputs: string[], commit: string): Promise<string>;
track(address: string): Promise<boolean>;
untrack(address: string): Promise<boolean>;
verify(address: string, root: string, commit: string, siblingPath: MerkleTreeNode[]): Promise<boolean>;;

IRegistry

// workgroups
createWorkgroup(params: object): Promise<any>;
updateWorkgroup(workgroupId: string, params: object): Promise<any>;
fetchWorkgroups(params: object): Promise<any>;
fetchWorkgroupDetails(workgroupId: string): Promise<any>;
fetchWorkgroupOrganizations(workgroupId: string, params: object): Promise<any>;
createWorkgroupOrganization(workgroupId: string, params: object): Promise<any>;
updateWorkgroupOrganization(workgroupId: string, organizationId: string, params: object): Promise<any>;
fetchWorkgroupInvitations(workgroupId: string, params: object): Promise<any>;
fetchWorkgroupUsers(workgroupId: string, params: object): Promise<any>;
createWorkgroupUser(workgroupId: string, params: object): Promise<any>;
updateWorkgroupUser(workgroupId: string, userId: string, params: object): Promise<any>;
deleteWorkgroupUser(workgroupId: string, userId: string): Promise<any>;

// organizations
createOrganization(params: object): Promise<any>;
fetchOrganizations(params: object): Promise<any>;
fetchOrganizationDetails(organizationId: string): Promise<any>;
updateOrganization(organizationId: string, params: object): Promise<any>;

// organization users
fetchOrganizationInvitations(organizationId: string, params: object): Promise<any>;
fetchOrganizationUsers(organizationId: string, params: object): Promise<any>;
inviteOrganizationUser(organizationId: string, params: object): Promise<any>;

IVault

createVault(params: object): Promise<any>;
fetchVaults(params: object): Promise<any>;
fetchVaultKeys(vaultId: string, params: object): Promise<any>;
createVaultKey(vaultId: string, params: object): Promise<any>;
deleteVaultKey(vaultId: string, keyId: string): Promise<any>;
encrypt(vaultId: string, keyId: string, payload: string): Promise<any>;
decrypt(vaultId: string, keyId: string, payload: string): Promise<any>;
signMessage(vaultId: string, keyId: string, msg: string): Promise<any>;
verifySignature(vaultId: string, keyId: string, msg: string, sig: string): Promise<any>;
fetchVaultSecrets(vaultId: string, params: object): Promise<any>;
createVaultSecret(vaultId: string, params: object): Promise<any>;
deleteVaultSecret(vaultId: string, secretId: string): Promise<any>;

Supported Providers & Protocols

The following providers of the Baseline API are available:

Ethers.js - example provider; not yet implemented but included here for illustrative purposes
Provide - BRI-1 reference implementation (see examples/bri-1/base-example)
RPC - generic JSON-RPC provider

Baseline

@baseline-protocol/baseline

The core baseline package provides unified access to internal integration middleware interfaces for systems of record.

Installation

npm install @baseline-protocol/baseline(npm package soon to be published)

Building

You can build the package locally with npm run build.

Testing

Run the local test suite with npm test.

Baseline JSON-RPC Module

Ethereum clients that support baseline JSON-RPC

Nethermind .NET client
Any client supported by the commit-mgr service. These include:

Interfaces

IBaselineRPC

getCommit(address: string, index: number): Promise<MerkleTreeNode>;
getCommits(address: string, startIndex: number, count: number): Promise<MerkleTreeNode[]>;
getRoot(address: string): Promise<string>;
getProof(address: string, commitIndex: number): Promise<MerkleTreeNode[]>;
getTracked(): Promise<string[]>;
verifyAndPush(sender: string, address: string, proof: number[], publicInputs: string[], commit: string): Promise<string>;
track(address: string): Promise<boolean>;
untrack(address: string): Promise<boolean>;
verify(address: string, root: string, commit: string, siblingPath: MerkleTreeNode[]): Promise<boolean>;;

IRegistry

// workgroups
createWorkgroup(params: object): Promise<any>;
updateWorkgroup(workgroupId: string, params: object): Promise<any>;
fetchWorkgroups(params: object): Promise<any>;
fetchWorkgroupDetails(workgroupId: string): Promise<any>;
fetchWorkgroupOrganizations(workgroupId: string, params: object): Promise<any>;
createWorkgroupOrganization(workgroupId: string, params: object): Promise<any>;
updateWorkgroupOrganization(workgroupId: string, organizationId: string, params: object): Promise<any>;
fetchWorkgroupInvitations(workgroupId: string, params: object): Promise<any>;
fetchWorkgroupUsers(workgroupId: string, params: object): Promise<any>;
createWorkgroupUser(workgroupId: string, params: object): Promise<any>;
updateWorkgroupUser(workgroupId: string, userId: string, params: object): Promise<any>;
deleteWorkgroupUser(workgroupId: string, userId: string): Promise<any>;

// organizations
createOrganization(params: object): Promise<any>;
fetchOrganizations(params: object): Promise<any>;
fetchOrganizationDetails(organizationId: string): Promise<any>;
updateOrganization(organizationId: string, params: object): Promise<any>;

// organization users
fetchOrganizationInvitations(organizationId: string, params: object): Promise<any>;
fetchOrganizationUsers(organizationId: string, params: object): Promise<any>;
inviteOrganizationUser(organizationId: string, params: object): Promise<any>;

IVault

createVault(params: object): Promise<any>;
fetchVaults(params: object): Promise<any>;
fetchVaultKeys(vaultId: string, params: object): Promise<any>;
createVaultKey(vaultId: string, params: object): Promise<any>;
deleteVaultKey(vaultId: string, keyId: string): Promise<any>;
encrypt(vaultId: string, keyId: string, payload: string): Promise<any>;
decrypt(vaultId: string, keyId: string, payload: string): Promise<any>;
signMessage(vaultId: string, keyId: string, msg: string): Promise<any>;
verifySignature(vaultId: string, keyId: string, msg: string, sig: string): Promise<any>;
fetchVaultSecrets(vaultId: string, params: object): Promise<any>;
createVaultSecret(vaultId: string, params: object): Promise<any>;
deleteVaultSecret(vaultId: string, secretId: string): Promise<any>;

Supported Providers & Protocols

The following providers of the Baseline API are available:

Ethers.js - example provider; not yet implemented but included here for illustrative purposes
Provide - BRI-1 reference implementation (see examples/bri-1/base-example)
RPC - generic JSON-RPC provider

CCSM

@baseline-protocol/ccsm

The Baseline core CCSM package provides interfaces for general interaction with an underlying mainnet or layer-2 distributed solution.

Installation

npm install @baseline-protocol/ccsm(npm package soon to be published)

Building

You can build the package locally with make. The build compiles the Baseline solidity contracts package and its dependencies using truffle.

Shield

The contracts package includes a generic "shield" contract which enforces on-chain verification of commitments before they are added to the on-chain merkle-tree. The logic encoded into the on-chain "verifier" contract can be custom code or a workgroup can choose to use a generic verifier (i.e. verifier may only require that a commitment is signed by each workgroup member). For convenience, a "VerifierNoop" contract is provided in the contracts package for testing a baseline workflow. The "no-op" verifier will return true for any set of arguments with the proper types.

Standard

Reference Implementations

Connectors

Deprecated Work

SAP/Microsoft Dynamics

⚠️ The "Baseline-SAP-Dynamics" ERP connector codebase is being integrated with this new reference implementation as a result of the v0.1 release.

Baselining Business Process Automation across SAP and Microsoft Dynamics

Stefan Schmidt (Unibright), Kyle Thomas (Provide), Daniel Norkin (Envision Blockchain) May 21, 2020

Introduction

The "Baseline-SAP-Dynamics Demo" shows a setup of different Enterprise Resource Planning Systems ("ERPs") using the Baseline Protocol to establish a common frame of reference on the public Ethereum Mainnet. The demo extends the Radish34 POC, showing a procurement process in a supply chain POC.

The open-source-available code of the development work on this demo evolved out of a Hackathon of the EEA Eminent Integration Taskforce members Unibright and Provide and is being made available alongside the Radish34 example.

What is Baseline?

The Baseline Protocol is an approach to using the public Mainnet as a common frame of reference between systems, including traditional corporate systems of record, any kind of database or state machine, and even different blockchains or DLTs. It is particularly promising as a way to reduce capital expense and other overheads while increasing operational integrity when automating business processes across multiple companies.

The approach is designed to appeal to security and performance-minded technology officers.

You can find all the details on the Baseline Protocol here.

Challenges and Scope of Work

The setting of tasks in the Community Bootstrapping Phase of Baseline roadmap include extraction of concepts out of the Radish34 demo case into the protocol level. This demo therefore wants to extend the Radish34 case by integrating off-chain systems of record, to work out major challenges and provide solutions to them. The learnings should be manifested in a reference implementation that can support standards on the protocol itself.

The Use-case shown in the demo follows this path:

A buyer, using SAP ERP, creates a Request For Proposal and sends it out to 2 of his potential suppliers
One supplier, using a Microsoft Dynamics D365 ERP, receives the Request For Proposal, turning it into a Proposal with different price tiers, and sending it back to the buyer
The buyer receives this Proposal, runs a comparison logic between different received proposals (including those of other suppliers), decides for one specific proposal, creates a corresponding Purchase Order and sends this to the supplier
The supplier receives the Purchase Order and continues the process

The shown use-case does not claim to be complete. For example, no Master Service Agreements are involved, and a productive process would continue with additional steps including Delivery Notes, Invoices and Payments, which not in the scope of this demo.

The participants discovered the following challenges to be addressed indispensably:

Establishing a non-centralized rendezvous point for multiparty business process automation, with such place also providing a solution for automating the setup of a baseline environment for each process participant (here: a supplier or a buyer) on its own infrastructure (i.e., using the participant's own AWS or Microsoft Azure credentials); and
Establishing a minimum domain model, abstracting from the baseline target objects and offering a process oriented entry point for systems of record to integrate; and
Integrating systems of record via a suitable service interface.

The proposed architecture and solutions to these challenges are presented in the next sections.

Architecture Proposal

The main idea is to orchestrate the container environment for each baseline participant in a way it supports the addressing of the mentioned challenges at best.

Baseline itself is a microservice architecture, where the different components of this architecture are residing in docker containers. The existing radish demo applies a UI on top of this architecture to play through the demo case.

The architecture proposal of this demo builds upon the existing microservices, and adds layers to extract communication and integration with baseline towards an external system.

Baseline Containers: The microservices providing the Baseline Protocol and Radish34 use-case, based on this branch in GitHub, including several key fixes (i.e., unwiring cyclic dependencies within the existing Radish34 environment) and enhancements (i.e., point-to-point messaging between parties, use of a generalized circuit for baselining agreements).

Provide Containers: Provide's identity, key management, blockchain and messaging microservice API containers representing the technical entry point and translation layer for data and baseline protocol messages, and the provider of messaging infrastructure leveraged by the Baseline stack for secure point-to-point messaging.

Unibright Proxy: An extraction of the Unibright Connector (a blockchain integration platform), consisting of a simplified, context-related domain model and a RESTful api to integrate off-chain systems.

The actual system of record is integrated by on premise or cloud based integration software in the domain of the respective Operator, leading to the "full stack."

Each role in the process should run its own full-stack, connecting to the standardized Unibright Proxy by way of Shuttle.

Challenge: Automating the setup of a baseline environment for each process participant

Implementing the demo use-case as described and demonstrated herein arguably illustrates levels of technical and operational complexity that would prevent most organizations from successfully applying the Baseline approach to their processes.

A viable rendezvous point where every participant in a multiparty business process can "meet in the middle" to ensure common agreements exists between each party (i.e., agreement on the use-case/solution) and each technical team (i.e., agreement on the protocols, data models, integration points, etc.) is a prerequisite to starting any actual technical integration. Such a rendezvous point can only be considered "viable" if it:

is non-centralized; and
can automate container orchestration across major infrastructure vendors (i.e., AWS and Microsoft Azure); and
it can provide atomicity guarantees across all participants' container runtimes during protocol upgrades (i.e., to ensure forward compatibility and continuity for early adopters)

Shuttle is a bring-your-own-keys rendezvous point enabling turnkey container orchestration and integration across infrastructure vendors. Shuttle de-risks multiparty enterprise "production experiments " using the Baseline Protocol, providing continuity to early adopters of the Baseline approach. Provide is actively contributing to the standards and protocol while commercially supporting Shuttle projects.

The following complexities related to enabling the Baseline Protocol for a multiparty process such as the one illustrated by the Radish34 use-case are addressed by Shuttle as an enterprise rendezvous point:

Infrastructure
- Container Orchestration
  - Security
  - Dependency Graph
- Blockchain
  - HD Wallets / Accounts
  - Meta transaction relay (i.e., enterprise "gas pump")
  - Smart Contracts (i.e., deployment, interaction)
  - Organization Identity / PKI / x509
  - Key material (i.e., for advanced privacy, messaging, zkSNARKs
Baseline Protocol
- Circuit Registry
- Continuity & forward-compatibility (i.e., with rapidly-evolving protocols)
- Point-to-point messaging (i.e., proof receipts, etc.)
- Translation for DTO → Baseline Protocol

Baseline smart contract deployment to Ropsten testnet -- as of today, new projects are automatically subsidized by the Provide platform faucet when transaction broadcasts fail due to insufficient funds on every testnet. This same meta transaction / relay functionality will be helpful to organizations who want to participate in mainnet-enabled business processes in the future but do not want to hold Ether (i.e., when the Baseline Protocol has been deployed to the public Ethereum mainnet).*

Baseline smart contract suite intricacy, as illustrated by the contract-internal CREATE opcodes issued from within the Shuttle deployer contract. This functionality will become a standardized part of the Baseline protocol.*

Container orchestration "work product" -- each organization, using its own AWS/Azure credentials, leverages Shuttle to automate the configuration and deployment of 13 microservice container runtimes to cloud infrastructure under their own auspices. Provide also has capability of supporting this for on-premise deployments via a rack appliance.*

Challenge: Establishing Domain Model and Proxy

As the Baseline Protocol itself is still in its bootstrapping phase, it was not possible to just use a perfectly working "Baseline" endpoint, and feeding it with perfectly designed and standardized data for the use case. To establish a development environment, in which all participants (e.g. distributed software teams) can continue working and are not blocking each other. One solution to this can be a proxy.

A proxy is an intermediate layer that you establish in an integration process. The proxy only consists of simple domain model descriptions and basic operations like "Get List of Objects", "Get Specific Object" or "Create new Specific object". So we created a Domain Model for the procurement use case we wanted to show, and designed basic DTOs ("Data Transfer Objects") for all the object types involved, like RequestForProposals, Proposals, PurchaseOrders and so on. We also generated a service interface for all these DTOs automatically, and an authentication service as well.

The proxy defines the entry point for all integration partners in the use case scenario, agreeing on a common domain model and service layer. Still, every participant runs its own proxy, keeping the decentralised structure in place.

The proxy does not perform any business logic on its own (apart from some basic example mappings to make the first setup easier). The proxy leverages the local Provide stack as a gateway to the Baseline Protocol by way of this open-source NuGet package.

Challenge: Integrating Systems of Record

SAP ERP Integration

To help baselining SAP environments (following the Buyer role in this demo), Unibright configured the Unibright Connector (the integration platform of the Unibright Framework) to integrate and map the SAP models with the proxy automatically.

Object Mapping in the Unibright Connector

SAP Main Navigation Hierarchy for Purchasing Process, incl ME49 -> Price Comparison

Request for Quotation for 2 materials

Quotation to the Request, incl PriceScale referenced to the OrderItem

Resulting Purchase Order for Supplier ("Vendor" 100073)

Using the action Dashboard of the webversion of the Unibright connector to monitor SAP <> Proxy communication

Microsoft Dynamics

To help baselining Dynamics 365 environments, Envision Blockchain built an extension called Radish34 for Dynamics 365 Finance and Operations. While this demo is showing the Dynamics 365 Supplier environment, it's important to note that the Radish34 extension is dually configured to support both roles (Buyer and Supplier). Below is a diagram showing the specific Dynamics 365 Finance and Operation modules used and the objects that are passing through the Radish34 extension.

Radish34 Implementation Flow Chart

After importing the extension, organizations will need to configure parameters to interact with the Unibright Proxy, setup Customer codes, Vendor codes, and setup custom Number sequences (which creates identifiers for Dynamics 365 objects).

Radish34 Parameter Module

Supplier Role

When setting up Customers, you'll need to identify customers using the Customer Setup Module and input the External code used in the Radish Module. The Value is automatically filled out by the proxy.

Customer Setup Module

You can use the Radish34 service operations feature to make periodic or on-demand calls of the UB Proxy and receive RFPs.

Radish34 Service Operations Module

You can use the Sales Quotation module to view, adjust the prices for the items the Buyer is requesting, and send the quotation.

Sales Quotation Module

The Radish 34 Outgoing Proposals module allows you to approve, and send the proposal to the Buyer

Radish34 Outgoing Proposals Module

The Radish 34 Service Operations module will periodically check for incoming purchase orders from the Buyer

Radish34 Service Operations Module (Unchecked for incoming purchase orders)

The Sales Order modules to look at the approved proposal from the Buyer and confirm the sales order

Sales Order module