# Equity tokenization
Source: https://docs.settlemint.com/docs/operators/runbooks/equity-tokenization
Set up actors, verify compliance, mint 100,000 ACME shares, and distribute tokens to issuer and exchange through the DALP console.
Follow this runbook to complete the ACME Holdings equity scenario in the Console. By the end, ACME Holdings holds 80,000 ACME equity tokens, NovaX Vault holds 20,000, and your setup has applied identity and collateral checks.
Stay on this page when you operate the scenario through DALP screens. Use the [API-led equity tokenization
walkthrough](/docs/developers/runbooks/equity-tokenization) when you need request-oriented steps for an integration,
script, or test.
## Prerequisites [#prerequisites]
Before starting this example, ensure your blockchain network has the core platform contracts deployed. The table below lists each required contract.
| Contract | Purpose | Deployed by |
| ------------------------- | ------------------------------------------------------------------------------ | ----------------- |
| **DALP Directory** | Registry and discovery service for all platform instances and their components | Platform deployer |
| **DALP Identity Factory** | Creates on-chain identity contracts for users | Platform deployer |
| **DALP System Factory** | Deploys organisation-specific system contracts | Platform deployer |
These contracts are typically deployed during initial platform setup by your implementation team. They provide the
foundation for all organizations to build upon.
Additional requirements include access to the platform web interface, email addresses for all demo participants, and ETH or native tokens for transaction gas fees on public chains.
Gas requirements vary by persona on public chains.
| Persona | Gas needed |
| ---------------- | ------------------------------------------------------------- |
| Daniel Admin | Moderate: system deployment and permission management |
| Clara Compliance | Small: user registration and verification issuance |
| Olivia Operator | Moderate: asset creation, permissions, minting, and transfers |
| Colin Collateral | Small: issuing collateral verifications |
| Invited users | Small: identity creation when using the invitation flow |
## Scenario overview [#scenario-overview]
This demonstration tokenizes 100,000 shares of ACME Holdings S.A., a Luxembourg company, using a multi-organisation platform operated by Digital Securities S.A.
### Organizations [#organizations]
| Organisation | Role | Domain | Jurisdiction |
| ------------------------------------ | ----------------------- | --------------------------- | ------------ |
| **Digital Securities S.A.** | Platform operator | digital-securities.example | Luxembourg |
| **ACME Holdings S.A.** | Issuer (equity owner) | acme-holdings.example | Luxembourg |
| **Guardian Collateral Services Ltd** | Collateral agent | guardian-collateral.example | (generic) |
| **Exchange Ltd** | Exchange/vault provider | exchange.example | (generic) |
### Key personas [#key-personas]
Platform Operators (Digital Securities S.A.)
| Persona | Name | Email | Purpose |
| ------------------ | ---------------- | --------------------------------------------------------------------------------------------- | ------------------------------ |
| Platform Admin | Daniel Admin | [admin@digital-securities.example](mailto:admin@digital-securities.example) | System setup and configuration |
| Asset Operator | Olivia Operator | [operator@digital-securities.example](mailto:operator@digital-securities.example) | Asset creation and management |
| Compliance Officer | Clara Compliance | [compliance-kyc@digital-securities.example](mailto:compliance-kyc@digital-securities.example) | KYC and regulatory compliance |
External Partners
| Organisation | Persona | Name | Email | Purpose |
| ---------------------------- | --------------------- | ---------------- | --------------------------------------------------------------------------------------------------- | ----------------------- |
| ACME Holdings S.A. | Issuer Representative | Ian Issuer | [issuer@acme-holdings.example](mailto:issuer@acme-holdings.example) | Legal equity owner |
| Guardian Collateral Services | Collateral Agent | Colin Collateral | [collateral-agent@guardian-collateral.example](mailto:collateral-agent@guardian-collateral.example) | Collateral verification |
| Exchange Ltd | Vault Provider | NovaX Vault | [vault@exchange.example](mailto:vault@exchange.example) | Token custody |
### ACME equity token specifications [#acme-equity-token-specifications]
Real-world instrument properties:
| Property | Value |
| ---------------------- | ------------------------------- |
| **Issuer** | ACME Holdings S.A. (Luxembourg) |
| **Security type** | Ordinary shares |
| **Total shares** | 100,000 |
| **Reference currency** | EUR |
| **Price per share** | €0.71 |
On-chain representation properties:
| Property | Value |
| ---------------------------------- | ---------------------------------------------- |
| **Token name** | ACME Holdings Equity |
| **Symbol** | ACME |
| **Decimals** | 0 (1 token = 1 share) |
| **Maximum supply** | 100,000 |
| **Asset class** | EQUITY |
| **ISIN** | LU0000ACME01 |
| **Final distribution after setup** | 80,000 held by issuer, 20,000 held by exchange |
## Implementation steps [#implementation-steps]
### Platform initialization [#platform-initialization]
Start by setting up Daniel Admin as the platform administrator. He will initialize the entire system.
Follow the [First Administrator Setup](/docs/operators/platform-setup/first-admin-setup) guide using these values: email `admin@digital-securities.example`, organisation name Digital Securities S.A., base currency EUR, and asset factories set to Equity.
For public chains: Ensure Daniel's wallet has sufficient native tokens (ETH, MATIC, etc.) for system deployment
transactions before proceeding.
As the first user, Daniel Admin will deploy all system contracts including identity registry, access manager, and asset factories.
### Grant additional administrative permissions [#grant-additional-administrative-permissions]
Continue as Daniel Admin. After platform setup, he holds only the minimum required roles: Permission Manager and System Manager. This demo requires two more. Use the [Change Admin Roles](/docs/operators/platform-setup/change-admin-roles) guide to add Add-on Manager (manages platform extensions and modules) and Identity Manager (required to invite other users).
Access Organisation settings > Admins & roles, find Daniel Admin, click the three dots, select "Change roles", and add the roles listed above.
### Invite platform team [#invite-platform-team]
Continue as Daniel Admin. Add the other platform operators and external partners who will participate in this demo.
Use either the [Invite users](/docs/operators/user-management/invite-users) guide or the [Create users](/docs/operators/user-management/create-users) guide. The invite flow sends email invitations so participants onboard themselves, which is more realistic. The create-user flow sets up accounts with random passwords for faster demo setup when participants do not need direct platform access.
Platform operators:
1. Olivia Operator ([operator@digital-securities.example](mailto:operator@digital-securities.example)): creates tokens, manages corporate events, handles minting/burning.
2. Clara Compliance ([compliance-kyc@digital-securities.example](mailto:compliance-kyc@digital-securities.example)): manages KYC and AML verification, registers identities, issues verifications.
External organizations:
3. Ian Issuer ([issuer@acme-holdings.example](mailto:issuer@acme-holdings.example)): legal owner of the equity being tokenized.
4. Colin Collateral ([collateral-agent@guardian-collateral.example](mailto:collateral-agent@guardian-collateral.example)): independently verifies collateral backing.
5. NovaX Vault ([vault@exchange.example](mailto:vault@exchange.example)): institutional vault provider for token custody. NovaX Vault receives 20,000 tokens in the final forced transfer step.
### User onboarding process (if "Invite user" was chosen) [#user-onboarding-process-if-invite-user-was-chosen]
All invited users follow the same onboarding process. See [User Onboarding](/docs/operators/user-management/user-onboarding) for the complete flow.
Each invited user will accept their invitation, generate a blockchain wallet with PIN security, save backup codes, create an on-chain identity, and complete their profile.
For public chains: If using the invitation flow, invited users will need native tokens in their wallets to pay for identity creation. If using the create-user flow, the identity manager pays for identity creation.
### Assign platform admins [#assign-platform-admins]
Continue as Daniel Admin. After team onboarding, use [Add Administrators](/docs/operators/platform-setup/add-admins) to assign roles to platform admins.
Olivia Operator needs the Asset Manager role to create and configure new assets.
Clara Compliance needs four roles: Identity Manager (manages the users registry), Verification Issuer (issues KYC and compliance verifications), Compliance Manager (manages global compliance rules), and Verification Policy Manager (configures verification topics and trusted issuers). Clara owns all regulatory compliance and user verification.
Colin Collateral needs one role: Verification Issuer. Colin's only function is issuing collateral verifications.
### Configure trusted issuers [#configure-trusted-issuers]
Log in as Clara Compliance to set up the verification framework by designating who can issue which types of verifications.
For public chains: Ensure Clara's wallet has native tokens for trusted issuer configuration transactions.
Follow [Configure Trusted Issuers](/docs/operators/compliance/configure-trusted-issuers) to configure each issuer:
Clara Compliance as trusted issuer for investor-level verifications: add Clara for Know Your Customer (KYC) and Anti-Money Laundering (AML). Add Accredited Investor and Qualified Institutional Investor if the scenario requires those statuses. As Compliance Officer, Clara owns all investor-related verification.
Colin Collateral as trusted issuer for collateral verification: add Colin for the Collateral topic. Guardian Collateral Services is the independent third party verifying collateral backing.
Olivia Operator as trusted issuer for asset-level verifications: add Olivia for Base Price, Unique Identifier, Asset Classification, and Asset Location (the last is optional and needed only for real estate). As Asset Operator, Olivia manages asset metadata and classification.
### Register investors in registry [#register-investors-in-registry]
Log in as Clara Compliance and use [Register User](/docs/operators/user-management/register-user). For both Ian Issuer and NovaX Vault, choose Luxembourg as jurisdiction. Both users then show "Registered" status and can receive KYC verifications.
Platform operators (Daniel, Olivia, Clara) don't need registration unless they'll hold tokens.
### Issue KYC and AML verifications [#issue-kyc-and-aml-verifications]
Continue as Clara Compliance and use [Verify KYC](/docs/operators/compliance/verify-kyc). Issue Know Your Customer and Anti-Money Laundering verifications for both Ian Issuer and NovaX Vault. Both users now have the KYC and AML verifications the ACME token requires.
### Create ACME equity token [#create-acme-equity-token]
Create the equity token using the Asset Designer with full compliance configuration.
For public chains: Ensure Olivia's wallet has native tokens for asset creation and permission management transactions.
Log in as Olivia Operator and follow [Create Asset](/docs/operators/asset-creation/create-asset). Complete the Asset Designer configuration as follows.
Asset Class (step 1): select Flexible Income class, choose Equity type.
Basic Details (step 2): Name = ACME Holdings Equity, Symbol = ACME, Decimals = 0 (whole shares only), Jurisdiction = Luxembourg.
Asset Classification (step 3): Category = Common Equity, Class = Common Equity, Unique Identifier = LU0000ACME01 (ISIN format), Internal Reference = ACME-EQ-001.
Pricing (step 4): Currency = EUR, Base Price = 0.71 (€0.71 per share).
Compliance Modules (step 5): enable Identity verification with required expression AML and KYC, so only users with both accepted verifications can receive assets. Enable Collateral Requirement (optional) with topic "Collateral" at 100% ratio; the collateral verifier records backing for the tokenized equity example.
### Configure token permissions [#configure-token-permissions]
After asset creation, Olivia has the minimum required roles (Permission manager + Governance) following the principle of least privilege. For this demo, she needs additional token-specific roles.
Use [Change Asset Admin Roles](/docs/operators/asset-servicing/change-asset-admin-roles) to assign Olivia Operator these additional roles: Custodian (execute transfers and forced transfers), Emergency (pause/unpause token operations), and Supply Management (mint and burn token supply).
### Issue collateral verification [#issue-collateral-verification]
Colin must issue a collateral verification before minting is possible, because collateral modules block any mint until this step is complete.
For public chains: Ensure Colin's wallet has native tokens for issuing collateral verification transactions.
Log in as Colin Collateral and follow the [Collateral](/docs/operators/compliance/collateral) guide to issue verification with these details:
* Amount: 100000 (covering full supply)
* Expiration: 1 year from now
This confirms Guardian Collateral Services has verified sufficient backing for the full token supply.
### Unpause the token [#unpause-the-token]
Log in as Olivia Operator and use the [Pause/Unpause Asset](/docs/operators/asset-servicing/pause-unpause-asset) guide to activate the ACME asset.
Collateral verification and token unpausing can be done in any order. Both are needed before minting, but they don't
depend on each other.
Olivia can unpause because she holds the Emergency role on the ACME token, which pause/unpause operations require.
### Mint and distribute ACME tokens [#mint-and-distribute-acme-tokens]
Continue as Olivia Operator and use [Mint Assets](/docs/operators/asset-servicing/mint-assets):
For public chains: Ensure Olivia's wallet has sufficient native tokens for minting transactions, which can be
gas-intensive for large amounts.
Mint to ACME Holdings:
* Recipient: Ian Issuer (select from contacts or use wallet address)
* Amount: 100000 (full token supply)
* Purpose: issue the complete supply to the legal issuer before the exchange allocation is moved by forced transfer
### Execute forced transfer to exchange [#execute-forced-transfer-to-exchange]
Continue as Olivia Operator. Transfer 20,000 tokens from the issuer to the exchange using forced transfer capability.
For public chains: Ensure Olivia's wallet has native tokens for the forced transfer transaction.
Use [Forced Transfer](/docs/operators/asset-servicing/forced-transfer) with these details:
Set the from address to ACME Holdings, the to address to NovaX Exchange, amount 20000, and purpose to allocate tokens to exchange for secondary market custody.
This demonstrates custodian-controlled movement between verified parties after issuance. Final holdings are 80,000 ACME tokens for ACME Holdings and 20,000 for NovaX Vault. Olivia can execute this transfer because she holds the Custodian role on the ACME token.
## Troubleshooting [#troubleshooting]
| Issue | Solution |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Minting fails | • Ensure collateral verification covers the mint amount when enabled
• Verify each recipient satisfies KYC and AML
• Check the operator has the Supply Management role
• Confirm the wallet has enough native gas tokens |
| User cannot receive assets | • Verify the user is registered in the identity registry
• Ensure the user has KYC and AML verifications
• Check token compliance requirements
• Confirm the wallet address is correct |
| Verifications not trusted | • Verify issuer is configured as trusted for specific topic
• Check verification data format and expiration
• Ensure issuer transaction was confirmed
• Refresh page after configuration changes |
| Role assignment fails | • Confirm you have role management permissions
• Verify target user completed onboarding
• Ensure user belongs to your organisation (for internal roles)
• Check transaction has sufficient gas tokens for public chains |
Each row in the troubleshooting table links to the underlying cause. Consult the individual feature guides for the affected step when the table guidance does not resolve the issue.