Compliance posture
Who this is for: institutions, issuers, and their legal and compliance teams assessing how Lumia's architecture separates a permissionless base layer from a permissioned application layer that an issuer configures per asset. This page describes architecture only.
What is architectural, and can be described
Lumia separates two layers:
A permissionless base layer. The chain itself does not gate who can transact, deploy a contract, or hold a token. That is a property of the chain, not a compliance guarantee.
A permissioned application layer, chosen per asset. An issuer's own contracts enforce whatever compliance gate that asset needs. This is where a KYC, KYB, transaction-screening, or vendor-standing check actually runs.
This split makes a compliant configuration implementable per asset, chosen by the issuer. It is not, by itself, a statement that any given asset or issuer configuration meets a specific legal requirement. The full model and taxonomy (KYC, KYB, KYT, KYV) are documented at /lumia/compliance/compliance-model and /lumia/compliance/permissionless-base-permissioned-app-layer. Read those pages directly rather than relying on a summary here.
Independent security review
Two independent security firms are engaged around Lumia: Hacken and Halborn. Their engagements are Solidity smart-contract reviews covering the token, staking, governance and migration contracts. Scope and reports for each are at /lumia/chain-security/audits. Review them directly before citing either name to a counterparty.
Talk to counsel, not just docs
Nothing on this page is legal advice, and it is not a substitute for your own counsel's review of your specific structure and jurisdiction. To start a conversation about your specific requirements: /institutions/talk-to-us.
Last updated
Was this helpful?