SDKs

Reading Frost works with any Ethereum library. Writing from a post-quantum account does not, because no mainstream library can produce an ML-DSA signature or serialise a type 0x06 transaction.

These are the libraries that can.

viem-8141TypeScript. A viem companion package — native ML-DSA in pure JS, browser-capable, pluggable hardware signers.

web3-8141Python. A web3.py companion package — codec, signing, account builders, and witness-segregation support.

frametxGo CLI. The reference implementation: keygen, address derivation, sends, and rotation from the command line.

Pre-release

Neither viem-8141 nor web3-8141 is published to npm or PyPI yet, and the repositories are not yet public. Until they are, install from source. This page will carry the install commands the moment they land.

Which one

Building a wallet or a web app → viem-8141. It runs in the browser, has @noble/post-quantum as its only runtime dependency, and exposes a WitnessSigner interface for out-of-process hardware signers.

Scripting, backends, or testing → web3-8141. It attaches to a normal Web3 instance as a w3.eip8141 module and leaves stock web3.py untouched.

Trying things by hand, or a reference to check against → frametx. It is the Go implementation the others are differentially tested against, and it emits stable JSON on stdout.

What they all do

Every one of these implements the same core, and it is more than a convenience wrapper:

• The codec. Building, RLP-encoding, and hashing type 0x06 transactions, including the signature-elision rule for the sig-hash. Getting this wrong by hand is the single most common integration failure.
• ML-DSA signing. FIPS 204 signatures over the sig-hash, carried as ARBITRARY witnesses.
• Counterfactual addresses. CREATE2 derivation against the factory predeploy, with the frost/account/v1 salt scheme — offline, before the account exists.
• Account builders. First send, spend, and rotation transactions for the rotatable ML-DSA-65 account, with the signed gas_limit sized correctly.
• The signed gas limit. Sizing it over the final encoding, budgeting witness bytes at their eventual length before hashing. Easy to get wrong and fatal when you do.

Correctness

These libraries are clean-room implementations built from the published EIP-8141 specification, and they are tested three or four ways each:

• Byte-exact against golden vectors, hermetically.
• Differentially against the reference frametx CLI, so two independent implementations must agree byte for byte.
• End to end against a live chain — derive, fund, self-deploy, spend, rotate.
• For viem-8141, additionally in a headless browser, and against a signature produced inside a real Apple Secure Enclave.

Spec pin

EIP-8141 is a draft under active revision. Both SDKs implement the spec as published on 2026-07-11 — the three-entry signature-scheme table (ARBITRARY, SECP256K1, P256) with ARBITRARY entries introspectable via SIGPARAM.

They additionally implement Frost’s chain-local extensions, which are not in the upstream draft:

• the signed transaction-level gas_limit,
• witness segregation — the permanent-witness surcharge and size caps, the strippedTransactionsRoot commitment, and the serving RPCs,
• the EIP-7997 factory predeploy that counterfactual addresses derive against.

Open spec proposals upstream (guarantors, keyed nonces, signer binding) may change the payload shape or the sig-hash. A re-pin will be a version bump with a changelog note.

Using ordinary tooling alongside

Everything that only reads works normally. viem, ethers, web3.py, cast, Etherscan-style explorers, and subgraph indexers all work against https://rpc.frostfi.net with no modification.

The line is precisely at signing a frame transaction from a post-quantum account. Ordinary secp256k1 EOAs can also transact with stock tooling — they are simply not quantum-safe.