The 2026-07-29 upstream sweep found drift on the ant-client record on this page that needs a human decision before the page is stamped or rewritten. The verification block is left byte-identical to base on the sweep branch.
Record
docs/sdk/how-to-guides/use-external-signers-for-upload-payments.md:10 — ant-client, 81848a09..6f0c9572
Verification block (unchanged on the sweep branch)
<!-- verification:
source_repo: ant-client
source_ref: main
source_commit: 81848a0900fa9972e9af2d323bf3b49bf8d382aa
verified_date: 2026-07-28
verification_mode: current-merged-truth
-->
Upstream change
ant-client adds a new public error variant Error::MerkleBatchTooLarge { addresses, max_leaves } (ant-core/src/data/error.rs) and wires it into prepare_merkle_batch_external (ant-core/src/data/client/merkle.rs, file.rs). External-signer merkle preparation now refuses any batch larger than one merkle tree can hold — the MAX_LEAVES limit is 256 addresses. The rationale in-source: one prepared external-signer batch is one signature and one payment transaction, and the wallet path's multi-transaction split for oversized uploads has no external-signing equivalent, so the oversized case is refused before any candidate collection or on-chain spend.
Why this is ambiguous rather than a straightforward prose update
This page documents the external-signer merkle flow and the prepare_merkle_batch_external helper (Step 5), but it makes no claim about a batch-size limit today, so nothing rendered is wrong. The new MerkleBatchTooLarge limit is part of the same merkle-batch-payment rework that is mid-rollout and pending economic sign-off (ADR-0008 Proposed; see the payment-model.md manual-review issue). A reviewer should decide whether to add the 256-address external merkle batch limit to this page's "Common errors" or Step 5 prose now, and confirm how the limit surfaces through the antd REST/gRPC merkle prepare path (verified against ant-sdk) versus the ant-core helper directly.
Fingerprint: docs/sdk/how-to-guides/use-external-signers-for-upload-payments.md:10|ant-client|81848a0900fa9972e9af2d323bf3b49bf8d382aa..6f0c957289371cc0b0e766f2c580adc8ecb69074
The 2026-07-29 upstream sweep found drift on the
ant-clientrecord on this page that needs a human decision before the page is stamped or rewritten. The verification block is left byte-identical to base on the sweep branch.Record
docs/sdk/how-to-guides/use-external-signers-for-upload-payments.md:10—ant-client,81848a09..6f0c9572Verification block (unchanged on the sweep branch)
Upstream change
ant-client adds a new public error variant
Error::MerkleBatchTooLarge { addresses, max_leaves }(ant-core/src/data/error.rs) and wires it intoprepare_merkle_batch_external(ant-core/src/data/client/merkle.rs,file.rs). External-signer merkle preparation now refuses any batch larger than one merkle tree can hold — theMAX_LEAVESlimit is 256 addresses. The rationale in-source: one prepared external-signer batch is one signature and one payment transaction, and the wallet path's multi-transaction split for oversized uploads has no external-signing equivalent, so the oversized case is refused before any candidate collection or on-chain spend.Why this is ambiguous rather than a straightforward prose update
This page documents the external-signer merkle flow and the
prepare_merkle_batch_externalhelper (Step 5), but it makes no claim about a batch-size limit today, so nothing rendered is wrong. The newMerkleBatchTooLargelimit is part of the same merkle-batch-payment rework that is mid-rollout and pending economic sign-off (ADR-0008 Proposed; see the payment-model.md manual-review issue). A reviewer should decide whether to add the 256-address external merkle batch limit to this page's "Common errors" or Step 5 prose now, and confirm how the limit surfaces through theantdREST/gRPC merkle prepare path (verified against ant-sdk) versus theant-corehelper directly.Fingerprint: docs/sdk/how-to-guides/use-external-signers-for-upload-payments.md:10|ant-client|81848a0900fa9972e9af2d323bf3b49bf8d382aa..6f0c957289371cc0b0e766f2c580adc8ecb69074