Skip to content
B3Pay homeB3Pay homeB3Pay

ERC-7730 Clear Signing for EVM protocols

Contract calls people can read before they sign

B3Pay gets EVM protocols clear-signed with ERC-7730, then puts the same descriptors to work so that AI agents can only send transactions a person can read and approve.

Get your contracts clear-signedRead the docs
  1. Calldata
  2. Decode
  3. Clear-sign
  4. Confirm
A wallet's signature request, shown three ways. Without a descriptor, a wallet can show only its calldata. Decoded with the contract's ABI alone, it is approve, with a spender address and a 78-digit value. With an ERC-7730 descriptor, it reads: Approve USDC. Spender: Permit2. Amount: Unlimited USDC.
ERC-7730

One JSON file turns calldata into a sentence

A wallet that can't read a contract call shows hex and asks for trust. ERC-7730 closes that gap: a JSON descriptor tells the wallet how to show each call to your contract, with every value labeled and formatted. Since 12 May 2026 the standard has a registry hosted by the Ethereum Foundation, and a framework for independent reviewers to attest descriptors. A wallet that supports it can show your users what they are signing once a descriptor for your contract is in a registry it reads.

Sources, checked 30 October 2026: the Ethereum Foundation's announcement and ethereum.org's Clear Signing guide.

display.formatsUSDC · Ethereum
"approve(address spender,uint256 value)": {"intent": "Approve USDC","fields": [{"path": "#.spender","label": "Spender","format": "addressName","params": {"types": ["eoa", "contract"],"sources": ["local", "ens"]}},{"path": "#.value","label": "Amount","format": "tokenAmount","params": {"tokenPath": "@.to","threshold": "0x8000000000000000000000000000000000000000000000000000000000000000","message": "Unlimited"}}]}
An illustration: the format for USDC's approve, from a descriptor written for this page. We have not submitted it, and no one has attested it.

  1. Intent

    A format is keyed by the function's signature, with its parameter names. A wallet drops the names, hashes what is left, and uses the format for calls that start with the same four bytes: 0x095ea7b3 here. Its intent says in plain words what the call does.

  2. Spender

    #.spender points at the call's spender argument. addressName tells the wallet to show a trusted name for it, looked up only in the sources listed: names saved in the wallet, or ENS. With no trusted name, it shows the checksummed address. types says what kind of address to expect, so the wallet can check it.

  3. Amount

    tokenAmount finds the token at @.to, the contract the call is sent to, and writes the value in whole USDC with its ticker. At or above the threshold, 2255, it writes the message in place of the number, so 2256 − 1 reads as "Unlimited USDC", not as a 78-digit number.

Checked against ERC-7730, still a draft, on 31 October 2026.The anatomy of a descriptor, in full

One descriptor, two readers

Written once, read by a wallet and by an agent

The descriptor we write so a wallet can show a person what a call does is the file our toolkit, now in development, turns into an agent's tool for that call, with the same readable text as its consent message. An agent working through it can only propose calls the descriptor explains, and a person reads each one before it is signed.

The same descriptor, read twice. A wallet shows the call as Approve USDC, spender Permit2, amount Unlimited USDC, with Reject and Approve. Through an agent, with our toolkit once it is built, the call is simulated against current chain state, decoded with the contract's verified ABI and clear-signed with the descriptor, then waits for a person to confirm it.

Nothing is signed until a person approves that one transaction. What the toolkit will do

What we do

Your protocol clear-signed, from ABI to registry

Clear Signing, done for you

Written, tested, submitted and kept current

We write the descriptors for your contracts, test them against real transactions, submit them to the registry, and keep them current when your ABI or a proxy's implementation changes.

  1. 01Scope
  2. 02Descriptors
  3. 03Tests on real calldata
  4. 04Submission
  5. 05Upkeep
Get your contracts clear-signed

Toolkit and MCP server

In development

Open-source TypeScript tools that draft and check descriptors from ABIs, and an MCP server that has an agent simulate, decode and clear-sign each call, then wait for a person to confirm it.

B3Forge

Beta

Visual workflows for contract calls. In beta on the Internet Computer today; a version for EVM contracts, with every write step clear-signed, is in development.

Internet Computer

Where B3Pay started, still maintained

B3Pay started on the Internet Computer. These products are maintained, and their docs are here with everything else. All of them

  • IC ReactordocsMaintained

    Typed canister calls for TypeScript and React: a client, one error type, units helpers, a test client and a React provider, over a module generated from a .did file.

    SourcePackage

  • MeantdocsMaintained

    The meaning layer for contract calls: Candid interfaces compiled into a canonical, identity-addressed graph, and profiles that say what each value means and what each call does.

    SourcePackage

  • B3NotedocsMaintained

    Private notes on the Internet Computer, encrypted in the browser with vetKeys before they reach the canister.

    SourceOpen the app

Start

Which contracts do your users sign?

Tell us the chains, the addresses and the flows your users sign: public information only. We reply with a scope and a quote, based on how many contracts and functions you want covered.

Start with your contractsWrite to us about anything else

© 2026 B3Pay. Code on GitHub.