DEV Community: Shawn Xie

Introducing Batch Transactions on the XRP Ledger: More Opportunities, Less Friction

Shawn Xie — Fri, 27 Jun 2025 15:43:58 +0000

XRPL has always been known for being fast, reliable, and cheap to use. The proposed batch transactions feature will make it even easier for developers to build apps that can generate revenue directly onchain.

This long sought after amendment from the broader community, makes it much easier to offer paid features, automate flows, and build apps that generate revenue. It’s a big step forward for anyone building on XRPL and a sign that the ecosystem is evolving and getting ready to support the next wave of serious financial apps. With the batch transactions amendment, developers can now bundle multiple actions into a single onchain transaction.

That’s the goal of XLS-56d: Batch Transactions, created by Denis Angell, a powerful new feature now proposed as an amendment on the XRP Ledger.

Atomic Execution Made Simple

Batch Transactions let you bundle up to eight individual transactions into one atomic package. This means they can be submitted together and executed according to your chosen logic. This ensures more predictable and reliable results. You decide whether every transaction must succeed, only one, or some combination. It’s a significant leap in programmability, without needing smart contracts.

Think of it as putting multiple steps of a process into a sealed container: either the whole thing goes through exactly how you planned, or none of it does.

Why This Matters for XRPL Developers

Batch transactions remove a major blocker for developers: the need to send multiple transactions in a specific order and hope everything goes smoothly. Before, if one step failed, the whole flow could break, hurting the user experience and making it harder to build reliable, revenue-generating apps.

Now, you can group multiple actions into a single, atomic transaction that makes your app logic cleaner, safer, and easier to monetize. Here’s what this unlocks:

Safer UX: No partial mints, broken offers, or misfired transfers.
Cleaner code: Group transactions logically and sign them once.
New design patterns: Enable conditional actions, fallback logic, and multi-party coordination natively on XRPL.
New Monetization paths: Offer premium features, usage-based billing, or transaction-based services

Whether you’re building a RWA Tokenization service, Payment app or DeFi platform or automated treasury system, this opens up new possibilities.

Under the Hood: Batch Modes and Transaction Anatomy

A batch consists of an outer transaction (the container) and multiple inner transactions (the steps). You can include up to 8 inner transactions per batch, and each must be explicitly flagged as such.

Crucially, each batch must declare a batch mode and determine how the inner transactions are processed:

ALLORNOTHING: Every transaction must succeed, or none are applied.
ONLYONE: The first transaction that succeeds is applied; the rest are ignored.
UNTILFAILURE: Transactions are applied in order until one fails.
INDEPENDENT: All transactions are processed regardless of individual success.

All inner transactions must be unsigned and have zero fees. The outer transaction carries the signatures and total fee, calculated as:

2 x b a s e f e e + s u m o f i n n e r f e e s + b a s e f e e p e r e x t r a s i g n a t u r e

This design ensures deterministic behavior, secure coordination between accounts, and compatibility with XRPL’s existing multi-sign infrastructure. Each inner transaction is stored on-ledger with its own metadata, making it easy for existing tools and systems to track outcomes.

Utilizing Batch Transactions to Build and Monetize Today

Batch Transactions enable immediate utility across many sectors. A few real-world examples:

Platform Fees: Bake platform fees into user transactions for simpler UX
DEX Swaps: Submit multiple offers with varying slippage levels—whichever one succeeds first wins
Trustless Multi-Account Swaps: Alice and Bob can atomically trade XRP and USD between their accounts without trusting each other or relying on a third-party escrow
Fallback Withdrawals: Try withdrawing from Account A, and if that fails, fallback to Account B with no manual resubmissions needed
NFT Mint + Offer: Mint and list an NFT in one atomic step. If the offer creation fails, the mint is rolled back too

Developers can already start experimenting with test cases like these on devnets and prepare for what’s possible post-activation.

A Step Toward Smarter, More Scalable and Monetizable Applications

This amendment doesn’t just offer convenience - it unlocks a new layer of flexibility and power for developers on XRPL.

By enabling complex, multi-transaction logic within a single submission, Batch Transactions helps build advanced, revenue-generating workflows that were previously awkward, error-prone, or outright impossible. Batch is a foundational feature that improves how decentralized systems behave.

And while it opens up these new possibilities, the amendment stays true to what XRPL does best: fast, low-cost, and reliable performance. Inner transactions are recorded individually onchain, maintaining clarity and traceability. Fee escalation and signature verification remain efficient and secure.

The result? A smarter, more scalable XRPL that is ready to support serious builders who want to ship polished products and generate real value onchain.

How to Support the Amendment

The Batch Transactions feature is currently live as a proposed amendment. That means it’s undergoing validator voting and needs broad consensus to activate on mainnet.

If you’re running a validator or are part of a network participant group:

Enable voting for the Batch amendment.
Stay up to date on vote status via XRPL amendment registry
Join discussions in the XRPL Discord or GitHub to collaborate with others building on Batch.

Batch Transactions are more than just a technical upgrade, they’re a shift in what developers can imagine and execute on the XRP Ledger. If you’ve been waiting for native atomicity and multi-step logic, your moment is here.

Deep Freeze: Strengthening Institutional Asset Control on XRPL

Shawn Xie — Thu, 06 Mar 2025 15:25:49 +0000

As blockchain adoption expands into institutional finance, ensuring secure, compliant, and controlled tokenized asset management is essential. To meet these needs, the Deep Freeze amendment (XLS-77d) has been proposed for the XRP Ledger (XRPL), providing issuers with a more robust tool to freeze assets at the account level while maintaining decentralization and transparency.

This blog explores how Deep Freeze enhances XRPL’s existing freeze functionality, why it’s a critical feature for institutional token issuers, and how validators can participate in the voting process.

What Is Deep Freeze?

Deep Freeze is an enhanced asset-freezing mechanism that enables token issuers to freeze all issued assets in a specific account at the protocol level. Unlike the existing trustline freeze, which only prevents further transactions, Deep Freeze restricts all outgoing transactions and prevents account holders from transferring assets entirely—offering a stronger level of control for compliance-driven use cases.

XRP Disclaimer

It’s important to note that Deep Freeze does not apply to XRP—the XRP Ledger’s native digital asset. Deep Freeze is designed exclusively for issued tokens and does not impact XRP balances or transactions in any way.

Why Is Deep Freeze Necessary?

Currently, issuers can freeze individual trustlines, preventing new transactions involving their issued assets. However, this has several limitations:

Trustline Freeze is limited to individual assets – An issuer must freeze each asset on a per-user basis, making enforcement inefficient for large-scale compliance scenarios.
Users can still transfer their remaining balances – While frozen trustlines prevent additional transactions, users can still hold and transfer already issued assets to others.
Does not address high-risk compliance scenarios – Institutional issuers require a stronger freeze mechanism for situations involving sanctioned entities, fraud mitigation, or legal compliance.

Why This Matters for Institutional Issuers

For institutions leveraging XRPL to issue tokenized real-world assets (RWAs), stablecoins, or financial instruments, Deep Freeze ensures they can respond to regulatory requirements, security threats, or fraud cases similar to many other blockchains. It provides a compliance-friendly safeguard for central banks, payment providers, asset managers, and regulated financial institutions issuing assets on-chain.

Stablecoin issuers in particular are drawn to XRPL’s robust compliance features. Many stablecoins have launched on XRPL or are in the process of doing so, including those issued by Ripple (RLUSD), Societe Generale Forge (EURCV) and Braza Bank (BBRL). It would further benefit XRPL to attract major regulated stablecoin issuers such as Circle. Stablecoin issuers rely on being able to freeze send and receive functions to sanctioned addresses, in order to remain compliant and attractive to institutional users. DeepFreeze provides this ability, making it essential for institutional issuers on XRPL.

Use Cases for Deep Freeze

Regulatory Compliance & Enforcement: Deep Freeze enables institutions to align with evolving regulatory frameworks by preventing asset transfers when required. If a regulator mandates a suspension of a specific account’s assets, issuers can enforce this with on-ledger transparency while ensuring compliance.
Fraud & Security Risk Mitigation: If an account is compromised or associated with fraudulent activity, issuers can quickly restrict asset movement, preventing unauthorized transactions and safeguarding the integrity of their tokenized assets.
Sanctions & Blacklisted Accounts: Governments and compliance bodies blacklist entities due to illicit activity, necessitating preventive measures for financial institutions. Deep Freeze allows swift action to block specific accounts from transferring issued tokens while maintaining full on-chain traceability.
Institutional Tokenization: Many financial institutions exploring tokenized deposits require built-in asset control mechanisms. Deep Freeze ensures central banks or authorized issuers can pause token transfers if necessary, helping bridge regulatory trust between blockchain technology and traditional finance.

How to Vote for the Deep Freeze Amendment

To support the adoption of Deep Freeze on the XRPL, you can participate in the amendment voting process!

Refer to the Amendments Guide for a step-by-step overview of how to vote.

New to XRPL? This guide also explains how the amendment process works and how you can contribute to the network’s evolution.

Multi-Purpose Tokens (MPT): Chronology and How to Test on Devnet

Shawn Xie — Mon, 27 Jan 2025 21:04:38 +0000

The Multi-Purpose Token (MPT) is a forthcoming token standard designed to offer a new level of flexibility and functionality to the XRP Ledger. MPT will serve as a ‘best of both worlds’ token standard between fungible and non-fungible tokens, facilitating new or enhanced use cases such as tokenization of real world assets, compliance controls, and developer accessibility.

MPTs will combine straightforward fungibility with the flexibility to store metadata, enforce supply controls without blackholing an account, authorize specific account holders, and more. This addresses limitations in existing token formats by eliminating floating-point math and reducing on-ledger storage requirements, and enabling simpler token flows that can represent everything from stablecoins to complex financial assets with precision.

By seamlessly integrating on-chain metadata and offering a lower storage footprint, MPT aims to enhance token utility without sacrificing XRPL’s performance. This makes it a good option for issuers that require efficient tokenization, while node operators can reduce their long-term infrastructure and storage burdens, resulting in increased network resiliency and improving node performance when processing large volumes of MPT transactions.

Chronology of the MPT Standard

The MPT spec was first introduced to the community in 2022 as a solution to support common tokenization requirements and reduce the storage space required by trustlines. Following extensive review and community feedback, the spec was iterated upon.

The original design and implementation included an owner directory to store all MPTokens associated with the same MPTokenIssuance. This was intended to support the mpt_holders RPC in rippled. However, the owner directory was later removed because it was not utilized by transactions. Its removal reduced storage requirements. The responsibility for supporting mpt_holders has since been delegated to Clio, which serves the same purpose.
Originally, Multi-Purpose Tokens on XRPL were designed to reuse the NFTokenPage structure to enable more compact object storage. However, this approach presented several disadvantages:
- Excessive metadata overhead: The NFTokenPage structure generated a large amount of metadata for each transaction, significantly increasing costs and storage requirements for full-history nodes that store the complete ledger history. Additionally, this would cause a notable performance impact when used in the Decentralized Exchange (DEX), where each payment transaction might involve multiple MPTokens. The resulting metadata would severely impact the overall efficiency of the network.
- Poor developer experience: Learning from experiences with NFTs, developers had a subpar experience working with NFT APIs and understanding how the functionality worked. For instance, calculating the reserve requirements for a given number of NFTs was nearly impossible for users. NFTokenPage also introduced unnecessary complexity, as its full functionality had to be supported by Clio, making it exceptionally difficult to use. So we decided to not use the NFTokenPage structure to provide user-friendly APIs and simple, easy-to-understand mechanisms.
MPT is uniquely identified by its MPTokenIssuanceID because because it combines the issuer and issuance sequence, preventing re-creation of the same MPT after deletion and ensuring uniqueness for token holders. Full explanation.
The reason why MPT amount supports range 0 - 2^63-1:
- MPT amounts in ledger objects are generally stored as unsigned 64-bit integers (0 to 2^64 - 1). However, when MPT amounts appear in transactions requiring an STAmount, they are restricted to 0 to 2^63 - 1. This same limit applies to balance tracking in MPTokenIssuance and MPToken. The restriction is due to limitations of the internal Number class, which currently cannot handle values beyond 2^63 - 307 without losing precision or overflowing. Full explanation.

After implementing these design changes, the MPT standard was released on a devnet. Approaching its merge to the rippled codebase, in October 2024, Softstack GmbH completed a security audit. Shortly thereafter, the MPT standard was included as an amendment in the XRPL version 2.3.0 release in November.

More recently in 2025, the RippleX team has completed performance testing of the MPT standard, finding that XRPL remains performant. Additionally, the team has published an MPT metadata schema, that explains our recommended metadata format for the XRPL and includes examples using tokenized RWAs.

MPT Use Cases

1. Real World Asset Tokenization

MPT enables seamless tokenization of real-world assets with enhanced precision and flexibility, making it ideal for:

Bond Issuance: Store terms such as face value, coupon rate, and maturity dates directly on-chain for transparency and efficiency.
Fractional Ownership: Facilitate the trade of fractional investment assets with accurate decimal support and visible on-chain details.
Bulk and Decimal Trading: Support large-scale or fractional trading with precision, ensuring smooth and reliable transactions.

2. Compliance Controls

MPT introduces robust compliance mechanisms to align token operations with regulatory requirements:

Freezing & Clawback: Issuers can freeze or recover tokens in scenarios like lost wallet recovery or fraud mitigation.
Authorization & Non-Transferability: Tokens can be restricted to specific wallets or made non-transferable, ensuring compliance with targeted use cases and regulatory needs.

3. Developer Accessibility

MPT simplifies the developer experience with intuitive tools and features:

On-Chain Metadata & Pointers: Developers can store key asset details or reference off-ledger data directly on-chain using simple APIs, enhancing transparency and functionality.
Flexible Supply & Fees: Natively supported mechanisms allow developers to set maximum issuance limits or collect transfer fees, simplifying token management and monetization.

How to Test on Devnet

Testing MPT functionality is straightforward on Devnet. Here’s how to get started:

Visit the XRPL Faucet to obtain test XRP and access Devnet.
Utilize the latest client libraries that support MPT: xrpl-py, xrpl.js
Experiment with creating and managing MPT objects, testing scenarios like bulk trades, fractional ownership, or compliance features.

Go to the Devnet where you can test new object types in various scenarios. MPT is supported in the latest release of client libraries:

How to Vote for the MPT Amendment

To support the adoption of MPT on the XRPL, you can participate in the amendment voting process.

Refer to the Amendments Guide for a step-by-step overview of how to vote.
New to XRPL? This guide also explains how the amendment process works and how you can contribute to the network’s evolution.

With its flexibility, enhanced compliance controls, and ease of integration for developers, MPT represents the next evolution in token standards on the XRPL. Whether you’re looking to tokenize real-world assets, implement secure compliance measures, or innovate with new use cases, MPT provides the tools to unlock new opportunities across the ecosystem.

For more information and updates, visit the XRPL MPT Overview.

Enhancing Trust and Safety with the Clawback Feature on the XRP Ledger

Shawn Xie — Thu, 31 Aug 2023 19:57:02 +0000

In the ever-evolving landscape of digital assets and financial transactions, Trust and Safety remain paramount. To address these crucial concerns, the RippleX engineering team is excited to introduce the Clawback feature on the XRP Ledger, designed to empower issuers with enhanced trust and safety capabilities. Clawback will be proposed as an amendment, known as XLS-39.

Unveiling the Clawback Feature

At its core, the Clawback feature offers a solution for issuers seeking enhanced trust and safety while maintaining control over their issued assets. This feature allows issuers to ‘claw back’ funds from a trustline under specific circumstances, amplifying their ability to respond to challenges like lost account access or malicious activity.

The amendment offers the introduction of a lightweight feature, a novel account level flag (lsfAllowTrustlineClawback) which, if activated, allows the issuer the ability to modify a trustline object providing the ability to ‘claw back’ funds from a relevant account.

The Power of Clawback

The Clawback feature grants issuers the ability to reclaim their issued assets from token holders when faced with challenges that jeopardize safety and integrity. If an asset has been issued with the Clawback feature enabled, the issuer can initiate a Clawback transaction, effectively retrieving the tokens from the token holder. This capability extends to assets that are currently spendable by the holder, ensuring a balanced approach to asset recovery.

Addressing Trust and Safety Concerns

Trust and safety has never been more critical, especially in the blockchain industry and also in highly regulated industries such as with financial institutions. Issuers that choose to enable the Clawback feature gain a mechanism to increase trust and safety with requirements that might otherwise limit their ability to issue assets on the XRP Ledger.

Where the Clawback Feature can be Implemented

Here are a couple real-life scenarios in which Clawback features and capabilities can be effectively implemented.

Remedying Loss of Access: Imagine a scenario where a token holder is locked out of their account, a situation that often causes panic and frustration. Here, the Clawback feature comes to the rescue, placing control back into the hands of the issuer. With its activation, issuers gain the authority to seamlessly reassign tokens to an alternate wallet. This not only safeguards the rightful ownership of assets but also acts as a potent defense against potential losses, providing reassurance in times of vulnerability.
Combating Malicious Intent: Instances of fraud or malicious intent can wreak havoc on decentralized ecosystems. When an issued asset equipped with Clawback encounters fraudulent or malicious activity, issuers can swiftly and decisively take action. By reclaiming the funds from those responsible, issuers uphold the sanctity of their assets, reinforcing integrity and trust within the system.

Broader Impact

As we navigate the potential use cases, the Clawback feature emerges as a vital cog in the machinery of trust and safety enhancements. While not a solitary solution, it stands as an essential piece within a broader trust and safety strategy. Consider Clawback as one among many tools residing within the XRP Ledger’s arsenal, each designed to facilitate alignment with standards and expectations.

Clawback is an optional feature, intentionally disabled by default that can only be enabled for issued assets and never for XRP. By understanding that their assets won’t be clawed back arbitrarily, holders can engage in transactions with peace of mind. This conscious decision amplifies the spirit of collaboration and partnership that defines the XRP Ledger ecosystem.

A note about enabling the Clawback feature: Once the Clawback flag is set, it cannot be changed, no matter what. If this account level flag is disabled, the issuer cannot claw back from any trustline at all.

Lightweight Feature, Impactful Innovation

Compared to other on-ledger features like freezing, Clawback offers a lightweight, straightforward yet impactful approach that aligns with the XRP Ledger community’s commitment to innovation and safety.

The Clawback feature is open to any developer seeking enhanced control and trust and safety for their company and/or their issued assets. The community is invited to check out the documentation, review the code on Github and provide feedback or suggestions.

By enabling issuers to ‘claw back' funds from trustlines, this feature empowers them to navigate digital assets with confidence and safety.

Stay tuned for further updates and insights as we delve deeper into the capabilities and implications of the Clawback feature, and other tools to help the XRPL developer community thrive and succeed.

Legal disclaimer:
Ripple disclaims any responsibility to any user of the Clawback feature. Issuers should determine whether the Clawback feature is permitted in the applicable jurisdiction. Users should determine whether the Clawback feature is enabled.