docs: getQuote API #48
Conversation
| // priority: which token the user prefeer to spend (e.g., 0 = Max Priority) | ||
| userBalances: Map<chainId, {balance, tokenAddress, priority}> | ||
|
|
||
| // Desired amount to receive on target chain (as integer string in wei) |
There was a problem hiding this comment.
We should consider the target outputs to be a mapping as well, accepting multiple desired outputs
| targetTokenAddress: string | ||
|
|
||
| // Optional: specify which routing algorithm to use | ||
| algorithm?: 'greedy' | 'dynamic-programming' | 'dijkstra' | 'multi-objective' | 'genetic' | 'simulated-annealing' | 'ant-colony' | 'a-star' |
There was a problem hiding this comment.
If the server does not support this configuration, should it return an error or simply ignore it?
There was a problem hiding this comment.
We could return a NotValidAttribute error, and if the algorithm attribute is valid but the algorithm is not there, we could return a NotFoundAlgorithm error, mentioning the implemented algorithms
| }> | ||
|
|
||
| // Sum of all fees across all steps (in wei of respective native tokens) | ||
| totalFee: string |
There was a problem hiding this comment.
How would this work if there are multiple native tokens involved? We should consider this to be an array of objects (network, fee)
There was a problem hiding this comment.
You are right let's change this for usdTotalFee and then they have each fee inside each step
|
|
||
| ### **Disadvantages:** | ||
|
|
||
| - **Limited Transparency**: Users cannot see alternative options or understand trade-offs |
There was a problem hiding this comment.
We can potentially change the response format to be an array of options, each option being the currently proposed schema, but allowing solvers to return different options that the client then can decide to show to the users
|
|
||
| - **Limited Transparency**: Users cannot see alternative options or understand trade-offs | ||
| - **Reduced Control**: Wallets cannot implement custom routing preferences | ||
| - **Trust Dependency**: Users must trust the server's optimization choices |
There was a problem hiding this comment.
Is this not the definition of an intent? Users do not need to worry about middle steps, and rather select the better output.
There was a problem hiding this comment.
You're right. But anyway, I think it's worth mentioning it as a disadvantage to see the trade-offs between approaches.
Like, Approach 2: Client-Side Route Calculation plus a Route endpoint would still have Users do not need to worry about middle steps but also give flexibility for those who want to see what's happening.
We've identified a key missing piece is a standardized API for requesting quotes with multi-chain inputs. This API should handle: