We chose Substrate early on so Serai did not have to build its own blockchain. While we could have, the point of Serai was to offer a quality user experience to swap between Bitcoin, Ether, DAI, and Monero, where our usage of a blockchain was an implementation detail, not the purpose itself. Substrate, now considered part of the Polkadot SDK, offered an expansive, flexible blockchain SDK built by Parity and usable for our purposes, where we would not have to maintain the database, networking layers ourselves.
Despite being built with Substrate, Serai has no direct relation to Polkadot and is its own network entirely. As our use of a blockchain is an implementation detail of Serai, the usage of Substrate is also considered an implementation detail of the blockchain. To this end, we've worked extensively to define our own ABI and JSON-RPC API, ensuring we define the protocol fundamentally used for the lifetime of the project and have control over the entire experience, from developers to users. One notable feature to this end has been our own transaction format, allowing users to atomically perform multiple actions within a single transaction, with guarantees on when the transaction is executed and the effects of it.
In January, we announced this blockchain's upcoming audit by Security Research Labs. SRLabs are experts within the Polkadot ecosystem, including for Substrate, and have worked for years to ensure its security. We found such review critical not only due to how important our blockchain is to our protocol, but also because of the depth of the work we had done with Substrate as a blockchain framework. We are exceptionally happy to have benefited from SRLabs participation in Serai's security, them having contributed many valuable insights and caught many bugs and subtleties, which will be covered in the remainder of this blog post.
This audit was primarily conducted in the first few months of 2026, with the findings reported in real time to Serai's GitHub issues. Serai's GitHub issues are not only how the project itself primarily organizes, naturally indexing the findings, but also served to ensure transparency. Anyone could see opened issues as they were found and inspect how they were handled.
This review was conducted incrementally, with certain sections of the codebase being submitted after others had already been reviewed. This helped with the review's timeline, but due to scheduling issues on our end, some sections were submitted without our intended degree of testing. This can be attributed as the primary underlying reason for some of these findings, highlighting the importance for Serai to ensure its code is ready and completely through internal processes before being sent for external review.
SRLabs's report notes 21 issues, their framework classifying issues as "Critical", "High", "Medium", "Low", or "Informational". No issues in the report had a "Critical" classification, all being "High", "Medium", "Low", or "Informational". While we can be happy with how we proactively engaged with SRLabs, working towards a codebase we can trust to be safe and reliable prior to any deployment, the amount of issues found during external review (and the severity of some) mean we must work towards higher standards in the future. We must ensure issues such as these do not continue to occur and that any remaining issues are thoroughly identified and mitigated. While security reviews and audits are part of our processes (as incredibly justified here), we must always be mindful of what may slip through the cracks and determined to always be vigilant accordingly. All following uses of these labels for classifying severity will be as assigned within the audit.
We would like to thank MAGIC Grants for helping to facilitate the audit and Power Up Privacy for their donation which funded it. For MAGIC's insight, please read their own blog post.
All issues were responded to, with accepted mitigations, except four. We would like to explicitly cover these four issues to be exceptionally clear on their status.
Of all 21 reported findings, we consider 12 of them to either be a denial of service or performance degradation in some regard. Each's severity was dependent on how accessible the issue was and the impact of it. We present all of them in a single section here. The brief descriptions represent Serai's own summary and is not intended to be presented as a quote from SRLabs or their report.
S0-757 (Info): When the network launches, anyone may add external coins to become 'genesis liquidity'. As Serai's liquidity pools are symmetric, all liquidity is composed of both an external coin and SRI. In order to actually add the genesis liquidity to the pools, the protocol will airdrop the corresponding SRI portion to those who added external coins. In order to know how much SRI to use for sriBTC liquidity, and how much to use for sriETH, sriDAI, sriXMR liquidity, the values of one to another are oraclized onto the network by the genesis validators who start the network.
This finding noted that this oraclization process used the latest keys declared by the genesis validators, not the keys declared upon genesis. This allowed a genesis validator to sign a signature before updating their key, invalidating the signature (due to being signed by an old key), and forcing the genesis validators to have to sign a new signature. This was mitigated by ensuring we use the keys declared upon genesis.
Serai, as a project, generally considers undocumented, reachable panics in any public API as a security issue. This is reflected in our long-standing Bug Bounty Program with Immunefi, where even when the caller crafts arguments in a way intended to cause panics, we still consider the code panicking an issue and offer rewards. We are generally proud of covering our work under such a rigorous criteria, and to that end, acknowledge and accept all of the above issues.
Practically, S3-727 and S3-729 (each assigned "High" severity) are the most notable in our opinion. S3-753, S3-759, S3-760, are notable as they should have been caught with testing and highlight a need for us to continue to write and expand our test suite, for all aspects of our codebase.
With 12 of 21 findings considered as denial of services, or performance degradations of some form, nine can be considered as logical bugs affecting or questioning the soundness of the protocol. This section will cover each of these in more detail due to how each bug could potentially have had much greater impact. Thankfully, of these nine findings, only two were assigned "High" severity, with three assigned "Medium", one assigned "Low", and the remaining three assigned an "Informational" severity.
S3-741 (High): This was interesting as it was a flaw in our Economics design. This review process led to multiple improvements of the mechanisms posited, the resulting document (the one linked) intended to be near-final if not final. Barring any documentation errors, or sections deserving clarification, the only sections actively being considered for any further changes are the exact fees proposed for deployment.
Before the network achieves Economic Security, the phase where the validators' stake's value exceeds the value of the coins tracked on the Serai blockchain itself (with a certain additional buffer), users are allowed to swap external coins to staked SRI in order to form validators. While SRI may always be swapped to via the liquidity pool, and anyone with sufficient SRI may allocate stake to become a validator, swapping to staked SRI is a specific functionality which only exists prior to achieving Economic Security. While swapping through a liquidity pool would cause the quote to change in response to the swap itself, swapping to staked SRI mints SRI directly as stake allocated to a validator at a specific quote (without impacting the quote). This makes becoming a validator much more stable and accessible, promoting becoming a validator so that the network may become Economically Secure.
The external coins which are used to swapped to staked SRI are then used to form Protocol-Owned Liquidity. This process, both as originally and currently specified, involves acquiring liquidity from the existing liquidity pool in exchange for the external coins.
This finding, when paraphrased, covered how users who supply liquidity and swap to staked SRI could effectively do so at a discount. While the external coins would be used to form Protocol-Owned Liquidity, part of the liquidity acquisition would be from the user's own liquidity position. This would cause the user to swap to staked SRI as expected, yet effectively receive back a portion of the external coins (proportional to how much of the pool's liquidity they had). We mitigated this issue by ensuring that while users are always able to remove their liquidity, they only receive any upside according to a trickle feed which only begins after Economic Security is achieved. This is to ensure a steady and predictable flow for value which all users may observe and decide how to react accordingly to, without any sudden changes.
S3-758 (High): The code for validating misbehavior in the GRANDPA consensus code had an inversion such that any alleged misbehavior (even if invalid) would be accepted as evidence of misbehavior. This was a complete oversight present due to when the code for misbehavior was added, and due to how it unfortunately lacked tests when submitted.
S2-761 (Medium): When forming Protocol-Owned Liquidity, the coins used to acquire liquidity are dripped into the pools. If the amount of these coins is less than the amount of blocks to drip over, the rate per block may be zero, where any remainder is expected to be added with the final block of the drip feed. If the drip rate was zero however, the code incorrectly interpreted it as there being no liquidity to drip, potentially not adding some coins into the pools as expected. This was mitigated by correcting how we check for if there's outstanding liquidity to drip into the pools, as suggested.
S2-771 (Medium): Serai does not have a premine nor any fund for development enshrined into the protocol. Serai also lacks the on-chain upgrade functionality frequently seen with projects built with Substrate, believing the only code which should run is that which the whoever runs the node downloads and explicitly consents to. To this end, Serai lacks anything we would call or consider approximate to a Decentralized Autonomous Organization (DAO).
Serai does have 'signals' however, where users may express favor for a signal. A signal may be either to halt an external network, if an issue is perceived, or to retire the network itself. These signals only cause a corresponding effect when a sufficient amount of the protocol's validators actively express favor for the signal.
This issue noted that while expressed favor for a signal intended to have a limited lifespan, specifically until the end of the following session of Serai validators, the favor's lifetime could potentially last until the end of any validator set which overlapped with the following session of Serai validators. In practice, this meant a lifetime intended to be for just one to two weeks could actually last two to three weeks.
While potentially not the most impactful finding, we greatly appreciate the focus applied to find and report it. The challenge with writing the code was organizing around the schedules of multiple different sets of validators, all who may update independently and seemingly arbitrarily. While this oversight did occur, we are thankful SRLabs put in the effort necessary to identify even more delicate oversights such as this. As we do not consider Serai a product but a project, aiming to capture an ideal of correctness and security missing throughout the space, SRLabs also considering Serai as a protocol and thoroughly holding it the same ideal was above and beyond any expectations we could have had.
S2-763 (Medium): When an external network is halted, only the external network's integration's ability to publish new events was halted. This prevented any new coins from being minted on-chain and prevented the associated validators from being able to rotate to the next set. This finding noted how other aspects, such as the ability to swap to coins associated with the 'halted' external network, remained possible.
Originally, this was not considered an issue, as the coins on the Serai network were still coins on the Serai network, with all on-chain abilities intact. While further transfers, swaps, burns could complicate how these coins are tracked, any observations after the fact would have to develop comprehensive tracking and accounting solutions regardless to ensure their correctness. Accordingly, the impact of this could be considered non-existent.
Two specific ideas were raised in the following discussions however which justified this finding. The first was that if an external network's integration is halted due to a bug, the fact the coins on the Serai network could still be burnt meant the external integration could still be instructed to take action (despite being 'halted'). It was only if there was a bug or issue with reporting events onto Serai that the halt would be effective. While our integrations should be programmed to observe a halt and stop on their own, meaning applying such a methodology on-chain would be unnecessary, it was still agreed worthwhile to be so robust with our methodology. The other concern was how swapping to coins is intended to specify a minimum amount to receive, yet if the external network has been halted, one can question if those coins are the same and should be considered as having the same amount for the purposes of enforcing a minimum value out when swapping. To ensure both of these were handled optimally, halts were expanded to not halt just the publication of events, but to also halt burns of and swaps to related coins.
S2-742 (Low): One of our build scripts output the first binary found with the expected name, instead of the binary which was a result of that build process. If the build directory was dirty, or in exceptionally strange cases such as a build process which outputs interim artifacts with the same name as the final artifact, this could cause the wrong binary to be selected. This has been fixed by adding a JSON parser to properly parse the Rust compiler's output in order to identify the location of the result.
S0-731 (Info): This finding noted how coins are associated with a network, yet any coin could be specified in any context, even when that context was associated with a distinct network. This finding was questioned when received as in general, contexts are always derived from the immediately present data. For example, when given a coin, one may call a method to obtain its network, or vice-versa. As the network of a coin is baked into the code itself, and cannot be manipulated, the only way for such a potential mismatch to occur would be in a location where both a network and a coin was given.
Because being provided with two pieces of data which can conflict is a risk that they may conflict, the Serai codebase is written to avoid such scenarios, preventing this issue from ever appearing. In response to this finding, we checked the entirety of the in-scope code for any such cases, and only identified one place this could occur. This was in our handling of batches, where batches represent a series of events from an external network. The batches are specified by network, as the batches may not contain any events regarding coins. If the batch does have events regarding coins, each event specifies the associated coin, as required due to how one network may correspond to multiple coins (such as Ethereum, with Ether and DAI). Due to specifying a network as context, and then specific coins, this could be a place where such a conflict could occur.
The code to verify batches did check that for all coins in all events, the network of the coins corresponded to the network of the batch. This was considered and was never a reachable issue. In response to this issue however, we did extend the code which created and decoded batches with checks for consistency. This means the batch, the object which creates the opportunity for this mismatch, is responsible for ensuring the data does align, not any/all consumers.
S0-774 (Info): This is the aforementioned issue where coins which would be otherwise inaccessible may be swept by anyone, which we've accepted as-is. For the reasoning of this, please read the issue itself.
S0-776 (Info): This is the aforementioned issue which noted some aspects of the node, such as mitigations for denial of service, were marked for future consideration and therefore not possible to include in the current scope. It is left for us to continue to work on and mitigate in the future.
The report included a series of recommendations for Serai, as a project, to adopt. One notable suggestion was for "constrained on-chain governance and upgrade mechanism to enable rapid incident response". As a project, we consider the defined halting mechanism (which is accessible on-chain to the active validators) as the project's ability to respond to any misbehavior. The gap is if the blockchain protocol itself is faulty, as the halting mechanism may only be applied to external networks, meaning to halt the blockchain protocol would require a sufficient amount of validators to pull their plugs. Additionally, even if Serai may halt in response to an issue, a fix cannot be automatically deployed.
Our response to S2-771 briefly explained the signals functionality, including the ideology behind it. That commitment to whoever runs a node choosing and explicitly consenting to the software they run prevents us from adopting an on-chain upgrade mechanism. Despite this, we will continue to consider how the project is organized, and if it may be made more efficient/effective without compromising on user sovereignty nor decentralization.
Another suggestion was to minimize our divergences from the Substrate, as developed and published as part of the Polkadot SDK, to reduce our maintenance overhead and likelihood of introducing security issues. The maintenance burden can definitely be discussed. Historically, Serai maintained an outright fork of Substrate, yet the difficulty of reconciling it with new releases caused the process of updating to take multiple days in what was not generally feasible. Today, we maintain a patch set and patcher, which we've found reasonable to maintain and able to update to new releases within just an hour or so. It was included in this audit's scope.
As for why we maintain a derivative, the biggest reason is for scale. As an immediate metric, our Substrate is measured as having 141,980 lines of Rust code compared to the upstream's 663,615 lines of Rust code. If we used the upstream, we may actually only compile and run the same amount of code, but with our derivative, we have clarity on exactly what that code is. This is intended to benefit our own work to identify the exact behavior and definition of our own protocol, while also providing a clearer scope to potentially benefit and enable review in the future without having approximately five times as much work due to unnecessarily including the parts of Substrate we don't use.
We also apply patches to reduce how many dependencies we have (as part of our ongoing efforts regarding supply-chain security), have three patches fixing bugs in Substrate, have four patches adding features to Substrate, and only three patches which we consider opinionated (patches not generally desirable yet desirable for Serai as a project specifically). Note that some modifications are not represented via patches, solely via instructions to the patcher, and would not be counted by these metrics.
While we can present all of the above justifications for having our own derivative of Substrate, the recommendation itself remains sound. With every modification we make, we may fix a problem or improve something, yet we also may introduce a problem. While we've drastically clarified our scope, we've also taken responsibility and liability for our scope by defining this methodology. We must always keep that in mind and be able to justify our future changes.
Other recommendations included adding fuzzing, expanding tests, and writing documentation, which we agree on and is a focus of ours. One note was on the organization of a specific code path, the code path itself already having an open issue tracking it, and a suggestion to adopt pair programming as part of our internal practices. We agree on the benefits of such a solution, and while that isn't currently in place, will consider how we may adopt aspects of it in order to strengthen our processes.
We've indexed this audit into our audits folder. This index accurately presents the exact scope, with references to the relevant GitHub issues and associated context. We encourage everyone to feel welcome to review the full report and all the documentation. Our audits folder also contains our other audits, covering various parts of our cryptography, Bitcoin integration, Ethereum integration, and more. For our Monero integration, the libraries which were monero-serai have become monero-oxide, which has been audited and maintains its own audits folder.
At this time, only one unaudited aspect of the Serai protocol stands out to us: our implementation of our DKG protocol. We are still actively considering follow-up reviews for our blockchain, and whether any other aspects of the project would greatly benefit from external review prior to deployment (instead of solely our internal review and testing), but are excited for how close we are to the end of our checklist.
Moving forward, with our Substrate blockchain protocol considered complete (even though the node has some features remaining), we will be prioritizing working towards a testnet. This will be by continuing with integration tests for all of our services, confirming they work together as expected in all cases, before an internal test network, before finally once again preparing public networks. To this end, we recently had tests for a notable part of our "coordinator" service contributed and merged, with the other parts' tests actively being developed (and in some cases, already submitted).
If you'd like to keep up with Serai as its development continues, we welcome you to join our Matrix or Discord, the two being bridged to each other to allow your choice in how you connect. We also maintain a Twitter feed and our blog supports RSS for those who prefer.
]]>While these topics are about how Serai interacts with external networks, be they Bitcoin, Ethereum, or Monero, there is also the Serai network itself (or even networks, depending on where one draws the lines). Fundamentally, Serai uses a blockchain to select validators and order swaps, one built upon the Substrate framework. The Substrate framework was chosen for being written in Rust, being incredibly flexible, intending to allow developers to build their own blockchains, as well as performant. While this meant we did not have to write a blockchain node implementation from scratch for Serai's blockchain, which would've been unnecessary and out-of-scope to the Serai project, we did still have to define and implement the protocol for our specific needs and functionality.
As of Monday, the audit of our Substrate-based blockchain kicked off, with SRLabs as our auditor. SRLabs has a long history within the Substrate ecosystem, giving them unmatched experience. They've previously developed tooling to secure the Substrate ecosystem, with extensive usage over several projects, and maintain a security consultancy relationship with Parity, the company which primarily developed the Substrate framework.
The audit is being executed in a staged approach, with the first set of libraries already submitted, and the complete implementation expected to be delivered in mid-February. This pipelined approach allows us to minimize the delay on having our works externally reviewed, a crucial requirement for a secure deployment. We look forward to this engagement with SRLabs and hope to maintain a relationship moving forward into the future as well.
The audit was facilitated by MAGIC Grants, an American 501(c)(3) which funds research and development of noteworthy projects in the cryptocurrency and privacy space. They provide scholarships to students interested in the field, and also host the MAGIC Monero Fund as a tax-deductible way to donate to Monero development (along with the MAGIC Firo Fund and MAGIC Privacy Guides Fund).
The funds for the audit were generously donated by Power Up Privacy, a charitable entity that donates to projects which benefit privacy. They've previously donated to Serai to enable the security proofs for its bespoke Distributed Key Generation protocol and the audit of its Ethereum contracts.
We are incredibly thankful to both organizations for enabling us to do our best
to ensure the security of the Serai project, which is moving into a final
state. With our Substrate-based blockchain being audited, and the ongoing
review and testing of our other services, we plan to be able to host testnets
soon after this audit resolves. We look forward to finally demonstrating the
experience Serai enables to swap between various cryptocurrencies, including
Monero, in a decentralized way.
If you would like to keep up to date with Serai as it achieves these milestones, we welcome you to follow us on Twitter, or join our community via Discord or Matrix.
]]>The FROST paper posits a DKG, known as PedPoP, which Serai originally planned to use. PedPoP does not allow identifying a participant who misbehaves however, so Serai implemented a 'complaint round' into our protocol. After PedPoP completes on paper, each participant sends a message to say either "I'm good!" or "Eve sent me an invalid key!", allowing us to detect invalid participants. Our implementation was initially written independently yet was effectively the protocol from the ICE FROST paper.
Unfortunately, our DKG protocol still faced an issue: everyone must be online and remain online for three 'rounds' (every participant sending one set of messages and receiving the messages from the other participants). With Serai, the point is to be robust and remain operational even if up to a third of validators go offline.
Our initial solution was to detect if a validator was offline, and if so, remove them from the key generation protocol. Unfortunately, this means they would be permanently excluded from the key and considered as 'offline' for its entire lifetime, even if they came back online later. While this was functional and acceptable, it clearly wasn't optimal.
So, in July of 2024, we posited a new protocol for distributed key generation protocols building on the eVRF paper's. Using its methodology, we were able to posit an efficient mechanism for sending encrypted shares of the signing key while allowing anyone to verify their correctness (an efficient mechanism for Verifiable Encryption).
This allows us to remove the 'complaint round' from our DKG protocol and ensures that all participants receive valid shares of the signing key, guaranteeing their ability to participate in signing if online and willing. Combined with the eVRF paper's own proposal for a one-round DKG (but still requiring a way to identify misbehaving participants), we were able to achieve a one-round DKG!
While there are prior works on combining DKGs with Verifiable Encryption for these results, they generally require non-elliptic-curve cryptography or repetition (instead of encrypting a 256-bit key share in one message, encrypting each bit of a key share in 256 messages, each requiring their own proof of validity). Our methodology is notable for only requiring elliptic-curve cryptography (the hardness of the Decisional Diffie-Hellman problem) and supporting encrypting entire key shares in a single message.
Today, we've published the security proofs for our protocol, which were contracted from HashCloak by MAGIC Grants, as possible thanks to a donation by Power Up Privacy!
We also have implemented our protocol in Rust, published under the MIT license. While our implementation has yet to be audited, it builds upon the generalized-bulletproofs, generalized-bulletproofs-ec-gadgets libraries for Bulletproofs and efficient elliptic curve cryptography within them. These were audited by the Monero project for usage within their upcoming FCMP++ hard fork. This provides a strong base for them, helping ensure its foundation.
This marks one more step forward to building a secure, trustworthy, and robust decentralized exchange for Bitcoin, Ethereum, and Monero. If you wish to learn more, please visit our website or join us on Discord on Matrix. We look forward to seeing you there!
]]>In February of 2023, the Cuprate project began, striving to build a complete implementation of the Monero protocol in Rust. Later that same year, they adopted monero-serai to represent transactions and validate Monero's zero-knowledge proofs, contributing back implementations of legacy aspects of the Monero protocol and helping to ensure the library's quality.
Due to monero-serai intending to benefit the community, a request was made for the Monero community to crowdfund an audit. Raising the funds, Cypher Stack was contracted to prove the security of our multisignature protocol audit monero-serai. This produced FROSTLASS, a formalized and proven-secure threshold signing protocol for CLSAGs inspired by FROST, and the audit of monero-serai itself. FROSTLASS offers a major performance improvement over the multisignature implementation inherently present in Monero, and now formally proven, can be strongly recommended for implementation by anyone who wants to secure Monero within a threshold multisig.
Audit in-hand, to ensure monero-serai would remain a neutral library, monero-serai was transferred to the recently-formed monero-oxide organization. The organization is led by boog900, maintainer of Cuprate, and kayabaNerve, lead developer of Serai. Together, they're trusted to steward it for the benefit of the whole Monero community. Our upcoming goal will be a 1.0 release, representing a degree of stability over our APIs.
In the future, monero-oxide will also take responsibility for the Rust libraries underpinning Monero's Full-Chain Membership Proofs++ upgrade, prior maintained personally by kayabaNerve. The generalized-bulletproofs library, implementing the zero-knowledge proof underlying FCMPs, is expected to be merged into the monero-oxide repository in the near future.
By the generosity of Power Up Privacy, we are also able to announce a $100,000 bug bounty for monero-oxide. Payouts will be in XMR and entirely handled by Power Up Privacy. We offer this to prioritize our implementation's security and accuracy, welcoming security researchers to take a look. Our codebase includes Rust code, zero-knowledge proofs, multi-party protocols, and soon even elliptic curve implementations, offering a plethora of topics to review.
If you wish to keep an eye on, or discuss, monero-oxide, please join Cuprate's Matrix, which currently hosts discussions for the monero-oxide organization. We look forward to seeing you there!
]]>Our router is the most critical part of our Ethereum integration. Comparable to a bridge contract, it handles messages to and from the Serai network. In an age where cross-chain bridges are frequently insecure, and frequently compromised for billions of USD across the industry, our router contract represented a prime target. Accordingly, we wanted to work to ensure its correctness and accuracy.
Trail of Bits found no high, medium, nor low severity issues with the included scope, an increadible feat. Our quality of documentation was praised, and we were found to follow best practices. We had two informational findings, both remediated with Trail of Bits reviewing our fixes, and three comments; two were responded to and one was dismissed as intentional behavior.
The first informational finding was how alloy, a prominent Rust library for interacting with Ethereum, potentially panicked when decoding invalid calldata without checking it. While Serai never decoded arbitrary calldata without checking it, the latest release of alloy was expected to remove the ability to check calldata upon decoding. Accordingly, the concern was Serai would upgrade the version of alloy used, removing the checks performed upon the calldata, and become vulnerable to these panics. We have performed the upgrade to alloy's 1.0 release and validated the new version does not have the same panics, addressing the finding.
The second finding was how we didn't allow the identity point, or point at infinity, as a public key yet only via an indirect check. We intentionally banned points whose x-coordinates are zero, as they would have undefined behavior within our smart contract, yet the identity point is special in that it doesn't have a well-defined x-coordinate, and accordingly itself would exhibit undefined behavior. Conventionally, the x-coordinate of the identity point is considered zero however, and the Rust library we use for the secp256k1 elliptic curve did represent the identity point with zero for its x-coordinate. This meant we did ban the identity point, yet only due to this common convention, and not due to an explicit intent. While the identity point should never be observed in practice, as randomly selecting it as a public key has the same odds as selecting Satoshi's public key, we always want to ensure properly defined rules and flow throughout the entire codebase. We have since added an explicit check the public key is not the identity point.
One comment was on how our documentation in one location was out of date, which has been updated. One comment was on how when we sign messages for the Ethereum contract, we sign the blockchain's ID (ensuring a message for Ethereum is not also used with an another Ethereum-esque blockchain), yet we didn't sign the contract's address (ensuring a message for a router on Ethereum isn't used with another router on Ethereum). As we only expect to deploy a single router on any network, this wasn't an issue, but we agree it's better practice and have updated accordingly. Finally, it was noted how our contracts are built with a Solidity compiler whose version is explicitly compared to the expected value, instead of parsed with greater logic. As we only want our contracts built with a single version of the Solidity compiler, ensuring they're reproducible and verifiable, this was accepted as intended behavior.
Secure, properly functioning code is our utmost priority. We thank Trail of Bits for their thorough assessment and professional evaluation of our contracts. The findings and recommendations from this audit help inform our ongoing security efforts. For their full audit, please see their publication, which we've additionally uploaded to the Serai repository. We look forward to continuing publication of audits we have performed, and to the initial release of our codebase.
]]>ECDSA's complexities made it almost impossible to prove the security of the scheme. A recent paper concludes in its abstract:
As a consequence, a meaningful security proof for ECDSA is unlikely to exist without strong idealization.
In practice, while we may not be able to formally argue ECDSA's security, we have not practically broken it. These comments exist to show ECDSA's awkwardness and difficulty modeling, a difficulty which creates further complications down the road.
Serai could use ECDSA signatures, enabling taking advantage of networks which natively support ECDSA. To do so, we'd need a threshold ECDSA protocol, enabling certain validators to go offline yet for Serai to continue functioning. These protocols are leagues more complex than threshold Schnorr protocols due to their being forced to deal with the ECDSA-specific complexities. They also are more difficult to prove secure due to not only being more complex themselves, but also due to extending a protocol itself without clean security proofs. This is to say nothing about their track record.
The most famous works descend from Gennaro and Goldfeder, being GG18, GG20, and joining forces with Canetti, Makriyannis, and Peled, CGGMP21. GG18 and GG20 were notably broken in 2021 by the publication of Alpha-Rays. Recently, Makriyannis and Yomtov published four new attacks on threshold ECDSA, two for GG18/GG20, one for Lindell's 2017 work, and one for a custom protocol. Please note all of these rely on the Paillier cryptosystem, distinct from the elliptic curves ECDSA actually operates over, to achieve their goals.
Implementations of threshold ECDSA have also had several issues in practice, even if the protocols can be assumed theoretically sound. Verichains' TSShock demonstrated several implementations had vulnerabilities in practice. While this could be the teams responsible for these implementations being inexperienced, and any audits performed being incomplete, it also serves as commentary on the difficulty in successfully implementing threshold ECDSA especially since successful implementations of protocols still break when the protocols do.
If necessary, Serai could review CGGMP21 and/or protocols which aren't based on the Paillier cryptosystem. They should be sufficiently performant (though still multiple orders of magnitude less efficient than a Schnorr-based protocol), and ideally the protocols that don't use a distinct cryptosystem to add functionality to ECDSA avoid most potential issues (all above theoretic exploits took advantage of the Paillier side of things). The sole question becomes if the benefit outweighs the attack surface and effort required.
By comparison, the most famous protocols for Schnorr multisignatures are MuSig, MuSig-DN, MuSig2, and FROST. The MuSig family of protocols are not threshold multisignature schemes, requiring all signers to work together to produce every signature. MuSig was proven insecure when run in parallel, leading to its successors. MuSig-DN and MuSig2 have been proven secure however, and while a fault in the proofs could surface, they have industry confidence.
FROST, which is a threshold multisignature scheme, and the scheme Serai uses, builds off the techniques of MuSig2 to provide a highly efficient threshold multisig. Not only did its own paper prove its security, it's had its security continuously further proven. Due to its performance, use-cases, and security, the Internet Research Task Force (IRTF) has drafted it for standardization.
With EdDSA, a frequent choice among newer cryptocurrencies, being Schnorr-based, Bitcoin adding support for Schnorr signatures with its Taproot upgrade, and Ethereum supporting Schnorr signatures via its smart contracts, Schnorr signatures are now widespread and well supported.
Serai took the IRTF draft and produced modular-frost, our extremely flexible implementation of FROST. We had this audited, along with the rest of our cryptography which we plan to use, all the way back in March 2023. We successfully applied it to all the networks that we plan to launch with and have even had it acknowledged by multiple other parties looking to utilize FROST for their own purposes.
With FROST, we have a protocol we can be confident in. With our implementation, we have a highly efficient signature scheme we can apply to any network we want, which supports Schnorr. With our audit, we've worked to ensure our implementation is properly secure.
]]>modular-frost is our audited implementation of FROST, a threshold signature scheme to produce Schnorr signatures. We applied it to Monero's CLSAG signature scheme in our very own Monero library (monero-serai).
Initially, our Monero library utilized monero-rs, a Rust library implementing various structures for working with Monero transactions. monero-rs never implemented signing, leaving monero-serai to do so. We also relied on the existing Monero cryptography in C++ to perform the Bulletproofs needed inside Monero transactions.
Over time, we replaced more and more of monero-rs as it wasn't as ergonomic as we desired. Eventually, monero-serai completely removed monero-rs, instead fully implementing the Monero transaction structures ourselves. We did still use Monero's C++ for some cryptography, until that was also removed for performance benefits.
This left us with a complete implementation of Monero transactions, signing, and scanning in Rust.
We then extended our library with functionality beneficial to Serai, notably:
1) Featured Addresses: A specification for Monero addresses offering more functionality than the already defined address schemes.
2) Eventualities: A way to check if an on-chain transaction matches a transaction we intended to sign.
We are not Monero-focused. While yes, we did a lot of work to integrate Monero, all of that work was done in a self-contained Monero library. The actual integration with Serai completely conforms to the expected API. At no higher level did we add Monero-specific code.
We are a project that respects Monero for being a quality privacy coin, yet we are our own project which is attempting to be the best solution for cross-chain swaps. Our integration of Monero, with all the time it took, may be a love letter to Monero, but it is not a pledge of allegiance.
Serai has also never taken funding from the Monero community.
Correct. There is no Monero-specific code outside of its integration file (and the self-contained monero-serai library, of course). It satisfies the exact same API we use for Bitcoin, despite being a privacy coin with its own set of complexities. This is possible thanks to:
1) Strong theoretic modeling of requirements to integrate an external network
2) Reduction of those requirements to minimal forms, offering more flexibility with integrations
3) Our own software stack being incredibly robust and versatile
All of this work on Monero took several months. If we aren't Monero-focused, how can we justify delaying all of Serai for so long in order to launch with it?
Integrating Monero prior to launch has actually been amazing for us. Only due to facing Monero's complexities did we properly define, and revisit, assumptions we place on external networks in order to successfully integrate with them. By ensuring we can support Monero prior to launch, we've ensured and rigorously demonstrated our software stack can face whatever challenge we may line up in the future.
There also wouldn't be notable appeal to Serai if we solely launched with Bitcoin and Ethereum. There's multiple protocols which already offer Bitcoin-Ethereum swaps. By also including Monero, we provide a unique offering and demonstrate our technical competency. We aren't here to be the 20th bridge between Ethereum and all the forks of Ethereum. We are here to connect networks, regardless of their specific challenges, and provide a quality cross-chain decentralized exchange.
We could have launched with a distinct network, one largely unserviced by DEXs, in order to establish our unique offering. We chose Monero, despite the amount of time and effort it would be, due to its importance. In a modern day society which is increasingly digital and increasingly less private, Monero fights to re-establish privacy for your payments. We believe in that mission and want to enable everyone to have access to personal privacy.
Largely nothing. If you're interested in Serai for its integration of Monero, Serai will still do its best to integrate Monero. Serai will also do its best to integrate Bitcoin and Ethereum, the other networks its launching with, as part of its responsibility to be the best DEX it can be. This post isn't intended to disregard Monero, yet instead to highlight how Serai is a freestanding project with its own goals and responsibilities. With that comes responsibilities to Monero, yet none unique to Monero. Instead, they're the same responsibilities given to all integrated networks.
]]>Serai itself is a blockchain, built on top of Substrate, a blockchain development framework comparable to the Cosmos SDK. The main reason for using a blockchain framework is because Serai is not attempting to revolutionize blockchain networks with advanced consensus mechanisms and new methods of P2P communication. Serai is attempting to be a rock-solid decentralized exchange, and using a blockchain to coordinate token and liquidity pool state is an implementation detail. Substrate is sufficiently performant for our needs, with a notable ecosystem built around it.
Validators stake to participate in consensus, either Serai's own or consensus over an external network. Since validators stake per network, at launch we will be looking at having up to 600 validators. With this capacity, we can ensure all validators who want to participate can actually do so, never leaving stake unused due to not being selected to actively participate. We also can drastically bring down the node requirements in comparison to other networks as validators do not have to run nodes for every single blockchain. They solely have to run a Serai node and nodes for any external networks they choose to validate over.
Each validator who validates over an external network runs a "coordinator". The coordinator is a service which forms a P2P network with all other validators' coordinators, enabling performing signing operations. While we could reuse the Serai blockchain for this, doing so would bloat the blockchain with ephemeral data we don't need nor want to keep around forever.
We do however need to obtain consensus over how signing operations occurred. If any validator was allowed to publish multiple messages within a signing protocol, it'd cause a variety of security issues. In order to ensure everyone sees all messages, and that each validator only published a single message, we place all messages for each signing protocol into the mempool of a disposable blockchain known as a "tributary". Validators produce blocks containing these messages, coming to consensus on them. Only messages with consensus are acted on, ensuring that no validator sent distinct messages to different validators without detection.
At the end of a multisig's lifetime, its blockchain is disposed of, ensuring we don't waste storage space on old signing protocols that have run their course.
Each validator for an external network runs a "processor" for it. Processors index the external network, find relevant transactions, inform Serai of any received coins, and schedule payments out from Serai.
This is arguably the most critical part of Serai. Our entire purpose is to connect with external networks and the processor must do so with complete accuracy. Any mistake when indexing could lead to a double spend against Serai. Any hiccup in how we sort data could cause processors to disagree on the current state, leading to consensus failures.
To ensure security and propriety, we've clearly modeled our data pipelines and have extensively worked to ensure we're free of race conditions. We've even begun exhaustively modeling Serai's design to prove it free of race conditions.
We also have audited the cryptography used by our processor, audited our application of our cryptography to Bitcoin, and are planning audits for our application to Ethereum/Monero, along with an audit for the processor itself.
All of these work in concert to become Serai, a platform priding itself on correctness and efficiency, intending to offer the most competent cross-chain decentralized exchange out there.
If you have any questions, or simply want to keep an eye on Serai, please join us on Discord/Matrix/X (Twitter).
]]>