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.
Lukso is an EVM Layer-1 whose flagship feature, Universal Profiles, is built on a family of Lukso Standard Proposals (LSP) 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 an upgrade for the existing system: pay once, store forever, with on-chain proof of storage and protocol-level redundancy across the Supernode network.
Lukso is not IBC-enabled and there is no token bridge. The integration is metadata and storage only.
Why this fits
| IPFS pinning (Pinata / Infura) | Cascade | |
|---|---|---|
| Persistence | Pin-dependent; lapsed pin = lost data | Permanent, enforced by protocol |
| Pricing | Recurring per-month bills | Pay once on-chain |
| Redundancy | None by default | RaptorQ erasure coding across Supernodes |
| Self-healing | No | Yes, automatic chunk restoration |
| Reader compatibility | Standard IPFS gateways | Standard HTTPS gateways (cascade api) |
Cascade is a drop-in upgrade. No reader-side changes, no new wallets, no new schemas.
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:
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 L1 | On 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.
Three options for production:
-
Use the public Lumera-operated gateway (
api.lumera.help). The gateway is operator-funded and ready for integrations. -
Self-host a cascade api on a custom domain. The on-chain URL references the self-hosted instance rather than the public gateway.
-
Use a multi-gateway URL resolver. The resolver queries cascade api gateways in order. If one gateway returns an error, it moves to the next. The
cascade://URL scheme builds that fallback into the resolver, removing the need for client-side retry code.