feat: Reference token

[marcovc]

Problem

I suppose I am missing it, but in the new JSON solver API I don't see a way to figure out which the native token is, and consequently in which blockchain we are. Before there was a normalize_priority attached to each token, and for mainnet it would be 1 for WETH and 0 for all others. This would set the "reference token".

This is useful to implement sanity checks of the solution using absolute tolerances (in e.g USD) in addition to relative tolerances. Also for generating interaction data, collecting extra liquidity, simulating, etc. Finally for debugging a solution, it is useful to express volumes in the native token.

The only workaround I see would be to find the token with external price of 1e18, but per docs I am not sure must exist if there is no trader order trading WETH in the auction.

[fleupold]

Other than knowing on what chain we are (which could probably be solved by using a dedicated endpoint per chain), are there other advantages of highlighting the reference token that would warrant putting it on the instance directly (we are trying to keep this model clean and minimal)?

[marcovc]

If there is a way to know which chain we are, then we can hardcode a map between chain and ref token on our end.

But I think that is suboptimal. The instance file should have everything we need to solve it and debug it. If we want to rerun the solver on an old instance, where do we get the chain info from?

Additionally, oftentimes we create small artificial problems to illustrate some issue, or on our e2e tests, and these have artificial tokens like A and B, and one of them is the ref token. Of course we could keep supporting the previous version of the API just to run these, but in my opinion that seems a large burden just to avoid adding one or two fields to new API.

[fleupold]

The instance file should have everything we need to solve it and debug it.

I know we started with the model that the solver engine should be a stateless pure function, but I don't think this has manifested in practice as (I believe all) sophisticated solvers do their own state enrichment (liquidity fetching, gas price estimation, volatility analysis), which is why we started being less strict about model. That being said, I think even without the reference token pointed out explicitly, the instance should be "solvable".

I would say the need for checking certain tolerances is another example for custom solver engine state (e.g. if ETH is the reference token you also need to pass in some relatively up to date price if you want to compute USD slippage tolerances).

[marcovc]

which could probably be solved by using a dedicated endpoint per chain

So instead of having the driver insert a field with the name of the chain or the name of the native token, we will have to create N endpoints, and then in each endpoint end up doing exactly that - insert the chain id in the json (because jsons are not only solved, they are also stored for future inspection, they are logged, and so on).

I still find it more complex than it needs to be, just to save adding a field. I mean, there is already the concept of native price in the json, why can't it also say what the native token is?

Anyway, there are more important things worth disagreeing about :)

[github-actions[bot]]

This issue has been marked as stale because it has been inactive a while. Please update this issue or it will be automatically closed.