Introducing Web3-Hooks

For several years, I have been working on Blockchain projects, and for most of them, my library choice is React, because React is usually the best architectural decision for these projects. The most common (and more repetitive) features are those such as sending transactions, reading smart contract functionalities, and keeping UIs synchronized with on-chain data. It has been great working with available blockchain/web3 libraries — but every new dApp meant re-implementing the same patterns: request/response typing, cache keys, polling vs. subscriptions, chain switching, and error boundaries. I kept wishing there was a lightweight, adapter-agnostic library that gave me the primitives and opinions I needed, without locking me into a single provider stack.

So I decided to build Web3-Hooks.

The goal with Web3-Hooks is to provide a modular React hooks library for Web3 that cleanly separates concerns. You can swap transports and providers (e.g., Viem, Ethers, custom JSON-RPC), keep React-specific concerns in React, and scale your codebase without coupling every component to a specific SDK.

Why another Hooks library?

• Adapter freedom. Many libraries bundle wallet connectors, transport, and React state in one box. That’s great when you want batteries included, but it can create problems for teams who need to mix & match RPCs (Alchemy/Infura/self-hosted), add custom middleware (retries, tracing), or target non-EVM chains later.


• Predictable caching. Reads in dApps are perfect for TanStack Query (React Query): cache keys, stale times, SSR awareness, and deduplication eliminate flicker and wasted requests.


• Typed flows end-to-end. Strong typing across JSON-RPC requests, hook signatures, and responses reduces “unknown hex” and any drift, especially with BigInt and 0x-prefixed data.

Architecture

Web3-Hooks ships as three composable layers:

For writes:

• A hook (e.g., useSendTransaction) calls walletClient.sendTransaction(...)
  


• You can optimistically update UI or invalidate queries on receipt
  Errors bubble through React Query’s error states/error boundaries

SSR & Next.js: Because TanStack Query plays well with SSR, you can prefetch critical reads on the server (where appropriate), and hydrate on the client for instant UI.

Where It Fits Among Other Tools

• Viem — a modern, typed, EVM toolkit. web3-hooks uses it via the EVM adapter today.


• Ethers.js — the classic EVM library. An Ethers adapter could be added; the React layer wouldn’t change.


• wagmi — a feature-rich React EVM library with connectors and actions. If you want more control over transport/adapters (or you’re mixing chains), web3-hooks gives you a lean alternative.


• The Graph — for indexed data and historical queries. web3-hooks focuses on live RPC reads/writes; combine them when you need richer analytics/history.


• TypeChain — generate TypeScript typings for contract ABIs. Works great alongside web3-hooks for type-safe contract calls.

Roadmap

• Additional adapters: Ethers, WS transports, non-EVM chains (Solana/Starknet)


• More hooks: useFeeHistory, useEnsName, useTokenList, useBundlePrice


• Event streams via WebSocket subscriptions with backoff/retry


• DevTools integ
  ration (React Query + request tracing)

If you’ve use cases (rollups, L2 gas oracles, MEV-resistant patterns), I’d love to hear about them.

Contributing

• Issues/Ideas: Open a /
  


• Viem: typed EVM toolkit (clients, actions, transports) —
  


• The Graph: Subgraphs & Substreams for indexed on-chain data —
  


• JSON-RPC 2.0: transport/specification — https://www.jsonrpc.org/specification