Skip to content
Catalyst Documentation

Open Intents & ERC7863

LI.FI strives to support and contribute to existing and upcoming intent standards to unify intent networks to paving the road towards chain abstraction.

By actively contributing to TheCompact with the goal of advancing resource locks 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 OIF.

By submitting feedback on ERC7683 and paving a road for ERC7683 integration into Catalyst. While Catalyst does not support ERC7683 today, the goal is to support it in the future.

General Incompatibilities

Section titled “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

Section titled “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.

Additionally, the specification should contain a description of how to integrate the lock flow: outputs first, inputs second.

You can read more about our recommendations for change here: https://github.com/ethereum/L2-interop/pull/15/files#diff-636d6bbfc9b1e613195503fdc721676aebdd4dd14eeb8d1ac5fb79cceaf2bc2eR28-R46