Both XOXNO and Blend V2 are overcollateralized lending protocols running on Stellar’s Soroban. They solve the same core problem — letting users supply assets to earn interest and borrow against collateral — but organize liquidity, track positions, and manage risk differently.
The comparison below draws from the official XOXNO vs Blend docs page (https://xoxno.com/docs/stellar-lending/xoxno-vs-blend), Blend’s public documentation (https://docs.blend.capital/ and https://docs.blend.capital/users/general-faq), Blend whitepaper details on isolated pools + backstop, and the architecture and config files in rs-lending-xlm (hubs.json, spokes.json, blend.json, ADRs). Additional market data from rwa.xyz, cryptobriefing.com, stellar.org.
At a glance
| Area | XOXNO Stellar Lending | Blend V2 |
|---|---|---|
| Liquidity | One central pool, markets keyed by HubAssetKey | Separate immutable pool per deployment |
| Position tracking | Single lending account, balances grow in place | bTokens and dTokens per pool |
| Cross-asset | One account can supply and borrow across assets and hubs | Positions scoped to one pool |
| New listings | Governance-timelocked proposals | Permissionless pool creation |
| Insurance / bad debt | Index floor socialization in central pool | Per-pool backstop absorbs first, then socialized within pool |
| Liquidation | Health-factor based with per-spoke curve | Dutch auction per pool |
| Migration path | Atomic one-tx from approved Blend pools | Manual exit then re-deposit |
| Oracle model | Dual-source (Reflector + RedStone) with tolerance enforced at read time | Pool creator chooses oracle at deploy |
Liquidity model
XOXNO keeps one pool contract. All accounting rows live under HubAssetKey { hub_id, asset }. Core (hub 1) and RWA (hub 2) therefore never mix cash or debt even though they share the same contract. Spokes.json shows the same asset (USDC on hub 1) appearing with different caps in different spokes while still drawing from the shared pool liquidity.
Blend is permissionless isolated pools. Anyone can deploy a pool with chosen assets, oracle, and parameters. Positions and bad debt in one pool are independent of every other pool. This gives flexibility for niche use cases but fragments liquidity across many small pools.
Positions and tokens
On XOXNO your wallet owns a lending account (account id). Supplies and borrows are recorded directly against that account as scaled positions. Interest compounds into the balance every ledger. No receipt token is minted.
Blend issues ERC-20-like bTokens for supply and dTokens for debt per pool. These tokens represent your share and can be transferred or composed into other contracts. Non-collateral supply is also supported — you can lend without the same account posting collateral.
Risk and liquidations
XOXNO computes a single health factor across the account’s positions. LTV gates new borrows; liquidation threshold (higher than LTV) decides when liquidation is possible. Each spoke can carry its own liquidation curve (ADR 0012) so an RWA spoke and a volatile spoke can have different target health factors and bonus ramps.
Blend tracks borrow capacity per pool using collateral and liability factors. Liquidations use a Dutch auction driven by market dynamics rather than a fixed bonus. The per-pool backstop acts as first-loss capital before any socialization inside that pool.
Oracle handling also differs: XOXNO enforces dual-source tolerance and staleness at every price read used for risky actions. Blend lets each pool creator select its oracle at deployment time.
Governance and change
XOXNO uses on-chain governance with a timelock (roughly 48h on mainnet for many operations). Parameter, oracle, spoke, and upgrade changes are proposed and delayed. Pause is immediate for emergencies.
Blend pools are immutable after deployment (standard pools) or have limited owner controls (owned pools). No protocol-wide governance delays new pool creation; the backstop threshold and depositors act as the main curation mechanism.
Migration
XOXNO ships a migrate_from_blend entrypoint for pools listed in blend.json. One transaction repays your Blend debt, withdraws collateral, and opens the matching XOXNO position on the target hub/spoke. Rollback on any failure.
Moving the other direction requires manually withdrawing from XOXNO and depositing into the chosen Blend pool.
When each design fits
Choose XOXNO when you want:
- Deep shared liquidity for major assets (USDC, XLM) instead of choosing among many pools.
- Timelocked governance for visibility into risk changes.
- Simple account balances and cross-asset positions in one place.
- Atomic migration from approved Blend positions.
- Strategy flows (multiply, collateral/debt swaps) that compose across the shared pool and spokes.
Choose Blend when you want:
- An isolated pool tuned exactly for a community, asset set, or use case.
- Permissionless creation without waiting for protocol governance.
- Receipt tokens that plug into other DeFi primitives.
- The backstop module as explicit first-loss insurance funded by BLND/USDC deposits.
- Non-collateral supply on the same account.
Many users will use both. The protocols are complementary on the same chain.
Start with live markets
Both protocols support USDC and XLM today. On XOXNO those live in the Core hub:
- Go to the lending markets to supply or borrow.
- Use swap to enter the assets.
Read the hubs and spokes article for how XOXNO isolates liquidity while keeping one pool, and the features article for timelock, curves, and migration details. Always check live parameters and caps before moving size.
This comparison is for educational purposes. Protocol parameters, backstop depths, and market conditions change. Verify current state on each UI and in the on-chain configs.
