ChainLaunch
Pro Feature

Governance & Policies

Multi-org governance proposals, signature collection, and automated policy enforcement require ChainLaunch Pro. The single-instance policy editing covered…

ChainLaunch Pro Feature

Multi-org governance proposals, signature collection, and automated policy enforcement require ChainLaunch Pro. The single-instance policy editing covered below works in core. Learn more about Pro features.

How to manage channel governance, organization policies, and consortium rules in Fabric networks. For multi-instance proposal flows (drafted by one org, signed by others), see Pro Sharing.

Channel Policies

Every Fabric channel has policies that control who can read, write, and administer the channel. ChainLaunch lets you view and modify these policies.

Default Policies

When you create a channel, these default policies are applied:

Policy Default Rule Controls
Readers ANY member of any org Who can query the ledger
Writers ANY member of any org Who can submit transactions
Admins MAJORITY of org admins Who can modify channel config
LifecycleEndorsement MAJORITY of orgs Who must approve chaincode
Endorsement MAJORITY of orgs Who must endorse transactions

View Current Policies

curl http://localhost:8100/api/v1/networks/{networkId}/channels/{channelName}/config \
  | jq '.channel_group.policies'

Modify Policies

See Update Channel for step-by-step policy modification.

Organization Governance

Adding an Organization

Adding a new org to a consortium requires approval from existing members:

  1. The new org creates their ChainLaunch instance and creates their organization
  2. An existing admin updates the channel to add the new org
  3. A majority of existing org admins must sign the config update
  4. Once approved, the new org's peers can join the channel

Removing an Organization

Removing an org follows the same approval process:

  1. An admin proposes removing the org from the channel config
  2. Majority of remaining org admins must approve
  3. The org's peers are disconnected from the channel
  4. The org's data on the ledger remains (immutable)

Warning

Removing an org does not delete their historical data from the ledger. All past transactions remain visible to remaining channel members.

Chaincode Lifecycle Governance

Fabric's chaincode lifecycle ensures all organizations agree on which smart contracts run on the channel.

Approval Flow

Define chaincode → Install on peers → Approve per org → Commit to channel
  1. Define: Package the chaincode with a label and version
  2. Install: Each org installs the package on their peers
  3. Approve: Each org's admin approves the chaincode definition
  4. Commit: Once majority approve, any org can commit to the channel

The LifecycleEndorsement policy controls how many orgs must approve (default: MAJORITY).

Upgrade Chaincode

To upgrade chaincode, re-run the install command — chainlaunch fabric install queries the committed definition, detects that the bytes or policy changed, and bumps the sequence number automatically before approving and committing:

chainlaunch fabric install \
  --chaincode mycc \
  --channel mychannel \
  --policy "OR('Org1MSP.member','Org2MSP.member')" \
  --config ./network-config-org1.yaml \
  --config ./network-config-org2.yaml \
  --organizations Org1MSP \
  --organizations Org2MSP \
  --users admin \
  --users admin \
  --chaincodeAddress localhost:9999

For step-by-step lifecycle control (install only, approve only, commit only), use the API or the web UI Chaincode wizard — see Deploy Chaincode.

Orderer Governance

Orderer Policies

The ordering service has its own policies:

Policy Default Controls
Readers ANY member Who can fetch blocks
Writers ANY member Who can broadcast transactions
Admins MAJORITY of orderer org admins Who can modify orderer config
BlockValidation ANY orderer org member Who can validate blocks

Adding/Removing Orderer Nodes

To add a new orderer (consenter) to a Raft cluster:

  1. Create the orderer node in ChainLaunch
  2. Update the channel config to add the new consenter
  3. The new orderer syncs the ledger and joins consensus

Tip

Add orderers one at a time and verify they've caught up before adding the next. Adding multiple orderers simultaneously can destabilize Raft consensus.

Consortium Management Best Practices

  1. Document governance rules — agree on policies before creating the network
  2. Use MAJORITY policies — prevents any single org from making unilateral changes
  3. Separate orderer org — consider a neutral orderer organization for the ordering service
  4. Regular policy reviews — audit channel policies quarterly
  5. Test policy changes in dev — always test config updates on a dev network first

Next Steps