Architecture
The clients-transports-actions model and how typing flows from ABI definitions through to decoded results.
Third-party documentation. This is independently authored analysis of the public Viem codebase — not the official docs, and not reviewed or endorsed by the Viem team.
Architecture
Viem's runtime model has exactly three moving parts: clients, transports, and actions.
Clients
A PublicClient bundles a chain definition with a transport and provides read access: block/transaction lookups, event logs, eth_call-based contract reads, and simulations. A WalletClient extends it with an account — either a local key (signing happens in-process) or a JSON-RPC account backed by an EIP-1193 provider (signing is delegated). Clients are cheap to create; the idiomatic pattern is one per chain-context you talk to.
Transports
A transport knows how to get bytes to a node: http() wraps fetch against any RPC endpoint, webSocket() maintains subscriptions over sockets, fallback() races or fails-over between several. Transports are swappable at client construction, which is what makes viem equally at home in browsers, workers, and serverless functions.
Actions
Every capability — getBalance, readContract, sendTransaction, watchBlockNumber — is an action function hanging off a client. Actions are individually importable and tree-shakeable; unused ones cost nothing in bundle size. Contract interactions go through the ABI layer: encode arguments per the ABI item, dispatch the RPC call, decode results, and surface errors as typed, structured exceptions rather than raw revert strings.
The typing pipeline
When an ABI is declared as a literal (as const), TypeScript resolves each function name to its exact argument tuple and return type. That means invalid function names, wrong argument shapes, and mistyped decodings become compile-time errors instead of runtime surprises — the library's most consequential design decision.
System Diagram
Typed actions wrap transports and ABI codecs into composable clients.