Skip to main content
You can handle every failure the SDK reports by checking for UzoError and branching on its code, which doesn’t change between releases even if the message wording does.
Early release. This is published in @uzolabs/sdk 0.2.0 on npm and you can use it today. The API may change before 1.0, so pin the version.

How errors work

Every error the SDK throws extends UzoError, which extends JavaScript’s Error. Each one has:
string
The class name, such as "ExplorerError".
string
A stable code, such as "EXPLORER_ERROR". Branch on this, not on message.
string
A sentence that says what went wrong and what to do next.
unknown
The underlying error, when there is one. For example, the fetch failure behind an ExplorerError.
Import any class from the package root:
handle-errors.ts
Output
Errors from viem itself, such as a reverted call or an RPC timeout, aren’t wrapped. They reach you as viem’s own error classes.

Errors thrown in 0.2.0

UnsupportedChainError

Cause: a chain ID other than 677 (BOT Chain) or 968 (BOT Chain Testnet). Often this is the user’s wallet being on another network. Fix: pass 677 or 968. In a dapp, ask the user to switch networks before you call the SDK. See Connect a wallet.

InvalidAddressError

Cause: the input isn’t a 0x-prefixed, 20-byte hex string. Common causes are a truncated paste, a missing 0x, or an ENS-style name. Fix: pass a full address. Mixed-case addresses are accepted and checksummed for you.

ExplorerError

Reserved for planned modules

These classes are exported in 0.2.0 so you can write handlers now, but nothing throws them yet. They’re for the planned modules. Their fields come from the 0.2.0 source. When they’ll be thrown may change.

Types

Exported TypeScript types.

Explorer client

The main source of runtime errors in 0.2.0.
Last modified on October 3, 2026