Asset design
Build the reusable product shapes and compliance rules an issuer selects when creating an asset, plus the identity-evidence chain every compliance check reads.
Asset design is where you define a product before any token exists. Seven of its nine pages write a reusable definition that a later step reads: the product shape an issuer fills in, the compliance rules that shape enforces, and the identity evidence those rules check. The other two are references. Compliance modules explains what those rules do, and token features explains what each feature a template can include does. Neither writes a definition itself. Issuing, transferring, and holding happen elsewhere in the Console; what you change here decides how those steps behave the next time they run.
To create an asset, open Issue new asset, which reads the templates and policies built here. Come here first when you define a new product line or assemble a new compliance rule set, and come back whenever a regulation or a product's terms change.
Three routes lead from these pages to a live token. The product-definition chain runs through issuance: an asset classAn Asset Class groups instrument templates by economic category for catalog navigation and exposure reporting.Read the concept labels an instrument templateAn Instrument Template lets an issuer configure a new instrument from an approved shape, instead of re-deciding what it records, does, and permits each time.Read the concept, a policy template attaches its compliance rulesA Compliance Policy lets a compliance team write eligibility and holding rules once, while a platform floor reaches every current-factory token.Read the concept to that template, and creating an asset copies the published template into the new instrument. The identity-evidence chain never touches issuance: verification topics name categories of evidence, trusted issuers are authorised to attest them against a participant's on-chain identityAn On-Chain Identity lets a subject's verification serve every asset that accepts it, so a screened wallet skips re-onboarding for the next regulated asset.Read the concept record, and every compliance check reads that authorisation at the moment it runs. Global controls operate outside the template chain and binds its rules straight to every bound token on a system and network, minus whatever the rule's own scope carves out.
The product chain is copied into a token once, at issuance, while the evidence chain is read again at every compliance check. Global controls operate independently and binds to tokens directly, so its reach includes tokens issued long before the rule existed.
The build order runs top to bottom in the product chain. An instrument template attaches a class and a published policy. The policy must already be published on Policy templates; the wizard has no inline way to draft one. A class is more flexible: pick one from Asset classes, or create it without leaving the wizard. The identity chain orders only one step: a topic must exist before anything can attest it. A trusted issuer and a compliance provider are then two separate paths to the same result, not a sequence; registering a compliance provider makes it a trusted issuer for the topics it provisions, rather than requiring one to exist first. Compliance modules is the shared reference across every configuration surface: what each rule permits or refuses, wherever you configure it.
Two of these pages sit in the Console sidebar under "Asset design": Asset classes and Instrument templates. They need an admin, system manager, or asset designer role. Policy templates, Global controls, verification topics, trusted issuers, and compliance providers sit under "Compliance" instead; compliance modules has no sidebar entry, since it is a reference, not a screen you open directly. The sidebar also hides a link when none of your roles can open that screen, so your sidebar may carry fewer links than another operator's. Opening a page is not the same as changing anything on it: global controls, for one, opens read only to an administrator and takes writes from a compliance manager alone, and each page's own "Before you start" section names its exact write role. For a missing sidebar entry, check the role requirements and the deployment's enabled capabilities.
The surface you pick decides a rule's reach
A new rule can live on a policy template, in Global controls, or on a single token's own compliance tab. Which tokens must never escape it decides which one.
| Surface | Choose it when | What it costs you |
|---|---|---|
| Policy template | The requirement belongs to one product's terms. | It reaches only instruments issued after the change; a live token keeps the rules it was issued with. |
| Global controls | The requirement should hold everywhere by default, such as a sanctions list. | The next regulated operation on any bound token enforces it, live tokens included, except whatever the rule's own scope carves out; a misconfigured rule refuses operations across every token in scope until you correct it. |
| Token's compliance tab | A single instrument needs a stricter rule than its siblings. | It reaches that one token alone, layered on top of whatever the token already inherits from its policy template and from Global controls. |
Issuance copies policy-template modules into the token's own bindings. The token compliance tab manages those bindings after issuance. Global controls remain a separate inherited layer; they do not depend on retaining the template link.