Assets & Regulations
This page is a docs-focused overview of common regulatory and product concepts that show up when building tokenized assets, native issuance workflows, and other regulated financial applications on Dusk.
If you’re looking for implementation details, start here:
- Digital Identity Protocol (Citadel)
- Transaction Models (Moonlight & Phoenix)
- Market Infrastructure on Dusk
- Dusk Trade
MiCA (EU)
Section titled “MiCA (EU)”MiCA (Markets in Crypto-Assets Regulation) is the EU framework that sets requirements for:
- Crypto-asset issuers (including stablecoin categories like EMTs and ARTs)
- Crypto Asset Service Providers (CASPs)
Official sources
Practical regulated asset requirements
Section titled “Practical regulated asset requirements”Regardless of jurisdiction, regulated assets often imply a few recurring product requirements:
- Access control: only eligible parties can hold/transact (allowlists or identity/credential checks).
- Transfer checks: transfers fail with clear reasons and can be simulated or checked before submission.
- Corporate actions: dividends/coupons, burns, splits, and issuer-driven actions.
- Recovery & remediation: processes for lost keys, fraud response, and legally required actions.
- Governance/voting: snapshots and vote windows without double-counting.
- Audit & reporting: the ability to produce compliant reports without leaking unnecessary user data.
- Settlement coordination: asset and payment legs need to settle predictably.
On Dusk, these concerns typically connect to identity/credentials (Citadel), smart contracts, and the dual transaction models (Moonlight for transparent flows and Phoenix for shielded flows).
Access controls
Section titled “Access controls”Access controls answer questions such as:
- Who is allowed to hold this asset?
- Who is allowed to receive it?
- Which transfers should fail?
- Which rules apply to a venue, jurisdiction, or asset class?
On Dusk, access-control patterns can be implemented with identity credentials, wallet binding, smart contract logic, and application-level checks. The exact design depends on the legal and product requirements of the asset.
Privacy with selective disclosure
Section titled “Privacy with selective disclosure”Regulated markets need privacy, but they also need evidence.
Examples:
- an investor should not expose every balance or transfer to every market participant
- an issuer may need visibility into specific ownership or eligibility data
- a supervisor, venue, or auditor may need controlled disclosure for a defined purpose
Dusk’s privacy model supports this direction through shielded transfers, zero-knowledge proofs, and selective disclosure patterns.
Settlement and servicing
Section titled “Settlement and servicing”Regulated assets usually require more than a transfer:
- primary issuance
- secondary market transfers
- settlement against a payment leg
- corporate actions
- investor updates
- reporting and audit trails
DuskDS provides deterministic finality and Dusk’s Moonlight and Phoenix transaction models. Applications can use DuskEVM or DuskVM contracts depending on whether a workflow needs EVM compatibility or direct L1 execution.
Dematerialization and CSDs (Concepts)
Section titled “Dematerialization and CSDs (Concepts)”Dematerialization is the shift from paper certificates to electronic records of ownership. In traditional finance, Central Securities Depositories (CSDs) and associated market infrastructure manage issuance, custody, and settlement processes.
For many tokenization projects, the relevant takeaway is that “real-world” asset workflows often require more than transfers: role-based controls, recovery paths, servicing, reporting, and auditability tend to be first-class requirements.