admin
An AI agent that calls an on-chain service cannot safely infer contract functionality from a brand name or promotional claim. ERC-165 offers a standard way for some smart contracts to report which interfaces they implement. That is useful but narrow. A contract may advertise the expected function selectors while behaving deceptively, charging unexpected fees or operating under an untrusted upgrade administrator. A responsible agent needs to separate technical compatibility from identity, authority, spending limits and evidence of the requested service. This guide turns ERC-165’s limited guarantee into a practical discovery and verification workflow.
Know precisely what interface detection guarantees
ERC-165 was finalized in April 2018. It defines a supportsInterface(bytes4) query and a way of deriving identifiers from function selectors. An integrating client can ask a compliant contract whether it implements a particular interface without relying solely on project documentation. The standard also describes a detection process that checks the known ERC-165 identifier and rejects the invalid 0xffffffff identifier.
A successful response does not prove that the contract implements the method honestly or that its behavior will remain unchanged. An adversarial contract can return an expected boolean while producing misleading business results. The client should treat support as a compatibility hint, then perform authorization and behavioral checks independently.
For an AI-agent workflow, store the exact interface identifiers expected by each tool and the chain and contract where they were observed. Avoid translating a single true response into a broad claim that a seller is verified.
Build a capability manifest with provenance
An agent buying computing services may need to request a quote, submit a job, inspect a delivery receipt, cancel unused capacity or recover funds. Map those operations to formal interfaces where available. If no standard exists for a function, document its audited ABI and version explicitly rather than inventing a universal interface identifier that the ecosystem has not adopted.
The manifest should also identify the deployment network, contract address, implementation or code fingerprint, service terms and date of review. A capability queried last month might no longer represent current behavior if the contract is upgradeable or the upstream service has changed. Refresh discovery at appropriate risk boundaries.
Treat missing or contradictory manifest entries as reasons to stop and request clarification. Do not let an AI model improvise arbitrary selectors simply because a supplier claims broad compatibility with Web3 agents.
Authorize calls separately from capability checks
The ability to call a contract function is not authority to spend a customer’s assets. Before any state-changing transaction, verify the approved wallet, chain, destination address, token, quantity, deadline and remaining budget. Contract-wallet validation may involve ERC-1271, a different standard that lets a wallet determine whether a signature is valid. Neither ERC-1271 nor ERC-165 independently certifies the target seller’s honesty.
Bind an agent’s privileges to the narrowest necessary function set. Give unknown destinations no permissions by default. If a tool proposes to redirect an authorized payment to a new contract, the agent should require a new approval rather than copying the old spending allowance.
For high-value or irreversible tasks, retain a human review step and show which signature or policy permitted the call. A clear authorization receipt is easier to audit than a generic message that ‘the wallet was connected’.
Test hostile contracts before production
A happy-path unit test with the supplier’s own demonstration contract proves little about how the integration behaves under attack. Include test doubles that claim ERC-165 support but revert on the actual call, charge more than quoted, return inconsistent receipts, or refuse refunds. Add a proxy that changes its implementation after the initial capability check.
Test reentrancy, unexpected callback behavior, incorrect network selection and sessions whose approved budget has already been consumed. Each test should assert the wallet balance and service state afterward. A failed transaction may still consume gas, and off-chain effects may not be reversible simply because an on-chain operation reverted.
Record test input, contract revision, expected rejection and observed outcome. A screenshot of a successful transaction is not a sufficient release artifact for an autonomous spending system.
Link service evidence to the actual transaction
A successful blockchain transaction shows that code executed, not that an inference model returned a correct response or met a promised service level. Attach a task identifier, request receipt, agreed output constraints and any relevant delivery digest to the commercial order. Preserve sensitive prompts and customer records in access-controlled storage rather than placing them directly on a public ledger.
Design a dispute path for unavailable capacity, partial delivery, unacceptable results and duplicate charges. The business contract should state whether a job can be canceled after execution begins and how an agent discovers that status. An interface bit does not encode those commercial conditions.
A complete transaction record allows an operator to explain what was purchased, which contract handled payment and what evidence justified settlement. That accountability is more valuable than treating every compatible contract as an interchangeable vendor.
Publish independent capability and risk findings
Before launch, list supported interface IDs, exact deployments, authorized operations, spending limits, upgrade trust assumptions and negative test results. Re-evaluate when critical code, account policy or payment destinations change. Make it possible for a non-developer operator to revoke credentials and stop new agent transactions without needing to recompile contracts.
Measure integration reliability, denied unauthorized calls, incident response time and cost per accepted task. Do not rely exclusively on gas used or the number of contract calls that succeeded. If an agent can execute a method but cannot safely explain the corresponding commercial transaction, the system is not ready for unrestricted automation.
The useful division of labor is clear: ERC-165 checks advertised technical compatibility, ERC-1271 can validate signatures for contract wallets, and the product supplies identity checks, business policy and service assurance. Robust autonomy requires all of them.
