admin
A general-purpose AI agent that interacts with Web3 contracts needs to know which functions a contract actually supports. A language model’s guess about a contract address is not reliable evidence. ERC-165 offers a standardized interface-detection mechanism for supporting smart contracts, but it is not universal and does not describe permissions or economic safety. This article shows how to use capability checks as one input to a carefully constrained AI tool registry.
Understand what ERC-165 detects and what it does not
The ERC-165 standard, created January 23, 2018, defines a way for contracts to report support for interface identifiers. It uses a supportsInterface function with an interface ID derived from function selectors. A positive response can help choose a compatible adapter. It cannot prove the contract is honest, that the user owns an asset, or that a proposed transfer is authorized. The design rule is to treat interface support as a capability assertion requiring additional validation. A contract might implement a recognizable function while deliberately behaving differently from expectations. Maintain an allowlist of reviewed deployment addresses and code versions for value-bearing operations. AI-generated descriptions should not silently add new addresses to that registry.
Perform the mandatory two-step probe correctly
ERC-165 describes checking support for the ERC-165 interface ID, then checking that the invalid all-ones ID is not reported as supported. These positive and negative probes help distinguish a compliant interface detector from arbitrary fallback behavior. Follow the specification’s gas constraints and do not interpret a reverted call as confirmation. Store a distinction between unsupported, call failed and provider unavailable. Use a reproducible fixture with a known compliant test contract, a contract that does not implement ERC-165, a malicious contract that always returns true and a proxy whose implementation changes. Record return data, chain ID, block number, target address and gas consumed. A single Boolean property in a cache hides the evidence needed to diagnose incorrect tool selection.
Do not confuse interface presence with spending authorization
Suppose an AI agent discovers that a contract exposes an expected NFT-related interface. The next tool call might still be an asset transfer requiring explicit approval, owner checks and transaction simulation. Capability detection cannot bypass those steps. Design the workflow so an AI model can request a capability lookup but can only propose spending, not execute it without a user-confirmed policy. Show the intended asset and recipient before asking for a signature. For every adapter, define an authorization predicate and the exact data the agent may access. A read-only metadata request is different from changing token ownership. Use least-privilege RPC credentials where possible and preserve a boundary between capability discovery, policy evaluation, signing and broadcasting.
Cache results with chain and code identity
Capability detection is inexpensive relative to many downstream operations, but repeatedly probing the same contract can waste RPC budget. Cache by chain ID, address, code hash or deployment version, interface ID and a bounded validity period. Proxy upgrades and network switches can invalidate stale results even when the address remains constant. Provide a force-refresh path for incidents and migration testing. Avoid showing ‘verified interface’ as a general trust badge; the only verified statement is that a specified response was observed under specific conditions. Expose the block number and probe result in internal debugging. A contract may be paused or have restrictions even while its declared interfaces remain unchanged. Use separate flags for interface presence, audited implementation status and current authorization.
Design a safe fallback for legacy contracts
Not every useful contract implements ERC-165, and absence of interface detection should not be treated as evidence of maliciousness. Legacy integration may require ABI review, explicit deployment registries, static analysis and integration tests. The ERC-1271 standard, created July 25, 2018, concerns contract-based signature validation and illustrates why detection, signature validity and supported business behavior are separate layers. Do not allow the AI model to compensate for a failed probe by trying arbitrary write transactions until something succeeds. A safer fallback is to classify the contract as unsupported for automated execution and request engineering review. Offer a clear user-facing error, not a fabricated capability claim. Preserve a human-readable reason code that support teams can use without sensitive keys.
Release with differential tests and monitoring
Build a matrix of contract types, chain environments, supported and unsupported IDs, reverting proxies and deliberately misleading responses. Compare each adapter’s predicted capability with an independently configured expected result. Add a negative test where an interface is technically present but the user lacks permission to execute a requested action. Record false-positive and false-negative rates separately. If production monitoring shows unexpected interface outcomes, disable affected adapters while preserving read-only visibility and past records. Attribute each agent action to a versioned adapter, policy decision and human authorization event. ERC-165 helps an agent ask better technical questions; it does not replace security review or transaction-level consent. Publish a minimal incident runbook with owner, escalation threshold and rollback steps so a failure cannot trigger repeated costly agent retries.
