Strengthening XRPL EVM Sidechain: Key Takeaways from Informal Systems Security Audit

The XRPL EVM Sidechain—bringing smart contract capabilities to the XRP Ledger ecosystem—recently underwent a rigorous security audit conducted by Informal Systems, a team of world-class researchers, engineers and operators who specialize in security audits for blockchain products.. The audit, carried out in February of 2025, assessed the correctness, security, and reliability of the XRPL EVM Sidechain implementation, including both the core node diff and its customized Cosmos EVM fork. As programmability expands across the XRP Ledger ecosystem, ensuring a secure foundation is paramount. The XRPL EVM Sidechain is built with Cosmos SDK and its consensus layer is enabled by CometBFT. It has full EVM compatibility, including all Ethereum libraries, smart contracts and EVM development tools like Open Zeppelin and Hardhat, and it supports institutional use cases and cross-chain flow of digital assets. This audit helps validate the robustness of the sidechain’s architecture as it scales for real-world financial applications. The diagram above illustrates the architecture of Cosmos SDK using Evmos/Cosmos EVM as the EVM execution layer and CometBFT as the consensus layer. Exploring Audit Findings The audit identified only one critical issue overall, which was tied to the use case of the crisis module for invariant enforcement. Other issues were rated low or informational and are largely related to architectural clarity and best practices. All of these findings have since been resolved by the Peersyst and RippleX engineering teams, with Informal Systems designating them as such. Let’s dive into a breakdown of the aforementioned findings: Critical Finding: Crisis module Ineffectiveness The audit identified that the crisis module does not reliably halt the chain upon detecting invariant violations, which could allow unnoticed security issues. This behaviour is consistent with a broader Cosmos SDK advisory. RippleX and building partner Peersyst are actively considering alternative approaches for checking invariants, and have since added a relevant fix which has been acknowledged by Informal Systems. PoA with Guardrails: A Secure Validator Set The audit outlines that the XRPL EVM Sidechain’s Proof-of-Authority (PoA) consensus is enforced with strong and stable safeguards that include the fact that validators can only be added or removed via a transparent governance process. A key aim in building the XRPL EVM Sidechain was the preservation of the XRP Ledger’s focus on security and trust, where consensus participants define their own Unique Node List (UNL) and as a consequence the XRPL network minimizes the risk of a single point of failure or centralized control. The PoA Consensus is built on CometBFT’s PoS: The XRPL EVM sidechain adapts CometBFT’s PoS consensus by introducing specific restrictions to enforce PoA: Validators are added and removed exclusively through the governance process. A special BondDenom token is used solely for staking: -- When a validator is created, a predefined amount is minted as stake. -- When a validator is removed, the staked amount is burned. The system does not contain any unstaked (free) BondDenom tokens. Re-delegations and un-delegations are not permitted. Each validator has only a single self-delegation (created at the moment of adding the validator, when the staking amount is minted). Slashing penalties do not apply, meaning staking amounts remain unchanged. No BondDenom token rewards are distributed (no inflationary rewards), and since there are no delegations, rewards distribution and commission rate settings are irrelevant. These parameters reinforce predictable validator behaviour and reduce governance and consensus risk, which is of course critical for institutional-grade applications. Strengthened Token Management via Cosmos EVM Fork The Evmos fork introduced enhancements to ERC-20 token precompiles, allowing minting, burning, and ownership transfer. The audit confirmed that only authorized token owners can mint or burn assets. Ownership is gated through governance or EVM precompiles with strict checks, and no unauthorized token actions are possible through the Cosmos SDK or EVM paths. The audit also suggested separating ownership revocation from transfer logic to avoid unintentional contract lockouts- an improvement the team has acknowledged and will consider for future releases. Low-Risk and Informational Observations Roundup Most other findings related to other informational aspects that did not pose immediate risks but offer opportunities for streamlining and ensuring further clarity in future development cycles. Minimum and maximum validator number validation Unnecessary token burning on validator removal Cosmos SDK v0.50 upgrade housekeeping Separate revoke ownership from transfer ownership Messages MsgDelegate and MsgCancelUnbondingDelegation should be disabled Refactoring suggestions (For example, separating logic in mint.go) Building on t

Apr 4, 2025 - 00:34

Strengthening XRPL EVM Sidechain: Key Takeaways from Informal Systems Security Audit

The XRPL EVM Sidechain—bringing smart contract capabilities to the XRP Ledger ecosystem—recently underwent a rigorous security audit conducted by Informal Systems, a team of world-class researchers, engineers and operators who specialize in security audits for blockchain products.. The audit, carried out in February of 2025, assessed the correctness, security, and reliability of the XRPL EVM Sidechain implementation, including both the core node diff and its customized Cosmos EVM fork.

As programmability expands across the XRP Ledger ecosystem, ensuring a secure foundation is paramount. The XRPL EVM Sidechain is built with Cosmos SDK and its consensus layer is enabled by CometBFT. It has full EVM compatibility, including all Ethereum libraries, smart contracts and EVM development tools like Open Zeppelin and Hardhat, and it supports institutional use cases and cross-chain flow of digital assets. This audit helps validate the robustness of the sidechain’s architecture as it scales for real-world financial applications.

The diagram above illustrates the architecture of Cosmos SDK using Evmos/Cosmos EVM as the EVM execution layer and CometBFT as the consensus layer.

Exploring Audit Findings
The audit identified only one critical issue overall, which was tied to the use case of the crisis module for invariant enforcement. Other issues were rated low or informational and are largely related to architectural clarity and best practices. All of these findings have since been resolved by the Peersyst and RippleX engineering teams, with Informal Systems designating them as such. Let’s dive into a breakdown of the aforementioned findings:

Critical Finding: Crisis module Ineffectiveness
The audit identified that the crisis module does not reliably halt the chain upon detecting invariant violations, which could allow unnoticed security issues. This behaviour is consistent with a broader Cosmos SDK advisory.

RippleX and building partner Peersyst are actively considering alternative approaches for checking invariants, and have since added a relevant fix which has been acknowledged by Informal Systems.

PoA with Guardrails: A Secure Validator Set
The audit outlines that the XRPL EVM Sidechain’s Proof-of-Authority (PoA) consensus is enforced with strong and stable safeguards that include the fact that validators can only be added or removed via a transparent governance process. A key aim in building the XRPL EVM Sidechain was the preservation of the XRP Ledger’s focus on security and trust, where consensus participants define their own Unique Node List (UNL) and as a consequence the XRPL network minimizes the risk of a single point of failure or centralized control.

The PoA Consensus is built on CometBFT’s PoS: The XRPL EVM sidechain adapts CometBFT’s PoS consensus by introducing specific restrictions to enforce PoA:

Validators are added and removed exclusively through the governance process.
A special BondDenom token is used solely for staking:
-- When a validator is created, a predefined amount is minted as stake.
-- When a validator is removed, the staked amount is burned.
The system does not contain any unstaked (free) BondDenom tokens.
Re-delegations and un-delegations are not permitted.
Each validator has only a single self-delegation (created at the moment of adding the validator, when the staking amount is minted).
Slashing penalties do not apply, meaning staking amounts remain unchanged.
No BondDenom token rewards are distributed (no inflationary rewards), and since there are no delegations, rewards distribution and commission rate settings are irrelevant.

These parameters reinforce predictable validator behaviour and reduce governance and consensus risk, which is of course critical for institutional-grade applications.

Strengthened Token Management via Cosmos EVM Fork
The Evmos fork introduced enhancements to ERC-20 token precompiles, allowing minting, burning, and ownership transfer. The audit confirmed that only authorized token owners can mint or burn assets. Ownership is gated through governance or EVM precompiles with strict checks, and no unauthorized token actions are possible through the Cosmos SDK or EVM paths.

The audit also suggested separating ownership revocation from transfer logic to avoid unintentional contract lockouts- an improvement the team has acknowledged and will consider for future releases.

Low-Risk and Informational Observations Roundup
Most other findings related to other informational aspects that did not pose immediate risks but offer opportunities for streamlining and ensuring further clarity in future development cycles.

Minimum and maximum validator number validation
Unnecessary token burning on validator removal
Cosmos SDK v0.50 upgrade housekeeping
Separate revoke ownership from transfer ownership
Messages MsgDelegate and MsgCancelUnbondingDelegation should be disabled
Refactoring suggestions (For example, separating logic in mint.go)

Building on the Audit
The RippleX engineering team and Peersyst have since addressed all relevant recommendations, as outlined in the final report, and will continue to strengthen the XRPL EVM Sidechain ahead of production-grade adoption. This audit reaffirms the XRPL EVM Sidechain’s willingness and readiness to support enterprise-grade tokenization, smart contract deployment, and real-world asset applications.

To learn more you can explore the official XRPL EVM Sidechain website and reach out to the Peersyst team and broader RippleX team via X to stay up to date on future developments, open source contributions, and production rollout plans. You can also reach out to the masterminds at Peersyst who have been instrumental in the development of the XRPL EVM Sidechain.