Batch Payments

When to batch#

Payroll or a multi-recipient payment can need several spends. The router submits them in order without taking custody. Each spend carries its own proof and authorization for its inputs and outputs.

You can also use a sequence to combine small notes of one asset into fewer, larger notes. This makes a fragmented balance easier to use for the next payment.

Build the proof sequence#

A later proof can use the root created by an earlier spend in the bundle. Read and authenticate the starting chain state, then calculate each append in order when building those proofs.

Older accepted roots do not make a wrongly calculated future root valid. Refresh chain state before constructing the sequence, and use the recorded output commitments when recovering its result.

Submission and partial progress#

The router can execute its sequence atomically in one EVM transaction. Once you share the bundle, however, anyone who sees it can submit a component proof separately because the Pool accepts each valid spend on its own.

Design every component to be safe on its own. Do not rely on publication forcing the whole bundle to land together. Recovery must identify the components that already executed and those still pending.

Review and recover a batch#

Before proving, show each recipient and amount, the recipient count, total value and controller approvals. Show progress for multiple proof steps, then save the bundle before submitting it.

If submission times out, check the component nullifiers and recovered outputs. Continue only from the steps the chain has not consumed.

• Give the batch one stable operation reference.
• Store each component proof and its transaction hash.
• Check that each spend's inputs use the required asset and controller.
• Recover the final change and the outputs for every recipient.