hyperledger/fabric · error

chaincode instantiation policy violated, error %s

Error message

chaincode instantiation policy violated, error %s

What it means

The instantiation policy is evaluated against the transaction's creator/endorser signatures. If policyEvaluator.Evaluate returns an error — the endorsements do not satisfy the policy — the transaction is rejected with this message. This enforces that only principals authorized by the chaincode's instantiation policy may deploy/upgrade it.

Source

Thrown at core/handlers/validation/builtin/v13/lscc_validation_logic.go:54

}

// checkInstantiationPolicy evaluates an instantiation policy against a signed proposal
func (vscc *Validator) checkInstantiationPolicy(chainName string, env *common.Envelope, instantiationPolicy []byte, payl *common.Payload) commonerrors.TxValidationError {
	// get the signature header
	shdr, err := protoutil.UnmarshalSignatureHeader(payl.Header.SignatureHeader)
	if err != nil {
		return policyErr(err)
	}

	// construct signed data we can evaluate the instantiation policy against
	sd := []*protoutil.SignedData{{
		Data:      env.Payload,
		Identity:  shdr.Creator,
		Signature: env.Signature,
	}}
	err = vscc.policyEvaluator.Evaluate(instantiationPolicy, sd)
	if err != nil {
		return policyErr(fmt.Errorf("chaincode instantiation policy violated, error %s", err))
	}
	return nil
}

func validateNewCollectionConfigs(newCollectionConfigs []*pb.CollectionConfig) error {
	newCollectionsMap := make(map[string]bool, len(newCollectionConfigs))
	// Process each collection config from a set of collection configs
	for _, newCollectionConfig := range newCollectionConfigs {

		newCollection := newCollectionConfig.GetStaticCollectionConfig()
		if newCollection == nil {
			return errors.New("unknown collection configuration type")
		}

		// Ensure that there are no duplicate collection names
		collectionName := newCollection.GetName()

		if err := validateCollectionName(collectionName); err != nil {

View on GitHub (pinned to 2736b63f8f)

Solutions

  1. Ensure the transaction is endorsed by identities satisfying the recorded instantiation policy (correct orgs/roles)
  2. Renew or update enrollment certificates if the admin certs expired or rotated
  3. If the policy is stale, have an authorized principal perform the upgrade with valid endorsements, or redeploy with a corrected policy

Example fix

// before
peer chaincode invoke ... -C mychannel -n mycc (endorsed only by Org2, policy requires Org1)
// after
collect endorsements from Org1 peers required by the instantiation policy before submitting
Defensive patterns

Strategy: try-catch

Validate before calling

const endorsers = tx.endorsements.map(e => e.mspid);
const satisfied = policyOrgs.some(org => endorsers.includes(org));
if (!satisfied) {
  throw new Error(`Endorsements ${endorsers} do not satisfy instantiation policy orgs ${policyOrgs}`);
}

Try / catch

try {
  await upgradeContract.submitTransaction(...);
} catch (e) {
  if (String(e).includes('instantiation policy violated')) {
    // collect endorsements from the required orgs and resubmit
  }
}

Prevention

When it happens

Trigger: An lscc deploy/upgrade transaction whose endorsements fail to satisfy the chaincode's instantiation policy during checkInstantiationPolicy evaluation.

Common situations: Endorsing with identities outside the orgs listed in the instantiation policy (e.g. default 'ANY of Peers of Orgs...' vs actual endorsers); expired/revoked admin certificates; MSP reconfiguration after the policy was written; using a member/admin signature mismatch.

Related errors


AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04). Data as JSON: /api/errors/5c45ea513833ab3c. Report an issue: GitHub.