Existing version of the cc on the ledger (%s) should be diff

Error message

Existing version of the cc on the ledger (%s) should be different from the upgraded one

What it means

VSCC requires that the version in an UPGRADE transaction differs from the version currently recorded on the ledger. If they are equal, the transaction is rejected, because an upgrade must represent an actual version change; otherwise the rwset would overwrite identical state.

Source

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

			// CONS: this would be a point of non-determinism
			err := vscc.checkInstantiationPolicy(chid, env, pol, payl)
			if err != nil {
				return err
			}

		case lscc.UPGRADE:
			/**************************************************************/
			/* security check 1 - cc in the LCCC table of instantiated cc */
			/**************************************************************/
			if !ccExistsOnLedger {
				return policyErr(fmt.Errorf("Upgrading non-existent chaincode %s", cdsArgs.ChaincodeSpec.ChaincodeId.Name))
			}

			/**********************************************************/
			/* security check 2 - existing cc's version was different */
			/**********************************************************/
			if cdLedger.Version == cdsArgs.ChaincodeSpec.ChaincodeId.Version {
				return policyErr(fmt.Errorf("Existing version of the cc on the ledger (%s) should be different from the upgraded one", cdsArgs.ChaincodeSpec.ChaincodeId.Version))
			}

			/****************************************************************************/
			/* security check 3 validation of rwset (and of collections if enabled) */
			/****************************************************************************/
			// Only in v1.2, a collection can be updated during a chaincode upgrade
			if ac.V1_2Validation() {
				// do extra validation for collections
				err := vscc.validateRWSetAndCollection(lsccrwset, cdRWSet, lsccArgs, lsccFunc, ac, chid)
				if err != nil {
					return err
				}
			} else {
				// there can only be a single ledger write
				if len(lsccrwset.Writes) != 1 {
					return policyErr(fmt.Errorf("LSCC can only issue a single putState upon upgrade"))
				}
			}

View on GitHub (pinned to 2736b63f8f)

Solutions

Increment the chaincode version in the upgrade command (e.g. -v 2.1 instead of 2.0)
Check the current on-ledger version with peer chaincode list -C <channel> and use a different version
Package/install the new version binaries before upgrading so the version actually changes

Example fix

// before
peer chaincode upgrade -C mychannel -n mycc -v 1.0   # ledger already at 1.0
// after
peer chaincode upgrade -C mychannel -n mycc -v 1.1

Defensive patterns

Strategy: validation

Validate before calling

const current = await peer.chaincodeList(channelName);
const c = current.find(cc => cc.name === targetName);
if (c && c.version === newVersion) {
  throw new Error(`Version ${newVersion} already on ledger; increment before upgrade`);
}

Try / catch

try {
  await upgradeContract.submitTransaction(...);
} catch (e) {
  if (String(e).includes('should be different from the upgraded one')) {
    // bump version and retry submit
  }
}

Prevention

Bump the version in every release pipeline automatically (e.g. from git tag)
Compare against peer chaincode list output before submitting
Never reuse a previously committed version string

When it happens

Trigger: Issuing an lscc UPGRADE whose ChaincodeId.Version equals cdLedger.Version for the already-instantiated chaincode.

Common situations: Re-running an upgrade command with the same -v flag after a previous successful upgrade; forgetting to bump the version in chaincode.yaml / the deploy command; CI pipelines re-applying a spec without incrementing the version.

Related errors

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