Serai primary-source snapshot
Fetched: 2026-05-14 UTC
1) Official docs home
Source: https://docs.serai.exchange/
Selected excerpts from the docs:
Serai is a fairly launched cross-chain decentralized exchange, integrating Bitcoin (BTC), Ethereum (ETH, DAI), and Monero (XMR).
The Serai mainnet has yet to launch, and until then, all details are subject to change.
As a fairly launched project, SRI will have no ICO, no IEO, no presale, no developers’ tax/fund, and no airdrop for out-of-mainnet activity.
Additional signals from the source:
- The docs present Serai as a protocol still in motion, so architectural claims matter more than maturity claims in this pass.
- The fair-launch framing matters because it pushes issuance policy into protocol rules rather than token-distribution discretion.
- The docs home is useful as ecosystem framing, but the repository spec is the stronger source for mechanism details.
2) Repository README / project overview
Source: https://github.com/serai-dex/serai
Selected excerpts from the repository page:
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.
Additional signals from the source:
- The README gives the cleanest one-sentence description of Serai’s architectural cut: AMM-style liquidity pools above threshold-multisig custody.
- The repo layout matters because it separates spec, cryptography, processors, coordinators, and network libraries into explicit subcomponents.
- The repo also highlights that Serai carries its own Bitcoin–Monero atomic-swap cryptography libraries even though the main protocol does not reduce to atomic swaps.
3) Core spec overview
Source: https://raw.githubusercontent.com/serai-dex/serai/develop/spec/Serai.md
Selected excerpts from the spec:
Serai is a decentralized execution layer whose validators form multisig wallets for various connected networks, offering secure decentralized control of foreign coins to applications built on it.
Serai is exemplified by Serai DEX, an automated-market-maker (AMM) decentralized exchange, allowing swapping Bitcoin, Ether, DAI, and Monero. It is the premier application of Serai.
Additional signals from the source:
- This page is the clearest evidence that Serai should not be flattened into a single DEX product.
- The key architectural move is a reusable execution layer for foreign coins, with the DEX as merely the first application.
- This framing makes Serai a stronger comparison point for bridge and execution-layer projects than for ordinary trading apps.
4) Validator-set protocol rules
Source: https://raw.githubusercontent.com/serai-dex/serai/develop/spec/protocol/Validator%20Sets.md
Selected excerpts from the spec:
Every Validator Set is expected to form a
t-of-nmultisig, wherenis the amount of key shares in the Validator Set andtisn * 2 / 3 + 1, for each of its networks.This multisig is secure to hold coins valued at up to 33% of the Validator Set’s allocated stake. If the coins exceed that threshold, there’s more value in the multisig and associated liquidity pool than in the supermajority of allocated stake securing them both. Accordingly, it’d be no longer financially secure, and it MUST reject newly added coins.
Additional signals from the source:
- This is the strongest control-surface description in the Serai corpus reviewed today.
- Serai makes custody capacity an explicit function of stake allocation rather than an implicit social assumption.
- Multisig creation and rotation are protocol events with onchain confirmation, which helps separate operational coordination from state finality.
5) UTXO management spec
Source: https://raw.githubusercontent.com/serai-dex/serai/develop/spec/processor/UTXO%20Management.md
Selected excerpts from the spec:
Serai linearly amortizes this fee over all outputs this transaction intends to create in response to burns.
The solution implemented into Serai is to consume all burns from the start of a global queue which can be satisfied under currently available inputs.
Due to the logarithmic complexity of fulfilling burns, attacks require exponential growth (which is infeasible to scale).
Additional signals from the source:
- This spec reveals the hidden operational economics behind validator-controlled custody on UTXO chains.
- Fee handling, output bottlenecks, input aggregation, and anti-DoS policy are core protocol surfaces, not incidental wallet-engineering details.
- The global-queue / branch-output tree design is worth retaining for later comparisons against other threshold-custody and bridge systems.
6) Monero integration spec
Source: https://raw.githubusercontent.com/serai-dex/serai/develop/spec/integrations/Monero.md
Selected excerpts from the spec:
Integrated addresses are not supported due to only being able to send to one per Monero transaction. Supporting them would add a level of complexity to Serai which isn’t worth it.
Monero In Instructions are present via
tx.extra…
Additional signals from the source:
- Serai does not treat Monero as just another ticker; it adapts to Monero-specific address and instruction constraints.
- The omission of integrated addresses is analytically useful because it shows where protocol generality yields to chain-specific operational limits.
- Monero support therefore adds a second layer of comparison beyond threshold custody alone.
Notes
- Serai is worth cataloging because it isolates a specific design family: validator-governed custody as a reusable execution layer for foreign coins.
- The main comparison point to preserve is Serai versus atomic-swap DEXs and versus bridge systems that lack an explicit economic custody bound.
- The strongest control surfaces are validator-set admission and stake allocation, threshold-multisig formation/rotation, processor/coordinator services, and fee / queue policy for outbound fulfillment.