mirror of
https://github.com/serai-dex/serai.git
synced 2024-12-25 13:09:30 +00:00
8f2a9301cf
The router will now match the top-level transfer so it isn't used as the justification for the InInstruction it's handling. This allows the theoretical case where a top-level transfer occurs (to any entity) and an internal call performs a transfer to Serai. Also uses a JoinSet for fetching transactions' top-level transfers in the ERC20 crate. This does add a dependency on tokio yet improves performance, and it's scoped under serai-processor (which is always presumed to be tokio-based). While we could instead import futures for join_all, https://github.com/smol-rs/futures-lite/issues/6 summarizes why that wouldn't be a good idea. While we could prefer async-executor over tokio's JoinSet, JoinSet doesn't share the same issues as FuturesUnordered. That means our question is solely if we want the async-executor executor or the tokio executor, when we've already established the Serai processor is always presumed to be tokio-based. |
||
|---|---|---|
| .. | ||
| contracts | ||
| deployer | ||
| erc20 | ||
| ethereum-serai | ||
| primitives | ||
| router | ||
| src | ||
| Cargo.toml | ||
| LICENSE | ||
| README.md | ||