Our auction DCA and DSF strats require an initial-io which helps the strat start auctions at or near the current market price.
This is a pain for users and often something they get wrong, sometimes leading to total loss of funds. They have to find the right ratio and make sure it's in the right direction.
In our custom GUI's (e.g. Cyclo), we simply use the sushiswap lib to pull the current market price and the end user doesn't need to do anything.
Ideally, strategy writers would be able to define where external prices should be used as part of the YAML config, and the SDK would handle fetching the ratio and inserting it in the correct place. But, we don't want to enshrine a specific method of fetching prices.
The proposed solution would consist of:
- A way of specifying where a price ratio should be used. We already have
${...} to use contextual info, so it could simply be ${io-ratio(input, output)}, e.g. ${io-ratio(order.inputs.0.address, order.outputs.0.address)}.
This could be used in a couple of places.
As a default:
- binding: initial-io
name: Kickoff ${order.inputs.0.token.symbol} per ${order.outputs.0.token.symbol}
description: |
The initial ${order.inputs.0.token.symbol} per ${order.outputs.0.token.symbol} to kickoff the first auction.
This ratio is calculated in the same way as the baseline ratio.
It must be greater than the baseline ratio, regardless of what you are selling or buying.
This is because getting more input per output is always better for you.
The initial auction will start high (at the value you set here) and then drop to the baseline ratio over time.
Subsequent auctions will start at some % above the last auction price and drop to the baseline ratio over time.
default: ${io-ratio(order.inputs.0.address, order.outputs.0.address)}or, in the name/description of a field (basically as a helper for the user inputting into the field.
base:
name: Base
description: Deploy a limit order on Base.
deposits:
- token: token2
fields:
- binding: fixed-io
name: ${order.inputs.0.token.symbol} per ${order.outputs.0.token.symbol}
description: Fixed exchange rate (${order.inputs.0.token.symbol} received per 1 ${order.outputs.0.token.symbol} sold).
The current market price is ${io-ratio(order.inputs.0.address, order.outputs.0.address)}
select-tokens:
- key: token1
name: Token to Buy
description: Select the token you want to purchase
- key: token2
name: Token to Sell
description: Select the token you want to sell
- The actual method of fetching prices injected as a dependency when creating the
DotrainOrderGui, basically just a js function to be used as a callback.
const priceCallback = (inputTokenAddress, outputTokenAddress) => {
return fetchPrice(inputTokenAddress, outputTokenAddress)
};
const gui = DotrainOrderGui.newWithDeployment(dotrain, 'deployment', priceCallback);We'd need to think through error handling etc.
Our auction DCA and DSF strats require an
initial-iowhich helps the strat start auctions at or near the current market price.This is a pain for users and often something they get wrong, sometimes leading to total loss of funds. They have to find the right ratio and make sure it's in the right direction.
In our custom GUI's (e.g. Cyclo), we simply use the sushiswap lib to pull the current market price and the end user doesn't need to do anything.
Ideally, strategy writers would be able to define where external prices should be used as part of the YAML config, and the SDK would handle fetching the ratio and inserting it in the correct place. But, we don't want to enshrine a specific method of fetching prices.
The proposed solution would consist of:
${...}to use contextual info, so it could simply be${io-ratio(input, output)}, e.g.${io-ratio(order.inputs.0.address, order.outputs.0.address)}.This could be used in a couple of places.
As a default:
or, in the name/description of a field (basically as a helper for the user inputting into the field.
DotrainOrderGui, basically just a js function to be used as a callback.We'd need to think through error handling etc.