Docs / Concepts / Non-custodial

Non-custodial.

Settle never takes possession of merchant funds. The router contract sends the merchant's 99.5% directly to the merchant's wallet, in the same transaction the customer signs.

What non-custodial means.

Custodial means a company holds your funds and lets you withdraw them. Stripe is custodial — your sales sit in Stripe’s bank accounts until they pay you out, and the company has the authority to freeze, deduct, or reverse them. Most crypto payment processors are custodial too: they take the customer’s tokens, hold them in a hot wallet, and wire you fiat or transfer crypto on a schedule.

Settle is non-custodial. Funds never enter our wallet. They go from the customer’s wallet, through the router contract, to your wallet — atomically, in one transaction. We could not freeze, deduct, or reverse them even if a court ordered us to, because we never have them.

Where funds live.

Funds live in the wallet whose address you registered. We do not operate that wallet. We do not have its keys. If you registered a Coinbase deposit address, your funds end up in your Coinbase account. If you registered a Ledger address, your funds end up on your Ledger. Same for Phantom, Trezor, Safe multisig, anything that can receive the relevant token.

The 0.5% fee goes to a separate treasury contract on each chain. That contract is governed by a 2-of-3 multisig with a 48-hour public timelock — see Security.

Registering an address.

At signup you register one payout address per chain you want to accept. From the dashboard or from your AI agent over MCP:

MCP
// MCP
register_payout_address({
  chain: "base",
  address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
})
// → returns a challenge string for the merchant to sign with the same wallet

We screen the address against OFAC SDN and Chainalysis sanctions API before accepting it. A hit rejects the registration; this happens at signup time so funds never move. The check is automated and fast (~$0.01 per address, cached). There is no human review.

The signature challenge.

We have to know that the address you registered is yours. The challenge is a short string we generate; you sign it with the same wallet using EIP-191. Submit the signature back:

MCP
// MCP
confirm_payout_address({
  chain: "base",
  address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
  signature: "0x..."
})
// → { verified: true }

Verified addresses are marked verified: true in list_payout_addresses. Until an address is verified we will not route funds to it.

Rotating an address.

You can register a new address at any time. Old invoices keep paying out to whichever address was verified when the invoice was created; new invoices route to the most-recently-verified address for that chain. This is the same model as treating a signed challenge as a durable proof: we never silently change which wallet receives funds.

Trust model.

You have to trust two things and only two things.

  1. The router contract. It is open source, static-analysis-clean (Slither, Mythril, Aderyn — zero findings), owned by a 2-of-3 multisig, and any change goes through a 48-hour public timelock. The verifiable bytecode is the same on every chain.
  2. The Settle frontend that creates invoices. A bug there could mark an invoice as paid before the chain confirmed. We mitigate this by following finality thresholds (see Settlement) and by firing webhooks only after the on-chain event is finalized.

You do not have to trust us with custody. There is no custody.

Was this helpful?