Building Your Own Wallet with OKX Signing SDK: Keys, Broadcasting, and Verification

OKX

23 October 2026

OKX's Signing SDK performs offline signing. It does not broadcast transactions or hold your keys for you. When you build a wallet with it, key generation and signing happen locally. You need to connect your own RPC node or broadcasting service to get transactions on-chain. Once you understand this boundary, the trade-offs in each step become clear.

OKX Exchange
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！

The word "verification" in the title has two meanings in the SDK context: whether the signature result is valid (checked with validSignedTransaction), and whether the transaction actually made it on-chain (confirmed by looking up the TxID on a block explorer). These are not the same thing. A successful signature does not mean a successful broadcast, and a successful broadcast does not mean on-chain confirmation.

Which SDK to Choose: Language and Chain

OKX provides multi-language, multi-chain signing toolkits. For JavaScript/TypeScript projects, use the @okxweb3/coin-* series. Install the package that matches your chain, such as @okxweb3/coin-ethereum, @okxweb3/coin-bitcoin, or @okxweb3/coin-solana. For Go projects, use github.com/okx/go-wallet-sdk. The common crypto package provides basic algorithms like BIP32, BIP39, ECDSA, and Ed25519. Each coin module is imported separately.

Both paths support offline signing and cover major chains like Ethereum/EVM, Bitcoin-based chains (including BRC20, Atomicals, Runes), Solana, Cosmos, Aptos, Sui, and Tron. If you only need signing and do not want to write serialization logic for each chain yourself, the SDK is the right choice. If you also do not want to deal with node operations, you will need to connect an additional broadcasting service.

Keys: Generation, Derivation, and Validation Happen Locally

The SDK's private key functions include getRandomPrivateKey (generates a random private key), getDerivedPrivateKey (derives from a mnemonic or seed), validPrivateKey (validates the private key format), and getNewAddress (gets an address from a private key).

One key principle: from the moment a private key is generated, it should never leave your local environment. OKX's Signing SDK is designed for offline operation and does not need to call OKX servers. If you send a private key to any remote interface in your code, you have broken the security assumption of this SDK yourself.

Use getDerivedPath to get the derivation path, which follows BIP44. In a multi-chain wallet scenario, the same mnemonic can derive addresses for each chain using different coin types. However, do not assume that derivation results from different chains can be mixed. The path parameters for each chain need to be confirmed separately.

Signing: Build the Raw Transaction First, Then Sign

The signing process has two steps: first call getRawTransaction to generate raw transaction data, then call signTransaction to sign the raw transaction. Ethereum signing parameters usually include to, value, nonce, gasLimit, gasPrice (or EIP-1559's maxFeePerGas/maxPriorityFeePerGas). Bitcoin-based chains also involve UTXO selection and change addresses.

After signing, use validSignedTransaction to check if the signed transaction is valid. This step is worth doing because it can catch issues like mismatched private keys and addresses or incorrect signature formats. It helps you avoid discovering a failure only after broadcasting an invalid signed transaction.

The SDK also provides signMessage and verifyMessage for message signing, as well as ecRecover to recover a public key from a signature. Message signing and transaction signing serve different purposes. Message signing is often used for login verification or proving control of an address. It cannot be used directly as a transaction.

Broadcasting: The SDK Does Not Do This, You Need to Add It

The Signing SDK documentation does not include broadcasting as a built-in feature. To get a transaction on-chain, you need to send the signed raw transaction to an RPC node or broadcasting service. OKX's own Onchain OS provides a transaction broadcasting API that integrates proprietary nodes and third-party nodes for smart multi-path broadcasting. However, this is a separate product from the Signing SDK and needs to be integrated separately.

If you do not want to use OKX's broadcasting service, you can use any public or self-hosted RPC node to send the raw transaction. Whichever path you choose, run an on-chain simulation before broadcasting if possible, especially for transactions involving contract interactions. Simulation can reveal revert risks early and help you avoid paying miner fees for a failed transaction.

Verification: Two Stages, Checked Separately

Signature stage verification: validSignedTransaction returns valid, and the transaction hash (calculated from the raw transaction using calcTxHash) matches expectations. Note that calcTxHash calculates the hash of the raw transaction, not the on-chain confirmed TxID. Before broadcasting, they are the same string of characters, but their meanings are different.

On-chain stage verification: After broadcasting, get the TxID and check its status on the corresponding chain's block explorer. pending does not mean success. success means the on-chain execution succeeded. If the transaction involves token transfers or contract calls, also check the actual transfer amount and receiving address in the event logs. Do not assume assets arrived at the right place just because the transaction status is success.

An Easy-to-Miss Boundary

OKX's WaaS product line includes a "keyless wallet" solution based on MPC/TSS threshold signatures. This is a different system from the Signing SDK: the Signing SDK gives you full private key control, while the MPC solution splits keys into shares and does not let you access the complete private key. If you need a wallet experience with "no user friction and social login recovery", the MPC solution is more suitable. If you want a self-built wallet where you fully control the private key and sign offline, the Signing SDK is the right path. Do not mix the two, and do not assume that using the Signing SDK automatically gives you the security model of MPC.