Tokens & pairs
How Assetera separates a logical asset from its per-chain token, names a listing, builds same-chain pairs, and manages the catalog lifecycle.
Assetera's catalog separates what an instrument is from how it exists on-chain. That separation is what lets one regulated instrument live on more than one blockchain, and be offered by more than one source, without re-architecting anything.
Asset, token, listing
- Asset: the logical instrument. It carries the regulatory identity (ISIN, name, issuer, suitability profile, documents). There is one asset per instrument, regardless of how many chains it lives on.
- Token: a concrete on-chain deployment of that asset, identified by its chain plus an on-chain reference (an EVM contract address, a Solana mint, and so on). The reference is unique per chain, never globally, and decimals are per token (never assume 18).
- Listing: the catalog entry an investor sees and trades. One canonical listing exists per (asset, chain) deployment, so the same asset on two chains is two listings that can roll up to one logical group.
Naming and fields
A listing carries these fields. Several are optional, because real catalogs include one-sided and ICO listings:
| Field | Meaning | Notes |
|---|---|---|
symbol | Ticker for the listing | |
name | Display name | From the project name, falling back to the asset name, then the symbol |
base_asset | The instrument being traded | Can be absent for one-sided / ICO listings |
quote_currency | What it is priced in | A stablecoin or RWA symbol (for example USDC, USDY, OUSG). No default currency; EUR is not assumed. Can be absent |
chain_id | Which chain (CAIP-2) | Best-effort; may be absent. Identity leans on the on-chain reference |
token_ref | The on-chain reference | Opaque and chain-scoped: a 0x address on EVM, a base58 mint on Solana |
min_price / max_price | Price deviation collar | The MiFID deviation bounds. Absent when a listing has no collar |
logo_url, status | Branding and lifecycle | See below |
Field names being finalised
Exact field names and the response shape are being finalised during marketplace-api development. Treat the names above as the model, not a published contract.
Chain identity (CAIP-2)
Chain is a first-class dimension. Each chain is identified by the CAIP-2 standard, not a raw integer, so non-EVM chains fit the same model:
- EVM:
eip155:137(Polygon),eip155:8453(Base) - Solana:
solana:<genesis-ref>
The on-chain reference is treated as an opaque, chain-scoped value, so a Solana mint and an EVM address sit in the same field without special cases. Adding a chain is inserting a row, not migrating core tables.
Trading pairs
A pair is a tradable listing: a base token quoted against a quote token (for example a tokenized instrument quoted in a stablecoin).
- A pair's base and quote live on the same chain, and the trade settles on that chain.
- Cross-chain settlement is deliberately not supported. Bridges and atomic swaps are easy to demo but hard to track and a large attack surface, so Assetera chose the smaller, auditable surface on purpose.
Catalog status lifecycle
Every listing carries a single global status. For MiFID II, retired listings are never deleted:
deleted is a flag, and the row (with an audit snapshot) is retained.
| Status | Meaning | Visible to investors? |
|---|---|---|
new | Created, not yet released (go-forward state) | No |
active | Live and tradable | Yes |
paused | Temporarily halted, still on the storefront | Yes (view), trading gated |
inactive | Withdrawn from trading, retained for audit | No |
deleted | Retired; row retained (flag only) for long-term audit | No |
Visibility is derived, not stored: an investor sees a listing only if it is entitled to their tenant,
and its status is active or paused, and it is not hidden by a narrow ops override. Administrators
get a cross-tenant read of everything (including deleted), which doubles as the searchable archive of
retired listings.
One catalog, many sources
The catalog is multi-source from day one. Assetera's own listings and partner catalogs (for example Ondo, Dinari) are the same kind of canonical listing, tagged with their source. Cross-source identity uses the on-chain reference plus chain, so the same token arriving from two sources can be reconciled.
For how a tenant is entitled to a listing and sees only its slice of the catalog, see Tenancy & responsibility.