Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breakdown fees protocol 3/3: DB field and returning on /get_trades #2910

Merged
merged 32 commits into from
Sep 6, 2024

Conversation

sunce86
Copy link
Contributor

@sunce86 sunce86 commented Aug 19, 2024

Description

Related to #2862

Exposes executed protocol fees from database on /get_trades endpoint.

Database fee field is an array of <token, amount> so that we have the flexibility now (and also in the future) to save taken fee in whatever token we want. This was inspired by discussion where even for the same order we considered defining taken protocol fee in sell token for "surplus" variant, while, for "volume" variant it's more logical to define it in non-surplus token (sell token for sell order and buy token for buy order) so that the taken fee doesn't depend on the amount of surplus provided in a solution.

Changes

  • Add new columns protocol_fee_tokens and protocol_fee_amounts to order_execution database table.
  • Expand executedProtocolFees field on Trade struct to return both executed protocol fees and fee policies.

How to test

Updated db test.
Existing tests.
e2e test updated to prove correctness.

@sunce86 sunce86 requested a review from a team as a code owner August 19, 2024 11:09
Copy link

github-actions bot commented Aug 19, 2024

Reminder: Please update the DB Readme.


Caused by:

crates/model/src/trade.rs Outdated Show resolved Hide resolved
crates/database/src/order_execution.rs Outdated Show resolved Hide resolved
database/sql/V068__executed_protocol_fees.sql Outdated Show resolved Hide resolved
Copy link
Contributor

@fleupold fleupold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, let's please avoid any advanced postgres features unless there is a very strong reason to do so (ideally we keep the db as vanilla as possible so we are not locked into a specific DB implementation)

database/sql/V068__executed_protocol_fees.sql Outdated Show resolved Hide resolved
crates/model/src/trade.rs Outdated Show resolved Hide resolved
crates/database/src/order_execution.rs Outdated Show resolved Hide resolved
Copy link

This pull request has been marked as stale because it has been inactive a while. Please update this pull request or it will be automatically closed.

@github-actions github-actions bot added the stale label Aug 28, 2024
@sunce86 sunce86 removed the stale label Aug 28, 2024
@sunce86 sunce86 changed the title Breakdown fees protocol 2/3: DB field and returning on /get_trades Breakdown fees protocol 3/3: DB field and returning on /get_trades Sep 3, 2024
Comment on lines 4 to 5
ADD COLUMN protocol_fee_tokens bytea[] NOT NULL DEFAULT '{}',
ADD COLUMN protocol_fee_amounts numeric(78,0)[] NOT NULL DEFAULT '{}';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was it considered to use a single JSON column?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but i don't see any significant advantage

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ability not to think about the ordering of 2 arrays.

Comment on lines +80 to +81
pub protocol_fee_tokens: Vec<Address>,
pub protocol_fee_amounts: Vec<BigDecimal>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it guarantee in the query that we are retrieving the token and its corresponding amount in the same order? it could be dangerous in case the first token doesn't correspond with the first amount, etc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caller is responsible for storing the values in proper order.

Copy link
Contributor

@fleupold fleupold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's combine fee policy and executed protocol fee into one type please.

crates/autopilot/src/domain/settlement/trade/mod.rs Outdated Show resolved Hide resolved
crates/autopilot/src/domain/settlement/trade/math.rs Outdated Show resolved Hide resolved
crates/model/src/trade.rs Outdated Show resolved Hide resolved
database/README.md Outdated Show resolved Hide resolved
crates/orderbook/openapi.yml Outdated Show resolved Hide resolved
@sunce86 sunce86 self-assigned this Sep 4, 2024
/// Breakdown of protocol fees. Executed protocol fees are in the same order
/// as policies are defined for an order.
pub protocol: Vec<(eth::SellTokenAmount, fee::Policy)>,
pub protocol: Vec<ExecutedProtocolFee>,
Copy link
Contributor Author

@sunce86 sunce86 Sep 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

had to fallback to <total, protocol> since now the values are in different tokens.

willing to revert once the "network" is switched to surplus token as well, since this is a final goal and agreement with solver and frontend team. Doing it in this PR increases significantly the scope.

@sunce86
Copy link
Contributor Author

sunce86 commented Sep 4, 2024

Ok, ready for another round of code reviews

Copy link
Contributor

@MartinquaXD MartinquaXD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly nits but would like to see the DB test also assert that we recover the correct values not just the expected number of entries.

crates/autopilot/src/domain/settlement/trade/mod.rs Outdated Show resolved Hide resolved
crates/database/src/order_execution.rs Outdated Show resolved Hide resolved
crates/database/src/order_execution.rs Outdated Show resolved Hide resolved
crates/database/src/order_execution.rs Outdated Show resolved Hide resolved
crates/orderbook/src/database/fee_policies.rs Show resolved Hide resolved
crates/autopilot/src/domain/settlement/trade/mod.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@fleupold fleupold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good imo, one question I have is if we will also expose this information on the order endpoint (it seems this would be more convenient for the frontend)

crates/database/src/order_execution.rs Outdated Show resolved Hide resolved
crates/database/src/order_execution.rs Outdated Show resolved Hide resolved
crates/autopilot/src/infra/persistence/mod.rs Outdated Show resolved Hide resolved
crates/autopilot/src/domain/settlement/trade/mod.rs Outdated Show resolved Hide resolved
crates/autopilot/src/domain/settlement/trade/mod.rs Outdated Show resolved Hide resolved
@@ -1192,12 +1192,12 @@ components:
allOf:
- $ref: "#/components/schemas/TransactionHash"
nullable: true
feePolicies:
executedProtocolFees:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it sufficient to expose this information on the trade? Currently, we are returning the executed fees on the order (and the frontend plans to display the fee on the order page). Are we also planning to return it there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, will ask the frontend. If they want it on order api as well, I think we can add that in a separate PR.

Copy link
Contributor

@MartinquaXD MartinquaXD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main suggestions were addressed.

@sunce86 sunce86 enabled auto-merge (squash) September 6, 2024 07:22
@sunce86 sunce86 merged commit 5fa5c4f into main Sep 6, 2024
10 checks passed
@sunce86 sunce86 deleted the breakdown-fees-protocol branch September 6, 2024 07:37
@github-actions github-actions bot locked and limited conversation to collaborators Sep 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants