Why Lumia

Who this is for: institutions and issuers deciding whether Lumia's chain architecture fits a real-world asset (RWA) program, before any technical or legal integration work starts.

The full lifecycle, on one chain

An RWA program touches more than issuance: assets get issued, their backing gets attested, they're distributed to eligible holders, serviced over their life, and eventually redeemed. Lumia's docs frame this as one lifecycle rather than disconnected tools. See /tokenize/overview for how each stage maps to what Lumia provides and what an issuer still has to bring.

The architectural split: permissionless base, permissioned app layer

Lumia's chain layer (execution, sequencing, data availability) does not gate who can transact; it is a general-purpose EVM chain like any other public L2. Compliance is enforced one layer up, by the contracts a given asset implements. That means an issuer chooses the exact gate their asset needs: a check on individual holders, a check on institutional counterparties, transaction-level screening, or a combination. That choice is not imposed on every other contract running on the same chain.

The split in one view: where the chain stops gating, and where an asset's own contracts start.

The diagram does not show which gate any specific asset uses, and it makes no statement about the regulatory treatment of any gate. Both are per-asset questions, not properties of the chain.

This split is documented in full at /lumia/compliance/permissionless-base-permissioned-app-layer, with the underlying taxonomy at /lumia/compliance/compliance-model. It describes chain architecture, not a jurisdictional or licensing position. See /institutions/compliance-posture for what is and isn't asserted about regulatory status.