Non-Custodial Sweeps Explained: Architecture and Treasury Safety

If you accept crypto invoices or checkout payments, you eventually face a practical question: money landed at a deposit address — now what? In custodial systems, the processor pools funds and pays you out on schedule. In non-custodial systems, funds sit at addresses derived for each payment until something moves them to your main treasury. That movement is called a sweep, and whether it is truly non-custodial depends entirely on who can sign the transaction and whether the destination can be changed after the fact.

We build Settlematic around non-custodial settlement, and sweeps are one of the most misunderstood pieces of the architecture. This article explains how non-custodial sweeps work across Bitcoin, EVM chains, and Solana; why they differ from custodial payout queues; and what to verify before trusting any vendor's "we never hold your funds" claim. For the regulatory framing, start with what is non-custodial crypto invoicing.

What a sweep is — and what it is not

A sweep is an on-chain transaction that consolidates funds from one or more deposit addresses into a destination wallet the merchant controls. It is not a bank transfer initiated by a payment processor on your behalf. It is not a credit to an account balance that later becomes a withdrawal. It is a blockchain transaction with a from-address, a to-address, and a signature authorizing the move.

In custodial payment processing, the word "sweep" sometimes appears in internal ops documentation — meaning the processor moves customer deposits from hot wallets to cold storage. The merchant is not involved; the processor holds all keys. In non-custodial invoicing, the sweep is the merchant's funds moving from a payment-scoped address to a treasury address, and the critical design constraint is that the platform cannot substitute its own destination.

Confusing the two models is common. A vendor may say "we sweep to your wallet" while meaning "we eventually send you a payout from our balance." The test is simple: between customer payment and treasury arrival, could the platform redirect, freeze, or claim the funds? If yes, you are not in a non-custodial sweep model regardless of marketing language. Review custodial vs non-custodial payment processors for the full contrast.

Why per-invoice deposit addresses exist at all

Non-custodial payment systems assign unique deposit addresses per invoice, checkout session, or payment link. Uniqueness solves reconciliation: when a payment confirms at address N, you know exactly which invoice it satisfies without guessing among shared-wallet deposits.

On Bitcoin, this typically uses BIP-84 hierarchical deterministic derivation from a merchant-provided extended public key (xpub). The platform derives child addresses at indices it allocates transactionally; it never sees the private key. On EVM chains, CREATE2 counterfactual deployment computes deposit addresses from a factory contract and a salt tied to the invoice ID, with the merchant treasury baked into the init code as an immutable destination. Solana and Tron follow analogous patterns with program-derived or counterfactual addresses.

The deposit address is not the merchant's main wallet. It is a payment-scoped receiving point. Sweeps exist because leaving funds scattered across hundreds of deposit addresses is operationally painful — accounting, tax reporting, and treasury management all improve when consolidated. Settlematic Collect derives unique addresses per invoice while binding each to your configured treasury destination.

The non-custodial sweep trust model

Three properties must hold for a sweep to be non-custodial in substance:

Address binding is the property most vendors fail. Many systems generate unique deposit addresses but control the keys to those addresses. Uniqueness aids reconciliation; it does not imply non-custodial settlement. Read our guide on address-bound settlement for the full distinction.

Key separation means the merchant (or the merchant's own hardware wallet, multisig, or signing service) holds signing authority for treasury consolidation — or the sweep contract routes automatically to a pre-committed destination without any platform signature. Permissionless exit means if the platform disappears, funds are not stranded. CREATE2 contracts with immutable destinations satisfy this on EVM; BIP-84 with merchant-held seeds satisfies it on Bitcoin. Settlematic's security model documents how these properties are enforced in production.

Bitcoin sweeps: BIP-84, watch-only derivation, and merchant signing

On Bitcoin, the non-custodial pattern looks like this:

• Merchant connects a BIP-84 account xpub (watch-only) to the invoicing platform.
• Each invoice receives the next derived receive address at m/84'/coin'/0'/0/index.
• Customer pays; the platform detects confirmation via blockchain monitoring.
• Merchant sweeps from the deposit address to treasury using their own wallet software, or an automated sweep service the merchant authorizes.

BIP-84 (native SegWit, bech32 addresses) is the modern standard for Bitcoin invoicing in 2026. It offers lower transaction fees than legacy P2PKH addresses and broad wallet compatibility across Ledger, Trezor, Coldcard, and software wallets. The platform's role is derivation and monitoring — not custody. It never possesses the private key that could spend from the deposit address.

Some platforms offer automated sweep triggers that call into the merchant's connected wallet or a merchant-controlled signing policy; the authorization still originates from the merchant's key material. Operational nuance: UTXO management matters. Each deposit address may hold one or more UTXOs. Sweep transactions must account for fees, change outputs, and confirmation depth. A well-designed non-custodial system surfaces sweep recommendations and UTXO states without holding signing keys.

For confirmation policy before triggering sweeps on large BTC payments, see on-chain payment confirmation. Zero-conf sweeps on high-value invoices invite double-spend exposure that confirmation thresholds mitigate.

EVM sweeps: CREATE2, immutable destinations, and factory integrity

EVM non-custodial sweeps rely on counterfactual contract addresses. At invoice creation, the system computes a deposit address from a factory contract, a salt tied to the invoice ID, and init code that embeds the merchant treasury as an immutable forward destination. The customer sends tokens to that address. The contract may not be deployed yet — CREATE2 guarantees the address is valid and will execute the baked-in logic when deployed.

When a sweep is triggered, the contract deploys (if needed) and forwards tokens to the immutable treasury argument. The platform cannot change the treasury after the address is quoted to the customer. The init code hash is deterministic. This is the EVM equivalent of address binding.

Factory contract integrity is a separate concern. If the factory bytecode changes between deployments, deposit addresses derived from an old factory may not match expectations. Production systems pin factory addresses, verify bytecode hashes at startup, and refuse to operate if the on-chain factory does not match the expected artifact. See true non-custodial crypto invoice platform for why this guard matters.

Gas for sweep transactions is typically paid by the merchant or deducted from the swept amount, depending on product design. Non-custodial platforms do not subsidize gas by holding float. Settlematic Gateway supports EVM settlement across Ethereum, Base, Polygon, Arbitrum, and Optimism with the same binding principles.

Multi-destination and split sweeps

Treasury operations rarely involve a single wallet. Agencies may route 90% to operating treasury and 10% to a partner. Marketplaces split to sellers. DAOs may allocate to a multisig and a contributor wallet. Non-custodial split sweeps encode allocation rules at issuance — not at sweep time.

Settlematic supports merchant-configured sweep destinations and split flows where allocations are committed before payment. The principle is unchanged: whatever the customer pays toward must be knowable from on-chain data and issuance-time configuration, not from a dashboard edit after money arrives. For marketplace-style splits, Gateway exposes multi-destination settlement with webhook reconciliation per recipient.

Auto-sweep vs manual sweep: operational trade-offs

Auto-sweep does not imply custodial behavior if the sweep path is permissionless or merchant-authorized. It implies automation. The custody question remains: who signs, and can the destination change?

For high-volume merchants, auto-sweep with merchant-controlled signing keys (or immutable forwarder contracts) is the operational sweet spot. For low volume, manual sweep from a watch-only wallet may suffice. Test both modes in the demo sandbox before committing mainnet treasury policies.

Treasury safety: threat model and mitigations

Non-custodial sweeps remove platform insolvency risk — your funds are not on the processor's balance sheet — but they do not remove all risk.

Compromised merchant keys. If your treasury seed is stolen, sweeps deliver funds to an attacker. Mitigation: hardware wallets, multisig, separate hot/cold policies. Institutional teams often use a 2-of-3 multisig for operating treasury and cold storage for reserves.

Wrong xpub or treasury address at setup. A misconfigured extended public key derives addresses your wallet does not control. Mitigation: depth and parent-fingerprint validation on xpub import; test invoices on testnet before mainnet. Send a small test payment and verify you can sweep before invoicing clients.

Reorg and confirmation policy. Sweeps should respect confirmation thresholds appropriate to the chain and invoice value. Triggering sweeps on zero-conf for large BTC payments invites double-spend exposure. Ethereum and L2s have different finality assumptions than Bitcoin.

Factory or program drift. On EVM/Solana, deploying new factory versions without migration breaks address predictability. Mitigation: bytecode integrity checks at startup; immutable factory pinning documented in security.

Webhook spoofing. Sweeps are on-chain; webhooks are off-chain. Reconcile sweep completion against chain data, not webhook alone. Our webhooks and reconciliation guide covers signed webhook verification.

Insider threat at the platform. Even without keys, a malicious employee could display a fake treasury address in the UI while binding a different one on-chain — which is why independent verification of on-chain binding matters. Reputable vendors publish factory addresses and derivation schemes for audit.

How non-custodial sweeps compare to custodial payouts

The Celsius bankruptcy case illustrated this distinction brutally: custody-account holders recovered assets; earn-account holders became creditors. Sweep architecture is how non-custodial systems keep you in the custody-account column. Float — the period when custodial processors hold your money — is eliminated entirely when sweeps route directly to wallets you control.

Implementing sweeps in your stack

If you are evaluating or building non-custodial payment flows:

• Document the sweep path for each chain you support — who signs, what contract, what destination.
• Verify address binding with a test payment and attempt to change the treasury in the dashboard after issuance. If it changes, the binding is cosmetic.
• Run testnet end-to-end including sweep. Settlematic's demo supports this without mainnet risk.
• Integrate webhooks for payment.confirmed and sweep.completed events; reconcile both against chain explorers.
• Set confirmation policies per asset and value tier.
• Export sweep records for accounting — each sweep tx hash, timestamp, and amount should map to invoice IDs.

For developers, the Gateway API exposes sweep job status and webhook events so your ERP or accounting system stays in sync without polling block explorers. Idempotent webhook handlers prevent duplicate ledger entries when events retry.

Audit questions for vendors

Ask any crypto invoicing or payment vendor:

• Do you hold private keys to deposit addresses, even temporarily?
• Can the sweep destination be changed after the invoice is created?
• What happens to in-flight funds if your company shuts down tomorrow?
• Is the factory or derivation scheme documented and independently verifiable?
• Do you pass Travel Rule or AML checks by freezing funds you do not custody?
• Who pays gas, and can you subsidize it without holding float?

Honest answers should be: no keys, no post-issuance destination change, funds remain reachable via merchant keys or immutable contracts, yes to documentation, and compliance without custody where structurally possible. Read what non-custodial means in crypto payments for the regulatory framing.

Putting it together

Non-custodial sweeps are the operational bridge between per-payment deposit addresses and a sane treasury. They are not a separate product feature bolted onto custodial rails — they are the consequence of a settlement architecture where the platform watches the chain instead of holding the money.

Treasury safety comes from binding destinations before payment, separating keys from the platform, and ensuring permissionless exit. Sweeps are where that architecture becomes visible in day-to-day operations. Get them right, and platform insolvency, payout freezes, and float risk disappear from your payment stack. Get them wrong, and you have custodial exposure with extra steps.

To see non-custodial invoicing and sweep flows end to end, start with Settlematic Collect, explore Gateway for embedded checkout, or run a test invoice in the free sandbox. Review security documentation before connecting production treasury wallets.

Architecture at a glance