Address-Bound Settlement: Crypto Payment Address Binding Explained

Address-bound settlement means each deposit address is cryptographically derived so that it can only ever settle to a specific wallet you control, fixed at the moment the invoice is issued. The payment provider cannot redirect it — not because of a policy, but because the destination is a property of how the address was created. The provider's only job is to watch the chain, confirm the payment, reconcile it against the invoice, and fire a webhook. It never takes custody.

This is the strictest point on the non-custodial spectrum, and it is how Settlematic works. This article explains the mechanism, why it removes the redirect and freeze risks that other models carry, and where its limits are.

The problem address binding solves

Every crypto gateway needs a way to know which payment belongs to which invoice. The naive approach is one shared wallet address plus a memo — fragile and error-prone. The common approach is a unique deposit address per invoice. The question is: who controls that address?

In a forwarding model, the provider generates an address it controls, funds arrive there, and the provider's software then sweeps or forwards the funds to your wallet. That forwarding step is the vulnerability: it is software the provider controls, so a compromised, coerced, or buggy provider could route your payment somewhere other than your wallet, and there is a moment where the funds sit at a provider-controlled address. Address binding removes that step entirely.

How the binding works

The core idea is deterministic key derivation. Instead of the provider creating and holding a fresh keypair per invoice, each deposit address is derived from a settlement key that you control, using a public, auditable derivation scheme.

• You configure a settlement wallet — typically via an extended public key (xpub) or a settlement address for account-based chains — that the provider stores but for which it never holds the private key.
• For each invoice, the system derives a unique deposit address from that settlement key using hierarchical deterministic derivation (see BIP-32 and, for native SegWit Bitcoin, BIP-84).
• Because the address is derived from your key, the funds sent to it are spendable only by your key. The provider can compute the address (from your public key) but cannot spend from it.
• The mapping from invoice to address is recorded at issuance, so reconciliation is deterministic: a payment to that address is unambiguously this invoice.

The binding is the derivation. There is no separate "destination" field the provider can edit, because the destination is inherent to the address. To settle to a different wallet, you would have to issue an invoice with a different address derived from a different key — a different invoice entirely.

Forwarding vs. binding, side by side

Detection and reconciliation, not custody

If the provider never touches funds, what is it actually for? Everything except custody. Watching each issued address for incoming transactions, waiting for the required number of confirmations (see on-chain payment confirmation), matching the amount against the invoice, handling underpayments and overpayments, and firing a signed webhook so your system can mark the invoice paid. This is the operational layer that makes on-chain payments usable at business scale, delivered without reintroducing custody.

Reconciliation is deterministic precisely because binding is one-to-one: each address maps to exactly one invoice, so there is no ambiguity about which payment cleared which bill. For the webhook and reconciliation mechanics, see crypto payment webhooks and reconciliation.

What address binding protects against — and what it doesn't

Being precise about the security boundary matters:

• Protects against: provider-side redirection of incoming payments, transient provider custody, freeze of settled funds, and loss of your revenue in a provider bankruptcy — there is no provider balance to claw into an estate.
• Does not protect against: loss or theft of your own settlement keys, a compromised address shown to the customer at your own checkout (integration security is yours), or on-chain irreversibility if a customer pays the wrong amount. Those are your responsibility.

In other words, address binding removes the intermediary as a point of failure. It does not remove your obligation to manage keys well — if anything, it concentrates that responsibility on you, which is why key hygiene and cold storage matter more, not less.

How Settlematic uses it

Every Settlematic invoice and checkout deposit address is bound at issuance to a settlement wallet you control, across USDC, USDT, EURC, ETH, and BTC on six chains. We never hold keys, cannot redirect or freeze funds, and only detect confirmations and reconcile them before firing your webhook. See how it works for the end-to-end flow and the security page for the architecture.

The clearest way to understand address binding is to watch it once. Issue a real invoice in the free sandbox, inspect the derived address, and confirm the funds settle straight to your wallet with nothing in between.