As we know, a blockchain network is meant to be fully decentralized. Thus, the expansion of participants is a normal thing that we would expect to see in a healthy network.

However, since this is an enterprise-grade network that is subject to rules and regulations, there are things that need to be established upfront during network formation and the on-boarding of new participants:

• Who owns the privilege to invite organizations to the network?
  This should include considerations as to who can submit a proposal to create a new organization, but should also include considerations for channel-level invitation. Are there privacy and confidentiality constraints that will need to be accounted for during the on-boarding?
• What are the minimum security requirements that the organization needs to meet?
  An organization that cannot properly secure their peers would risk exposing their ledger data and compromising their private keys. Dealing with fraudulent transactions would lead to chaos and painful investigation. Clearly articulating the security requirements will help a new participant understand the level of investment they need to make.
• What are the standard contractual agreements that participants should accept?
  As we mentioned in previous chapters, the smart contract should be accepted as the law within the network, but this needs to be bounded by contractual agreements that not only recognize this fact, but also state the expectation of the participant and the dispute processes.
• What are the IT service-level agreements that the participant will need to adhere to?
  As we have seen in Chapter 8, Agility in a Blockchain Network, getting an agreement on the frequency of promotion to smart contracts and the implicit evolution of the integration layer is important. Now this is an example, but from a service-level agreement, there are other aspects, such as availability, performance, and throughput, that can impact the network.

Through the on-boarding process, an organization will need to deploy its own infrastructure, integrate their transactions into their own enterprise system, and complete a round of testing before they can actually start transacting. During their life on the network, the governing body may dictate that some audits should be performed on the participant's infrastructure to demonstrate adherence to the terms and conditions.

A situation that is often overlooked is the event of an organization off-boarding the network. There could be two events that cause this to occur:

• The participant's interest in the network changes and they no longer want to transact
• A breach of contract or a dispute causes the participant to be removed

No matter what the reason is, if there are no provisions for this event, there can be issues related to the ownership of the organization's data. While the transaction data is shared in the context of a legal agreement, the parties may agree to have the distributed ledger stored in everyone's peers, but once that agreement comes to an end, what happens?