Contract ABIs, Sourcify, and overloads

txcast encodes ABI-backed calls only from ABIs saved in your organisation. Workflow authoring never performs a hidden external ABI lookup.

Import from Sourcify

1. Inspect the contract in the address book or through an agent.
2. Review deployed-code status and any proxy or implementation candidates.
3. Choose the exact candidate whose ABI you intend to trust.
4. Confirm the expected ABI digest.
5. Register the contract.

txcast fetches Sourcify again before committing and rejects a stale digest. A temporary Sourcify outage is retryable; “not found” means no verified candidate was available for the selected address.

Caution

A proxy’s callable interface may be published on the proxy, the implementation, or both. Confirm the implementation address through the proxy design and trusted project material before importing it.

Supply an ABI

Use a supplied ABI only when you can obtain it from a trustworthy build artifact or project release. txcast validates functions, inputs, outputs, tuple components, mutability, canonical signatures, and duplicates.

Do not paste private source code or secrets. An ABI describes a public interface and should not contain credentials.

Overloaded functions

Overloads are selected by canonical Solidity signature, not only by name:

transfer(address,uint256)
configure((address,uint256))

Tuple signatures include their component types recursively. If an older saved key is ambiguous, txcast fails closed and asks you to reselect the function.

Replace an incorrect ABI

Agent registration cannot overwrite a conflicting ABI. Use the web app’s explicit administrative replacement flow after independently verifying the new ABI, then review affected workflow drafts and save new revisions.