hyperledger/fabric · error · VSCCEndorsementPolicyError

chaincode instantiation policy violated, error %s

Error message

chaincode instantiation policy violated, error %s

What it means

For lscc invocations, VSCC additionally evaluates the chaincode's instantiation policy against the transaction creator's signed data. If the creator's signature set does not satisfy that policy, the transaction is rejected with this message. It prevents unauthorized users from deploying or upgrading chaincode on a channel.

Source

Thrown at core/handlers/validation/builtin/v12/validation_logic.go:197

}

// 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. Deploy/instantiate the chaincode with an identity that satisfies the instantiation policy (typically an admin of the required org)
2. Set a correct instantiation policy at chaincode install/deploy time matching who should be allowed to deploy
3. Verify the creator's MSP membership/role (admin vs member) is as expected in the channel config

Example fix

// before
// deploy signed by a regular member of Org1, policy requires Admin
signer = orgMemberIdentity
// after
signer = orgAdminIdentity // satisfies chaincode instantiation policy

// verify deployer identity is permitted before instantiating chaincode
if !isChannelAdminOrAllowedByInstantiationPolicy(creatorIdentity) {
    return errors.New("creator does not satisfy chaincode instantiation policy")
}

When it happens

Trigger: Deploying or upgrading (lscc deploy/upgrade) a chaincode whose creator is not a member/admin per the stored instantiation policy; invoking ValidateLSCCInvocation with a transaction signed by an identity the instantiation policy rejects.

Common situations: A user from an organization outside the instantiation policy attempting to instantiate chaincode; instantiation policy left at its default (e.g. requiring a specific org admin) while deployment is attempted by a regular member; certificate/MSP changes that alter the creator identity's role.

Related errors

• no instantiation policy was specified
• No instantiation policy was specified
• no instantiation policy was specified
• Instantiation policy mismatch for cc %s
• instantiation policy cannot be nil for a SignedCCDeploymentS

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