Skip to content

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.

  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.

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.

An owner/admin agent may explicitly create a contract capability with abiSource: "none". This records that the address is a contract without making it callable from ABI-backed workflow authoring. It never triggers a hidden Sourcify lookup; add an ABI later with the guarded update flow.

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.

Use the web app or an agent with registry.write. An agent must supply the latest entry timestamp, current saved digest (or null), and the selected candidate digest when Sourcify is used. Stale values return 409. Review affected workflow source and save new revisions after the change.