Only Endorser Transactions are supported, provided type %d

Error message

Only Endorser Transactions are supported, provided type %d

What it means

Returned by v20 extractValidationArtifacts when the envelope's channel header type is not ENDORSER_TRANSACTION. VSCC in the v20 plugin only validates endorser transactions, so config or other header types are rejected with the observed type number.

Source

Thrown at core/handlers/validation/builtin/v20/validation_logic.go:136

		return nil, err
	}

	// ...and the payload...
	payl, err := protoutil.UnmarshalPayload(env.Payload)
	if err != nil {
		logger.Errorf("VSCC error: GetPayload failed, err %s", err)
		return nil, err
	}

	chdr, err := protoutil.UnmarshalChannelHeader(payl.Header.ChannelHeader)
	if err != nil {
		return nil, err
	}

	// validate the payload type
	if common.HeaderType(chdr.Type) != common.HeaderType_ENDORSER_TRANSACTION {
		logger.Errorf("Only Endorser Transactions are supported, provided type %d", chdr.Type)
		err = fmt.Errorf("Only Endorser Transactions are supported, provided type %d", chdr.Type)
		return nil, err
	}

	// ...and the transaction...
	tx, err := protoutil.UnmarshalTransaction(payl.Data)
	if err != nil {
		logger.Errorf("VSCC error: GetTransaction failed, err %s", err)
		return nil, err
	}

	cap, err := protoutil.UnmarshalChaincodeActionPayload(tx.Actions[actionPosition].Payload)
	if err != nil {
		logger.Errorf("VSCC error: GetChaincodeActionPayload failed, err %s", err)
		return nil, err
	}

	pRespPayload, err := protoutil.UnmarshalProposalResponsePayload(cap.Action.ProposalResponsePayload)
	if err != nil {

View on GitHub (pinned to 2736b63f8f)

Solutions

Route only endorser transactions to this validator
Fix clients submitting wrong transaction types

Example fix

// before
env := &common.Envelope{Payload: configPayloadBytes} // wrong type routed to tx validator
// after
if common.HeaderType(chdr.Type) != common.HeaderType_ENDORSER_TRANSACTION {
    // route to config validation instead of validateTx
}
env := &common.Envelope{Payload: endorserTxPayloadBytes}

Defensive patterns

Strategy: validation

Validate before calling

func isEndorserTx(env *common.Envelope) bool {
    payload := &common.Payload{}
    if proto.Unmarshal(env.Payload, payload) != nil { return false }
    chdr := &common.ChannelHeader{}
    if proto.Unmarshal(payload.Header.ChannelHeader, chdr) != nil { return false }
    return common.HeaderType(chdr.Type) == common.HeaderType_ENDORSER_TRANSACTION
}

Type guard

func isEndorserTxType(t int32) bool {
    return common.HeaderType(t) == common.HeaderType_ENDORSER_TRANSACTION
}

Try / catch

artifacts, err := extractValidationArtifacts(bytes, policy)
if err != nil {
    if strings.HasPrefix(err.Error(), "Only Endorser Transactions are supported") {
        return nil, validationerrors.InvalidTxType // route to config validation
    }
    return nil, err
}

Prevention

Route CONFIG/CONFIG_UPDATE envelopes to config validation, never to tx validation
Set HeaderType explicitly when building envelopes in tests/tools
Decode and log the channel header on rejection for diagnosis
Keep tx producers on supported Fabric SDKs

When it happens

Trigger: A block envelope submitted to the v2.0 validator contains a payload of another header type (CONFIG, CONFIG_UPDATE, PEER_RESOURCE_UPDATE, or a fabricated type number) instead of an endorser transaction.

Common situations: A malformed or hostile transaction enters a block; tooling writing blocks directly (test harnesses, snapshot replay tools) mixes config envelopes into tx blocks; version mismatches where the tx type field was corrupted.

Related errors

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