Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft PR that provides a template to get started on integrating the new exchange Velocore.
https://docs.velocore.xyz/technical-docs
Preliminary testing has been done on a Tenderly fork on Linea and backdate_pools in functioning with correct pool data.
With the correct fetching of current pool state from backdate_pools, it correctly populates the pool data, allows curve generation and discovery of arbitrage opportunities - however CANNOT handle live events in its current state.
The partial implementation in this POC is modelled on handling of the solidly forks.
This work is concerned primarily with Velocore's volatile pools - they have separate handling for their stable (wombat) pools.
The code presented here is simply a POC and requires rewriting/testing/review.
There are a number of known outstanding issues (by no means is this comprehensive):
Velocore requires the use of 3 contracts Vault, Factory, Lens. The Lens contract was added to the
multichain_addresses.csv
under a new columnancillary_address
(since the Factory falls under factory_address, and the Vault serves much of the router functionality)1.a. Originating from the Vault contract - "Swap" events refer to the "pool" but have a unique challenge of having a list of relevant tokens (bytes) in
tokenRef
and a correspondingdelta
change to the token amounts - these lists can have more than 2 entries! Again, note, this is a delta not the resulting reserve amount = math. This will require specific logic (see appendix 1.a.)1.b. Factory contract can be used to get "PoolCreated" events with the tokens provided as bytes
t1
,t2
(see appendix 1.b.). I was able to implement handling that supports getting the static data from the terraformer (not necessarily perfect but functional in scope).1.c. The Lens contract is used to retrieve pool data and appears to only provide current data (i.e. cannot retrieve previous pool states from this contract). Inside the poolData is the poolParams which contain current reserves for the pool and fee info. Pool data is
LENS.queryPool(pool_address)
(examples in appendix 1.c.).1.d. poolData -> poolParams
WARNING - Pools can be implemented with non-standard (i.e. not 50:50) token weights - while no pools are implemented like this currently it is possible.
The fee for each pool is in the poolParams essentially the first 64 bytes of the poolParams / 10**18
More info on the poolParams: https://github.com/velocore/velocore-contracts/blob/4f9bbbd6e0de052725d8642e3efa4904059d44b2/src/pools/constant-product/ConstantProductPool.sol#L424
An example of extracting info from poolParams is in appendix 1.d - this is not a suggestion for implementation just a POC.
These methods have been used in this draft to successful get static pool data and do backdate_pools - please update as appropriate.
The swap interfaces matches univ2 so it should work with much of the existing infra. More info here: https://docs.velocore.xyz/technical-docs/how-to-interact-with-velocore/uniswap-compatible-interface
For the Event fetching to work correctly, we need to make a choice: a) fetch all pools state from pool data with multicall every iteration or b) tackle the challenges of the "Swap" event containing multiple tokens and using deltas instead of new reserves. If we choose (b) then there are many changes required that I dont have a comprehensive understanding of.
Added a new file
velocore_event_mappings.csv
that may need to be handledSearch TODO, in some cases it was unclear how best to access constants and so some token addresses were temporarily hardcoded - (e.g.
events\pools\velocore_v2.py
)APPENDIX
1.a.
1.b.
1.c.
1.d.