> ## Documentation Index
> Fetch the complete documentation index at: https://docs.li.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# 开放意图和 ERC-7863

> LI.FI 正在积极为意图系统做出贡献，通过对 The Compact、开放意图框架 (OIF) 的贡献以及对 ERC-7683 的反馈来推进意图采用和跨链互操作性。

LI.FI 致力于支持和贡献现有和即将推出的意图标准，以统一意图网络，为链抽象铺平道路。

* 通过为 [The Compact](https://github.com/Uniswap/the-compact) 做出贡献，目标是推进资源锁开发并传播开放和无国界的账户抽象实现。

* 与以太坊基金会合作，通过[开放意图框架 (OIF)](https://github.com/openintentsframework/oif-contracts) 为新兴链构建模块化和灵活的意图框架。

* 通过提交对 [ERC-7683](https://www.erc7683.org/) 的反馈并为 ERC-7683 集成到 LI.FI 意图中铺平道路。

## 一般不兼容性

* ERC-7683 非常关注开放接口。这是有道理的，因为 ERC-7683 的初始版本是在资源锁之前构思的。但是，对于资源锁，它提出了一个挑战，因为订单不再总是以链上调用开始。
* ERC-7683 填充函数很昂贵，因为它使用内存而不是 calldata，这是由于提供了透明字节。

### 我们的建议

* 将 `address user` 和 `uint256 nonce` 添加到 `OnchainCrossChainOrder`。
  * 目标：澄清谁是存款人。（代币仍应从 `msg.sender` 收集。）
* 将 `open` 事件转换为 `event Open(bytes32 indexed orderId, bytes resolveContext)` 并添加解析函数，这些函数采用原始订单和 `resolveContext` 以从链下视图调用准确生成 `ResolvedCrossChainOrder`。
  * 目标：降低发出 `Open` 事件的成本。
* 使函数 `open(...)` 和 `openFor(...)` 可选。
  * 目标：明确 `open` 应仅用于存款。
* 使函数 `validate(...)` 成为返回 `(uint32 fillDeadline)` 的视图函数，以轻松验证订单是否有效。
  * 目标：为纯链下订单提供明确的验证方式。

此外，规范应包含如何集成锁流程的描述：先输出，后输入。

您可以在此处阅读有关我们的更改建议的更多信息：
[https://github.com/ethereum/L2-interop/pull/15/files#diff-636d6bbfc9b1e613195503fdc721676aebdd4dd14eeb8d1ac5fb79cceaf2bc2eR28-R46](https://github.com/ethereum/L2-interop/pull/15/files#diff-636d6bbfc9b1e613195503fdc721676aebdd4dd14eeb8d1ac5fb79cceaf2bc2eR28-R46)