The distinction became particularly relevant after the recent Bitget security breach. Stolen XRP continued moving between addresses because the XRP Ledger has no protocol feature that allows Ripple, an exchange or another issuer to freeze native XRP. By contrast, issuers of centralized stablecoins can have administrative controls that allow specific token balances to be frozen.
This does not mean XRP can never be restricted in any context. A centralized exchange can freeze a customer’s exchange account, preventing the customer from withdrawing or trading XRP held in custody.
The difference is where the control exists.
Native XRP has no issuer-level freeze function. While XRPL-issued assets may have issuer-controlled freeze, lock or clawback features depending on the asset type and configuration. But if XRP held on a centralized exchange, the exchange can restrict access to assets it custodies.
Understanding these three layers explains why stolen XRP can behave very differently from assets such as USDT or USDC during a security incident.
Native XRP cannot currently be frozen or clawed back at the XRP Ledger protocol level. XRP has no issuer with administrative control over individual XRP balances.
Tokens issued on the XRP Ledger are different from XRP. Depending on their type and configuration, issuers can have freeze, lock or clawback capabilities.
Centralized exchanges can still freeze access to XRP they custody. That is an off-chain account restriction rather than the XRP Ledger freezing the XRP itself.
The simplest explanation is that XRP has no issuer.
On many blockchain networks, there is an important difference between the network’s native asset and tokens created by third parties.
Take Ethereum as an example, ETH is the native asset, while USDT and USDC are tokens issued through smart contracts.
The XRP Ledger makes a similar distinction.
XRP is the native asset used directly by the ledger. XRPL documentation describes XRP as having no issuer and states explicitly that it cannot be frozen. Issued assets are different because an identifiable account or entity creates them and may retain certain administrative powers over them.
This gives us the central principle that freeze authority generally comes from the asset’s issuer or controlling contract—not simply from the blockchain on which the asset exists.
XRP has no equivalent issuer account that can decide:
“This address can no longer transfer its XRP.”
That function does not exist for native XRP under the current XRP Ledger protocol.
The distinction becomes clearer when looking at how XRPL represents different assets.
XRP is tracked directly as part of an account’s XRP balance. Traditional fungible tokens issued on XRPL use trust lines, which represent the relationship between the token issuer and holder.
XRPL also supports Multi-Purpose Tokens (MPTs), a newer token model with different ledger structures and configurable issuer controls.
| Feature | Native XRP | Trust-Line Token | Multi-Purpose Token |
|---|---|---|---|
| Issuer | None | XRPL account | XRPL account |
| Can issuer freeze/lock? | No | Yes, unless freeze authority has been relinquished | Can support issuer locking |
| Clawback | No | Possible if enabled before issuance | Possible if enabled |
| Supply | Original 100B XRP; cannot increase | Determined by issuer | Determined by issuer |
| Main relationship | Native account balance | Issuer-holder trust line | MPT issuance/holder model |
This distinction explains why saying “XRPL has a freeze function” and “XRP can be frozen” are not the same statement. XRPL have asset-control mechanisms but they simply do not apply to native XRP.
For traditional trust-line tokens, XRPL currently supports several forms of freeze control.
An Individual Freeze prevents a specific counterparty from transferring the issuer’s token normally.
A Deep Freeze imposes stronger restrictions, including preventing the affected account from receiving the frozen token.
A Global Freeze allows an issuer to restrict its issued token across the network, such as during a security incident.
XRPL also has a "No Freeze" setting. An issuer can use it to permanently give up certain freezing capabilities.
These controls exist because an issued token represents something fundamentally different from XRP.
A stablecoin issuer, for example, may need mechanisms for complying with sanctions, responding to fraud or handling a compromise involving its underlying systems.
Native XRP has no equivalent issuer responsible for honoring a claim or maintaining an external reserve.
Another important distinction is between freezing an asset and clawing it back.
A freeze restricts what a holder can do with an issued asset.
A clawback actually allows an issuer to recover some of its issued tokens from another account when the relevant functionality was enabled.
Consider a hypothetical USD-backed token issued on XRPL.
If an address is linked to stolen funds, the issuer might freeze the token so the holder cannot transfer it normally.
If the token was configured with clawback authority, the issuer may also be able to remove eligible tokens from that account under the protocol’s clawback rules.
Neither mechanism applies to XRP.
XRPL’s documentation explicitly states that XRP cannot be clawed back.
That makes native XRP fundamentally different from an issuer-controlled token even when both assets move across the same XRP Ledger.
The comparison with centralized stablecoins makes the distinction easier to understand.
Suppose an attacker steals two assets, $1 million worth of native XRP and $1 million worth of an issuer-controlled stablecoin.
The blockchain may reveal exactly which addresses received both assets.
But knowing where an asset is located does not automatically provide the power to stop it from moving.
For the stablecoin, the issuer may have administrative functionality capable of restricting the stolen tokens, depending on the network and token implementation.
For native XRP, there is no XRP issuer with an equivalent blacklist function.
Ripple cannot simply identify the attacker’s XRPL address and disable the XRP balance.
That difference became highly visible during the recent Bitget's $387.5mil hack.
Bitget suffered a hot and cold wallet security breach which involved hundreds of millions of dollars in digital assets.
By September 26, CoinDesk reported that the attacker had moved approximately $83 million worth of stolen XRP from several holding wallets, while around $75 million remained across the original XRP holding addresses.
Those remaining XRP balances could be tracked publicly, which drew added attention because observers could watch the funds move but could not simply freeze them on the XRP Ledger.
At the same time, Circle and Tether had reportedly frozen roughly $320,000 of related centralized stablecoin funds with the action targeted an Ethereum address labeled "Bitget Exploiter 8" on Etherscan.
This creates an unusually clear real-world demonstration of the difference.
The problem was not identifying the XRP.
Blockchain investigators could see where much of it was located.
For an issuer-controlled stablecoin, the issuer may possess administrative powers over the token.
For native XRP, there is no equivalent issuer-level mechanism.
Once stolen XRP moves into attacker-controlled self-custody addresses, recovery therefore depends more heavily on tracing the funds to entities capable of acting before the trail reaches a dead end.
Ripple does not currently have a protocol-level function that allows it to freeze XRP in someone’s account.
This misconception partly comes from the close historical relationship between Ripple and the XRP ecosystem.
But Ripple and XRP are not the same thing.
The XRP Ledger was developed in 2011–2012, and 100 billion XRP existed at its creation. XRP Ledger documentation states that no more than the original 100 billion XRP can be created.
Ripple received a large allocation of XRP from the ledger’s founders, but owning XRP does not give Ripple administrative control over other XRP balances.
Ripple therefore cannot use its XRP holdings to freeze XRP belonging to another address.
Under the current protocol, validators do not have a transaction or administrative command that allows them to select an XRP account and freeze its native XRP balance.
Validators have a different role.
They participate in the consensus process used to agree on the state of the XRP Ledger.
This means validators help determine which valid transactions become part of a validated ledger. It does not give an individual validator ownership or administrative authority over users’ XRP.
There is an important governance nuance, however.
The XRP Ledger protocol can evolve through amendments. For a protocol amendment to become enabled, it must maintain more than 80% support from trusted validators for two weeks.
So the precise statement is:
The current XRP Ledger protocol contains no mechanism for validators, Ripple or another administrator to selectively freeze native XRP balances.
That is more accurate than claiming the protocol could never change under any circumstances.
A government cannot currently send an instruction to the XRP Ledger that directly freezes native XRP in a self-custody address.
But governments can still affect access to XRP through regulated intermediaries.
Suppose law enforcement traces stolen XRP to an account at a centralized exchange.
The exchange controls the private keys for XRP in its custody and maintains its own internal customer-account system.
If legally required, the exchange may restrict withdrawals, suspend the account or otherwise prevent the customer from accessing those custodial assets.
This does not mean the XRP itself has been frozen by XRPL.
It means the custodian controlling the XRP has restricted the customer.
This distinction is especially important when discussing sanctions, stolen assets and law-enforcement actions.
A validated XRP transaction cannot simply be reversed by Ripple, an exchange or a support team.
However, there is an important technical distinction between a submitted transaction and a validated transaction.
When an XRP transaction is first submitted, its result can still be provisional.
The network must reach consensus and include it in a validated ledger.
Once a successful transaction is included in a validated ledger, its outcome is final and the resulting ledger state is immutable.
XRPL documentation indicates that transactions are typically validated within several seconds, although network conditions can affect timing.
This means users should wait for validation before treating an XRP transaction as final.
After validation, sending XRP to the wrong address cannot simply be undone through a chargeback or blockchain administrator.
No additional XRP can be minted under the current XRP Ledger rules.
At the XRP Ledger’s creation, 100 billion XRP existed.
Unlike Bitcoin, XRP does not rely on mining to issue new units over time. It also does not use staking rewards to create new XRP.
The protocol contains an invariant specifically designed to prevent transactions from creating XRP.
In fact, XRP supply gradually moves in the opposite direction.
Every ordinary XRPL transaction specifies a small transaction cost paid in XRP. That XRP is not awarded to validators.
It is destroyed. As a result, the total XRP supply can decrease over time but cannot exceed the original 100 billion under the current protocol rules.
This supply mechanism is separate from freezing, but it reinforces the underlying architectural point: native XRP is governed by the ledger’s protocol rules rather than an issuer capable of minting, freezing or clawing back balances.
XRP’s inability to be frozen does not mean stolen XRP becomes invisible. On the contrary, XRPL transactions are recorded on a public ledger.
Investigators can follow transfers between addresses and potentially identify when stolen funds reach a centralized exchange or another service.
That creates an important distinction between tracking and freezing.
Tracking tells investigators, and blockchain analysis or a detailed report can help show where stolen XRP moved, but freezing still requires separate authority over the asset or account:
Where did the XRP go?
Freezing requires someone with authority over the asset or account to act:
Can anyone prevent it from moving further?
Native XRPL self-custody provides the first capability through public ledger data but does not provide an issuer with the second.
If stolen XRP reaches a cooperating centralized exchange, however, the situation changes. The exchange may be able to restrict the custodial account receiving the funds.
This is why exchanges and blockchain investigators can still play an important role in recovering stolen cryptocurrency even when the native blockchain has no freeze function, especially because people may act on false assumptions about whether XRP can be frozen during fast-moving theft investigations.
The broader lesson extends beyond XRP. Calling an asset “on-chain” does not tell you who ultimately controls it. Broad coverage of freeze mechanisms across blockchain systems often shapes user trust and perceptions of control.
Two assets can move across the same blockchain while having very different control models. One may be a native cryptocurrency governed primarily by protocol rules. Another may be an issued token whose issuer retains freeze or clawback powers. A third may represent an asset held through a centralized custodian that can restrict the user’s account. A gap can emerge when users assume all on-chain assets share the same protections or restrictions, even though control may sit at different layers.
For investors and traders, understanding those differences is part of evaluating counterparty risk and custody risk.
The useful distinction is therefore not simply whether a cryptocurrency is centralized or decentralized.
It is more specific— who can control the asset, what powers do they have, and at which layer does that control exist?
Native XRP cannot currently be frozen on the XRP Ledger because XRP has no issuer and the protocol provides no issuer-level freeze or clawback function for it.
That does not mean nothing on XRPL can be frozen.
Trust-line tokens can support issuer freeze functionality, and newer Multi-Purpose Tokens can include issuer controls such as locking and optional clawback. Centralized exchanges can also restrict access to XRP held in their custody.
The September 2026 Bitget breach demonstrates why the distinction matters. Stolen XRP could be identified and traced, but there was no XRP issuer capable of blacklisting the attacker’s self-custody balance. Related centralized stablecoins, by contrast, could be frozen by their issuers.
For Gate users, the practical lesson is to distinguish between native XRP, issued assets and custodial balances before making assumptions about who can stop, recover or restrict funds.
Not under the current protocol. Validators participate in consensus but do not have an administrative command that allows them to selectively freeze an account’s native XRP.
An exchange can restrict access to XRP it controls in custody. That is an exchange-level account restriction, not an on-chain XRP freeze.
Potentially, but not through a native XRP freeze function. Investigators can trace stolen XRP on the public ledger, but it cannot be directly stopped through any native freeze mechanism on the ledger itself, while centralized services receiving stolen funds may be able to restrict associated accounts. Recovery depends on where the funds move and whether entities with custody or legal authority can intervene.
A successfully executed transaction becomes final once it is included in a validated XRP Ledger. There is no protocol-level chargeback function that allows Ripple or an exchange to reverse that validated XRP payment.
* The information is not intended to be and does not constitute financial advice or any other recommendation of any sort offered or endorsed by Gate.
* This article may not be reproduced, transmitted or copied without referencing Gate. Contravention is an infringement of Copyright Act and may be subject to legal action.
