Public blockchains have a privacy problem that is easy to forget because it is structural: the transparency that makes them auditable also makes them exposed. Every amount, every address, every transfer is visible to anyone. For a payments network handling commercial transactions, that is a non-starter — you cannot run a card business on a ledger where competitors can read your volumes.

US11151558B2, “Zero-knowledge proof payments using blockchain,” granted to American Express Travel Related Services Company on October 19, 2021, applies zero-knowledge proofs to that tension. Classified under G06Q 20/389 with H04L 9/3221 (zero-knowledge), it claims proving a payment is valid without putting the sensitive details on the ledger.

“A zero-knowledge proof purchase system and process using blockchain is disclosed. The system may comprise a customer device, a merchant system, an issuer system, and a blockchain network having a zero-knowledge proof (ZKP) smart contract.”— U.S. Patent No. 11,151,558 source

The independent claim is unusually concrete about the cryptographic plumbing, and it is worth walking. Claim 1 has a blockchain computing device execute a “zero-knowledge proof (ZKP) smart contract” in response to receiving four things from the merchant during payment: a proof, a customer hash, a merchant hash, and a purchase amount. Inside the smart contract, the device runs a “validate function” by feeding it a verification key, the proof, and the customer hash; the function's output is a Boolean. Only if that Boolean passes does the contract adjust the customer's account balance — and a corresponding merchant balance — by the purchase amount, with both balances “maintained on the blockchain network.” The final step writes a success notification “in response to a consensus agreement among a plurality of blockchain computing devices.” So the validation, the balance adjustment, and the settlement record all happen on-chain, gated by a proof rather than by exposed account data.

The dependent claims fill in where the secrets stay hidden. Claim 2 has the customer device generate the proof from a “proof function” that takes a proving key, the customer hash, and a payment hash — and claim 3 specifies the payment hash is itself produced “by inputting customer identifying data and a customer nonce into a hashing algorithm.” Claim 4 attributes the whole scheme to an issuer that runs a “key generator function” on a random number to produce the proving and verification keys — the classic ZKP setup phase. Claims 5 and 7 do the same hashing trick for merchant and customer identities (identifying data plus a nonce), so what lands on the ledger are nonced hashes, not names or card numbers. The identity-to-hash boundary is exactly where the privacy lives.

The right question to ask of any zero-knowledge claim is: what exactly does the verifier learn, and what stays hidden? The whole value is in that boundary. Here the on-chain verifier — the smart contract — learns only a Boolean: the proof checks out against the verification key and the customer hash, or it does not. It never sees the customer's identifying data, only the nonced hash; it never reconstructs the payment hash; and it adjusts balances that are themselves keyed to hashes rather than to legible identities. A well-designed payment proof convinces the network that funds exist, that the payer is authorized, and that no double-spend occurred — while revealing none of the amounts or identities a transparent chain would otherwise broadcast. The claim defines where that line is drawn, and it draws it at the hash-and-Boolean layer.

There is a subtle architectural decision buried in claim 1 that is easy to skim past: the balances themselves live on-chain. The contract “adjusting… a customer account balance associated with the customer hash” and “a merchant account balance associated with the merchant hash,” with both “maintained on the blockchain network,” means settlement is not just proven on-chain and then booked elsewhere — the ledger of value is the blockchain, keyed to hashes. Claims 6 and 8 reinforce this by “writing… the merchant hash and the merchant account balance to the blockchain” and the customer equivalent. That is what makes the privacy claim non-trivial: a transparent ledger would expose those balances and their movements, so the design has to ensure the only legible quantities on-chain are nonced hashes and a Boolean verdict, with the proof carrying the assurance that the adjustment was authorized. The zero-knowledge proof is doing the work that would otherwise require trusting a centralized operator to keep balances honest while hiding them.

This is a recurring and durable Amex theme, not a one-off. The same applicant line carries forward into later grants — the continuation US11748750B2 (zero-knowledge proof payments, September 2023) and the biometric identity-verification grant US11645654B2 (May 2023). Read together, they sketch a deliberate program: prove things about people and payments without exposing the underlying data. The three statutory forms in this single patent — method (claim 1), system (claim 9), and article of manufacture (claim 17), each carrying the same validate-then-adjust-then-notify flow — show the applicant was claiming the construction across every form a competitor might implement it in.

Per the desk's rules: this is an issued grant (B2), not an application; and it is a method claim, not a deployed product. A patent on private blockchain payments does not mean Amex shipped a private blockchain — it means Amex staked the technique.

For the strategy reader, the signal is a major payments incumbent treating privacy-preserving cryptography as core IP, not a research curiosity. The mechanics in the dependent claims — key-generator setup, proof and validate functions, nonced identity hashes, consensus-gated settlement — are textbook zk-payment architecture, claimed end to end. When the assignee is American Express and the continuation chain runs for years, the technology has graduated from interesting to defended.