Emit PoolState After Buy and Sell #11

Activity

1. MeiHui1998 commented on Sep 23, 2026

   

   MeiHui1998

   on Sep 23, 2026

   Last edited by MeiHui1998

   More actions

   Thanks for the detailed explanation. I agree that exact reconstruction is possible with a complete, ordered event history, and I also agree with your suggestion to emit the getReserves() pair directly.

   That is the main goal of this request: making each trade event self-contained for reserve tracking. If a consumer misses events or starts midway, it currently needs to replay the missing history or fetch a state snapshot before it can reliably track reserves.

   The broader design principle is that each event should independently convey the information needed to interpret the state it reports. For a trade event, that means reporting the resulting tradable reserves alongside the trade amounts. Consumers should not need to reconstruct an entire sequence of previous trades merely to understand the pool state after this one. In my view, making that state explicit is a better event interface, not just a workaround for disconnects.

   Pump’s trade events are a useful reference because they include reserve snapshots. A similar design here would let consumers obtain the post-trade reserves from the event itself, without reconstructing the preceding reserve history.

   So this is not a disagreement with the replay approach—it is a request to simplify integration and recovery by including the post-trade pricing reserves directly in the events.