Skip to content
LI.FI Intent 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 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 LI.FI intents. While LI.FI intents 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