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 Proposal (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.
In production this means you should either:
- Point at the public Lumera-operated cascade-api gateway, or
- Run your own cascade-api behind a domain you control, or
- Configure multiple readers with a Cascade-aware URL resolver that talks to the Supernode network directly.