Non-custodial sweeps explained: architecture and operations

Custodial payment processors simplify UX at the cost of counterparty risk. You send funds to their balance sheet; they credit your account; you trust their security, solvency, and withdrawal policy. Settlematic takes a different path: derive unique deposit addresses per invoice, detect payments on-chain, then sweep to destinations you configure — we orchestrate movement but never hold your treasury keys.

Address derivation, not pooled wallets

Each invoice receives fresh deposit addresses per enabled asset and network. Reconciliation is deterministic: one expected address maps to one invoice ID. Privacy improves because clients cannot inspect your entire payment history on a single static merchant address.

Derivation follows BIP-44-style hierarchical paths scoped per invoice. The master seed material lives on worker processes isolated from the public API tier. API servers handle authentication, business logic, and read models; they do not sign transactions or hold seeds.

Detection, confirmations, and state machine

When a client broadcasts a transaction, workers index the relevant chain family and match outputs to open invoices. Status progresses through waiting, detected, confirming, confirmed, underpaid, and overpaid — each transition is visible on both merchant and client views.

• Detected: transaction seen in mempool or first block
• Confirming: accumulating confirmations per network policy
• Confirmed: threshold met; balance due updated; sweep eligible
• Underpaid / overpaid: partial payment enabled per invoice settings

Confirmation thresholds differ by asset and network risk profile. Bitcoin may require more confirmations than a fast-finality L2 stablecoin transfer. Finance configures policy; engineering does not patch scripts per client.

Worker isolation and blast radius

Master seeds live on worker processes, not the API tier that faces the internet. Redis queues connect detection jobs, confirmation counters, and sweep execution. If the API layer is compromised, keys are not on the box. If a worker is compromised, scope is limited to queue consumers and network egress policies you define.

This split mirrors how mature payment stacks separate card data environments from business logic. On-chain settlement deserves the same discipline.

Sweep destinations and percentage splits

After confirmation thresholds are met, sweeps execute to labeled destinations you define per asset and network. Split 80% cold multisig / 20% operational hot wallet, or route everything to an exchange deposit address — finance sets policy in the dashboard.

• Labeled destinations per chain and asset
• Percentage weights that must sum to 100%
• Cooldown window on destination changes to reduce hijack risk during account compromise
• Optional conversion flows (swap, bridge) before final sweep

Why non-custodial matters for merchants

When a processor holds funds, you inherit their security posture and withdrawal delays. Settlematic's model keeps settlement on-chain under wallets you control. We provide detection and orchestration — not a pooled balance you must trust for treasury.

DAOs, agencies, and SaaS companies increasingly treat on-chain receipts as operating revenue. Non-custodial sweeps let treasury policy live in configuration, not in someone's manual transfer script.

Operational checklist before mainnet

• Verify sweep destinations on testnet with fake funds
• Confirm explorer links on payment pages match expected networks
• Document who in your org can edit sweep settings
• Run a partial payment test if you enable that feature
• Validate webhook delivery for payment.confirmed before ERP sync

Fifteen minutes of staging on testnet prevents expensive mainnet misconfiguration. Settlematic's org-wide network toggle uses the same UI and state machine — only chain IDs and explorers change.