Currently the simulation script changes the order of tokens in a PAIR_CONFIG object if needed to align an unordered token pair (tokenA<>tokenB) to an ordered pair (token0<>token1). This is not a great solution because the token order is not guaranteed to be the default sort order used by jq.
This PR changes the script to allow an unordered token pair tokenA<>tokenB to be used throughout the script. The only real logic change necessary for this is aligning the response of the REST API /neutron/dex/user/deposits/$address to the unordered tokens order. This can be seen in the single commit: 0ed6b90317f0251711bd05b68e59efaf1b547daf
I have checked the correctness of this change using simulations:
make test-trade-bot BOTS=1 TRADE_FREQUENCY_SECONDS=0 TRADE_DURATION_SECONDS=30 \
MNEMONIC="banner spread envelope side kite person disagree path silver will brother under couch edit food venture squirrel civil budget number acquire point work mass" \
TOKEN_CONFIG='{"1000000000000uibcatom<>10000000000000uibcusdc":{"price":0.1,"gas":"1000000000untrn"}}' \
ON_EXIT_WITHDRAW_POOLS=1
and
make test-trade-bot BOTS=1 TRADE_FREQUENCY_SECONDS=0 TRADE_DURATION_SECONDS=30 \
MNEMONIC="banner spread envelope side kite person disagree path silver will brother under couch edit food venture squirrel civil budget number acquire point work mass" \
TOKEN_CONFIG='{"1000000000000uibcusdc<>10000000000000uibcatom":{"price":10,"gas":"1000000000untrn"}}' \
ON_EXIT_WITHDRAW_POOLS=1
Currently the simulation script changes the order of tokens in a
PAIR_CONFIGobject if needed to align an unordered token pair (tokenA<>tokenB) to an ordered pair (token0<>token1). This is not a great solution because the token order is not guaranteed to be the default sort order used byjq.This PR changes the script to allow an unordered token pair
tokenA<>tokenBto be used throughout the script. The only real logic change necessary for this is aligning the response of the REST API/neutron/dex/user/deposits/$addressto the unordered tokens order. This can be seen in the single commit: 0ed6b90317f0251711bd05b68e59efaf1b547dafI have checked the correctness of this change using simulations:
and