2025-03-25 XRPL EVM Sidechain

Security Audit Report

Ripple Q1 2025: XRPL EVM Sidechain

Last revised 25.03.2025

Contents Audit overview 3 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Audit plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Audit Dashboard 4 Target Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Engagement Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Severity Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

System Overview 5 Consensus Mechanism: Proof of Authority (PoA) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Interoperability and Asset Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Threat Model 6 Node diff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Invariant related . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 General Properties and Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 evmos fork related properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Findings 15 Invariant checks through crisis module may go unnoticed . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Slashing parameters can be modified to unexpected values . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Validator number validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Unnecessary token burning on validator removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Messages MsgDelegate and MsgCancelUnbondingDelegation should be disabled . . . . . . . . . . . . . . . 20 Separate revoke ownership from transfer ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Minor observations and improvements related to the Cosmos SDK v0.50 upgrade . . . . . . . . . . . . . . 22 Refactor mint.go by splitting responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Appendix: Vulnerability classification 25

Disclaimer 28

Audit overview The Project In February 2025, Ripple Labs engaged Informal Systems to conduct a security audit of the XRPL EVM Sidechain.

Scope of this report The audit focused on evaluating the correctness and security properties of the changes introduced in the XRPL EVM node and the Evmos fork. For the node implementation, the review covered the introduced diffs, with particular attention to their impact on validator management - specifically, the addition and removal of validators through governance proposals and the implementation of the PoA consensus, along with IBC v8 integration and upgrade handler implementations due to the Cosmos SDK v0.50 upgrade. In the Evmos fork, the audit examined the extensions made to the ERC20 precompile contract and the x/erc20 middleware, specifically the addition of mint, burn and ownership transfer functionalities. A key focus was ensuring that these modifications did not introduce unintended vulnerabilities in token pair management, whether executed via smart contract calls or Cosmos SDK messages.

Audit plan The audit was conducted between February 27th, 2025 and March 14th, 2025 by the following personnel: • Mirel Dalcekovic • Andrija Mitrovic

Conclusions The changes introduced in the node diff lack clarity. This stems from the earlier PoA consensus implementation, which retained its old code in the codebase. While this does not affect correctness, it creates confusion, as the communicated intended behavior differs from the existing code in the x/poa module. Additionally, the integration of the x/crisis module requires further review, and the team should decide on its intended impact - specifically, whether and under what cadence the chain should halt if the invariants introduced in the diff are violated. All the findings are listed in the Findings section. During the course of the audit, the development team independently discovered a critical issue that prevented the bank smart contract from minting ERC20 tokens as intended. The root cause was promptly identified and resolved by the development team through a PR. Additionally, we recommend following best practices and guidance related to publicly disclosed security advisories that impact dependencies used in the XRPL EVM Sidechain node codebase. Addressing these advisories before deploying to mainnet is crucial for maintaining the overall security posture of the project: • ibc-go related: ISA-2025-001; ASA-2025-004. • CometBFT related: ASA-2025-002; ASA-2025-001.

Audit Dashboard Target Summary • Type: Protocol and Implementation • Platform: Go & Solidity • Artifacts: – xrlpevm node diff (later tag v6.0.0) – xrplevm evmos fork diff (later tag v20.0.0-exrp.4)

Engagement Summary • Dates: February 27th, 2025 - March 14th, 2025 • Method: Manual code review, protocol analysis

Severity Summary

Finding Severity Number Critical 1 High 0 Medium 0 Low 2 Informational 5 Total 8

System Overview The XRPL EVM Sidechain is an extension of the XRP Ledger (XRPL) that introduces Ethereum Virtual Machine (EVM) compatibility, enabling smart contract functionality within the XRPL ecosystem. Built on the Cosmos SDK, this sidechain employs a Proof-of-Authority (PoA) consensus model. The integration of Ethereum’s smart contract capabilities with XRPL enhances its utility for decentralized applications (dApps) and cross-chain asset transfers.

Consensus Mechanism: Proof of Authority (PoA) The XRPL EVM Sidechain employs a Proof of Authority (PoA) consensus model, where validators are pre-approved through a governance process rather than relying on economic incentives such as Proof of Work (PoW) or Proof of Stake (PoS). Main goal with building the XRPL EVM Sidechain was Preserving the XRP Ledger’s Security & Trust Philosophy: where consensus participats 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. PoA approach aligns with the core principles of the XRP Ledger, ensuring security, trust, and decentralization. PoA Consensus is Built on CometBFT’s PoS: The XRPL EVM sidechain adapts CometBFT’s PoS consensus by introducing key 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.

Interoperability and Asset Transfers The XRPL EVM Sidechain is connected to the XRPL via the Axelar Network, utilizing Axelar’s decentralized validator set and message-passing protocols. This integration enables seamless XRP transfers between XRPL’s native ledger and its EVM-compatible sidechain. • IBC and ERC-20 Compatibility: The sidechain leverages the Evmos framework to facilitate ERC-20 token transfers using Inter-Blockchain Communication (IBC). The x/ibc/transfer application converts ERC-20 tokens into a Cosmos-compatible format for IBC transactions, while the x/erc20 middleware ensures bidirectional conversion between ERC-20 and Cosmos tokens. • Governance and Token Management: Token pairs (ERC-20 <> Cosmos) must be pre-registered via governance using MsgRegisterERC20. Ownership transfers of token pairs can be executed through governance with MsgTransferOwnership or by the current owners using EVM precompiles, allowing designated accounts to mint and manage token supplies. • Burn, Mint, and Ownership Functions: The Evmos fork extends the ERC-20 precompile contract and x/erc20 middleware to support burnable, mintable, and transferable ownership functionalities, ensuring efficient asset movement across the Axelar bridge.

Threat Model In our threat analysis, we start by defining a set of properties required for the correctness of the audited artifacts. For each property, we define one or more threats. We then analyzed them individually to see if they could be violated, resulting in the findings presented in the Findings section.

Node diff Property: Validators can only be instantiated and activated via gover- nance process Violation consequences: Validators can be created not only through an authority (governance) thus violating the PoA protocol. Threats: • Non-authorized (someone other than governance) entity can call AddValidator (submit a MsgAddValidator) and add a validator. • Validator can be created through a standard MsgCreateValidator message. Conclusion: The property holds. • The check ensures that the MsgAddValidator msg’s authority matches the PoA module keeper’s authority. The PoA module keeper is instantiated here, where it is explicitly defined that its authority parameter is set to governance. Enforcement that the MsgAddValidator authority parameter can’t be tampered with is done by setting this parameter to be filled with the msg signer. • Creation of validators through a standard MsgCreateValidator is not possible due to the fact that a validator cannot acquire the tokens the bondable denomination necessary for staking in any other way than through MsgAddValidator msg.

Property: Only validators can be removed from the validator set through the governance process Violation consequences: Validators can be removed not only through an authority (governance) thus violating the PoA protocol. Threats: • Non-authorized (someone other than governance) entity can call RemoveValidator (submit a MsgRemoveValidator) and remove a validator. • Validator can leave or be removed from the current validator set by: – Unbonding: A validator can voluntarily remove themselves (A validator can choose to stop validating by submitting a MsgUnbond transaction). – Low stake: If their total stake falls below the top N validators, they are automatically removed. Conclusion: The property holds. • The check ensures that the MsgRemoveValidator msg’s authority matches the PoA module keeper’s authority. The PoA module keeper is instantiated here, where it is explicitly defined that its authority parameter is set to governance. Enforcement that the MsgRemoveValidator authority parameter can’t be tampered with is done by setting this parameter to be filled with the msg signer. • Due to the fact that the undelegate and redelegate msgs are disabled there is no possibility for a validator to leave the validator set by removing staked coins thus falling outside the needed stake range.

Property: The total supply of BondDenom corresponds to DefaultPowerReduction * len(active validators) where each active validator has DefaultPowerReduction staked BondDenom Violation consequences: Violating this property would lead to existence of free BondDenom tokens in circulation that can be used to bypass the authorized validator creation. Threats: • On removing a validator not all tokens are burned. • BondDenom tokens can only be minted apart from validator creation. • Transfer of BondDenom tokens from a validator to another arbitrary address. Conclusion: The property holds. • No remnants of tokens are left after a validator is removed. All the tokens are burned no matter if these are: – On a balance in the bank. – Bonded. – Unbonded/Unbonding. • BondDenom tokens can be only minted through validator creation by governance and always in the same amount (DefaultPowerReduction) here. Thus there is no possibility of minting tokens on another address apart from a validator. • Transfer of BondDenom tokens from a validator to an arbitrary address is not possible because all the tokens are staked on validator creation and undelegation and redelegation are disabled.

Property: No redelegations and undelegations for validators are allowed Violation consequences: Possibility of redelegations and undelegations can lead to an uneven distribution of power among the validators and at the same time free tokens that can be transferred to arbitrary addresses and then used to bypass the authorized validator creation. Conclusion: The property holds. During validator creation in ExecuteAddValidator, the system verifies that the validator has no delegations to other validators or unbonding delegations. If either exists, the system returns an error and prevents validator creation. Additionally, undelegation and redelegation are prevented since these messages are disabled.

Property: If the authority (governance) initiates validator removal, validator cannot stop the removal Violation consequences: Validator can evade removal from the validator set even though the authority has decided to do so. Threat: • Validator could jail himself in order to avoid being removed from the set. Conclusion: The property holds. A validator cannot prevent their removal by the authority (governance) through self-jailing or any other action. This is because the authority removes validators through ExecuteRemoveValidator by burning all their BondDenom tokens, as explained above. Once these tokens are burned, the validator automatically falls out of the validator set through the staking module.

Property: Validator commission rates must be set to 0 Violation consequences: Basically, no impact if no delegations, but the validators should keep the initial PoA consensus settings. If delegations are somehow made, some validators would earn more rewards on account of their delegations. Threat: • Commission rate parameters can be changed to a value different than 0, leading to the misalignment in existing PoA validators settings. Conclusion: The property holds. The only way that commission rate parameters can be changed is through the MsgEditValidator , which execution is allowed. However XRPL’s Cosmos SDK fork was not altered and the vanilla implementation still stands: Since the maxRate and maxChangeRate are set to 0 initially, the validator is locked at 0% commission forever, They cannot earn staking rewards from their delegations. UpdateValidatorCommission can not be successful executed (code ref): • MaxRate defines the absolute maximum a validator’s commission can reach. If it’s 0, the validator cannot set rate to anything other than 0 - this is checked within ValidateNewRate function (code ref) • The validator can never change the commission rate because: MaxChangeRate = 0 means that even if MaxRate

0, the allowed daily increase is zero - this is checked within ValidateNewRate function (code ref).

Property: Validator’s minimumSelfDelegation must be set to 1 Violation consequences: Changing the minimumSelfDelegation to a value that is lower than DefaultPowerReduction can lead to the fact that not enough tokens have been staked in order to have the same influence from all the validators. Threat: • minimumSelfDelegation value can be changed with editing validator parameters. Conclusion: The property holds. After reviewing the XRPL Cosmos SDK fork, it was confirmed that the implementation remains consistent with the vanilla Cosmos SDK and that the minimumSelfDelegation can not be altered for the PoA validators. Specifically, the restrictions that prevent this are: • minSelfDelegation from decreasing (code ref) • minSelfDelegation from being increased above the validator’s currently bonded stake remains intact in the XRPL fork (code ref) if !msg.MinSelfDelegation.GT(validator.MinSelfDelegation) { return nil, types.ErrMinSelfDelegationDecreased }

if msg.MinSelfDelegation.GT(validator.Tokens) { return nil, types.ErrSelfDelegationBelowMinimum }

This ensures that all validators maintain their expected voting power, preventing any validator from artificially reducing/increasing their self-delegation to manipulate stake-based governance or consensus participation.

Property: Validator edits must not allow modifications to default PoA- related validator parameters Threats: • A validator operator can modify MinSelfDelegation, setting it to an arbitrary value. This may result in an insufficiently bonded token amount relative to the expected PowerReductionValue, potentially affecting staking security guarantees. • A validator operator can update commission rate parameters, which may introduce risks for existing delegations, particularly if excessive protocol changes occur. Conclusion: The property holds. After reviewing the XRPL Cosmos SDK fork, as already shared with the previous property analysis conclusions for the properties: Validator commission rates must be set to 0 and Validator’s minimumSelfDelegation must be set to 1 - it is impossible to alter the CommissionRates and minimumSelfDelegation values.

Invariant related Staking Power Invariant: All validators have the same staking power as the default power reduction (DefaultPowerReduction) Violation Consequences: Unequal staking power breaks the PoA guarantee, leading to validator centralization. This may allow a subset of validators to gain disproportionate influence over consensus and governance, potentially enabling censorship or malicious proposals. Threats: • Arbitrary user or validators could perform delegations of BondDenom tokens to other validators. • Validator rewards are issued in BondDenom tokens and can be used to increase the validator power with self-delegation. Conclusion: The property holds. After reviewing the code and the allowed messages, integrated modules we concluded: • No undelegation and redelegation is allowed (code ref). • Only self-delegations are allowed. All other delegations will be rejected with validation introduced in the BeforeDelegationCreated staking hook (code ref). • There is no mechanism for a validator to acquire unbonded BondDenom tokens to perform self-delegation and increase their power. Our analysis confirms that no additional apoa tokens can be created outside of MsgAddValidator—there is no mint module present, and consequently, no inflation (which aligns with the expectation for a PoA-based chain). Furthermore, all fees are paid exclusively in the designated token denom (verified through localnet testing).

Self-Delegation Invariant: Each validator has exactly one self-delegation, and it matches their validator address Violation consequences: Possibility of validators having different staking powers could lead to consequences listed in the property StakingPowerInvariant. Threats: • Arbitrary user or validators could perform delegations of BondDenom tokens to other validators.

• Validators and arbitrary users could perform undelegations and redelegations leading to fluctuations in validator

Excerpt (19995 of 54122 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation