Non-custodial is a ladder, not a label.

On-chain, money moves when a valid signature is presented, and only the private key can produce one. So the entire question of custody is: where does that key live, and who can use it? Everything else — balances, dashboards, statements — is bookkeeping on top of that one fact.

The two arrangements

In a custodial arrangement you send money to a platform. The platform holds the key, pools your coins with everyone else's, and shows you a number. That number is a liability on their books: a promise, not possession. When you withdraw, you are asking them to keep the promise.

In a non-custodial arrangement the key stays on your side. The platform can find markets, calculate an order and prepare an exact transaction — but it needs your signature to make anything happen, and it cannot produce one.

The three ways custody fails are not hypothetical, and they are all consequences of the same fact rather than of anyone's bad character:

• They can freeze it, because the balance is an entry they control. Disputes, compliance reviews, or simply a policy change apply to your money while they hold it.
• They can become insolvent while holding it. A pooled balance makes you an unsecured creditor, not an owner, and creditors are paid in an order you don't set.
• They are one target. A single set of keys controlling everyone's funds is worth attacking in a way that a thousand individual wallets is not.

The compensating advantage is real and worth naming: a custodian can reverse mistakes, restore access when you lose your password, and absorb an error that would otherwise be permanent. Self-custody trades that away.

The ladder, because "non-custodial" is used for four different things

The word gets applied to arrangements with very different security properties. The useful question is not "is it non-custodial?" but "if the web page I'm looking at were compromised tomorrow, what could it take?"

Rung three deserves a sentence of explanation, because it is the one most people have never had described. Browsers enforce the same-origin policy: code served from one origin cannot read the storage or the memory of another. If the signing code lives on its own origin and the app talks to it only by passing messages, then a compromised app can request a signature — it can even request a malicious one — but it cannot read the key, and it cannot sign anything you don't approve. The wall is enforced by the browser, which is why it holds even when the site's own promises don't.

Which is also the limit of rung three: it converts a theft into a lie. An attacker who owns the app can no longer take the key, so instead they show you a transaction that looks like one thing and is another. Everything then depends on whether the approval screen decodes the transaction from the exact payload it is about to sign, or just repeats a description the app handed it.

What self-custody costs you

This is the part that marketing pages skip. Moving the key to your side moves the responsibility with it.

• There is no reset. Nobody can restore a password they never had or decrypt ciphertext they can't read. If you lose every way of unlocking the key, the funds are not frozen — they are gone, permanently, and they remain visible on-chain forever as a reminder.
• There is no reversal. A transaction sent to the wrong address or approved in error is final. There is no chargeback and no support queue.
• Approval only protects you if you read it. A signing prompt you click through is exactly as safe as handing over the key, and attackers know that clicking through is the default behaviour.
• You need more than one way in. One password on one device is a single point of failure with no backup. Multiple unlock methods — a second device, a passkey, a written-down recovery — turn a lost phone into an inconvenience instead of a loss.

Where the line really sits, in practice

Almost no product is purely one thing, and the honest reason is worth stating plainly: anything that acts while you are asleep needs a key that can act without you. Automated strategies, copy-trading, scheduled orders, "set and forget" hedging — all of them require either a key held somewhere that isn't your pocket, or a delegated permission that behaves like one.

That does not make such features bad. It makes them a different arrangement, and the questions change accordingly: what is the acting key allowed to do, is it scoped to specific contracts and amounts, does it expire, can you revoke it in one action, and how much is behind it. A product that describes itself as non-custodial while running automation on your behalf is telling you about one part of itself. Ask which part.

The five questions that test any custody claim

1. Where does the signing code run? If it is the same origin as the app, the app can read the key. A separate origin, an extension, or a hardware device is a materially different answer.
2. Is that code open, and does the deployed version match it? Open source alone proves nothing about the bytes actually served. What proves it is a build you can reproduce and a hash manifest you can check against the live site — with the reference manifest coming from your checkout, not from the site being tested.
3. What does the approval screen show? It should decode the recipient, amount and asset from the payload it is about to sign, and show the raw payload on request. If it displays a friendly description supplied by the app, it is showing you the app's word.
4. What does the server hold? Ciphertext it cannot decrypt is fine. Key material, seed phrases, or a password that reaches the server at all is not.
5. Can you leave? Export the key and spend the funds with software that has nothing to do with the platform. If that is impossible, then whatever the label says, you cannot act alone — and acting alone is the whole point.

Question five is the one that settles arguments. Everything above it is evidence; that one is a test you can actually run.