Permissioned blockchains have an endorsement problem that public chains do not. In an endorsement model — the architecture behind IBM's Hyperledger Fabric work — a transaction is not valid until designated endorser nodes sign off on it. The natural way to prove the transaction was endorsed is to record the endorsements. But the endorsements themselves can leak who endorsed what, and how, which is exactly the kind of business-sensitive metadata a consortium chain is supposed to protect. US11,323,243, granted to International Business Machines Corporation on May 3, 2022, claims a way out: prove the endorsement happened without writing the endorsements down.

Claim 1 is written as a sequence, and the verbs matter. The system receives responses to a storage request from one or more endorser nodes; it extracts the transaction data carried in those responses; it generates a zero-knowledge proof of endorsement from that extracted data and the responses; and it transmits the proof — not the raw endorser responses — to a blockchain node for inclusion in a data block.

An example operation may include one or more of receiving one or more responses to a storage request for a blockchain from one or more endorser nodes of the blockchain, extracting transaction data of the storage request included in the one or more responses, generating a zero-knowledge proof of endorsement based on the extracted transaction data and the one or more responses, and transmitting the zero-knowledge proof to a blockchain node for inclusion within a data block among a hash-linked chain of data blocks.

The limitation that matters is the substitution. What gets committed to the hash-linked chain is the proof of endorsement, a compact zero-knowledge artifact, in place of the endorsements themselves. A downstream node can verify the proof — and on verifying it, store the request in a data block — without ever seeing which endorsers responded or what they signed. The dependent disclosure confirms the validation half: the storage request is committed only in response to determining the zero-knowledge proof is valid.

For scope, two boundaries are worth drawing. First, this is not a claim on zero-knowledge proofs in blockchains writ large — that field is enormous, with hundreds of grants spanning payments, identity, and rollups. The claim is specifically about proving endorsement, which is a permissioned-chain construct. A ZK system that proves a payment balance, or a credential, or a rollup state transition, is in a different lane entirely. Second, the extraction step is doing real limiting work: the proof is built on transaction data extracted from endorser responses, tying the claimed method to the endorse-then-prove pipeline rather than to any generic proof-of-validity.

The CPC tags are coherent with that: H04L 9/3218 is the zero-knowledge-protocol class, H04L 9/0637 and H04L 9/0643 cover block-chaining and hashing, and H04L 2209/38 is the blockchain application tag. Notably this grant predates the consolidated H04L 9/50 blockchain class becoming standard, which is consistent with its 2022 issue date — a small reminder that classification drift matters when you are counting an estate by CPC.

It is worth being precise about what privacy this actually buys, because zero-knowledge framing invites over-reading. The proof of endorsement does not necessarily hide the transaction payload — the transaction data is extracted and used to build the proof, and what gets stored may still record that a valid storage request occurred. What the construction hides is the endorsement metadata: which endorser nodes responded, the shape of their signatures, and the policy that was satisfied. In a consortium chain where the identity of endorsers can itself reveal commercial relationships — who vouches for whom — that is a meaningful disclosure to suppress. The claim's value is specific to that metadata-leakage problem, which is exactly why it is scoped to endorsement rather than to confidentiality in general.

The verification half of the construction is also load-bearing for scope. A proof that no node ever checks is useless, so the disclosure pairs proof generation with a verification step that gates commitment: the request is stored only if the proof is determined valid. An accused system that produces a zero-knowledge artifact but does not condition block inclusion on its verification is doing something the claim does not require, and conversely a system that proves and verifies endorsement in this way is squarely inside it. Reading the generate-and-verify pair together is how you keep the scope honest — the patent is a closed loop, not a one-sided proof generator.

This is a characteristic IBM filing in both subject and posture. IBM holds the largest distributed-ledger patent estate by a wide margin, and much of it clusters exactly here: permissioned-chain mechanics, privacy-preserving constructs for consortium settings, and Hyperledger-adjacent infrastructure. The named inventors — Yanyan Hu, Yuan Yuan, Shengjiao Cao, and Angelo De Caro — are working the privacy layer of enterprise blockchain, and this grant is one node in that dense thicket.

The disciplined read: the grant is genuine and the construction is specific and clever, but it does not give IBM a fence around “ZK on chain.” It gives IBM a fence around proving endorsement in zero knowledge and committing that proof instead of the endorsements. Whether a competing privacy scheme infringes turns on whether it proves endorsement from endorser responses, not merely whether it uses a zero-knowledge proof somewhere on a ledger. Read the claim before crediting any broader “IBM owns ZK blockchain” framing; the canonical record is deep-linked above.