ipsa.

IBC v2 · Stellar

Stellar, as an IBC chain.

ipsa is the IBC v2 implementation for Stellar: light clients, packet routing and proofs. Developers build cross-chain applications on top of it. Other chains connect to Stellar through it, and each side verifies the other's consensus itself, with nothing trusted in between.

Open the explorer Read the design docs

What a chain reaches by connecting

$820MUSDC held on Stellar
$2B+Tokenized real-world assets
$5.5BStablecoin volume, Q1 2026
5sSettlement, fractions of a cent

Figures dated July 2026, from DeFiLlama, Map of Zones and the Stellar Development Foundation's Q1 2026 report. Methodology and caveats are in the value documentation.

What it is

One layer, and two ways in.

ipsa is not an application. It is the layer applications sit on: the light clients that let two chains check each other, the packet machinery that carries messages between them, and the proofs that make a message provable rather than merely delivered.

For developers

A packet layer to build on

Send a packet from a Soroban contract and have it verified and acted on elsewhere, or the reverse. Ports live in the packet payload, so one client pairing already carries every application you write on it, and you inherit the verification rather than re-implementing it.

For chains

A light client that speaks Stellar

The Stellar light client compiles to wasm and runs on your chain as an 08-wasm client. It verifies SCP directly, so what your chain ends up depending on is Stellar's own validators, not ipsa and not anyone operating it.

APPLICATIONS token transfer interchain accounts cross-chain queries whatever you write PACKET LAYER commitments, routing and proofs LIGHT CLIENTS each chain verifies the other's consensus Stellar Counterparty chain
The trust work happens once, in the blue band. Everything above it is ordinary application code, and adding a new application does not change what anyone has to trust.

How it verifies

Stellar consensus, checked on-chain, eight ways.

The light client takes SCP externalize messages and establishes, without trusting whoever delivered them, that a quorum of the validators you already trust agreed on this exact ledger. Everything above it in the stack rests on this one result.

  1. 1envelope signatures
  2. 2statement validation
  3. 3quorum-set authentication
  4. 4quorum check
  5. 5value agreement
  6. 6ledger binding
  7. 7next-slot binding
  8. 8result-set binding

Fourteen ways to break it

The verifier ships a catalogue of tampering cases, from tampered-signature to foreign-trust-root. Each one names the step that must reject it, and the explorer runs them against live ledgers so you can watch the check fail on demand.

Proofs over a Sparse Merkle Tree

Packet commitments, receipts and acknowledgements live in a deterministic fixed-depth-64 tree, byte-exact against the reference implementation, whose root is recomputed on-chain on every provable write.

Verify it yourself

Point the explorer at any mainnet or testnet ledger and it fetches the consensus messages from the public history archives and re-runs all eight checks in front of you.

What you can build

One client pairing. Any number of applications.

IBC v2 carries the source and destination ports inside the packet payload, so one client pairing already carries packets for applications nobody has written yet. Nothing about the trust model changes when a second one appears: it rides the verification that is already there.

ICS-20 · running

Regional currencies, and somewhere to hedge them

Stellar is the only chain carrying tokenized non-USD currency at any meaningful scale: naira, reais, pesos, shillings, issued by regional anchors and used for payments. A currency nobody can hedge is a currency market makers quote badly or refuse. The IBC graph has the spot depth and the derivatives venues where that inventory risk gets offset. Neither side can build that market alone.

ICS-27 · next

Control a Stellar account from another chain

Interchain accounts let a contract or account elsewhere hold and move Stellar-native assets directly, so a strategy running on another chain can operate on Stellar as a first-class participant.

ICS-31 · next

Read another chain's verified state

Cross-chain queries let a Soroban contract price or settle against facts it never observed locally, checked the same way as everything else rather than reported by an oracle you have to trust.

Packet layer · next

Make Soroban a callable destination

The packet layer runs both ways. An application on another chain can trigger Soroban execution and receive the acknowledgement, which makes Stellar somewhere logic runs, not only somewhere assets come from.

What already works

Running end to end on a devnet, against a real IBC v2 host chain.

Tracked against the Interchain Standards the stack implements, rather than against a feature list.

ICS-26Routing. The Soroban router dispatches send, recv, ack and timeout, with IBC v2 counterparty registration on both sides and no v1 handshake.
ICS-24Host requirements. Commitment, receipt and acknowledgement paths in the Sparse Merkle Tree, with the root published on-chain.
ICS-02Client semantics. Both light clients implemented on-chain: an inbound client on the Stellar router, and the Stellar client uploaded to the host chain.
ICS-23Vector commitments. Membership proofs for recv and ack, non-membership for timeout.
ICS-04Packet flow. Demonstrated end to end, together with ICS-20 token transfer.
Stage 1 · devnet Stage 2 · testnet Stage 3 · mainnet