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. |
||
---|---|---|
.github | ||
audits | ||
common | ||
coordinator | ||
crypto | ||
docs | ||
message-queue | ||
mini | ||
networks | ||
orchestration | ||
patches | ||
processor | ||
spec | ||
substrate | ||
tests | ||
.gitattributes | ||
.gitignore | ||
.rustfmt.toml | ||
AGPL-3.0 | ||
Cargo.lock | ||
Cargo.toml | ||
CONTRIBUTING.md | ||
deny.toml | ||
LICENSE | ||
README.md | ||
rust-toolchain.toml |
Serai
Serai is a new DEX, built from the ground up, initially planning on listing Bitcoin, Ethereum, DAI, and Monero, offering a liquidity-pool-based trading experience. Funds are stored in an economically secured threshold-multisig wallet.
Layout
-
audits
: Audits for various parts of Serai. -
spec
: The specification of the Serai protocol, both internally and as networked. -
docs
: User-facing documentation on the Serai protocol. -
common
: Crates containing utilities common to a variety of areas under Serai, none neatly fitting under another category. -
crypto
: A series of composable cryptographic libraries built around theff
/group
APIs, achieving a variety of tasks. These range from generic infrastructure, to our IETF-compliant FROST implementation, to a DLEq proof as needed for Bitcoin-Monero atomic swaps. -
networks
: Various libraries intended for usage in Serai yet also by the wider community. This means they will always support the functionality Serai needs, yet won't disadvantage other use cases when possible. -
message-queue
: An ordered message server so services can talk to each other, even when the other is offline. -
processor
: A generic chain processor to process data for Serai and process events from Serai, executing transactions as expected and needed. -
coordinator
: A service to manage processors and communicate over a P2P network with other validators. -
substrate
: Substrate crates used to instantiate the Serai network. -
orchestration
: Dockerfiles and scripts to deploy a Serai node/test environment. -
tests
: Tests for various crates. Generally,crate/src/tests
is used, orcrate/tests
, yet any tests requiring crates' binaries are placed here.
Security
Serai hosts a bug bounty program via Immunefi. For in-scope critical vulnerabilities, we will reward whitehats with up to $30,000.
Anything not in-scope should still be submitted through Immunefi, with rewards issued at the discretion of the Immunefi program managers.
Links
- Website: https://serai.exchange/
- Immunefi: https://immunefi.com/bounty/serai/
- Twitter: https://twitter.com/SeraiDEX
- Mastodon: https://cryptodon.lol/@serai
- Discord: https://discord.gg/mpEUtJR3vz
- Matrix: https://matrix.to/#/#serai:matrix.org
- Reddit: https://www.reddit.com/r/SeraiDEX/
- Telegram: https://t.me/SeraiDEX