Native versus mirror is the first question to ask of any tokenised instrument, because it determines where the legal claim actually sits. A digital-native instrument is issued on-chain, where the token is the operative record; a mirror (or wrapped) token is an on-chain representation of an asset that continues to live off-chain, where the claim runs through a custodian or a wrapping party. The distinction drives custody, redemption, settlement finality, and counterparty risk, so we tag entries with an issuance_model field rather than lumping all "tokenised" products together. The definitions below are the working taxonomy for that field and are subject to editorial review.

Digital-native issuance

A digital-native instrument is created directly on a ledger, and the on-chain entry is the legally operative record of ownership. There is no separate off-chain register that the token points back to; transfer of the token is transfer of the asset. The practical tells: redemption and corporate actions are executed against the chain, settlement finality is the chain's finality, and there is no custodian holding an underlying instrument on behalf of token holders (though there may still be a custodian for the keys).

This is the harder model to stand up, because it requires the legal wrapper to recognise the chain entry as operative, which in most markets needs either bespoke legislation or a specific regulatory accommodation.

Mirror / wrapped tokens

A mirror or wrapped token represents an asset that remains issued and recorded off-chain. The token is a claim on, or a pointer to, the underlying instrument held by a custodian or issued by a wrapping party; the legal claim ultimately runs through that party, not the chain. Most "tokenised" money-market funds (MMFs) and many tokenised securities in market today are mirror structures: a transfer agent or fund administrator maintains the authoritative register, and the token tracks it.

The practical tells: there is a named custodian or administrator holding the underlying, redemption routes back to that party, and the token's value depends on the wrapping party's solvency and operational integrity, not only on the asset.

Why the distinction matters

• Counterparty risk. A mirror token carries the wrapping party's risk on top of the asset's. A native instrument does not interpose a wrapper, but it shifts weight onto the legal recognition of the chain entry.
• Redemption and finality. Native redemption settles on-chain; mirror redemption settles through the off-chain administrator, often on the administrator's calendar and cut-offs.
• Regulatory treatment. Regulators frequently treat the two models differently, particularly on whether the activity is securities issuance, deposit-taking, or fund administration.
• Hybrid is common. A platform may issue some products native and mirror others. The classification is per product, not per institution; an institution-level tag is hybrid only when sourced.

How we classify

The issuance_model field on institution and use-case entries takes one of native, mirror, hybrid, or unknown. The default is unknown, and it is never guessed: an entry is classified only when a source establishes the model for the specific product. An entry shown as "issuance unverified" means exactly that, not that the model is native.