feat: Update sdks to use svm opportunities #2009
Conversation
m30m
commented
Oct 8, 2024
m30m
commented
- Add necessary types for fetching SvmOpportunities
- Remove relayerSigner and feeReceiverRelayer from configs since they are dynamic and should not be hardcoded in the sdk but fetched in the initialization of the client
- Add fill rate option to the sample searchers
- Add support for submitting SvmOpportunities in the js sdk (python not supported yet)
- Add necessary types for fetching SvmOpportunities - Remove relayerSigner and feeReceiverRelayer from configs since they are dynamic and should not be hardcoded in the sdk but fetched in the initialization of the client - Add fill rate option to the sample searchers - Add support for submitting SvmOpportunities in the js sdk (python not supported yet)
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
| } | ||
|
|
||
| async opportunityHandler(opportunity: Opportunity) { | ||
| if (!("targetContract" in opportunity)) |
There was a problem hiding this comment.
Are we trying to validate fields and type here or just checking if it's a Svm or Evm opp?
There was a problem hiding this comment.
just checking it's an Svm/Evm opp.
| return bid; | ||
| } | ||
|
|
||
| async opportunityHandler(opportunity: Opportunity) { |
There was a problem hiding this comment.
Can we change the code so that opportunityHandler get a svm opportunity as input?
There was a problem hiding this comment.
I don't think so, this would affect all the subscription interfaces.
|
|
||
| async opportunityHandler(opportunity: Opportunity) { | ||
| if (!("order" in opportunity)) | ||
| throw new Error("Not a valid SVM opportunity"); |
There was a problem hiding this comment.
Is it okay to throw when getting invalid opp?
There was a problem hiding this comment.
If you have subscribed to a SVM chain and receive EVM opportunities, I think you should throw and it's fine here
| await new Promise((resolve) => setTimeout(resolve, 2000)); | ||
| await this.fetchConfig(); | ||
| try { | ||
| await this.client.subscribeChains([argv.chainId]); |
There was a problem hiding this comment.
I think if we pass a chain_type to server with chain_id, we can remove bunch of type checkings above :-?
There was a problem hiding this comment.
true, assuming we want to keep stuff backward compatible and not change a lot on the server side, I thought this is a good enough solution
| self.fill_rate = fill_rate | ||
| self.express_relay_metadata = None | ||
|
|
||
| async def opportunity_callback(self, opp: Opportunity): |
There was a problem hiding this comment.
Maybe the opp here is a OpportunitySvm type?
There was a problem hiding this comment.
this is the general callback and should accept a general opportunity type. I know it's suboptimal, but I guess the alternative is to have separate callbacks for svm and evm which is ugly in another way 😅
| await self.evaluate_order(order) | ||
|
|
||
| async def evaluate_order(self, order: OrderStateAndAddress): | ||
| async def assess_opportunity(self, opp: Opportunity) -> BidSvm: |
There was a problem hiding this comment.
I will move this check to the other function so that this one only accepts OpportunitySvm
express_relay/sdk/python/express_relay/searcher/examples/simple_searcher_svm.py
Show resolved
Hide resolved
express_relay/sdk/python/express_relay/searcher/examples/simple_searcher_svm.py
Show resolved
Hide resolved
express_relay/sdk/python/express_relay/searcher/examples/simple_searcher_svm.py
Show resolved
Hide resolved
2 participants
