Smart Contract and Sidechain Risks
The distinct risk profile of using Hooks, sidechains, and third-party XRPL applications compared to plain XRP transfers.
Simply holding or sending XRP on mainnet carries a narrower risk surface than interacting with the more programmable parts of the broader XRPL ecosystem. This page outlines where that risk surface expands, and why.
Why XRPL mainnet's native features are comparatively low-risk
As explained in Hooks, Sidechains, and Smart-Contract-Style Programmability, XRPL mainnet deliberately does not support general-purpose smart contracts — its native features (trust lines, the DEX, AMM, escrow) are fixed, narrowly scoped, and have been reviewed and battle-tested through the amendment process before activation. This significantly limits the kind of open-ended logic bugs that have caused major losses on more programmable chains.
Bridged sidechain risk
Using a bridged sidechain — such as Xahau or the EVM-compatible XRPL sidechain — introduces a different risk category: the bridge connecting mainnet to the sidechain is itself a piece of software (and often a set of trusted or semi-trusted signers) that must correctly and securely handle value moving between the two networks. Bridges, across the broader crypto industry, have historically been a common target for exploits, precisely because they concentrate value and complexity at a single connection point.
Hooks-specific risk
Because Hooks let an account attach custom logic to its own transactions, using an account with a Hook installed — especially one written by a third party — means trusting that Hook's code was written correctly and doesn't contain an exploitable bug or a deliberately malicious backdoor. This is conceptually the same category of risk as interacting with any smart contract on a general-purpose chain like Ethereum, even though it applies to a narrower slice of the XRPL ecosystem specifically.
Third-party application risk
Beyond the protocol layer, any third-party application — a DeFi protocol, an NFT marketplace, a yield product — built on top of XRPL's native features carries its own application-level risk, independent of the underlying ledger's security:
- Smart-contract-adjacent logic bugs, for applications built with Hooks or on a sidechain.
- Centralized points of failure, if the application relies on off-chain infrastructure, admin keys, or a centralized backend that could be compromised or misused.
- Economic design flaws, such as an AMM pool or lending product with parameters that can be exploited under specific market conditions, independent of any code bug.
Practical guidance
- Understand whether you're interacting with a native XRPL mainnet feature (lower protocol-level risk) or a bridged sidechain / third-party application (a meaningfully different, generally higher risk profile).
- For sidechain or Hooks-based applications, look for independent security audits, a track record of operation, and transparency about who controls any admin keys or bridge signing authority.
- Treat "new," unaudited applications — regardless of what chain or sidechain they're on — with proportionally more caution than long-established, audited infrastructure.
See Custody Risk and Counterparty Risk for the related, but distinct, question of who holds your funds rather than what code governs them.