When to provide metadata
| Scenario | Metadata needed? |
|---|---|
| Native transfers (ETH, SOL, SUI) | No |
| Known protocols (Uniswap, Jupiter, Aave) | No (built-in support) |
| Standard token transfers (ERC-20, SPL) | No (built-in support) |
| Custom smart contracts | Yes |
| Anchor programs without public IDL | Yes |
Ethereum: Contract ABI
For Ethereum and EVM chains, provide the contract ABI to decode function calls. ABIs are passed as a map keyed by contract address, so wallets can supply one ABI per contract the transaction touches. For an end-to-end Ethereum integration walkthrough (supported networks, what’s auto-decoded, the rendered payload), see Ethereum for Wallets.gRPC example
Address casing
abi_mappings keys are 0x-prefixed contract addresses. The parser parses each key into a numeric address before registration, so lookup is case-insensitive: 0xdAC17... and 0xdac17... resolve to the same contract. Use a consistent casing convention (all lowercase or EIP-55 checksummed) across your ABI store to avoid duplicate entries for the same address.
ABI format
The ABI is standard Solidity ABI JSON:Specifying network
For EVM chains other than mainnet, setnetwork_id. The parser recognizes a broad set of values (Ethereum mainnet and testnets, BSC, Polygon, Avalanche, Gnosis, Celo, Fantom, Optimism, Arbitrum, Base, Blast, Mantle, World Chain, zkSync Era, Linea, Scroll, Zora, Unichain, and their testnet variants where applicable). The authoritative list is defined by network_id_to_chain_id in src/chain_parsers/visualsign-ethereum/src/networks.rs.
Built-in token metadata is preloaded only for ETHEREUM_MAINNET, POLYGON_MAINNET, ARBITRUM_MAINNET, OPTIMISM_MAINNET, and BASE_MAINNET. On other recognized chains, token symbol and decimal resolution is limited to the built-in registry; chain_metadata currently only accepts network_id and abi_mappings, so wallet-supplied token metadata is not yet supported. Always pass the actual network_id for the chain you’re parsing; the value overrides the transaction’s chain ID and reusing an unrelated one will mislabel the Network field.
Solana: Program IDL
For Solana programs, provide the Anchor IDL to decode instructions:gRPC example
Multiple programs
If your transaction interacts with multiple programs, use the IDL mappings:Supported IDL types
| Type | Description |
|---|---|
SOLANA_IDL_TYPE_ANCHOR | Anchor framework IDL |
SOLANA_IDL_TYPE_SHANK | Shank IDL format |
Library integration
When using the library directly (not gRPC), pass metadata viaVisualSignOptions. The Ethereum metadata shape mirrors the proto: a network_id and an abi_mappings map keyed by contract address.
Obtaining metadata
Ethereum ABIs
| Source | How to get |
|---|---|
| Etherscan | View verified contract → Contract tab → ABI |
| Compilation | solc --abi Contract.sol |
| Hardhat | artifacts/contracts/Contract.sol/Contract.json |
| Foundry | out/Contract.sol/Contract.json |
Solana IDLs
| Source | How to get |
|---|---|
| Anchor build | target/idl/program_name.json |
| On-chain | Some programs publish IDL on-chain |
| Program repo | Check the program’s source repository |
Without metadata
If you don’t provide metadata for a contract interaction, the parser will:- Decode what it can (addresses, amounts in native token)
- Show the function selector (first 4 bytes) as hex
- Display raw calldata for unknown parameters
Next steps
- How Parsing Works: Understand the parsing pipeline
- Error Handling: Handle cases where parsing fails
- gRPC API Reference: Full request/response formats