> For the complete documentation index, see [llms.txt](https://docs.lumia.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lumia.org/what-is-lumia-chain.md). # What is Lumia Chain Lumia is a blockchain purpose-built for real-world assets. It brings multiple assets including credit, real estate, commodities, and funds on-chain, and carries them through issuance, distribution, and the whole of their lifecycle rather than stopping at the mint. Lumia is a zkEVM, so it is bytecode-compatible with Ethereum smart contracts and its state is secured by zero-knowledge validity proofs rather than by its own independent validator set. That makes Lumia a general-purpose EVM chain any Solidity developer can deploy to, with the RWA tooling built in rather than bolted on afterwards. Alongside Lumia mainnet, a public testnet called Lumia Beam exists for development and testing before you ship to mainnet. Current chain IDs, RPC endpoints, and explorer URLs for both networks are kept current at[ `/reference/networks`.](/reference/networks-and-endpoints.md) ### How it works Lumia's execution model separates three concerns across three distinct roles: ordering transactions, proving they were executed correctly, and making the underlying data available. **Sequencer.** A sequencer receives submitted transactions, orders them, and builds them into L2 blocks, the same job a block producer performs on any chain. What differs from a traditional proof-of-stake L1 is that Lumia does not rely on a validator set voting on blocks to reach consensus; block production is a single, defined role rather than a distributed voting process. Correctness of the resulting state is established separately, by proving, not by a quorum of validators agreeing on it. The trade-off is that ordering and liveness depend on that one role staying up, which is the centralization cost this architecture family accepts in exchange for fast, predictable ordering. **zkProvers.** Once blocks are built, a prover generates a zero-knowledge validity proof: a cryptographic proof that the batch of transactions was executed correctly according to the EVM's rules, without needing to re-execute or trust that batch. That proof is verified by a smart contract on Ethereum L1. This is what makes an invalid state transition mathematically unproducible rather than merely socially discouraged: a prover cannot generate a valid proof for an incorrect execution. **Data availability.** For anyone to independently verify the chain's state, or for a user to reconstruct their balance if an operator disappeared, the underlying transaction data behind each batch has to actually be available somewhere, not just the proof that it was valid. Lumia's architecture describes Avail as the chain's data-availability layer, which makes it a validium: the data sits on a dedicated DA network rather than in Ethereum calldata. Together, these three roles let Lumia have its execution correctness verified on Ethereum without requiring every application on the chain to run its own validator set. Correctness is what the proof establishes; data availability is handled separately, as below. ### Compliance: permissionless base layer, permissioned app layer The property that most distinguishes Lumia from a generic blockchain is how it handles compliance for regulated, real-world assets. It's a deliberate split, not a single global policy. The base chain itself is permissionless: anyone can read chain state, submit a transaction, deploy a contract, or run a node, the same as on any public EVM chain. Lumia does not gate the protocol layer by identity. Compliance instead lives at the application layer, enforced by the contracts an issuer chooses to deploy. An issuer building a regulated asset selects what gate applies: KYC on individual holders, KYB on institutional counterparties, transaction-level screening, or some combination. Only that asset's contracts enforce it. A DeFi contract with no compliance requirement at all can sit on the same base layer, unaffected. This means the compliance decision is made per application, not imposed once on the whole chain. ### Security and audits Two independent security firms have reviewed Lumia contracts: Hacken and Halborn. These are Solidity smart-contract reviews of the token, staking, governance and migration contracts. The chain protocol layer (sequencer, zkProvers, data availability, bridge) is a separate scope these reviews do not cover. ### The token LUMIA is the network's native token. What it's used for, how it's distributed, and its role in the network are documented at [`/lumia/tokens/lumia`](/ecosystem/lumia/lumia-tokens/lumia.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lumia.org/what-is-lumia-chain.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.