-
Notifications
You must be signed in to change notification settings - Fork 65
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
feat: UniswapV3 Provider #311
Conversation
e1a7bef
to
10ae953
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #311 +/- ##
==========================================
- Coverage 62.55% 56.93% -5.62%
==========================================
Files 221 227 +6
Lines 9771 11006 +1235
==========================================
+ Hits 6112 6266 +154
- Misses 3103 4179 +1076
- Partials 556 561 +5 ☔ View full report in Codecov by Sentry. |
providers/apis/uniswapv3/utils.go
Outdated
Interval: 2000 * time.Millisecond, | ||
ReconnectTimeout: 2000 * time.Millisecond, | ||
MaxQueries: 1, | ||
URL: "https://eth.public-rpc.com/", |
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.
This RPC is probably fine to have displayed on our main, can be a good default for people.
we got conflicts :( |
btw our lint is marking files i did not change with errors |
// GoEthereumClient is a go-ethereum client implementation using the go-ethereum RPC | ||
// library. | ||
type GoEthereumClientImpl struct { | ||
client *rpc.Client |
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.
Why do we need to wrap?
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.
2 small comments. My follow up thoughts:
- Do we need to be able to correlate requests among multiple rpc-providers (like solana)
- As needed for raydium, we'll need to have some way to verify that the ProviderMetadata per ticker unmarshals correctly into the expected json-data structure. Ideally, we'd be able to do this on market-map validation
} | ||
|
||
// MustToJSON converts the pool configuration to JSON. | ||
func (pc *PoolConfig) MustToJSON() string { |
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.
Where is this used?
} | ||
|
||
// Parse the result from the batch call for each ticker. | ||
for i, ticker := range tickers { |
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 there a way to guarantee the order of responses from batch-json RPC requests?
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.
the client should return things in the same order, but we can probably resort just for sanity before using the responses.
|
||
## Future Work | ||
|
||
The oracle side car is a combination of the oracle and provider packages. This is being moved to a [separate repository](https://github.com/skip-mev/slinky-sidecar). |
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.
Definitely want this removed 👍 wasn't aware this was in here.
@@ -98,21 +98,3 @@ To test these numbers yourself, spin up the the oracle server following the inst | |||
* [Data Provider Queries](./providers/base/metrics/README.md#usage): Provides general insight into how often price feeds are updated by status (success/failure), provider (binance, coinbase, etc.), price feed (BTC/USD, ETH/USD), and provider type (api/websocket). | |||
* [Websocket Performance Queries](./providers/base/websocket/metrics/README.md#usage): Provides insight into how often websocket providers are successfully updating their data. This is a combination of metrics related to the underlying connection as well as the data handler which is responsible for processing the data received from the Websocket connection. | |||
* [API Performance Queries](./providers/base/api/metrics/README.md#usage): Provides insight into how often API providers are successfully updating their data. | |||
|
|||
## DEFI |
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.
You need to sync w/ @nivasan1 because I think he's just added all of this and you're removing it now.
github.com/gagliardetto/solana-go v1.9.3 | ||
github.com/ethereum/go-ethereum v1.13.14 | ||
github.com/gagliardetto/binary v0.8.0 | ||
github.com/gagliardetto/solana-go v1.10.0 |
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.
@nivasan1 do we have sufficient coverage to convince us that this is ok based on CI passing?
if expected.Cmp(actual) > 0 { | ||
diff = new(big.Float).Sub(new(big.Float).SetInt(expected), new(big.Float).SetInt(actual)) | ||
} else { | ||
diff = new(big.Float).Sub(new(big.Float).SetInt(actual), new(big.Float).SetInt(expected)) |
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.
Can't you just use the Abs
function here?
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.
I don't fully remember why i didn't use Abs
but i do remember not using it for a specific reason. This code might change as we convert to big.Floats so I'd prefer leaving it as is for now.
@@ -149,7 +150,7 @@ func TestAggregateData(t *testing.T) { | |||
result := m.DataAggregator.GetAggregatedData() | |||
require.Equal(t, len(tc.expectedPrices), len(result)) | |||
for ticker, price := range result { | |||
verifyPrice(t, tc.expectedPrices[ticker], price) | |||
math.VerifyPrice(t, tc.expectedPrices[ticker], price, acceptableDelta) |
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.
Why did these become non-deterministic now?
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.
they aren't non-deterministic, they just put a bound on the amount of precision we expect in the resulting calculation. This only applies for big.Ints, for big.Floats we can directly specify precision so much of this might be deprecated with the changes that are following this.
} | ||
|
||
// NewPriceFetcher returns a new Uniswap V3 price fetcher. | ||
func NewPriceFetcher( |
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.
nit: Untested.
closes: BLO-1054
Uniswap V3 Provider implementation
Note: around ~2800 LOC from this PR is from code-generation, much more is testing. I recommend reading over the readme before reviewing