Cascade

Lukso × Cascade

Use Lumera Cascade as the permanent storage layer for Lukso Universal Profiles, digital assets, and any LSP that references off-chain JSON metadata.

The integration in three sentences

Lukso is an EVM Layer-1 whose flagship feature, Universal Profiles, is built on a family of LSP standards that reference off-chain JSON metadata via on-chain hash-bound pointers (LSP-2 VerifiableURI). Today that metadata is almost always pinned to IPFS through Pinata or Infura, which means it lives only as long as someone keeps paying the pinning bill. Cascade is a strict upgrade for that exact slot: pay once, store forever, with on-chain proof of storage and protocol-level redundancy across the Supernode network.

There is no token bridge in scope here. Lukso is not IBC-enabled. The integration is metadata and storage only, which is also exactly where Cascade's value proposition is sharpest.

Why this fits

IPFS pinning (Pinata / Infura)Cascade
PersistencePin-dependent; lapsed pin = lost dataPermanent, enforced by protocol
PricingRecurring per-month billsPay once on-chain
RedundancyNone by defaultRaptorQ erasure coding across Supernodes
Self-healingNoYes, automatic chunk restoration
Reader compatibilityStandard IPFS gatewaysStandard HTTPS gateways (cascade-api)

The reader-compatibility row is the important one for a Lukso integration: Cascade is a drop-in upgrade. No reader-side changes, no new wallets, no new schemas. The only thing that changes is who is keeping the bytes alive in 2030.

How a Lukso reader sees it

A Universal Profile or LSP-8 NFT contract has an ERC725Y key/value store. One of those keys, e.g. LSP3Profile, holds an LSP-2 VerifiableURI:

0x0000 <method-id 4B> 0x0020 <keccak256 hash 32B> <URI bytes…>

The hash binds the URI's payload. Readers fetch the bytes from the URI, recompute the keccak256, compare against the on-chain commitment, and reject any mismatch. The URI scheme itself is opaque to the standard, so anything that returns the original bytes works: ipfs://, https://, data:, anything.

When the URI points at a cascade-api gateway URL, the reader has no idea Cascade exists. It sees a normal HTTPS URL that returns bytes whose hash matches the on-chain commitment, which is all it cares about.

What lives where

On Lukso L1On Cascade
LSP-3 Universal Profile pointer (~50 bytes)
LSP-3 JSON document
Profile / background / avatar images
LSP-7 / LSP-8 contract code + storage roots
LSP-4 collection metadata pointer
LSP-4 metadata JSON + asset images / 3D / video
Per-token LSP-8 metadata pointers
Per-token metadata JSON + media

The on-chain footprint stays tiny; the off-chain footprint, which is most of the data by weight, is where Cascade earns its keep.

Trust model

Cascade itself is permanent: the bytes survive forever. The URL embedded in the on-chain VerifiableURI points at whichever gateway you configure, so readers depend on that domain being reachable to retrieve the metadata. The hash binding guarantees the gateway can't tamper with the bytes, only deny service.

In production this means you should either:

  • Point at the public Lumera-operated cascade-api gateway, or
  • Run your own cascade-api behind a stable domain you control, or
  • Configure multiple readers with a Cascade-aware URL resolver that talks to the Supernode network directly.

For a deeper look, see the Permanence note on the data-provider page.

Where to next

If you have not used Lukso before, start with the primer. If you already know Universal Profiles and just want the working code, jump straight to the Universal Profile tutorial, which mirrors the open-source permanent-up-app reference implementation end-to-end.

Reference implementation

A working Next.js dApp that implements every flow on this section, from connecting a UP through multi-resolution image upload to writing the LSP-2 VerifiableURI on chain, lives at github.com/kaleababayneh/permanent-up. Every code sample on the following pages comes from that repo or from the published @lumera-protocol/data-provider-cascade package.

Edit this page

On this page