Summary
Preparing a single deposit + addOrder submission via RaindexOrderBuilder issues 18 sequential eth_call round-trips. On a remote RPC (~300ms RTT) its ~5–6s of network latency per order build. Guaranteed exposes a service which has this exact flow. Having the service be alot faster at generating a quote would be preferable.
I haven't looked deep into the raindex source myself so this ai review of the problem could be wrong, but hopefully its enough to get started if its important:
Where the calls go
-
generate_deposit_and_add_order_calldatas — 14 of 18 calls. 12 hit the
deployer's DISPair address getters; 2 hit the parser. Root cause in
crates/common/src/add_order.rs::try_into_call: read_dispair() (4 calls:
expressionDeployerAddress, interpreterAddress, storeAddress,
parserAddress) runs three times —
- directly in
try_into_call,
- again inside
try_parse_rainlang for the main expression,
- again inside
try_parse_rainlang for the post-task expression.
Those four addresses are immutable for a given deployer contract. 8 of the 12
redundant.
In guaranteed, our input token is the same as our output token which also leads to more duplicated requests, with optimisation I believe these could be done once for both:
-
set_select_token ×2 — 1 call each. token_info() (a Multicall3
aggregating decimals/name/symbol). The same token is selected for both the
input and output slot, so its metadata is fetched twice.
-
generate_approval_calldatas — 2 calls. erc20.decimals() +
check_allowance(). The decimals here duplicate what set_select_token
already fetched.
If any of these requests could be cached, or could have the option to have hardcoded values parsed in instead of making network requets, that would be great.
Summary
Preparing a single deposit + addOrder submission via RaindexOrderBuilder issues 18 sequential eth_call round-trips. On a remote RPC (~300ms RTT) its ~5–6s of network latency per order build. Guaranteed exposes a service which has this exact flow. Having the service be alot faster at generating a quote would be preferable.
I haven't looked deep into the raindex source myself so this ai review of the problem could be wrong, but hopefully its enough to get started if its important:
Where the calls go
generate_deposit_and_add_order_calldatas— 14 of 18 calls. 12 hit thedeployer's DISPair address getters; 2 hit the parser. Root cause in
crates/common/src/add_order.rs::try_into_call:read_dispair()(4 calls:expressionDeployerAddress,interpreterAddress,storeAddress,parserAddress) runs three times —try_into_call,try_parse_rainlangfor the main expression,try_parse_rainlangfor the post-task expression.Those four addresses are immutable for a given deployer contract. 8 of the 12
redundant.
In guaranteed, our input token is the same as our output token which also leads to more duplicated requests, with optimisation I believe these could be done once for both:
set_select_token×2 — 1 call each.token_info()(a Multicall3aggregating decimals/name/symbol). The same token is selected for both the
input and output slot, so its metadata is fetched twice.
generate_approval_calldatas— 2 calls.erc20.decimals()+check_allowance(). The decimals here duplicate whatset_select_tokenalready fetched.
If any of these requests could be cached, or could have the option to have hardcoded values parsed in instead of making network requets, that would be great.