Introducing ERC-8313: Protocol Interaction Manifests
Using smart contracts is not an easy task for some protocols. Sometimes a DeFi protocol will consist of multiple smart contracts that have dependencies on each other.
A user’s options are to either read through some documentation and decipher how to build the necessary transactions, or they can connect their wallet to a website that is built and maintained by the team behind the protocol.
That second option is a centralisation risk in an otherwise decentralised system. What happens if the team moves on to another project and stops supporting the website? The smart contracts do not simply disappear. Or worse yet, if the website becomes compromised because of poor cybersecurity; then user keys could be at risk.
Another issue with connecting to these websites is that the current wallet connection logic is built for externally owned accounts. They create a raw transaction and present it to the wallet for signing. This does not work for account abstraction.
Account abstraction requires a user operation to be signed, not a raw transaction. Any website allowing a wallet to connect to it would need to know when that wallet is using account abstraction and instead provide the call data portion of the user operation. The tool connecting the wallet to the website would also need to use the account’s verifySignature function to validate the user operation; it cannot assume that the account uses elliptic-based cryptography.
These protocols will often have documentation available as well as a “software development kit” (“SDK”) so that anyone building a solution that wants to integrate the protocol can do so without the need to connect a wallet to a website.
I have been building a wallet where I want the user to be able to connect to any smart contract they want. It is using account abstraction so the websites are of limited help. The SDKs are also of limited help because I do not want to write custom code for every protocol; that is simply unfeasible.
The solution was to start looking at how interacting with smart contracts could be standardised.
The goal was to create something that could translate intent into transactions.
The result is what I have named the “Protocol Interaction Manifest” (“PIM”).
It is a machine-readable document that describes how to interact with a smart contract protocol. It is not just a list of functions but instead the full workflow required to safely and correctly fulfil a user’s intent.
Get Paul Bark’s stories in your inbox
Join Medium for free to get updates from this writer.
A PIM answers three questions that an ABI cannot:
- What does the user want to achieve? (intent layer)
- What data needs to be gathered first? (lookup layer)
- What transactions need to be build, in what order, with what safety checks? (execution layer)
As long as an application understands the PIM execution model, it will be able to load a manifest for a protocol it has never used before and immediately know how to build a correct, safe transaction on behalf of the user — no hardcoding of protocol knowledge is required.
This pattern could also be beneficial to autonomous agents. Currently, if an agent wants to interact with a smart contract, it has to read the SDK and build custom code. While artificial intelligence has improved its code writing in the past year, it still makes mistakes and hallucinates solutions. With a PIM, the agent just needs to develop the execution engine once and then it is able to use any smart contract it wants without further need to write custom code.
The intent layer provides context on what can be achieved through the protocol. For example, a user may decide to “swap 10 ETH for USDC”. They may already have a protocol in mind, like UniSwap or PancakeSwap, or they may need to find a protocol. The PIM for any such protocol would have in its manifest the intent description of “swap {{amount}} {{tokenIn}} for {{tokenOut}}”.
The intent of that intent description would include instructions on what data is needed to build a transaction. For the above example, the selected protocol may have a factory contract that needs to be called first to identify the pool contracts for the ETH/USDC pairs. Then a second contract may need to be called to get estimates on what amount of USDC would be returned from each pool.
Other steps may require off-chain computations such as acceptable slippage or time limits. The PIM would include the steps required by the application to make those calculations as expected by the protocol.
Once all the necessary information is collected, the application would then be able to build the transaction(s). These instructions could include the approval transaction that is typically required for a swap before the actual swap transaction itself.
During this time, the application’s execution engine would be subject to safety checks too. All transactions would be simulated first to ensure balances change as expected. Excessive approval requests would be flagged as suspicious and warnings would be given to the user. The PIMs would also be subject to a trust level based on the source of the PIM where those created by the protocol team would be trusted more than those written by a hobbyist.
Some may be tempted to point out the simularity with ERC-7730 but they are somewhat the inverse of each other and possibly complementary. ERC-7730 takes a transaction and translates it into intent so a user can be clear of what they are signing; ERC-8313 takes the intent and translates it into a transaction. Applications using ERC-8313 can still use ERC-7730 to provide end users with context of what the PIM is doing; it can be an additional safety check.
Externally owned accounts are on the cusp of obsolescence. They use quantum vulnerable cryptography and rarely provide a good user experience. They are also of limited value to autonomous agents since they offer no way to control spending limits.
Smart wallets are the future and are becoming increasingly more adopted. Protocols will need to adapt to offer better support for these accounts.
A protocol interaction manifest provides this capability. It provides a mechanism to safely use smart contracts in a decentralised way.
If you are interested in learning more, the discussion thread can be found here.
