XRP Ledger (XRPL)

None

Public APIs are typically hosted/exposed by public servers, and not UNL Validators. Admins of public servers are considered trusted within their own infrastructure.

UNL validators are considered trusted and will not maliciously deploy incorrect versions or altered source code.

MPT and IOU Token issuers are considered trusted for their own token issuances, and they will not maliciously use compliance-intended features like freeze, lock, clawback, etc. to affect token holders.

PoCs should consist of only public transactions and public APIs. They cannot contain altered rippled/xrpl source code, as that requires malicious intent by public server admins or UNL Validators. Public server admins are all admin roles in general and they're considered trusted.

No

Batch: https://xls.xrpl.org/xls/XLS-0056-batch.html

Permission Delegation: https://xls.xrpl.org/xls/XLS-0075-permission-delegation.html

MPT DEX: https://xls.xrpl.org/xls/XLS-0082-mpt-dex.html

Confidential Transfers for MPT: https://xls.xrpl.org/xls/XLS-0096-confidential-mpt.html and https://xls.xrpl.org/xls/XLS-0094-dynamic-MPT.html

Sponsored Fees and Reserves: https://xls.xrpl.org/xls/XLS-0068-sponsored-fees-and-reserves.html

Breaking the spec from the above XLS can qualify as Low severity even if impact is non-monetary (unless it conflicts with common sense).

None

Invariants in codebase will throw an error when broken, and these codebase invariants should hold. Breaking the invariant can qualify as Low severity even if impact is non-monetary (unless it conflicts with common sense).

FAQ of XLS specs will cover common design choice questions

Any public reported GitHub Issue in https://github.com/XRPLF/rippled/issues or https://github.com/XRPLF/mpt-crypto/issues , or GitHub PR opened in https://github.com/XRPLF/rippled/pulls or https://github.com/XRPLF/mpt-crypto/pulls , before the program start date (April 13th 3:00 PM UTC), would be considered a known issue for the codebase in general.

Previous audits for XRPL can be found at:

• https://www.halborn.com/audits/ripple/ripple---batch---smart-contract-assessment-420598
• https://github.com/fyeo-io/public-audit-reports/blob/main/Code%20Audit%20Reports/2025/Ripple/Ripple%20-%20Security%20Code%20Review%20of%20XRPL%20Permission%20Delegation%20v1.0%20FINAL.pdf
• https://www.halborn.com/audits/ripple/mpt-dex-ef128a
• https://github.com/fyeo-io/public-audit-reports/blob/main/Code%20Audit%20Reports/2026/Ripple/Ripple%20-%20Security%20Code%20Review%20of%20XRPL%20Sponsored%20Fees%20and%20Reserves%20v1.0.pdf

Build instructions:
https://github.com/XRPLF/rippled/blob/ripple/attackathon-april-2026/BUILD.md along with configuring amendment voting to XRPL mainnet plus all amendments described in commit https://github.com/XRPLF/rippled/commit/ac4f14298a8b64f3b1dec22e7abee86814a119e3

Confidential Transfer resources:
This utility https://github.com/XRPLF/mpt-crypto/blob/bdada902cdd0d27f84abee70037bba8656845ea1/src/utility/mpt_utility.cpp can be used to generate proofs needed to submit transaction related to Confidential Transfers for MPT

Docs:
https://opensource.ripple.com/
https://xrpl.org/docs

Determining valid finding:

• Previous version: https://github.com/XRPLF/rippled/commit/6d1a5be8d28e19feba530fed812ff28c341a1dc4 with the amendments described in commit https://github.com/XRPLF/rippled/commit/ac4f14298a8b64f3b1dec22e7abee86814a119e3 turned off (unsupported, non-existent, or voted no)
• Current Version: https://github.com/XRPLF/rippled/commit/a1613e5b0dbce93b705b82280a6760fd6955a974 and the amendments described in this commit https://github.com/XRPLF/rippled/commit/ac4f14298a8b64f3b1dec22e7abee86814a119e3 turned on (supported and voted yes)
• Diff: https://github.com/XRPLF/rippled/compare/6d1a5be8d28e19feba530fed812ff28c341a1dc4…a1613e5b0dbce93b705b82280a6760fd6955a974 along with the enablement and voting yes for amendments in https://github.com/XRPLF/rippled/commit/ac4f14298a8b64f3b1dec22e7abee86814a119e3. Make sure your setup has amendments turned on, as the issues with them turned off will be considered out of scope and invalid.

A valid finding must demonstrate new impact or significantly elevated impact in "Current version" in comparison to "Previous Version", and must include a coded PoC that contains transactions and/or APIs that relate to a feature's XLS spec. Coded PoCs are mandatory for any issue of any severity.

Issues included:

1. A completely new root cause, and the issue is fully introduced by the upgrade.
2. The root cause existed before the upgrade, but didn’t lead to any issues (e.g. there was no impact or the issue couldn't get triggered)
3. The issue existed before the upgrade, but the upgrade increased the severity (includes no impact to Low, Medium to Crit, Low to High, etc. any increased impact).

Issues excluded:

Existed before the upgrade and doesn’t lead to higher impact, or the impact remains unchanged.

Examples:

• The issue had no impact in the previous upgrade, but after the upgrade, it leads to Low or any higher severity -> this should be considered in-scope and valid.
• The issue had Medium impact in the previous version, but after the upgrade, it leads to High or Critical severity (or in general, the impact increased after the upgrade) -> this should be considered in-scope and valid.
• The issue had Medium impact in the previous version, but after the upgrade, it has Low severity impact (or, in general, the impact decreased after the upgrade) -> this should be considered out of scope and invalid.
• The issue had a medium impact in the previous version. After the upgrade, the impact changed (e.g. before it led to permanent DOS, but now it leads to a loss of funds), but the severity remains the same (still Medium severity) -> this should be considered out of scope and invalid.
• The issue existed in the previous version, but the upgrade introduced the very same issue in a different place (ie, the same root cause appears in a different part of the code introduced by the upgrade) -> the issue is considered a duplicate of the previously existing issue and is invalid.

Out of scope findings can be directly reported to Ripple's existing general Bug Bounty program: https://ripple.com/legal/bug-bounty/

Labelling confirmed findings to feature:

Please label each confirmed finding with the feature(s) that are relevant. Common ways to determine labelling would be looking at the Transaction types or API method in the PoC, and comparing that to the feature XLS spec that contains a list of new/adjusted transactions and APIs. Please mention the relevant feature at the start of the report. This labelling will help the triage team accurately determine validity.

The contest will use the following severity definitions:

Critical severity:

Direct loss of funds without (extensive) limitations of external conditions. The loss of the affected party must exceed 20% and 100 USD.

Examples:

Users lose more than 20% and more than $100 of their principal.

Users lose more than 20% and more than $100 of their yield.

The protocol loses more than 20% and more than $100 of the fees.

High severity:

Direct loss of funds without (extensive) limitations of external conditions. The loss of the affected party must exceed 5% and 50 USD.

Examples:

Users lose more than 5% and more than $50 of their principal.

Users lose more than 5% and more than $50 of their yield.

The protocol loses more than 5% and more than $50 of the fees.

Medium severity:

Causes a loss of funds but requires certain external conditions or specific states, or a loss is highly constrained. The loss of the affected part must exceed 1% and 10 USD.

Breaks core contract functionality, rendering the contract useless or leading to loss of funds of the affected party that exceeds 1% and 10 USD.

Examples:

Users lose more than 1% and more than $10 of their principal.

Users lose more than 1% and more than $10 of their yield.

The protocol loses more than 1% and more than $10 of the fees.

Low severity:

Causes a loss of funds (either due to an attack or broken functionality), but requires extreme external conditions or specific states, or a loss is highly constrained. The loss of the affected part must exceed 0.01% and 10 USD.

Breaks the invariants or the XLS spec, even without monetary impact, unless it conflicts with common sense.

Examples:

Users lose more than 0.01% and more than $10 of their principal.

Users lose more than 0.01% and more than $10 of their yield.

The protocol loses more than 0.01% and more than $10 of the fees.

Note: If a single attack can cause a 0.01% loss but can be replayed indefinitely, it may be considered a 100% loss and can be of higher severity, depending on the constraints.

Reward structure breakdown

The contest covers 5 features.
Each feature can unlock part of the reward pool depending on the highest valid severity found in that feature. The features include:

• Batch
• Permission Delegation
• MPT DEX
• Confidential Transfers for MPT
• Sponsored Fees and Reserves

The feature where the issue is will be considered based on the root cause. If the issue touches several features, the exact root cause of the issue will determine which feature pot is unlocked. For example, if the issue touches Batch and Confidential Transfers features, but the root cause of the issue is inside the Batch feature, then it's considered an issue in the Batch feature.

Pool unlocked per feature

For each feature, the unlocked amount is:

• At least 1 Low: USD 1,800
• At least 1 Medium: USD 13,800
• At least 1 High: USD 43,800
• At least 1 Critical: USD 103,800

These numbers come from dividing the total severity pools equally across the 5 features:

Note: the contest pools include Lead Senior Watson (LSW) and Lead Judge (LJ) fixed pays

• Low pool: USD 40,000 total - USD 25,000 LSW - USD 6,000 LJ → USD 9,000 total → USD 1,800 per feature
• Medium pool: USD 100,000 total - USD 25,000 LSW - USD 6,000 LJ → USD 69,000 total → USD 13,800 per feature
• High pool: USD 250,000 total - USD 25,000 LSW - USD 6,000 LJ → USD 219,000 total → USD 43,800 per feature
• Critical pool: USD 550,000 total - USD 25,000 LSW - USD 6,000 LJ → USD 519,000 total → USD 103,800 per feature

Important rule

For each feature, only the highest valid severity found in that feature determines how much of the pool is unlocked.

That means:

• if a feature has both a valid Low and a valid Medium, that feature unlocks USD 13,800, not USD 15,600
• if a feature has multiple valid Criticals, that feature still unlocks USD 103,800 total, not USD 103,800 per Critical

After the total unlocked pot is determined, it is distributed across all valid findings using the standard contest severity weights.

Severity weights used for payout

• Low: 0.5
• Medium: 1
• High: 5
• Critical: 10