Ant Design Web3: React components for dapp front ends across chains

A component layer for dapp front ends, not a wallet SDK

Ant Design Web3 is a set of React components for building dapps, and it belongs to the Ant Design organisation, the same group behind the antd component library. The README states the pitch in three feature lines: an out-of-the-box experience, flexible theme customization, and compatibility with different chains.

The chain list is specific. The project description names Ethereum, Solana, Bitcoin, TON, Sui, TRON and others, and the topics tag bitcoin, ethereum, solana and ton. So this is a component library that spans several chain families, not an Ethereum library with a Solana sticker on it.

What it is not is a wallet connection library or a signing library. The repository examples directory contains eth-web3js, ethers-v5 and ethers, which shows the intended arrangement: the component library renders the interface, and a wallet library of your choosing supplies the chain access. The example workspace entries in the root package.json are named to match, and the scripts section carries a run command for each of the three.

The documentation lives at web3.ant.design, with a guide section, a course section, and a faucet link for getting testnet Sepolia ETH. Licence is MIT. The last push to the repository was on 2026-07-22, and the most recent tagged package release listed in the project is @ant-design/[email protected], dated 2025-12-19.

Installing the package and rendering an address

Installation is a single npm command, and it pulls antd in alongside the web3 package because the components build on Ant Design rather than replacing it:

npm i antd @ant-design/web3 --save

The smallest example in the README renders a wallet address with a single component, and it shows the shape of the API clearly: import the component by name, pass the address as a prop, and return it from a React component.

import { Address } from '@ant-design/web3';

export default () => {
  return <Address address="0x1234567890123456789012345678901234567890" />;
};

That is the whole first use. There is no provider to wrap the tree and no configuration object to pass, at least not in the example the project gives. The component takes the value it needs and renders it.

For working on the library itself, the README documents a different path, using pnpm rather than npm:

$ git clone [email protected]:ant-design/ant-design-web3.git
$ cd ant-design-web3
$ pnpm i
$ pnpm start

The start script in the root package.json is dumi dev, so the local site is the dumi documentation app, and the clone and install steps are the ones the project expects for that workflow.

The wallet library stays your choice, and the examples prove it

The three example workspaces are the most informative thing in the repository layout. There is an ethers example, an ethers-v5 example, and an eth-web3js example, and the root scripts expose one run command per example:

"example:ethers": "pnpm run --filter \"@example/ethers\" dev",
"example:ethers-v5": "pnpm run --filter \"@example/ethers-v5\" dev",
"example:eth-web3js": "pnpm run --filter \"@example/eth-web3js\" dev"

This matters more than a feature list would, because the choice of wallet library is the most consequential decision in a dapp front end. A component library that hardcodes one of them gives you a migration later. One that is demonstrated against three gives you evidence that the components are not welded to a particular client object.

The distinction is between the two ethers examples. ethers-v5 and current ethers have different APIs, and shipping both as working examples tells you the project keeps the major-version gap in mind rather than assuming every user is on the latest one.

The same logic applies to chains. Naming Ethereum, Solana, Bitcoin, TON, Sui and TRON means the component set has been shaped around chain types with very different address formats and transaction models, not that a single abstraction covers all of them equally well. If your dapp is on one of the named chains, the component you need is more likely to exist in the shape you need it.

A pnpm monorepo with a dumi site, examples and a changeset release flow

The repository is a pnpm workspace. The root package.json declares the workspace globs and the pinned package manager:

"workspaces": [
  "packages/*",
  "examples/*"
],
"packageManager": "[email protected]"

Two things follow from that layout. The published packages live under packages/, and the runnable examples live under examples/, which is why every script that targets an example uses a filter rather than a path. The pinned package manager version is also what makes the local setup reproducible, since pnpm i inside a workspace resolves the whole graph at once.

The documentation site is dumi, driven from the.dumi directory and the.dumirc.ts config, with a start script of dumi dev and a build:docs script that ends in dumi build. The build:docs script pins specific React canary versions, which suggests the docs site is tested against an upcoming React rather than only a released one.

Releases run through changesets. The release script runs a prepare step that builds, lints and tests, then versions and publishes the changesets, with separate alpha and beta variants that publish under their own tag:

"release": "pnpm run release:prepare && changeset version && changeset publish",
"release:alpha": "pnpm run release:prepare && changeset version --snapshot alpha && changeset publish --tag alpha"

Testing is vitest, with a separate dist mode, and the repository also carries biome.json,.eslintrc.js and.prettierrc files alongside husky hooks, so formatting and linting run on commit rather than only in CI.

What the README does not tell you

The documentation is deliberately thin at the top and it is worth being explicit about what that means for an adopter.

There is no component inventory in the README. It gives one example, the Address component, and points at the documentation site for the rest. Whether a wallet connect button, a transaction list or a token balance view exists in a given version is something you have to check on the site or in the packages directory, not something the README confirms.

There is also no statement about browser support, no list of peer dependencies, and no mention of bundle size in the README itself, even though the repository carries a bundlephobia badge for the package. The absence is not a red flag on its own, but it means the evaluation happens in the documentation rather than in the repository landing page.

The version gap is the other thing to look at. The most recent tagged release in the list is @ant-design/[email protected] from 2025-12-19, while the last push to the repository was on 2026-07-22. Changes in the repository are therefore not necessarily in a published package, and if you depend on a fix that landed after that release date you would be building from source rather than from npm.

Sponsor-backed, with a faucet and a course alongside the components

The project carries a commercial sponsor. The README shows ZAN as the sponsor and describes it as a Web3 technology service provider offering node services, a testnet faucet, smart contract auditing and other services. The same provider is behind the faucet link for getting testnet Sepolia ETH that appears at the top of the project page.

That is worth knowing plainly rather than glossing over. A sponsored open source component library is not a red flag, but it does mean the sponsor's services are the ones the documentation points you toward for node access and for testnet funds. Teams that need to choose a node provider on technical grounds should not let the faucet link make that decision for them.

The course section of the documentation site is a separate learning resource rather than API reference, and the contribution guidelines live at their own guide page. The repository also carries a LEGAL.md alongside the MIT LICENSE, and a CNAME file for the documentation domain, plus a Chinese README variant at README-zh_CN.md, which tells you the project is maintained for a Chinese-speaking audience as well.

Editorial conclusion

Adopt ant-design-web3 if your front end already runs on Ant Design and on ethers, ethers-v5 or web3js, because the components assume that stack and save you from building wallet connect, address and transaction UI by hand. Do not adopt it on the strength of the chain list alone, since the README names the chains but does not publish a component inventory, and check the component you need against the documentation site before committing. Before you start, pin a version from npm rather than tracking main, and read the guide pages linked from web3.ant.design to confirm the component you want exists in that release.

Frequently asked questions

Official sources

1. ant-design/ant-design-web3 on GitHub
2. License: MIT
3. Project website
4. README
5. Releases