Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Stage 1 Issue

Who this is for: issuers at the start of the asset lifecycle, deciding what their on-chain token needs to represent before anything is deployed. This is concept content. It describes what issuing generally requires.

What issuing means

Issuing is the point where an off-chain asset (a loan, a property, a commodity position, a fund interest) gets a corresponding on-chain token. That token is only useful if it correctly encodes three things the issuer has to decide up front:

  • The legal wrapper. What entity or structure actually holds the underlying asset, and what legal claim does the token represent against it? This is a legal-structuring decision, not a contract-code decision. See Compliance overview for issuers for the questions to raise with counsel before minting anything.

  • The token standard. Fungible assets (fund shares, a pool of receivables) are typically represented as ERC-20; unique or serialized assets (a single property, a specific note) as ERC-721 or ERC-1155. See Token standards for RWA for the tradeoffs.

  • The transfer restriction. Most RWA tokens are not freely transferable like a generic ERC-20. A transfer() call typically checks an identity or eligibility registry first. See Compliance model overview for how that check fits Lumia's permissionless-base/permissioned-app split.

What Lumia provides today

Lumia's zkEVM execution environment runs standard EVM contracts, so standard deployment tooling applies. See Quickstart: your first contract on Lumia for deploying with Hardhat or Truffle. The on-chain KYC verifier pattern is documented at Integrate on-chain KYC (dev guide) and can be called from a transfer-restriction hook.

Treat issuance as deploying your own EVM contract using standard tooling, rather than using a dedicated Lumia tokenization product.

What the issuer brings

  • The legal/offering structure and the initial compliance ruleset (who can hold this, under what conditions).

  • The token contract itself, including its transfer-restriction logic.

  • Minting mechanics: supply, mint authority, and whether minting is one-time or ongoing.

Last updated

Was this helpful?