Overview

You already know how to move value on the XRP Ledger: fast, cheap payments, native tokens, an order book baked into the protocol. But the XRP Ledger doesn't run general-purpose smart contracts. It deliberately trades programmability for predictability — every transaction type is a known, audited primitive. So what happens when you want the developer experience of Ethereum — Solidity, ERC-20s, the whole tooling universe of Hardhat, Foundry, MetaMask, and OpenZeppelin — but you still want XRP and the XRPL community in the same neighborhood?

That's the gap the XRPL EVM fills. In this module you won't write much code. Instead you'll build an accurate mental model: what the EVM chain is, how it's wired to the XRP Ledger, how value crosses between them, and how to reason about which side of the bridge a given idea belongs on. Get this model right and the hands-on parts — deploying a contract, paying gas in XRP, bridging a token — become routine.

A quick note on names. People say "the XRPL EVM sidechain," but it's worth being precise: it is a standalone Layer 1 blockchain that supports Ethereum smart contracts, with XRP as its native gas token. "Sidechain" describes its relationship to the XRP Ledger — a sibling chain you can move value to and from — not a claim that it's secured by the mainnet. Keep that distinction in your pocket; it explains almost everything that follows.

Two chains, two jobs

Think of the XRP Ledger mainnet and the XRPL EVM as two specialists who share a workshop.

The XRP Ledger is the high-throughput settlement layer. It is fast, inexpensive, and intentionally limited: payments, trust lines, a native decentralized exchange, escrows, AMMs — a fixed menu of well-understood transaction types. There is no EVALUATE_ARBITRARY_CODE button, and that's a feature. The absence of a general virtual machine is exactly why the mainnet is so predictable and hard to attack at the application layer.

The XRPL EVM is the programmability layer. It runs the Ethereum Virtual Machine, so a contract written in Solidity behaves the way it would on Ethereum: you compile to EVM bytecode, deploy it, and call its functions. ERC-20 tokens, ERC-721 NFTs, lending markets, DEX routers, on-chain games — anything you can express as Ethereum bytecode runs here. Under the hood the chain is built on the Cosmos SDK and reaches finality through Cosmos-style consensus, but you mostly don't need to think about that: to your wallet and your tooling, it looks and feels like an EVM network.

The crucial shared detail: XRP is the native gas token on the EVM chain. On Ethereum you pay gas in ETH; here you pay gas in XRP. So XRP isn't a guest on this chain — it's the fuel. That single design choice is what makes the two chains feel like one ecosystem rather than two unrelated networks that happen to share a logo.

When should you reach for which? A rough heuristic: if your idea is fundamentally a payment, a transfer, or an order — moving value with minimal latency and cost — it belongs on the mainnet. If your idea needs custom logic, composability, or arbitrary state transitions — "when X happens, automatically do Y under conditions Z" — it belongs on the EVM chain. Many real applications do both: settle on the mainnet, compute on the EVM side.

How value crosses: the bridge

Two independent chains can't see each other's state. The mainnet has no idea your EVM contract exists, and the EVM chain can't read mainnet balances. So moving XRP between them is not a "send" — it's a bridge operation, and understanding the shape of it is the heart of this module.

The XRPL EVM uses Axelar as its interoperability layer — Axelar was the first crosschain connectivity provider to go live for the chain. Axelar is a decentralized network that specializes in passing verified messages and value between blockchains, connecting the XRPL EVM to 80+ other chains in the process. The pattern it uses is the standard bridge pattern, and it's worth internalizing because nearly every cross-chain system works this way:

Lock (or escrow) on the source chain. You send your XRP to a bridge-controlled account on the XRP Ledger. That XRP is now held; it has not been destroyed, but you no longer control it directly.
Attest the event. Axelar's validators observe the locked deposit and reach consensus that it really happened. This off-to-on-chain witnessing is the security-critical step — you are trusting the bridge's validator set to report honestly.
Mint (or release) on the destination chain. Once the deposit is attested, a corresponding amount of XRP is made available to you on the EVM chain, where it functions as native gas and value.

Crossing back reverses the flow: you burn or return the EVM-side balance, Axelar attests it, and the locked XRP is released back to you on the mainnet. The same machinery — Axelar's General Message Passing — can carry not just tokens but instructions, so a transaction on the mainnet side can trigger a contract call on the EVM side. User-facing tools like Squid wrap this whole dance into a single bridge UI, so an end user clicks once and the lock-attest-mint sequence happens underneath.

The word to be careful with is wrapped. Value that originated on one chain and now lives on another is a representation of the original, backed one-to-one by the locked amount on the source side. Because XRP is the native gas token on the EVM chain, the experience is smooth — you spend it like native currency — but the mental model stays the same: the EVM-side balance is only as sound as the bridge holding the real XRP on the mainnet. When you evaluate any bridge, the question is always "who or what guarantees the lock, and what happens if they misbehave?"

A worked mental walkthrough

Trace one token end to end — no code yet, just the journey, because if you can narrate this you understand the module.

You hold 50 XRP in a mainnet account. You want to use a lending contract that lives on the EVM chain.

You initiate a bridge transfer of, say, 20 XRP. Twenty XRP leaves your control and is locked by the bridge on the XRP Ledger.
Axelar's validators see and attest the deposit. After their consensus, 20 XRP becomes available to your address on the EVM chain.
Now you're a normal EVM user. You hold XRP as gas, you connect a wallet like MetaMask to the EVM chain's RPC endpoint, and you call the lending contract's deposit() function. The transaction costs a small amount of XRP in gas — paid in the same XRP you bridged.
Later you withdraw and bridge back. The EVM-side balance is burned/returned, Axelar attests, and the corresponding XRP unlocks on the mainnet into your account.

Notice what didn't happen: at no point did the mainnet "run" your contract, and at no point did the EVM chain reach into mainnet state. Each chain did its own job; the bridge was the only thing that touched both.

Deploying a contract, conceptually

Because the EVM chain is genuinely EVM-compatible, deploying to it is the ordinary Ethereum workflow with the network parameters swapped out. You write a contract in Solidity, compile it with Hardhat or Foundry, and deploy by pointing your tool at the XRPL EVM RPC endpoint instead of an Ethereum one. Your wallet needs the chain's network parameters — an RPC URL, the chain ID, and XRP as the gas currency. (The production EVM chain uses chain ID 1440000, with a corresponding Cosmos chain ID of xrplevm_1440000-1; there is a separate testnet/devnet you'll target for practice — always confirm the current values from the official docs before you configure a wallet, since endpoints evolve.)

The mechanics from there are pure Ethereum: gas is estimated, you sign with your key, the contract bytecode is stored on-chain at a deterministic address, and you interact with it through its ABI. The only XRPL-specific facts you carry into this familiar process are (1) you fund the deploying account with bridged XRP, and (2) gas is denominated in XRP. Everything else — events, require checks, view functions, OpenZeppelin imports — is the toolchain you may already know. That is the entire point of an EVM chain: it meets Solidity developers exactly where they are.

Where this leaves you

Hold two ideas at once. The XRP Ledger stays lean and predictable because it refuses to run arbitrary code. The XRPL EVM adds arbitrary code precisely because it's a separate chain, so that complexity never threatens mainnet settlement. The bridge — Axelar's lock-attest-mint flow — is the seam that lets XRP flow between the safe-and-simple world and the flexible-and-programmable one. If you can explain that seam, including its trust assumptions, you can reason about almost any cross-chain XRPL application you'll meet.

Check

You've got the model when you can, unprompted, explain three things in plain language: what the XRPL EVM is (a standalone EVM Layer 1 where XRP is the gas token, sibling to the XRP Ledger), how XRP crosses between the two chains (a bridge that locks on the source chain, has Axelar attest the event, and mints/releases on the destination chain — and reverses to go back), and which environment fits a given workload (payments/transfers/orders → mainnet; custom logic/composability → EVM). Capture it as a short written explainer or a diagram that follows one XRP token from a mainnet account, across the bridge, into a Solidity contract, and back. Submit that doc for your own review against these three points.

XRPL EVM Sidechain & Interop