Fetch: Winning Settlement from Orderbook API #220
Conversation
Introducing transaction log parsing via ethers library with appropriate Contract artifacts. Namely, we introduce dependencies on @cowprotocol/contracts which contain the abi files for GPv2Settlement and iERC20 and suffice for us to decode relevant event data from settlement transactions. For us these are Transfer, Settlement and Trade. We construct Event types out of each which only keep the parts that matter for our purposes (namely TradeEvent having owner as the only relevant field).
|
New dependency changes detected. Learn more about Socket for GitHub ↗︎ 👍 No new dependency issues detected in pull request Bot CommandsTo ignore an alert, reply with a comment starting with Pull request alert summary
📊 Modified Dependency Overview:
|
bh2smith
force-pushed
the
fetch/winning-settlement
branch
from
ffc32bf to
c8d7eaf
Compare
| // TODO - Note that old records have solver = ZeroAddress! | ||
| // We need to rectify this (use txReceipt or whatever Tenderly web-action provides) |
There was a problem hiding this comment.
We will have to get this from the tx.from field of receipt.
bh2smith
changed the title
| import axios from "axios"; | ||
|
|
||
| // https://api.cow.fi/docs/#/ | ||
| const PROD_API_URL = |
There was a problem hiding this comment.
As a comment, although I guess you are already aware, there are rate limits for the API. Not sure if that can potentially create issues.
There was a problem hiding this comment.
I would hope that the rate limit is not more than how frequently settlements are happening.
There was a problem hiding this comment.
Yeah, I would hope so as well, so maybe we don't need to worry about this after all.
There was a problem hiding this comment.
Generally rate limits are more on par with numbers like N per second, so I think we're ok here. However you might have issues with the EBBO thing if you're gonna wake up and make a bunch of requests every 30 minutes.
|
Putting it here as a more general thought. With solver-driver collocation (which will probably happen in the next 2-3 months max), I believe we might not have anything related to the winning solution other than what actually happened onchain. Which means that looking at "uninternalized" calldata will be impossible, unless we explicitly enforce that the winner commits to submitting both versions of the data to the protocol. So I believe the backend team should be involved in this discussion. |
|
Great point @harisang -- then perhaps we should get the ball rolling by tagging someone like, maybe, @sunce86 or @MartinquaXD (who has been working on this). |
Part of #177
A standalone component of the internalized transfer workflow, we fetch the WinningSettlement Data from the Orderbook API. This PR adds a model for the relevant data, a fetching method and tests for all possible cases. Remains in Draft State because we may want to use
txReceiptinstead oftxHashas function input.Furthermore, there are some TODOs regarding whether we should attempt to fetch from the Barn Orderbook when Prod not available. It turns out that there are quite large barn batches and we probably shouldn't ignore them when it comes to accounting. I just don't like how lopsided all our requests are.