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

Add partner fee meta-data #53

Merged
merged 13 commits into from
Feb 22, 2024
Merged

Add partner fee meta-data #53

merged 13 commits into from
Feb 22, 2024

Conversation

anxolin
Copy link
Contributor

@anxolin anxolin commented Feb 15, 2024

Add a new type of metadata: partnerFee

This meta-data will allow anyone to encode the intent to charge a fee for a given order.

  • Add new datata type
  • Version schema: v0.12.0 Version schema: v1.0.0 (changes are now breaking changes)
  • Build new types and adapt compile.ts to export the new metadata schema
  • Build tests: happy path, not-so-happy path

Validations

  • The metadata is optional, as all other metadatas
  • If present, all the props are mandatory: bip, recipient
  • bip is an integer (not a string)
  • bip should be greater than zero, and less than 10,000 (the protocol might limit further the maximum, for example 300, or 3%)

See unit tests
image

Example

Example on the new metadata:

partnerFee: {
   bips: 50,
   recipient: '0xb6BAd41ae76A11D10f7b0E664C5007b908bC77C9'
}

Copy link

github-actions bot commented Feb 15, 2024

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

4. Modify the `compile.ts` script

- Add the exported constant with the latest version in, and the new metadata:
- For example: https://github.com/cowprotocol/app-data/pull/44/commits/aeef8a58e7bbd2a53664ce396011cb157a18406d
Copy link
Contributor Author

Choose a reason for hiding this comment

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

unrelated: this link was just broken

@anxolin anxolin marked this pull request as ready for review February 15, 2024 17:08
Copy link
Collaborator

@alfetopito alfetopito left a comment

Choose a reason for hiding this comment

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

Other than the comments, the build is currently broken

src/scripts/compile.ts Outdated Show resolved Hide resolved
"type": "string"
},
"bips": {
"$id": "#/definitions/bips",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you use this definition in the quote slippageBips ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did the other way around here: #55

test/schema.spec.ts Show resolved Hide resolved
@anxolin
Copy link
Contributor Author

anxolin commented Feb 15, 2024

The build was broken before. Fixed in #54

@anxolin anxolin mentioned this pull request Feb 15, 2024
@anxolin anxolin requested a review from a team February 16, 2024 10:20
@@ -627,6 +628,142 @@ describe('Schema v0.11.0', () => {
)
})

describe('Schema v0.12.0', () => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

As mentioned in #55, v0.12 won't be created. It'll be v1.0 instead

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, but the changes are independent and I did the version here. I thought is ok to version it still, as those are 2 different changes and the one in this PR is backward compatible

I will delete the 0.12.0 in #54 instead as it seems you prefer 0.12.0 don't exist. If fine with that

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@fleupold
Copy link

Can we call it bps. Bips is very colloquial and not the official abbreviation: https://www.investopedia.com/ask/answers/what-basis-point-bps

@anxolin
Copy link
Contributor Author

anxolin commented Feb 19, 2024

@fleupold no problem with that on my end. The only issue will be that for coherence would be great if I change it also in the quote information. I could make it part of the breaking change #55

This would require @olgafetisova to adapt the queries, and I'm unsure if that's problematic or not. Maybe she could confirm if it's ok to rename.

@alfetopito
Copy link
Collaborator

@fleupold no problem with that on my end. The only issue will be that for coherence would be great if I change it also in the quote information. I could make it part of the breaking change #55

This would require @olgafetisova to adapt the queries, and I'm unsure if that's problematic or not. Maybe she could confirm if it's ok to rename.

Keep in mind this change would require analytics to handle both cases for quotes

@anxolin
Copy link
Contributor Author

anxolin commented Feb 19, 2024

Keep in mind this change would require analytics to handle both cases for quotes

yes, that was my point. This is why I bring it up:

  • Option 1: keep all as defined in Add partner fee meta-data #53 and Fix build #54 (coherent, using the colloquial term)
  • Option 2: use bps in parnerFee but not in quote (incoherent, using the right term at least in the partner fee)
  • Option 3: use bps in both parnerFee and quote quote (coherent, using the right term, potentially adding trouble for analytics to adapt queries or discard older data in some queries)

@olgafetisova
Copy link

This would require @olgafetisova to adapt the queries, and I'm unsure if that's problematic or not. Maybe she could confirm if it's ok to rename.

We are currently changing slippageBips to integer in the code right away before doing any other adjustments, so I think casting both string and integer to integer should not break anything.

@alfetopito
Copy link
Collaborator

Keep in mind this change would require analytics to handle both cases for quotes

yes, that was my point. This is why I bring it up:

* Option 1: keep all as defined in [Add partner fee meta-data #53](https://github.com/cowprotocol/app-data/pull/53) and [Fix build #54](https://github.com/cowprotocol/app-data/pull/54) (coherent, using the colloquial term)

* Option 2: use bps in `parnerFee` but not in `quote`  (incoherent, using the right term at least in the partner fee)

* Option 3: use bps in both `parnerFee` and quote `quote` (coherent, using the right term, potentially adding trouble for analytics to adapt queries or discard older data in some queries)

Due to historical reasons and consistency, I prefer option 1.
Unless @olgafetisova doesn't mind the additional change/handling to go for option 3

@olgafetisova
Copy link

* Option 1: keep all as defined in [Add partner fee meta-data #53](https://github.com/cowprotocol/app-data/pull/53) and [Fix build #54](https://github.com/cowprotocol/app-data/pull/54) (coherent, using the colloquial term)

* Option 2: use bps in `parnerFee` but not in `quote`  (incoherent, using the right term at least in the partner fee)

* Option 3: use bps in both `parnerFee` and quote `quote` (coherent, using the right term, potentially adding trouble for analytics to adapt queries or discard older data in some queries)

If you change slippageBips to bips then it will break some queries, not a big work to adjust it but might take 1-3 days from Dune side to approve the PR, so we might be experiencing some issues there. So I would prefer the name to stay as it is for slippage.

If you change slippageBips from string to integer, it won't break the code. Everything will remain as is.

@anxolin
Copy link
Contributor Author

anxolin commented Feb 20, 2024

I would personally not add you 1-3 days of work for this name change (discard option 3) @fleupold do you agree?

If we can't change it for the quote, I would slightly prefer option 2, yes it's not coherent but at least we don't keep using the wrong term for some metadata that is more relevant for integrators.

Otherwise, we can go with option 1.

@olgafetisova
Copy link

I went over the documentation again and I do not see any simple way to allow a non-existing column in the code (as it will happen when we add the change). The change has to happen on the ETL side which is written in a flat way (same as in our backend), hence, there is no consideration for columns.
To conclude, my strong preference would be to keep the name as is as I did not find an easy way to adjust the code.

@anxolin
Copy link
Contributor Author

anxolin commented Feb 22, 2024

Okay, I believe we arrive to consensus over option 2. I applied the changes. Will create a release of this library

@anxolin anxolin merged commit 8cc394c into main Feb 22, 2024
5 checks passed
@anxolin anxolin deleted the add-partner-fee branch February 22, 2024 19:25
@github-actions github-actions bot locked and limited conversation to collaborators Feb 22, 2024
Copy link
Collaborator

@alfetopito alfetopito left a comment

Choose a reason for hiding this comment

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

👍

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.

4 participants