> 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/tokenize/the-asset-lifecycle/stage-1-issue.md).

# Stage 1 Issue

**Who this is for:** issuers at the start of the [asset lifecycle](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/tokenize/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](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/tokenize/legal/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](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/tokenize/standards/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](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/compliance/compliance-model-overview) for how that check fits Lumia's permissionless-base/permissioned-app split.

### What Lumia provides today

{% hint style="warning" %}
Lumia's zkEVM execution environment runs standard EVM contracts, so standard deployment tooling applies. See [Quickstart: your first contract on Lumia](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/build-on-lumia/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)](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/build-on-lumia/identity/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.
{% endhint %}

### 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.