Shipping Production Apps on XRPL

When people outside the XRPL ecosystem hear about the ledger, they usually think of one thing, which is fast and cheap payments. That picture is accurate as far as it goes, but it has gotten in the way of understanding what the ledger and its EVM sidechain can actually do for real products. We have been building on XRPL long enough to have taken things from experiment to production, and we want to share what that path actually looks like from the inside, because most of what gets written about the ledger is either marketing copy from above or technical documentation from below and there is not much in between.

Why the classic ledger is easier than people expect

The classic XRP Ledger is not a general computation platform in the way an EVM chain is, and a lot of developers assume that means it is limited to moving value from one address to another. That framing misses the point. Over the years the ledger has accumulated a set of native primitives that cover a surprising amount of what most applications actually want, including tokenized assets, trust lines, escrow, payment channels, on-ledger decentralized exchange functionality, and more recently the XLS series of native NFT operations. For a lot of products you can skip the custom smart contract step entirely, because the behavior you need is already a ledger transaction type and you just compose it.

That composition model has two consequences we have come to really appreciate. The first is that your critical path is never at the mercy of a contract bug you wrote yourself, which is no small thing in an environment where a single reentrancy mistake can empty a protocol in an afternoon. The second is that the behavior you rely on has been battle tested by the validators and the node operators for years and is documented with a rigor that newer chains have not had time to develop. When something strange happens in your logs you are reading material that has been used by hundreds of other teams before you, and that makes debugging feel less like archeology.

Where the EVM sidechain comes in

The trade-off with the classic ledger is that you cannot just drop in a Solidity contract and call it a day. Sometimes you genuinely need arbitrary computation or you need to port an existing EVM protocol without a full rewrite, and that is exactly what the XRPL EVM sidechain is for. The sidechain is a full EVM environment with XRP as the native gas token, it speaks the same JSON-RPC and Ethers that every EVM tool already knows, and it bridges to the classic ledger so you do not have to abandon the primitives you already built on the mainchain when you move complexity into a contract.

This is the combination that changed how we design on XRPL. For things that map cleanly onto native primitives, we stay on the classic ledger and get the reliability and cost profile we expect there. For anything that needs real logic, state machines, upgradeable administration, or integration with an existing DeFi or tooling ecosystem, we deploy to the sidechain and bridge what we need. The result is that most of our XRPL builds are not pure mainchain and not pure sidechain, they are a deliberate blend, and getting the split right is most of what our scoping calls end up being about.

A working example from our lab

The sharpest example we have is a blockchain game we built called DragonKill. It is an on-chain MMO that lives on the classic XRPL ledger, with player owned assets and a progression system built on the ledger's native primitives rather than custom contracts. Tradable in-game items are native tokens, because that is what the ledger is good at and because we wanted the items to behave the same way outside the game that they behave inside. The decision to stay on the mainchain rather than reach for the sidechain was deliberate, and it is the reason our cost profile and our reliability story are what they are, since every piece of critical behavior rides on validator-tested transaction types we did not have to write ourselves.

The minting pipeline is in beta as of this writing and that is not something we would hide from a prospective client, because the honest version of engineering on chain is that nothing is ever quite done, especially when new ledger features are rolling out and you want to adopt them. Items that are already minted work as expected, and the level-up system is very close to finished. The reason we mention this in public is that we think shipping on XRPL means being transparent about where you are in the lifecycle of a product, which is something a lot of teams get wrong by either pretending everything is perfect or hiding their work until it is.

Cross-chain token launches through Axelar Interchain Token Service

The other piece of our XRPL work that surprises people is how much of it involves other chains. We built an internal tool called Arcanie that deploys cross-chain ERC-20 tokens from a single command using the XRPL EVM sidechain as the home chain and Axelar Interchain Token Service for the bridge logic. The reason this exists is that a lot of founders want a token that is liquid on multiple networks without running a treasury of wrapped versions on every chain manually, and Axelar ITS lets us issue one canonical token and have it exist on every connected network as the same asset.

What makes XRPL EVM a good home chain for this pattern is the combination of low fees, fast finality, and a working Axelar gateway. Once the token is registered on the home chain, sending it to Base, Ethereum, or any other ITS-connected network is a single Axelar call on the user side, and the token that arrives on the destination is the same canonical asset. That is the kind of workflow we think is going to become ordinary over the next couple of years, and building on XRPL EVM put us early to it.

What we would tell a team starting out

If you are a founder or a technical lead sizing up XRPL for a project, the advice we keep giving is the same regardless of the specific use case. Start by mapping what your product actually needs onto the classic ledger's native primitives, because if what you need already exists as a transaction type you should not write a contract for it. Then pick up the EVM sidechain for the parts that genuinely need custom logic, and think about cross-chain from day one rather than bolting it on later, because the ecosystem is moving that way and the tooling rewards teams that plan for it. The ledger and its sidechain together are a lot more productive than either one on its own, and teams that treat them as a single platform instead of two separate options tend to ship faster and end up with cleaner architectures.

We are biased of course, since this is what we do for a living, but we have watched enough teams try to force every piece of their product into a single execution environment to know it is usually a mistake. Chains are tools, and XRPL is a particularly sharp tool for anything that looks like coordinated value movement, identity, real world assets, or cross-chain issuance, which covers more of what people actually want to build than the narrow payments framing suggests.