Progress logs
View All TagsInitially, we refactored clear-lyquid and match-lyquid so that they are now invoked through a Lyquor instance as the entry point. All state has been converted to instance-level state. The general idea is that multiple instances first initiate a form of local consensus for a transaction, and then the result is committed on-chain.
On March 27, we aligned on several practical directions across engineering, infrastructure, and content operations.
On March 26, we spent time on two connected topics: how exchange feed models differ in practice, and how Lyquid should continue moving toward instance-based execution.
很多时候，一提到交易系统，大家首先想到的都是性能，比如撮合速度、延迟和吞吐量。这些当然很重要，但这次内部讨论让我感觉，真正值得反复琢磨的，未必只有“快”这一件事。
When people talk about trading systems, performance is usually the first thing that comes to mind: matching speed, latency, and throughput. Those things are certainly important. But this internal discussion made me feel that speed is not the only topic worth revisiting again and again.
这次 3 月 22 日的周会，讨论的内容比平时更发散一些，但回头看，其实主线很清楚。一条主线是技术上怎么把系统做得更稳定、更适合演示，也更接近可落地的交易基础设施；另一条主线则是，如果项目继续往前推进，应该以什么样的产品定位、公开方式和创业节奏去展开。
The March 22 weekly meeting covered a wider range of topics than usual, but the main direction became fairly clear in hindsight. One thread was technical: how to make the system more stable, more demo-ready, and closer to something that can serve as real trading infrastructure. The other thread was strategic: if the project keeps moving forward, what kind of product positioning, public-facing approach, and startup rhythm should support it.
On March 9, the discussion moved the project toward a more unified architectural direction. Instead of continuing to think in terms of multiple Lyquid instances with pre-assigned responsibilities, the team aligned on a single-Lyquid design that could host multiple roles while sharing the same underlying state. That shift matters because it changes both the technical implementation path and the way different features, especially matching and index-price-related logic, are expected to coexist.
This diagram reflects the architecture concept discussed on February 27. See the earlier post here.
On February 27, the discussion combined three layers of the project that are usually hard to keep aligned at the same time: contract execution, day-to-day delivery discipline, and the longer-term system architecture. The result was a more grounded view of what had already been validated, where execution was slipping, and which architectural questions still needed sharper answers.
The February 22 discussion narrowed the project down to a practical migration sequence: validate the current system in a realistic environment first, then move service by service toward Lyquid without breaking the existing operational model. The emphasis was not on a big architectural rewrite, but on establishing a baseline, preserving comparability, and reducing uncertainty as each layer is adapted.
The project officially kicked off today, and we began exploring a new approach to implementing a DEX.