What causes "invalid chaincode deployment spec" in hyperledger/fabric?

Construct a valid *peer.ChaincodeDeploymentSpec (e.g. via container/NewCCDeploymentSpec or by unmarshalling proto bytes) before calling

hyperledger/fabric · error

invalid chaincode deployment spec

Error message

invalid chaincode deployment spec

What it means

OwnerCreateSignedCCDepSpec builds a signed chaincode deployment package from a ChaincodeDeploymentSpec. It throws this when the cds argument is nil, since there is nothing to package or endorse. It is a fail-fast guard before any marshalling or signing occurs.

Source

Thrown at core/common/ccpackage/ccpackage.go:163

			}

		} else if err = ValidateCip(baseCip, cip); err != nil {
			return nil, err
		}

		if endorsementExists {
			endorsements[n] = cip.OwnerEndorsements[0]
		}
	}

	return createSignedCCDepSpec(baseCip.ChaincodeDeploymentSpec, baseCip.InstantiationPolicy, endorsements)
}

// OwnerCreateSignedCCDepSpec creates a package from a ChaincodeDeploymentSpec and
// optionally endorses it
func OwnerCreateSignedCCDepSpec(cds *peer.ChaincodeDeploymentSpec, instPolicy *common.SignaturePolicyEnvelope, owner identity.SignerSerializer) (*common.Envelope, error) {
	if cds == nil {
		return nil, errors.New("invalid chaincode deployment spec")
	}

	if instPolicy == nil {
		return nil, errors.New("must provide an instantiation policy")
	}

	cdsbytes := protoutil.MarshalOrPanic(cds)

	instpolicybytes := protoutil.MarshalOrPanic(instPolicy)

	var endorsements []*peer.Endorsement
	// it is not mandatory (at this protoutil level) to have a signature
	// this is especially convenient during dev/test
	// it may be necessary to enforce it via a policy at a higher level
	if owner != nil {
		// serialize the signing identity
		endorser, err := owner.Serialize()
		if err != nil {

View on GitHub (pinned to 2736b63f8f)

Solutions

Construct a valid *peer.ChaincodeDeploymentSpec (e.g. via container/NewCCDeploymentSpec or by unmarshalling proto bytes) before calling
Check cds != nil (and that its ChaincodeSpec is populated) before invoking OwnerCreateSignedCCDepSpec
If the spec came from unmarshalling, check the unmarshal error first instead of proceeding with a nil result

Example fix

// before
env, err := ccpackage.OwnerCreateSignedCCDepSpec(cds, instPolicy, signer)
// after
if cds == nil || cds.ChaincodeSpec == nil {
    return errors.New("chaincode deployment spec must be constructed before signing")
}
env, err := ccpackage.OwnerCreateSignedCCDepSpec(cds, instPolicy, signer)

Defensive patterns

Strategy: validation

Validate before calling

if cds == nil || cds.ChaincodeSpec == nil {
    return errors.New("chaincode deployment spec must be built before creating signed package")
}
env, err := ccpackage.OwnerCreateSignedCCDepSpec(cds, instPolicy, owner)

Type guard

func isCDSValid(cds *peer.ChaincodeDeploymentSpec) bool {
    return cds != nil && cds.ChaincodeSpec != nil && cds.ChaincodeSpec.ChaincodeId != nil
}

Try / catch

env, err := ccpackage.OwnerCreateSignedCCDepSpec(cds, instPolicy, owner)
if err != nil {
    if err.Error() == "invalid chaincode deployment spec" {
        return fmt.Errorf("caller bug: nil CDS: %w", err)
    }
    return err
}

Prevention

Always construct the CDS through proto unmarshal helpers and check their errors
Assert non-nil spec in unit tests before signing
Never forward the result of an unmarshal that may return (nil, nil-ish state) without checking

When it happens

Trigger: Calling OwnerCreateSignedCCDepSpec(nil, instPolicy, owner), or passing a variable that was never populated by GetChaincodeDeploymentSpec/UnmarshalCDS (e.g. a failed or skipped spec parse left nil).

Common situations: Parsing a malformed chaincode install/instantiate payload where unmarshalling failed silently and the nil spec was forwarded; CLI or SDK callers building a SignedCDS without constructing the inner ChaincodeDeploymentSpec; tests that forgot to create a spec fixture.

Related errors

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