Browser Extension Wallet - SDK#
Prerequisites#
If you haven’t downloaded the KC Wallet browser extension yet, please go to the download page:If you have already installed the extension, check whether it is running properly in your browser. Copy the following code into the browser Developer Console:If it runs correctly, proceed to the next step.EVM Chains#
Standard Wallet Methods#
| Method | Params | Return Type | Description |
|---|
| enable | - | Promise | Connect method; returns account information |
| isConnected | - | boolean | Gets connection status |
| request | (payload, callback) | Promise | Generic eth call. payload.method can be personal_sign, eth_sendTransaction, eth_accounts, etc. callback is invoked after execution |
| _isConnected | Whether connected to current Dapp | boolean | Whether connected to the current Dapp |
| chainId | Current connected chain ID | string | Hex-encoded chain id |
| networkVersion | Current connected chain ID | string | String representation of chain id |
Create Connection#
To connect a wallet, you can initiate a “wallet connection” using the code below by calling eth_requestAccounts to access the user’s account address.Listen for Account Address Changes#
You can listen for changes via events:Whenever the return value of the eth_accounts RPC method changes, KC Wallet emits the corresponding event to notify the DApp of address changes. eth_accounts returns either an empty array or an array containing a single account address. If present, the returned address is the most recently used account address that the caller is permitted to access.Because callers are identified by their URL origin, sites with the same origin share the same permissions. Whenever the user’s exposed account address changes, accountsChanged will be emitted.Get chainId#
All RPC requests are submitted to the currently connected network, so accurately obtaining the user’s chain ID is critical for EVM-based application development.Use eth_chainId to get the user’s current chain ID:Listen to the chainChanged event to detect network changes:Chain IDs#
Below are the Ethereum-compatible chain IDs supported by KC Wallet by default. For more information, see chainid.network.| Hex | Dec | Network |
|---|
| 0x1 | 1 | Ethereum Main Network (Mainnet) |
| 0x4115 | 166610G | 0G |
| 0x38 | 56 | BNB Smart Chain |
| 0xa4b1 | 42161 | Arbitrum One |
| 0xa86a | 43114 | Avalanche C |
| 0x2105 | 8453 | Base |
| 0x138de | 80094 | Berachain |
| 0x659 | 1625 | Gravity Alpha |
| 0x3e7 | 999 | HyperEVM |
| 0x141 | 321 | KuCoin Community Chain |
| 0x8f | 143 | Monad |
| 0x279f | 10143 | Monad Testnet |
| 0xa | 10 | Optimism |
| 0x18232 | 98866 | Plume |
| 0x89 | 137 | Polygon |
| 0x531 | 1329 | Sei EVM |
| 0x13a7 | 5031 | Somnia |
| 0xc4 | 196 | XLayer |
Switch Chain#
To switch the chain that the wallet and DApp are connected to, use the example below:Message Signing#
Sign Arbitrary Messages#
personal_sign (often referred to as signPersonalMessage ) is used to sign arbitrary text messages with the user’s Ethereum private key.Sign Structured Data#
eth_signTypedData (specifically eth_signTypedData_v4 ) is used to sign structured data according to the EIP-712 standard. This standard enables applications to create cryptographic signatures for complex, structured data, ensuring signatures are both human-readable and verifiable.Sign Transactions#
A transaction is a formal action on the blockchain. In KC Wallet, transactions must be initiated by calling eth_sendTransaction . Transactions may involve simple ETH transfers, token transfers, deploying a new smart contract, or changing on-chain state in any manner. Such transactions must be initiated with a signature from an externally owned account (or a simple keypair).In KC Wallet, you can initiate a transaction via kcwallet.request .Parameters#
This section introduces transaction parameters covered in this document. Most transaction parameters in this document are handled by OKX Wallet. Transactions are divided into legacy transactions and EIP-1559 transactions, described below.Legacy Transaction#
EIP-1559 Transaction#
For EIP-1559 transactions, the key difference from legacy transactions is that maxPriorityFeePerGas and maxFeePerGas are used instead of gasPrice.maxPriorityFeePerGas (optional): An additional tip the user is willing to pay to the miner/validator to incentivize prioritizing the transaction.
maxFeePerGas (optional): The maximum total fee per unit of gas the user is willing to pay, including both the base fee and the priority fee.
Modified at 2026-04-08 03:20:29