Okx wallet connects to dApps through its mobile app and browser extension

App and extension access use different connection paths

When a dApp supports the necessary network and wallet integration, the available connection path determines where its requests appear and which installation you need. A desktop extension handles requests from the browser where it runs. The mobile wallet can handle requests within its own browser or receive them from an external website through a supported connection protocol.

A dApp may implement only some paths. Its connection menu shows the options; the requested network and methods determine whether an option works.

The mobile wallet browser keeps the dApp inside the app

For a dApp compatible with the wallet's built-in browser, the mobile app supplies the connection interface without needing a desktop extension. The app supports dApp discovery and opening a selected application. Browsing and signing remain different functions: loading a website does not establish whether every request it makes is supported. This path fits a phone-based session when the website works with the supplied provider. A dApp designed around a different connection interface may require another supported access path.

Injected desktop connections depend on the extension the website selects

On a desktop website using an injected wallet provider, the extension must be available in that browser and the dApp must select a compatible interface. The provider is the software connection between the webpage and wallet. It lets the application request account access and send supported signing requests. Merely installing the extension does not change a website's integration or add a missing connection option. Several wallet extensions can compete for the same website connection. The wallet's default-wallet preference controls whether it receives priority where that preference applies.

An explicit wallet selector lets you choose among the wallet connections the dApp supports. If an unintended extension opens, examine the wallet selection and default preference before responding to its prompt.

External browsers can connect through app links or WalletConnect

When the dApp implements an app connection, an external mobile browser can send requests to the installed wallet through a supported link. OKX Connect provides a mobile app connection protocol. WalletConnect offers a separate session-based route. A website implementing one protocol does not automatically implement the other.

Mobile links

Opening the wallet

A deep link directs the browser to the wallet app. On iOS, a hand-off triggered after an asynchronous webpage operation may fail because the launch needs a direct user action. This is an integration constraint, even when the app is installed. Some mobile flows also require a fresh tap to open a later signing request after connection.

View image file

Returning to the dApp

The dApp's return-link configuration affects navigation after the user signs or rejects a request. The wallet opening successfully establishes only that the hand-off worked. Returning to the original browser page still requires the application to receive and handle the response. An app switch alone does not establish successful signing or an on-chain transaction.

QR pairing

WalletConnect lets a website display pairing information the mobile wallet can scan, allowing the webpage to stay on another device. The connection proposal requests a session with particular permissions. Pairing avoids installing an extension in that browser, provided the dApp and mobile wallet support the requested connection. A pairing QR code carries session connection information. The wallet still needs to accept the connection request.

Network support includes the requested signing method

Even when an interface connects successfully, the dApp's network and required operation must fall within the capabilities available through that connection. Holding or displaying an asset on a supported blockchain does not establish compatibility with every application using it.

EVM requests

EVM means Ethereum Virtual Machine. The wallet provides Ethereum-style account, network and transaction requests for compatible networks. Chain IDs distinguish networks using this interface. Similar address formats can appear across separate networks, so the account address alone does not identify the intended chain. A network switch changes where requests operate; it does not transfer balances between chains.

Other chain interfaces

Solana connections use a separate provider with their own account and transaction-signing methods. Bitcoin integrations can handle partially signed Bitcoin transactions, known as PSBTs. These are different transaction interfaces. An application must use the relevant integration for its chain family, even when the same wallet application manages the assets.

Session-based connections also distinguish required capabilities from optional ones. In WalletConnect, required networks and methods must be satisfied for session approval. An unsupported optional capability can be omitted while other supported permissions remain available. This distinction explains why a session can connect without exposing every feature the website offers.

Signing access depends on the selected account and interface

When the selected account is watch-only, displaying its balance does not provide the authority needed to sign an on-chain action. The wallet supports monitoring an address without importing its signing credentials. That is useful for viewing activity, but an address alone cannot authorize a transaction. A signing account or compatible hardware-wallet authorization is necessary for actions requiring signatures.

Account selection matters independently of network selection. A dApp can connect to a different account from the one holding the intended assets. The mobile wallet provides account switching, while connected applications must handle account changes appropriately. Compare the address shown by the dApp with the active signing account. Hardware-wallet access adds another dependency: the device and connection method must be supported by the chosen interface.

Connection permissions differ from signatures and token allowances

An EVM account-connection request gives the dApp access to an approved wallet address. That permission allows the application to identify the account. A message signature or transaction request has its own meaning, and some connection flows can include signing. Read the requested action before approving it. An unexpected spending request remains a reason to reject the prompt even when the connection itself works.

An ERC-20 allowance records how much a specified spender may transfer from the approving account. The spender and permitted amount belong to the token contract on the selected network. Disconnecting the browser session does not by itself revoke that on-chain allowance. Session management closes the connection path; changing a token allowance changes a separate contract permission.

Network fees follow the on-chain action

The network and submitted action determine execution costs when a dApp sends an on-chain transaction through the app or extension. On Ethereum, gas used and the effective price per unit of gas determine the execution fee, even if execution fails. An estimated maximum is different from the amount ultimately charged. Contract activity can require different computational work from a simple transfer. For a sender-funded transaction, the signing account also needs enough of the network's fee-paying asset. A displayed token balance does not establish that this prerequisite is met.

Off-chain message signing itself does not consume blockchain gas, although a signature may authorize a later on-chain action. Network fees also differ from exchange trading fees. Comparing interfaces makes sense only when the underlying network, operation and fee inputs match.

Request results and chain records show different states

The result a wallet returns depends on the method the application calls. It might return a signed transaction without submitting it, or an identifier after submission. Neither response alone establishes successful execution. The network record must show the relevant confirmation and execution status. A dApp's connected indicator establishes account access, not completion of its proposed action. A stale application display can differ from that record, so the selected account and network remain necessary context.

View image file

Provider errors identify why a request failed

When a dApp surfaces a provider error, its meaning helps distinguish a rejected request from missing authorization or an unsupported capability. In the EVM provider standard, code 4001 identifies user rejection, 4100 indicates missing authorization and 4200 identifies an unsupported method. Code 4900 describes provider disconnection; 4901 concerns a requested chain the provider cannot currently access while connected elsewhere. These codes describe interface states, not token balances.

View image file

An absent wallet prompt points toward a different part of the connection path from a request the wallet explicitly rejects. Browser integration, app-link handling and existing session configuration are relevant before any on-chain action exists. Refreshing a connection cannot add a method the interface lacks. An alternative app or extension path helps only if the dApp supports it.

If an update changes the dApp's required method or the wallet's available capabilities, reassess the matching connection path before authorizing another request.