-
Notifications
You must be signed in to change notification settings - Fork 87
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
Conversation
Reminder: Please update the DB Readme. Caused by: |
There was a problem hiding this 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)
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. |
ADD COLUMN protocol_fee_tokens bytea[] NOT NULL DEFAULT '{}', | ||
ADD COLUMN protocol_fee_amounts numeric(78,0)[] NOT NULL DEFAULT '{}'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
pub protocol_fee_tokens: Vec<Address>, | ||
pub protocol_fee_amounts: Vec<BigDecimal>, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
/// 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>, |
There was a problem hiding this comment.
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.
Ok, ready for another round of code reviews |
There was a problem hiding this 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.
There was a problem hiding this 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)
@@ -1192,12 +1192,12 @@ components: | |||
allOf: | |||
- $ref: "#/components/schemas/TransactionHash" | |||
nullable: true | |||
feePolicies: | |||
executedProtocolFees: |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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
protocol_fee_tokens
andprotocol_fee_amounts
toorder_execution
database table.executedProtocolFees
field onTrade
struct to return both executed protocol fees and fee policies.How to test
Updated db test.
Existing tests.
e2e test updated to prove correctness.