Open Intents & ERC-7863

• By contributing to The Compact with the goal of advancing Resource Lock development and spreading open and borderless account abstraction implementations.
• Working with the Ethereum Foundation on building a modular and flexible intent framework for emerging chains through the Open Intents Framework (OIF).
• By submitting feedback on ERC-7683 and paving a road for ERC-7683 integration into LI.FI intents.

​

General Incompatibilities

• ERC-7683 places a lot of focus on the open interface. This makes sense, as the initial version of ERC-7683 was conceived before resource locks. However, with resource locks, it presents a challenge because orders don’t always start with on-chain calls anymore.
• The ERC-7683 fill function is expensive because it works with memory, not calldata, due to the transparent bytes provided.

​

Our Recommendations

• Add address user and uint256 nonce to OnchainCrossChainOrder.
  • Goal: To clarify who the depositor is. (Tokens should still be collected from msg.sender.)
• Convert the open event into event Open(bytes32 indexed orderId, bytes resolveContext) and add resolve functions that take the original order and resolveContext to accurately produce the ResolvedCrossChainOrder from an off-chain view call.
  • Goal: To reduce the cost of emitting the Open event.
• Make functions open(...) and openFor(...) optional.
  • Goal: To make it explicit that open should only be used for depositing.
• Make function validate(...) a view function that returns (uint32 fillDeadline) to easily validate whether an order is valid.
  • Goal: To provide an explicit way for pure off-chain orders to be validated.