Additional Interaction requirements / execution context

[pegahcarter]

Introduction

Interactions are straightforward: one creates data with the chainId, recipient, and functionSelector and passes it into the InteractionRegistry and the Interaction is created. Interactions are re-usable: they can be used repeatedly within the same hub, or across other hubs.

Interactions contain limited data: you don't know strictly based on a recipient and functionSelector the context of what was executed. So, for example, if recipient == UniswapRouter && functionSelector == addLiquidity(), there is no way to differentiate if the liquidity added is 50 ETH worth of ETH/PEPE or 1,000 USDC worth of USDC/DAI. While we do expect off-chain validators to verify specific data, on-chain, the same interaction NFT would be minted in each case. Following this example, this would be disappointing for hub members if they want to showcase their commitment of 50 ETH towards the PEPE meme but don't have the ability to because there is no way to uniquely identify their interaction.

Description

As we have interactions as NFTs we have some hook power: when minting an interaction, we can include data as a callback by the recipient to execute arbitrary data. Specifically, this line of the 1155 means that on receiving the NFT, a contract must implement the right interface for the tx to pass. What we can do, then, is store encoded data to an interaction which, upon transfer, to a contract can be executed. The encoded data would look like such:

• validator address
• functionSelector bytes4
• encodedArguments bytes

This would open up interaction functionality like:

• Only allow this interaction to be minted to hub A
• Only allow this interaction to be minted by member X
• Transfer ERC20 from the member to the hub dao as a fee
• On-chain proof of requirements met

Challenge

Significant engineering effort will be required to complete this task, potentially pushing back MVP date.

@Jabyl