Non-custodial answers the wrong question
A privacy option built into a swap interface gets filed under custody. Nobody else holds the coins, the wallet signs for itself, and the question a reader is invited to ask is whether the assets can be taken. On those terms the answer is reassuring, and most people stop there.
The answer is also correct. A proposal now open for comment in Uniswap governance keeps every key where it was, and in the same document describes a party that decides whether a trade happens at all. Those are two questions wearing one label.
Custody and permission are different questions
The proposal comes from a privacy infrastructure provider offering to sit behind an optional route in the interface. Its custody position is unambiguous: the provider never holds, sees or controls a private key, and the wallet stays under its owner’s control throughout.
Its permission position is equally unambiguous and points the other way. Screening for sanctions and money laundering runs before a transaction is authorised, and a request that fails cannot proceed. The document describes that refusal as absolute, with no override and no way around it.
Both can be true because they answer different questions. Custody asks who can take the asset. Permission asks who can refuse the transaction. Non-custodial is not an answer about permission; it is an answer about possession.
The gate sits before the trade, not after it
Order matters more than the existence of the gate. In the flow the proposal sets out, screening runs at the third step of eight, before the asset conversion executes against Uniswap liquidity. A refusal therefore produces nothing: no transaction, no partial fill, nothing on a public ledger to point at later.
That is the better of the two available designs, and it is worth granting plainly. A control that stops a trade before it starts is kinder than one that seizes an output after settlement.
It also means the refusal is invisible. A trade that never existed leaves no artefact, no counterparty to query and nothing that reads as an event. The absence of a bad outcome and the absence of any outcome look identical from the wallet.
Between execution and settlement the assets are elsewhere
The swap itself is ordinary. It executes against the same liquidity as any other trade, and the proposal is explicit that the privacy path changes nothing for people who never select it.
What follows the swap is not ordinary. The output leaves for the provider’s routing infrastructure, and settlement to the destination wallet comes out of accounts the provider funds in advance, which is what keeps the path down to a couple of minutes rather than a queue.
The duration is not the interesting part. The dependency is. For that window the holder is owed a settlement rather than holding a balance, which is the same structure as an exchange being briefly unreachable, only shorter and voluntary.
A refusal has no stated route back
The proposal is candid about which of its assurances are documents rather than published facts. Independent security reviews are named with the reports available on request, the legal opinion is available to delegates who ask, and the single market-size figure is labelled by its own authors as an internal estimate. None of that is checkable from the page.
What is missing is different in kind. A permission gate creates operational questions the architecture cannot answer, and the document does not answer them either: who reviews a refusal, whose list is being applied, and what a holder does when a screen returns a false positive on a wallet that passed before.
Those are not engineering problems, so an engineering review will not settle them. The specification covering the account lifecycle, the authorisation and the reconciliation behind those pre-funded accounts is deferred to a later phase, and deterministic refunds when routing fails after the swap remain a design consideration.
What a holder can check before opting in
The practical version is short. Establish which question a product’s non-custodial claim answers, because keeping your own keys settles possession and settles nothing about permission. Find out where the assets sit between execution and final settlement, and whose balance sheet closes the gap. Ask what a refusal looks like from your side, and whether there is anything to appeal to. And read the phase a proposal is in rather than the capability it describes.
None of this argues against execution privacy, which addresses a real exposure that most holders never price. It argues that a control able to refuse is a counterparty, whatever the documentation calls it, and that the word protecting your keys says nothing about who holds the switch.