Centralised and decentralised describe aspects of control, not a complete safety assessment. Compare who holds assets, how trades execute and which permissions you approve. Then inspect the actual service or protocol, because interfaces can combine several models.
A self-custody wallet and a contract interaction create different responsibilities from an ordinary service login.
BTKWIN.COM · EDUCATIONAL EXAMPLEBegin with asset control
In a custodial service, the provider typically manages signing arrangements and processes customer instructions under its terms. You protect account access while relying on the provider for custody and withdrawals. A displayed balance is not necessarily direct control of the underlying keys.
With self-custody, you manage the relevant signing and recovery information. That can remove some dependence on a custodian while adding responsibilities for backups, device security and approving instructions. A lost secret and a forgotten service password are different recovery cases.
The wallet questions help identify the actual arrangement. Avoid assigning one label to every stage without checking where assets are held during and after an operation.
Compare execution models
A central service can match an order book or provide a quotation through its own route. An on-chain application can use contracts and pools or another defined mechanism. Neither model guarantees an attractive price for every quantity.
Uniswap’s documentation describes its automated market-making approach as one example. Other protocols and versions can differ. Read the actual implementation and network rather than assuming every decentralised exchange follows one formula.
A service can also combine components, such as a custodial interface routing to external liquidity. Identify the route behind the interface. The platform types guide separates execution, custody and settlement.
Read permissions before signing
A wallet connection, message signature, spending approval and transfer are different actions. Read the request’s purpose and authority. An interface can look like a routine login while asking for a consequential permission.
Use official documentation to understand the exact asset, network and contract involved. A familiar token symbol can be copied, and a similar domain can imitate a trusted application. Do not infer legitimacy from a chart, logo or community link alone.
Disconnecting an interface should not be assumed to revoke every prior on-chain permission. Follow the relevant wallet and network guidance for reviewing approvals. If signing secrets were exposed, that is a different issue from an ordinary application connection.
Compare operational dependencies
A custodial service depends on its operator, account systems, custody and withdrawal processing. An on-chain route can depend on contracts, network access, frontend delivery, token behaviour and external inputs. A decentralised label does not remove every dependency.
A network can keep operating while an application interface is unavailable. A provider can show a trading screen while a withdrawal route is paused. Identify the stage affected rather than treating every failure as a failure of the asset itself.
Read upgrade, emergency and administrative powers where applicable. Some systems allow defined parties to change or pause components. Record those powers and limits instead of assuming all code is permanently immutable because it runs on a blockchain.
Compare complete costs
| Cost layer | Custodial route questions | On-chain route questions |
|---|---|---|
| Funding | Payment and conversion charges? | How do assets reach the wallet? |
| Execution | Spread and trading fee? | Pool or route cost and price impact? |
| Network | Withdrawal charge and inclusion? | Native fee currency and transaction costs? |
| Exit | Supported destination and limits? | What asset and permissions remain? |
Use the same intended quantity and endpoint. A low trading charge inside a service may be followed by a withdrawal fee. An on-chain route can require separate native-asset fees and include failed-transaction costs under its rules.
The transfer tool can organise costs you enter. It does not inspect a contract, certify support or model every swap route. Keep each assumption and fee currency visible rather than forcing all routes into one simple percentage.
Inspect failure and recovery paths
For a service account, read password and verification recovery, dispute and withdrawal procedures. For self-custody, preserve a usable backup under the wallet’s actual design. A support agent cannot recreate missing signing information from an email address alone.
For an application error, identify whether an instruction was submitted, included, failed or completed with an unintended result. A transaction record and a service ticket are different evidence. The transaction guide explains those stages.
Do not assume a mistaken on-chain action has a practical reversal path. Likewise, do not assume a central operator will always compensate or reverse an internal mistake. Read the actual documented process and preserve the relevant records.
Keep eligibility and identity checks separate
Public access to an interface does not establish that every activity is available or appropriate for every user. Verify applicable service terms, location and product conditions. Do not bypass restrictions or accept a promoter’s assurance as the official answer.
The operator verification guide explains entity and domain checks. For a protocol, identify the official documentation and actual deployment information. A copied interface can present a genuine protocol’s name while requesting unrelated permissions.
Do not share secrets in an attempt to resolve uncertainty. Support for either model can begin with non-secret details such as product, network, transaction reference and status. A request for full spending authority is a different action.
Choose by the actual responsibility map
Write who controls each stage, how execution is priced, what costs apply and what happens under a failure. Mark missing answers. A single centralised-versus-decentralised score can hide the most important dependency.
Use an ordinary and adverse example for the intended route. If the arrangement cannot be explained in terms you understand, the missing explanation is material. This comparison clarifies responsibility; it does not declare one model universally safe or guarantee that either will produce a profitable result.
Use one example to trace the permissions
Describe a hypothetical trade from the starting balance to the final destination. Identify each login, signature, contract interaction and withdrawal request. Then ask what happens if the interface disappears at each point. The answers reveal dependencies that a single model label can conceal.
Do not enter real secrets while doing this exercise. Public documentation and invented amounts are enough to map the steps. If the next action would grant authority or move assets, review it as a separate action rather than treating the earlier wallet connection as blanket permission.
Continue reading
English content and examples reviewed: 27 October 2026. Read the Arabic edition.