Providing protocol interaction knowledge in machine readable files (translating intent into transactions)

The Problem

Protocol interaction knowledge exists primarily in websites and SDKs and not on-chain or in a portable machine-readable format. The websites set up to support dApps are a centralisation risk that depend upon developer team availability for regular maintenance.

Every DeFi protocol exposes functionality through smart contract ABIs. While an ABI can tell you the function names, parameter types and returned values, it does not tell you anything about how to use them.

The more complex protocols, such as UniSwap and ENS, are a system of smart contracts where one contract may be used to discover details while a different contract is used to complete an action. To use these protocols, a user must either connect their wallet to a dApp’s webpage or write code using an SDK.

As more protocols are introduced, the ability to maintain wallets supporting these protocols becomes more difficult. Every new protocol would require a new integration. Any update to a protocol would require updating code. Supporting 50 protocols means maintaining 50 integrations where none of the logic is portable, auditable, or shareable.

As an example, if an autonomous agent is instructed to “lend 500 USDC on Aave”, it would have to determine that it must call getReserveData first, check the health factor, approve an allowance for the pool contract, call supply with the right referral code, and then confirm that the aToken balance has increased. That knowledge is currently not available in a form that a generic agent can read.

This problem becomes even more significant for generic wallet software, automation systems, and autonomous agents which cannot rely on bespoke integrations for every protocol.

The Solution

A Protocol Interaction Manifest (PIM) is a structured, machine-readable JSON document that describes how to interact with a smart contract protocol. It is not just a list of available functions but the full workflow required to safely and correctly fulfil a user’s intent.

A PIM answers three questions that an ABI cannot:

  • What does the user want to achieve? (intent layer)

  • What on-chain data needs to be gathered first? (lookup layer)

  • What transactions need to be build, in what order, with what safety checks? (execution layer)

A wallet or autonomous agent that understands the PIM execution model can load a manifest for any protocol it has never seen before and immediately know how to build a correct, safe transaction on behalf of the user — without any hardcoded protocol knowledge.

This would be a mechanism that translates intent into transactions.

It would be important to note that this does not replace ABIs but instead would augment them. It would be an optional metadata layer describing workflow semantics and execution requirements.

Safety

While a PIM may facilitate the use of dApps, it would also present a new attack vector if not implemented carefully. Any application using them would need to follow a standard set of best practices as preventative measures. These practices would include, but are not limited to:

  • transaction simulation

  • permission boundaries

  • validation

  • risk disclosures

  • trust levels

  • transaction constraints

The PIM would also include a signature section so that it can be verified against a known public key.

Discovery

An obvious question may be how an application would discover a PIM. This is where the trust levels would be applied. There could be multiple sources for PIMs including the dApp development team, established companies providing them as a service, or private individuals filling gaps. Trust levels would be used to categorise the providers of PIMs. The application would take extra precautions for PIMs with low trust levels such as blocking certain functions or providing additional risk disclosures to the user.

There could be a number of registries for these files available on hosted websites, on-chain, or using IPFS. ENS text records or Ethereum Comment Protocol could also be used to broadcast the PIMs or at the very least broadcast the latest version along with its signature.

In Summary

A Protocol Interaction Manifest would be a structured, machine-readable specification describing how an application, wallet, or automation system can safely interact with a smart contract protocol.

This is what I have as top-level objects in the PIM. There is no safety section because if the PIM was compromised then you could not trust that section anyhow.

This maps closely to work already in progress across a few active proposals, worth making the connections explicit.

On the manifest / discovery layer: agent.json served via ENS CCIP-Read (EIP-3668) is already a deployed version of this pattern for the agent side. The PIM is the protocol-side equivalent, instead of “what can this agent do” it’s “how do you interact with this protocol.” Same discovery infrastructure, complementary documents. ENS text records pointing to an IPFS CID for the PIM, resolved via CCIP-Read, gives you off-chain storage without gas costs per update and ENS-native versioning.

On the safety gap: the “no safety section because a compromised PIM can’t be trusted” problem is exactly what WYRIWE’s sanitization_pipeline_hash addresses. If the agent pins the PIM’s IPFS CID as part of its input commitment:

sanitization_pipeline_hash = keccak256(pim_cid || raw_input_hash)


A tampered or substituted PIM produces a different hash, detectable by any verifier checking the attestation. The safety guarantee doesn’t live inside the PIM; it lives in the commitment scheme that binds which PIM was used to which execution. WYRIWE spec: https://github.com/TMerlini/wyriwe

On the execution / settlement layer: ERC-8183 and ERC-8274 cover what happens after the PIM is consumed, the agent commits to the input, executes, and the output is settled on-chain with a verifiable proof. The PIM gets the agent to the right calldata; WYRIWE + OCP + ERC-8274 prove it used the right PIM to get there.

The three questions you identified (intent / lookup / execution) map cleanly onto the trust stack: WYRIWE anchors what entered the reasoning boundary, OCP anchors it on-chain before execution runs, ERC-8274 verifies the output. The PIM is the missing upstream piece that describes the protocol interaction knowledge the agent consumed, worth a formal requires: link between the specs once this has a number.