[matching engine] Track pending orders on user chains #4974

ma2bd · 2025-11-16T07:20:19Z

Motivation

Allow users to display their pending orders without following the entire CLOB appchain

Proposal

Add a new type of message and a field of user chains
Replace Cancel orders by Modify with new quantity equal to 0
Simplify ModifyQuantity to avoid code duplication

Test Plan

CI

Release Plan

These changes should be backported to the latest testnet branch

MathieuDutSik

This design of keeping track of the order structure inside of the Matching Engine is not the standard way that this is done.

What exchanges are publishing are the list of operations. See for example Nasdaq: Computer-To-Computer-Interface.
Then it is the job of the receivers of the information to keep track of he orders and maybe have a nice MapView<AccountOwner, BTreeMap<OrderId, ....>>.

If we follow this design, then what we would do is instead emit events corresponding to the transactions. Then another contract would keep track of those events and of the relevant balances, pending orders, and so on if he so wishes. We have all the functionalities in Linera for that.

afck

@MathieuDutSik: I think what you're suggesting would create a lot more overhead: Each user would have to read all events, rather than get notified about only the messages that concern their own orders.

afck · 2025-11-18T09:41:40Z

examples/matching-engine/src/state.rs

+        let cancel_quantity = state_order
+            .quantity
+            .try_sub(new_quantity)
+            .expect("Attempt to increase quantity");


Feels like we should support that, too.

Instead of distinguishing between deleting, reducing and adding an order, why not just have a single operation that sets the quantity for a given price? (Just a thought; not something for this PR!)

that's what we do in this PR!

Are we? I can see that it's being unified with canceling an order, but not with creating an order?

afck · 2025-11-18T09:47:33Z

examples/matching-engine/src/contract.rs

+                        let removal_message = Message::OrderUpdated {
+                            owner: filled_owner,
+                            order_id: filled_order_id,
+                            new_quantity: Amount::ZERO,


What about partially filled orders?

line 253 below

Do you mean orders that were already in the book? Apparently we do not support this?

I think insert_and_uncross_market does partially fill orders. E.g. if there's a single bid in the book with an amount of 10, and I make an ask with an amount of 5 and the same price, my ask will be filled, and the bid will be reduced by 5 but remain in the book.

In that case we should probably send a message to the bidder as well, to notify them that their order was partially filled, i.e. modified?

examples/matching-engine/src/lib.rs

afck · 2025-11-18T10:15:23Z

examples/matching-engine/src/lib.rs


-        // Test Cancel order (should always succeed)
-        let cancel_order = Order::Cancel { owner, order_id: 1 };
+        // Test order cancellation.


(I still think this whole test is not really carrying its weight: It just tests different methods that all delegate to the same, simple, precision check, regardless of the order type.)

examples/matching-engine/src/state.rs

afck · 2025-11-18T10:17:09Z

examples/matching-engine/src/state.rs

    /// The map giving for each account owner the set of order_id
-    /// owned by that owner.
+    /// owned by that owner (used on the matching engine chain).


Suggested change

/// The map giving for each account owner the set of order_id

/// owned by that owner.

/// owned by that owner (used on the matching engine chain).

/// The map giving for each account owner the set of order IDs

/// owned by that owner.

examples/matching-engine/src/state.rs

MathieuDutSik · 2025-11-18T14:22:57Z

@MathieuDutSik: I think what you're suggesting would create a lot more overhead: Each user would have to read all events, rather than get notified about only the messages that concern their own orders.

Well,
It depends on what we want to achieve:

Typically, when doing transactions, there aren't really that many transactions. The 1M achievement is just that, an achievement that has little relation to real usage. There are about 60K visa card transactions per second. So, the 1M is a little irrelevant. What is more important for payment is the latency.
So publishing all the transactions and reading them does not strike me as a bad idea.
The inconvenience of accessing pending_orders is that we have to parse the view and the BTreeMap. But yes, the managing of the orders is done by the contract.

afck · 2025-11-18T14:26:23Z

Sure, I'm not against also publishing all transactions in an event stream. I agree that could be useful, and I didn't mean to suggest that the overhead for the network would be large.

I just mean that for an individual user making an order it makes sense to me that there should be a low-overhead way to know their order status. This implementation provides that using a message. Subscribing to and filtering the event stream would be a lot more work for the client.

ma2bd · 2025-11-18T14:59:22Z

This design of keeping track of the order structure inside of the Matching Engine is not the standard way that this is done.

I don't understand this comment

We're only modifying the state of the application in user chains (acting as a client)
We're not tracking new information

Co-authored-by: Andreas Fackler <[email protected]> Signed-off-by: Mathieu Baudet <[email protected]>

ma2bd changed the title ~~Track pending orders on user chains~~ [matching engine] Track pending orders on user chains Nov 16, 2025

ma2bd force-pushed the clob_ack_messages branch 2 times, most recently from 1a9da86 to 8d5207e Compare November 18, 2025 01:10

ma2bd marked this pull request as ready for review November 18, 2025 01:21

ma2bd requested review from MathieuDutSik and afck November 18, 2025 01:21

ma2bd added 2 commits November 17, 2025 20:29

add order receipts

a5cce69

new_quantity

a731c23

ma2bd force-pushed the clob_ack_messages branch from 5523e98 to a731c23 Compare November 18, 2025 01:29

MathieuDutSik reviewed Nov 18, 2025

View reviewed changes

afck reviewed Nov 18, 2025

View reviewed changes

ma2bd and others added 5 commits November 18, 2025 10:02

Update examples/matching-engine/src/state.rs

dd50d85

Co-authored-by: Andreas Fackler <[email protected]> Signed-off-by: Mathieu Baudet <[email protected]>

Update examples/matching-engine/src/state.rs

1714dd2

Co-authored-by: Andreas Fackler <[email protected]> Signed-off-by: Mathieu Baudet <[email protected]>

Update examples/matching-engine/src/state.rs

63627f4

Co-authored-by: Andreas Fackler <[email protected]> Signed-off-by: Mathieu Baudet <[email protected]>

Update examples/matching-engine/src/lib.rs

8399843

Co-authored-by: Andreas Fackler <[email protected]> Signed-off-by: Mathieu Baudet <[email protected]>

Update examples/matching-engine/src/state.rs

ae80085

Co-authored-by: Andreas Fackler <[email protected]> Signed-off-by: Mathieu Baudet <[email protected]>

[matching engine] Track pending orders on user chains #4974

Are you sure you want to change the base?

[matching engine] Track pending orders on user chains #4974

Uh oh!

Conversation

ma2bd commented Nov 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Proposal

Test Plan

Release Plan

Uh oh!

MathieuDutSik left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

afck left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MathieuDutSik commented Nov 18, 2025

Uh oh!

afck commented Nov 18, 2025

Uh oh!

ma2bd commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ma2bd commented Nov 16, 2025 •

edited

Loading

MathieuDutSik left a comment •

edited

Loading

ma2bd commented Nov 18, 2025 •

edited

Loading