03-22 Lyquor 工程与策略记录

这次 3 月 22 日的周会，讨论的内容比平时更发散一些，但回头看，其实主线很清楚。一条主线是技术上怎么把系统做得更稳定、更适合演示，也更接近可落地的交易基础设施；另一条主线则是，如果项目继续往前推进，应该以什么样的产品定位、公开方式和创业节奏去展开。

先从技术侧说起。一个比较实际的进展，是这周已经尝试用 Lyquid 中的 ERC20 合约连接 MetaMask 做充值测试，整体流程基本已经走通。虽然未来演示时不一定会完全照着这条路径来做，但这至少说明，围绕资产接入和用户侧交互的基础路径，已经开始从概念走向可验证的实现。

这也自然带出了另一个更大的问题：如果系统未来不仅仅停留在单链上，那么底层的执行和共识结构是否可以支撑更灵活的多链接入。会上提到的一个思路，是把不同链上的余额变化统一纳入主系统的共识视角中，再通过后端切换或者兼容 EVM 的方式去扩展。这个方向本身还需要继续细化，但它反映出团队已经不只是把 Lyquor 看成一个单点系统，而是在把它往更通用的执行底座上思考。

另一个重要进展，是交易核心流程的重写和整理继续往前推进。下单、撤单、改单、成交和强平相关的处理已经基本完成，单元自测也做过，并合并到了当前的 clear 侧实现中。真正还在持续消化的部分，不是“功能有没有”，而是如何把原来比较复杂的模型，映射到一个更简洁、也更适合当前系统的表达方式上。

这个讨论和上一篇关于字段建模的思路其实是连在一起的。系统越想靠近更直接、更易理解的外部接口，内部越需要认真处理参数映射、模型压缩和语义统一。简化用户理解，并不意味着简化系统本身，很多时候恰恰相反。

会上另一个非常值得注意的点，是推送服务设计的调整。之前的思路是监听区块事件再向用户推送，但如果底层链路本身是一秒一块，那么用户看到结果就天然会有延迟。这对于交易场景来说，很容易让“链上确认”变成影响体验的瓶颈。因此这次讨论开始明显转向一种更偏链下的处理方式：先把后端结果推送给用户，再完成后续上链动作。

这种调整并不是简单地“追求更快”，而是开始正面面对一个交易系统里很现实的取舍：用户需要更快的反馈，但系统也必须防止错误推送、错误状态传播，以及 WebSocket 服务被劫持后带来的风险。所以问题已经不只是推不推，而是如何在速度、可信度和系统边界之间找到一个合适的平衡点。

这也和会议里对 Hyperliquid 的研究连了起来。大家讨论到，它宣称很高的 TPS，但链上实际看到的 event 数量却并不多，这意味着它在数据表达和状态记录上，大概率做了相当激进的压缩。这里最有意思的地方，不只是“它做到了什么”，而是这会反过来影响我们怎么理解链上记录、链下执行，以及结果回放之间的关系。

在架构层面，这些观察最终又落回到几个很实际的问题上：下单和推送是否都应该是链下服务，clear 和 match 是否要进一步合并，分片能不能作为后续横向扩展的一条路径。这些问题现在未必都有定论，但已经能看出来，团队在思考的不是单个模块怎么补齐，而是整个交易路径的形态应该怎么重新组织。

除了技术部分，这次会议还有一条同样重要的主线，就是项目的产品定位和创业方式。一个比较鲜明的观点是，项目更适合被理解为一个 DeFi 产品，而不是沿用传统中心化交易平台的叙事方式。这里面既有合规层面的考虑，也有增长方式上的考虑。

会议里提到的想法是，如果项目要继续往前推进，与其把大量精力放在一个过早封装的 MVP 上，不如优先把关键业务、架构方向和公开表达打磨清楚。通过直播周会、持续发周报、公开展示进展这些方式，让外部用户和潜在支持者真正看到项目在往哪里走。这种方式和很多传统产品“先闭门做完再拿出来”的路径不太一样，但和当前项目的节奏反而是相匹配的。

最后还有一个讨论点也很值得记下来，就是 ADL 和保证金逻辑的再理解。这里并不是简单复现某个平台的规则，而是想把触发条件、权益变化、可转资金限制这些东西重新想清楚。因为这些规则表面上像是风险控制细节，实际上会直接影响用户体验，也会影响系统是否稳定。

回头看这次周会，我自己的感受是，它没有给出一个单点结论，而是把几条关键主线慢慢拉到了一起。技术侧在继续往更稳定、更可展示的交易路径收敛，产品侧则在思考更公开、更持续的推进方式。对一个还在快速形成中的项目来说，这种同时整理工程问题和外部叙事的过程，本身就很重要。