# ABIType turns an Ethereum ABI into TypeScript types without a codegen step

> ABIType is a TypeScript library from the wevm team that provides strict types and utilities for Ethereum ABIs and EIP-712 typed data, so a contract ABI becomes a compile-time checked set of function names, inputs and outputs rather than a codegen artifact. It suits library authors and app developers working with Wagmi or Viem, and it is types only with no runtime behaviour of its own.

**wevm/abitype** — Strict TypeScript types for Ethereum ABIs

- Repository: https://github.com/wevm/abitype
- Website: https://abitype.dev
- Stars: 551 · Forks: 74
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/wevm-abitype

## The ABI as the single source of truth

ABIType is described in one line as strict TypeScript types for Ethereum ABIs, and the README spells out the coverage: it provides utilities and type definitions for ABI properties and values, covering the Contract ABI Specification as well as EIP-712 Typed Data. The problem it addresses is that an ABI is data, and data does not carry types. A contract's ABI tells you a function called transfer takes two arguments, but on its own it tells a TypeScript compiler nothing about the names of those arguments, their order, their types, or which of the functions are view functions and which are state changing. Most teams solve this with a build step: a code generator reads the ABI and writes a TypeScript file of interfaces, and from that moment the generated file and the ABI are two artefacts that can drift apart. ABIType takes the other approach. The README states it plainly, you do not need to set up a build process to generate types, and you just use your ABI and let TypeScript do the rest. The stated benefit is adding fast autocomplete and type checking to functions, variables, or your own types, and the topics list for the repository names type inference and static types alongside abi, ethereum and web3.

## What the type utilities actually derive

The README's example is short and shows the whole idea. Three type utilities are imported from abitype, along with the erc20Abi constant from the abitype/abis entry point.

```ts
import type {
  AbiParametersToPrimitiveTypes,
  ExtractAbiFunction,
  ExtractAbiFunctionNames,
} from 'abitype'
import { erc20Abi } from 'abitype/abis'

type FunctionNames = ExtractAbiFunctionNames<typeof erc20Abi, 'view'>
//   ^? type FunctionNames = "symbol" | "name" | "allowance" | "balanceOf" | "decimals" | "totalSupply"

type TransferInputTypes = AbiParametersToPrimitiveTypes<
  // ^? type TransferInputTypes = readonly [`0x${string}`, bigint]
  ExtractAbiFunction<typeof erc20Abi, 'transfer'>['inputs']
>
```

Read the inferred types and the value is obvious. ExtractAbiFunctionNames with the view selector produces a union of the names of the read-only functions on the ERC-20 ABI, so the editor will complete only the six names that can actually be called without a transaction. AbiParametersToPrimitiveTypes applied to the inputs of the transfer function produces a readonly tuple of a 0x-prefixed hex string and a bigint, which is exactly the shape of a transfer call. The type checker then rejects a call to a function that does not exist, a call with the wrong argument types, or a call with the arguments in the wrong order, all at compile time and all from the ABI you already have. The project is MIT licensed, the homepage is abitype.dev, the repository is not archived, and the last push was on 2026-10-01. Releases are on npm under the abitype name, with 1.3.0 published on 2026-07-16 after 1.2.4 in April 2026 and 1.2.3 in December 2025.

## Who the README says it is for

The TL;DR section of the README is unusually specific about the audience, and it is worth reading because it also names what ABIType is not. ABIType might be a good option for your project if you want to typecheck your ABIs or EIP-712 Typed Data, if you want to add type inference and autocomplete to your library based on user-provided ABIs or EIP-712 Typed Data, the way Wagmi and Viem do, if you need to convert ABI types such as 'string' to TypeScript types such as string or need other type transformations, and if you do not want to set up a build process to generate types, with TypeChain named as the example of the thing you avoid. The second point is the most consequential one for library authors, because it describes a scenario where your users supply an ABI at the type level and your API must accept it safely, which is a different problem from typing your own contracts. The boundary is stated just as clearly. The README carries a note saying that if you need runtime capabilities like Zod schemas or human-readable ABI parsing and formatting, you should check out Ox, which is a separate library from the same ecosystem. So ABIType is the type level half of a pair, and Ox is the runtime half.

## Installing and using it in a project

The package is published on npm under the abitype name, and the README points to the npm package page for the version and download badges. The import paths in the example show the two entry points you need: the root abitype for the types and utilities, and abitype/abis for the bundled ABI constants such as erc20Abi. There is no build step of your own to set up, which is the entire point of the library, so adopting it is a dependency line and a type import. The documentation and guides live at abitype.dev, with the API reference split into a types page and a utilities page. The utilities section is where the type transformations are documented, including the AbiParametersToPrimitiveTypes conversion the README links to directly.

## The monorepo behind the package

The repository is a pnpm workspace rather than a single package, and the root package.json shows the tooling. The root package is private and typed as a module, and the workspaces live under packages/, with docs/ for the documentation site and playgrounds/ for experiments. The scripts show how a library of this kind is maintained. Type checking runs the packages in parallel and then runs tsc --noEmit at the root, and there is a separate property types variant that reruns the check with exactOptionalPropertyTypes disabled, which is how you keep a strictness setting from blocking a release. There are bench scripts, one of them a bench:types script that runs the type level benchmark suite with a TYPES environment flag, and a typeperf script that measures type level performance across packages, so the cost of the inference on a large ABI is something the project tracks. Unused code is checked with knip, dependency versions are updated with a taze-based task and an actions-up script, and the test runner is vitest with a coverage variant. Releases go through changesets, with a version:update script and a formatPackageJson script that runs before publishing. The preinstall hook runs only-allow pnpm, so a stray npm install is refused rather than silently producing a broken lockfile.

## Where ABIType is the wrong tool

There are four boundaries and each one bites in a specific situation. The first is runtime validation. ABIType produces types, and types are erased at runtime, so a value arriving from a wallet or an RPC node is not checked against your ABI by this library, and the README points you to Ox for Zod schemas if you need that. The second is that it does not parse ABI JSON for you. Human-readable ABI parsing and formatting is explicitly Ox territory, so a project whose main job is reading ABI files needs the other library. The third is TypeScript itself. The library is types, so there is no runtime cost and also no runtime benefit, and a team on plain JavaScript gets nothing from it, while a team that has deliberately avoided TypeScript for other reasons would be adopting a compiler-level dependency on top of that decision. The fourth is that the type level work has a cost, and it is a cost on the consumer's compiler rather than the library author's build. The presence of bench:types and typeperf scripts in the repository says the project is aware of this, and it is worth checking how the inference behaves with a very large ABI in your own toolchain before you make every contract interaction in your codebase depend on it. A sensible alternative for teams that need both static safety and runtime guarantees is to keep ABIType for the compile time types and add Ox for the runtime checks, which is the split the README itself suggests.

## Conclusion

Adopt ABIType if your TypeScript project talks to Ethereum contracts through an ABI and you want the ABI itself to be the single source of truth for your types, because the inference utilities derive function names, parameter tuples and outputs from the ABI constant at compile time with no generated files to keep in sync. Do not adopt it if you need runtime validation or human readable ABI parsing, because the README directs you to Ox for that, and do not adopt it if you are not already in TypeScript. Verify two things first: that your compiler and type checker can handle the inference, since the whole value depends on the type level work, and that the extract utilities cover the ABI shapes you use, since the examples in the README cover view functions and a two argument transfer rather than every event or tuple form. The practical first step is to install abitype, import the erc20Abi constant from abitype/abis and let your editor show you the inferred function names before you write any call.

## FAQ

### What is ABIType?

It is a TypeScript library from the wevm team providing strict types and utilities for Ethereum ABIs and EIP-712 Typed Data, covering the Contract ABI Specification. It is MIT licensed and published on npm as abitype, with the documentation at abitype.dev.

### Does ABIType require a code generation step?

No. The README states that you do not need to set up a build process to generate types, and that you just use your ABI and let TypeScript do the rest, naming TypeChain as the kind of tool you avoid needing.

### Which type utilities does ABIType provide?

The README example uses AbiParametersToPrimitiveTypes to turn ABI parameters into primitive TypeScript types, ExtractAbiFunction to pick a single function out of an ABI, and ExtractAbiFunctionNames to produce a union of function names, optionally filtered by state mutability such as 'view'. The utilities page on abitype.dev documents more transformations.

### Can ABIType validate ABIs at runtime?

No, it is types only and they are erased at runtime. The README includes a note saying that if you need runtime capabilities such as Zod schemas or human-readable ABI parsing and formatting, you should check out Ox instead.

### How is ABIType developed and released?

The repository is a pnpm workspace with packages under packages/, a docs site and playgrounds, using changesets for releases and vitest for tests. Type checking runs per package and at the root with tsc --noEmit, there are type level benchmark and typeperf scripts, unused code is checked with knip, and a preinstall hook restricts the project to pnpm.

## Sources

- [License: MIT](https://github.com/wevm/abitype/blob/main/LICENSE)
- [Project website](https://abitype.dev)
- [README](https://github.com/wevm/abitype/blob/main/README.md)
- [Releases](https://github.com/wevm/abitype/releases)
- [wevm/abitype on GitHub](https://github.com/wevm/abitype)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wevm-abitype