The XRP Ledger (XRPL) is a decentralized layer 1 blockchain renowned for its decade-long reliability and stability in tokenizing and exchanging crypto-native and real-world assets.
The XLS-66 specification introduces the XRP Ledger-native Lending Protocol, which facilitates straightforward, on-chain, uncollateralised fixed-term loans with pre-set interest terms. Loan liquidity is sourced from pooled funds, while the design relies on off-chain underwriting and risk management to assess borrowers’ creditworthiness.
Live
Triaged by Immunefi
Step-by-step PoC Required
KYC required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Build commands, Test commands, and instructions on how to run them:
Build instructions: https://github.com/XRPLF/rippled/blob/develop/BUILD.md
Test environments:
- Public server: lend.devnet.rippletest.net
- Public server faucet: lend-faucet.devnet.rippletest.net
- curl -X POST https://lend-faucet.devnet.rippletest.net/accounts
- How XRPL faucets work: https://xrpl.org/resources/dev-tools/xrp-faucets
Previous Audits
Ripple’s completed audit reports for Single Asset Vault, MPT, Credentials, Permissioned Domainscan be found at http://opensource.ripple.com. Unfixed vulnerabilities mentioned in these reports are not eligible for a reward.
Public Disclosure of Known Issues
Bug reports for publicly disclosed bugs are not eligible for a reward.
- VaultWithdraw throws "tecINVARIANT_FAILED" when fee matches withdraw amount is being fixed in https://github.com/XRPLF/rippled/pull/5876/
- Submitting
LoanBrokerCoverDepositwith just the base reserve throws "telFAILED_PROCESSING" - sign_for error - multi-signing
- Conditions
- Borrower has multi-signing enabled with two signers.
- Lender creates LoanSet transaction, populates Counterparty with borrowers account and signs it.
- Signers individually signs the already signed transaction in #2.
- CounterpartySignature is populated by sorting two Signer objects based on the Account field as we do for multi-sign transactions.
- However, when submitting this transaction, I get: fails local checks: Counterparty: Invalid signature on account
- Conditions
Is this an upgrade of an existing system? If so, which? And what are the main differences?
- No upgrade. SAV and Lending protocol are V1
Where do you suspect there may be bugs and/or what attack vectors are you most concerned about?
Prioritize anything that has to do with the security of the funds. The security of funds can be compromised through the following vectors:
Lending Protocol:
- Liquidation Logic: Find ways to trigger unfair liquidations or prevent liquidations from happening
- Interest Rate Calculation: Discover bugs that lead to incorrect interest accrual, either for the lender or borrower
- Clawback and Deepfreeze: test if asset freezing and clawback can be circumvented in lending protocol
- Administrative attacks: Mess with the protocol's records and internal numbers to break its rules, causing a mismatch between funds and shares.
SAV:
- Share Redemption/Minting: Exploit the mechanism for issuing or redeeming MPT tokens to unfairly gain or drain assets
- Deposit/Withdrawal Logic: Uncover edge cases that allow a user to withdraw more assets than they deposited or are entitled to
- Reward Distribution: Discover flaws in how LPs are calculated and distributed
- FLC Exploit: Manipulate the First Loss Capital mechanism to unfairly shift losses, avoid liability, or directly drain funds from the pool
Interaction of SAV & Lending Protocol with compliance primitives:
- Access Control: Bypass administrative controls or privileged functions (The lending protocol supports permissioned access both on the borrower and lender side, via on-chain primitives such as permissioned domains, credentials - we wnat to make sure the protocol can work with these without security tradeoffs)
Which chains and/or networks will the code in scope be deployed to?
- XRP Ledger
What external dependencies are there?
We are targeting institutions with this protocol, which means that the collateral is not onchain. They might want to keep the collateral with crypto custodians like Bitgo for example. This does not directly affect the code, but the researchers should take into account that part of the loan lifecycle will be manually coordinated.
Are there any unusual points about your protocol that may confuse Security Researchers?
Not unusual, but it's something to remember: there are no smart contracts or hooks on the XRPL.
What are the most valuable educational resources already available? (Ie. Documentation, Explainer videos or articles, etc)
Drainage and/or stealing of funds from ledger objects (vault, first loss capital)
Direct loss of funds
Modification of the loan setting resulting in unfair distribution and/or gaming of funds
Gaming of vault and protocol setting using different types of tokens available on XRPL (IOUs, MPTs etc)
Modification of fees outside of design parameters (hacker modifies late payment fee, repayment fee, management fee)
Permanent freezing of funds (fix requires hardfork)
Theft of unclaimed yield
Permanent freezing of unclaimed yield
A bug in the respective layer 0/1/2 network code that results in unintended primitive behavior with no concrete funds at direct risk.
Impacts caused by griefing with no economic damage to any user on the network
Security best practices
Code Optimizations and Enhancements
Out of scope
Blockchain/DLT specific
- Incorrect data supplied by third party oracles
- Not to exclude oracle manipulation/flash loan attacks
- Impacts requiring basic economic and governance attacks (e.g. 51% attack)
- Lack of liquidity impacts
- Impacts from Sybil attacks
- Impacts involving centralization risks
All categories
- Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed
- Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
- Best practice recommendations
- Feature requests
- Impacts on test files and configuration files unless stated otherwise in the bug bounty program
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers