Cascade

Injective × Cascade

Use Lumera Cascade as the permanent storage layer for Injective dApps — claims, evidence, justifications, settlement records — over IBC + Interchain Accounts.

Injective is a CosmWasm-2.0 Layer-1 with a native orderbook module, sub-second finality, and full IBC connectivity. Most Injective apps store state on-chain and pin large auxiliary data — trade receipts, NFT metadata, governance attachments, oracle evidence — to IPFS or a centralised bucket. That auxiliary data lives only as long as someone keeps paying to host it.

Cascade is a permanent home for those bytes. Injective stays the venue for trading, state machines, and bonds; Cascade becomes the venue for everything those state machines reference but cannot afford to lose. The two chains coexist over IBC: contracts on Injective can drive Cascade through an Interchain Account, and end users can sign Lumera transactions directly from their Cosmos wallets.

Why this fits

IPFS pinning / centralised bucketCascade
PersistencePin-dependent; lapsed pin = lost dataPermanent, enforced by protocol
PricingRecurring per-month billPay once on-chain in ulume
RedundancyNone by defaultRaptorQ erasure coding across Supernodes
Self-healingNoYes, automatic chunk restoration
Cosmos nativeNoYes — IBC-addressable from any IBC chain
VerifiabilityHash-only at bestHash + on-chain action_id + chain receipt

Cascade does not replace anything on Injective. It augments contract state with permanent, content-addressed payloads that contracts can reference by action_id.

What lives where

On InjectiveOn Cascade
Order book + matching
Contract state, escrow, bonds
State machine transitions (Open → Final, etc.)
Trade receipts, attestations, large payloads
Claims, criteria, source allowlists
Evidence pools (per-market or per-app)
Oracle / settlement justifications
Canonical settlement records
Pointers (action_id) tying the two together

The Injective contract holds only the action_id (an integer) for each artifact. The bytes live on Cascade. The pairing is what makes the system both cheap to operate and permanent to read.

The flagship integration: Inscribe

Inscribe is a permanent, re-litigatable prediction-markets protocol that exercises this pattern at full depth. It runs on injective-888 today and stores every claim, every piece of evidence, and every voter's written justification on Cascade. Markets settle through a bonded human optimistic oracle whose entire reasoning trail survives the market.

Inscribe is the reference implementation we point developers at in this section: it shows the cross-chain wiring, the contract patterns, the off-chain services, and the wallet flows you need to build your own Injective × Cascade product.

ComponentWhat it does
inscribe-market-v2 (CosmWasm)Per-market state machine, bet escrow, evidence registry
bond-vault (CosmWasm)Bond custody for proposers, challengers, voters
voter-registry (CosmWasm)Bonded voter set + deterministic committee sampling
cw-ica-controller (live)The ICS-27 ICA controller that lets contracts/services act on Lumera
inscribe-api + inscribe-indexer (Go)Joined views over Injective + Cascade
Web app (Next.js, Keplr)Wallet-driven UX

Trust model

The Injective side is standard: CosmWasm contracts, native orderbook, BFT finality. No new assumptions.

The Cascade side adds one assumption: the Supernode network is honest in aggregate. RaptorQ erasure coding means a market's bytes survive significant node churn; sn-control + multiple gateways mean reads are not bottlenecked on a single domain. The hash binding on every artifact (action_id → content hash on chain) prevents tampering even by a hostile gateway — the worst it can do is deny service.

For the cross-chain bridge specifically, the trust assumption is the standard IBC one: a live relayer between injective-888 and lumera-testnet-2. The Inscribe deployment uses Hermes; the channel and the cw-ica-controller bridge have been live since before the contracts shipped.

Next steps

Edit this page

On this page