Protocol fee switch-over timestamp #3907

squadgazzz · 2025-11-13T20:34:42Z

Description

#3900 introduced a way to show the volume fees to users in advance via quotes. Autopilot should start applying the same policies simultaneously to avoid situations where the user receives an incorrect quote. This PR introduces timestamp-based configs in both orderbook and autopilot crates that control when the volume fee should start applying.

For the orderbook, it is pretty straightforward, which adds an optional timestamp param to the existing volume fee factor config, and each time the service tries to apply volume fees, it checks for the current time. If the timestamp config is None, it means volume fees are applied unconditionally, which should be useful once switched to a long-lasting config.

The autopilot config is a bit more sophisticated. It introduces a separate "upcoming" fee policies config with the effective "from" timestamp. So, if another order's creation timestamp is after the configured upcoming fee policy timestamp, the service starts using this fee policy. This is useful because the volume fee factor affects price improvement and surplus fee policy caps, so each time the volume fee factor is updated, other fee policy configs need to be adjusted accordingly, so we need to switch to the new fee policies set altogether. The config is also optional and can be easily switched to permanent.

The major disadvantage of this approach is that orderbook and autopilot use configs from different sources. A more correct approach would be to use a shared config via a DB or similar, but this would require many more changes, and we should probably avoid any mistakes by making deeper reviews.

How to test

New e2e tests.

# Conflicts: # crates/orderbook/src/arguments.rs

Copilot

Pull Request Overview

This PR introduces timestamp-based configuration for volume fee policies to ensure synchronization between the orderbook and autopilot services. The changes enable both services to start applying volume fees at the same configured time, preventing users from receiving incorrect quotes.

Added optional effective_from_timestamp to volume fee configuration in orderbook
Introduced "upcoming" fee policies configuration in autopilot with effective timestamp
Both services now check timestamps before applying volume fees

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
crates/orderbook/src/run.rs	Updated to pass the new `volume_fee_config` structure instead of simple fee factor
crates/orderbook/src/quoter.rs	Added timestamp checking logic to only apply volume fees when effective timestamp is reached, updated tests
crates/orderbook/src/arguments.rs	Refactored volume fee configuration into a `VolumeFeeConfig` struct with optional `effective_from_timestamp` field
crates/e2e/tests/e2e/quoting.rs	Updated test to use new command-line arguments with future timestamp to verify fee is not applied
crates/e2e/tests/e2e/protocol_fee.rs	Added new test for upcoming future fee policies and updated existing test to use new configuration structure
crates/e2e/tests/e2e/limit_orders.rs	Migrated from `to_string()` to `into_args()` method for protocol fee configuration
crates/e2e/src/setup/fee.rs	Restructured `ProtocolFeesConfig` to support upcoming fee policies and converted Display implementation to `into_args()` method
crates/autopilot/src/run.rs	Updated to pass the full fee policies config structure instead of individual parameters
crates/autopilot/src/domain/fee/mod.rs	Added logic to select between current and upcoming fee policies based on order creation timestamp
crates/autopilot/src/arguments.rs	Introduced `FeePoliciesConfig` and `UpcomingFeePolicies` structures to support timestamp-based fee policy switching

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

crates/orderbook/src/quoter.rs

crates/autopilot/src/arguments.rs

# Conflicts: # crates/e2e/tests/e2e/quoting.rs # crates/orderbook/src/arguments.rs # crates/orderbook/src/run.rs

m-sz

Thanks for extensively covering the change by well documented E2E tests!

m-sz · 2025-11-14T13:24:16Z

crates/e2e/tests/e2e/protocol_fee.rs

+
+    let order = services.get_order(&uid).await.unwrap();
+    let fee_in_buy_token = quote.fee_amount * quote.buy_amount / quote.sell_amount;
+    assert!(order.metadata.executed_fee >= fee_in_buy_token + quote.sell_amount / 10);


The 10 comes from effective Volume Fee Policy set to 0.1 right?

This test is just a copy of the previous buy order, with a single tiny configuration difference.

m-sz · 2025-11-14T13:27:50Z

crates/autopilot/src/domain/fee/mod.rs

+pub struct UpcomingProtocolFees {
+    fee_policies: Vec<ProtocolFee>,
+    effective_from_timestamp: DateTime<Utc>,
+}


Can we handle the upcoming/general protocol fees uniformly, by having the "always present" fees just start at UNIX epoch? This would simplify the approach, although will add timestamp checking to all fees in general. Let's discuss :)

Sorry, I didn't get your comment. Could you rephrase?

The ProtocolFees struct:

pub struct ProtocolFees { fee_policies: Vec<ProtocolFee>, max_partner_fee: FeeFactor, upcoming_fee_policies: Option<UpcomingProtocolFees>, }

contains fee_policies that are always applied unless superseded by upcoming_fee_policies which are essentially the same, but with an activation timestamp.

I was suggesting to unify these two, and instead support the generally applicable and late activated protocol fees in the same way. This would require the fee_policies to be a Vec of UpcomingProtocolFees.

But thinking about it the second time, I think it would unnecessarily complicate the solution as currently we support only 1 instance of upcoming protocol fees, whereas the generalization would have to support an arbitrary number of upcoming protocol fees. Then the evaluation would require making sure We apply the correct protocol fee based on the current time.

I am happy to approve the PR as-is.

fafk · 2025-11-14T13:54:21Z

So, if another order's creation timestamp is before the configured upcoming fee policy timestamp, the service starts using this fee policy.

Do you mean after the configured upcoming fee policy?

squadgazzz · 2025-11-14T14:27:56Z

Do you mean after the configured upcoming fee policy?

Yes, my bad.

m-sz

LGTM

m-sz · 2025-11-14T15:29:18Z

crates/autopilot/src/domain/fee/mod.rs

+pub struct UpcomingProtocolFees {
+    fee_policies: Vec<ProtocolFee>,
+    effective_from_timestamp: DateTime<Utc>,
+}


The ProtocolFees struct:

pub struct ProtocolFees { fee_policies: Vec<ProtocolFee>, max_partner_fee: FeeFactor, upcoming_fee_policies: Option<UpcomingProtocolFees>, }

contains fee_policies that are always applied unless superseded by upcoming_fee_policies which are essentially the same, but with an activation timestamp.

I was suggesting to unify these two, and instead support the generally applicable and late activated protocol fees in the same way. This would require the fee_policies to be a Vec of UpcomingProtocolFees.

But thinking about it the second time, I think it would unnecessarily complicate the solution as currently we support only 1 instance of upcoming protocol fees, whereas the generalization would have to support an arbitrary number of upcoming protocol fees. Then the evaluation would require making sure We apply the correct protocol fee based on the current time.

I am happy to approve the PR as-is.

fleupold

Overall the PR looks good (thanks for adding a test!). I think the semantics we want though is that even orders that are already in the orderbook should start carrying the new fee policies.

which should be useful once switched to a long-lasting config.

I would hope we remove this config once it's permanent.

fleupold · 2025-11-14T15:55:52Z

crates/autopilot/src/arguments.rs

-    #[clap(long, env, default_value = "0.01")]
-    pub fee_policy_max_partner_fee: FeeFactor,
+    #[clap(flatten)]
+    pub fee_policies_config: FeePoliciesConfig,


nice refactoring!

fleupold · 2025-11-14T16:02:24Z

crates/autopilot/src/domain/fee/mod.rs

    ) -> domain::Order {
-        let protocol_fees = self
-            .fee_policies
+        // Use new fee policies if the order creation date is after their effective


I don't think this is the desired logic. As of the target date, all orders that are settled should be settled according to the new fee policies (as these are what decides the rewards that solvers will receive for these trades0.

In particular, a limit order that has been placed in the past should also carry the new fee policy going forward.

I'm not sure what the best way to achieve this is, but don't we build the fee policies from scratch on every auction? In this case I'd apply the logic like in the orderbook - as of a certain timestamp we start adding them unconditionally on when the order was placed.

fafk · 2025-11-14T16:36:38Z

crates/orderbook/src/quoter.rs

    }
+
+    #[test]
+    fn test_ignore_volume_fees_before_effective_date() {


Should it also test the other case so we know the timestamp flow works?

squadgazzz added 4 commits November 13, 2025 19:52

Protocol fee switch-over timestamp

7be3dee

Adapt orderbook

c44359e

Optional timestamp

e519dff

Fix config collision

5415644

squadgazzz force-pushed the protocol-fees-timestamp branch from 919126f to 5415644 Compare November 13, 2025 21:07

squadgazzz added 9 commits November 14, 2025 08:09

Clap fix

6f8a75b

Config fix

b08afdf

Extend tests

096ce99

More e2e tests

ff799ff

Merge branch 'orderbook/volume-fees' into protocol-fees-timestamp

1015c1b

Fix

828b7dd

Update tests

a6cbac6

Adjust config

fd56126

Merge branch 'orderbook/volume-fees' into protocol-fees-timestamp

d6c19b6

# Conflicts: # crates/orderbook/src/arguments.rs

squadgazzz marked this pull request as ready for review November 14, 2025 09:32

squadgazzz requested a review from a team as a code owner November 14, 2025 09:32

Copilot AI review requested due to automatic review settings November 14, 2025 09:32

Copilot started reviewing on behalf of squadgazzz November 14, 2025 09:33 View session

Copilot finished reviewing on behalf of squadgazzz November 14, 2025 09:34

Copilot AI reviewed Nov 14, 2025

View reviewed changes

crates/orderbook/src/quoter.rs Outdated Show resolved Hide resolved

crates/autopilot/src/arguments.rs Outdated Show resolved Hide resolved

squadgazzz added 2 commits November 14, 2025 09:35

Merge branch 'orderbook/volume-fees' into protocol-fees-timestamp

3a93506

# Conflicts: # crates/e2e/tests/e2e/quoting.rs # crates/orderbook/src/arguments.rs # crates/orderbook/src/run.rs

Wording

20ef2c6

m-sz reviewed Nov 14, 2025

View reviewed changes

m-sz approved these changes Nov 14, 2025

View reviewed changes

fleupold reviewed Nov 14, 2025

View reviewed changes

fafk reviewed Nov 14, 2025

View reviewed changes

Protocol fee switch-over timestamp #3907

Are you sure you want to change the base?

Protocol fee switch-over timestamp #3907

Uh oh!

Conversation

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

Uh oh!

Description

How to test

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

m-sz 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!

fafk commented Nov 14, 2025

Uh oh!

squadgazzz commented Nov 14, 2025

Uh oh!

m-sz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fleupold 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

squadgazzz commented Nov 13, 2025 •

edited

Loading