Addresses and contracts

The address book helps people review targets and select addresses as contract arguments. Adding an ABI turns an address into a callable contract capability.

Add a known address

Open Address book.
Select Add entry.
Enter a name and EVM address.
Choose the relevant chains.
Save the entry.

Use names that describe purpose, not only ownership. Always compare the full address before a sensitive transaction.

Add a contract

Start from the deployed contract’s chain and address.
Confirm that code exists at that address.
Supply a strongly typed JSON ABI or choose an available Sourcify candidate.
Review whether the candidate describes the proxy or its implementation.
Save the contract capability.

txcast stores the ABI source and a digest. A second registration with the same normalized ABI is unchanged; a different ABI conflicts instead of silently replacing the saved definition.

Owners and admins may manage these resources through MCP or Agent REST with registry.write. Account tools add or edit Safe/wallet capabilities; contract tools add or edit contract capabilities. Compose both tools when one address needs both capabilities. An address with no remaining capability is removed.

Agent contract writes always choose one explicit ABI mode: a supplied ABI, a selected Sourcify candidate, or no ABI. Updates and deletions use the latest resource timestamp; ABI replacement/removal also checks the currently stored digest. Exact no-op edits leave timestamps and audit history unchanged.

Safes in the address book

A Safe may appear as a known address and as an execution account. These records serve different jobs: the address book supports identification and targeting, while the execution registry authorizes transaction effects to execute from the Safe.

Changes do not rewrite history

Editing a display name or enriching an address with an ABI does not change an immutable workflow revision or started run. Save a new workflow revision when registry changes should affect future runs.