mirror of
https://github.com/serai-dex/serai.git
synced 2024-12-24 20:49:27 +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. |
||
|---|---|---|
| .. | ||
| bin | ||
| bitcoin | ||
| ethereum | ||
| frost-attempt-manager | ||
| key-gen | ||
| messages | ||
| monero | ||
| primitives | ||
| scanner | ||
| scheduler | ||
| signers | ||
| src | ||
| view-keys | ||
| README.md | ||
Processor
The Serai processors, built from the libraries here, scan an external network
and report the indexed data to the coordinator. For details on its exact
messaging flow, and overall policies, please view docs/processor.