Skip to content

Tokens on the Concordium blockchain follow the CIS-2 specification and CIS-7 specification for PLTs . CCDExplorer tracks three categories:

  • Fungible tokens – CIS-2 tokens with divisible supply (e.g. EUROe).
  • Non-fungible tokens – ERC-721 style CIS-2 tokens where each token_id is unique.
  • Protocol-level tokens (PLTs) – CIS-7 system-issued tokens where supply changes are encoded in protocol events.

All CIS-2 token activity is sourced from logged events emitted by contract_initialized or contract_update_issued transactions. CIS-7 (PLT) token activity is tracked through account_transaction.token_update transaction type.

CIS-2

Token address format

  • <contract_index,contract_subindex>-<token_id>
  • Stored as _id in the tokens_token_addresses_v2 collection via MongoTypeTokenAddress.
  • Always accompanied by canonical account references to ensure aliases roll up correctly (see Alias Addresses).

Initialization flow

  1. ms_events_and_impacts parses every transaction and normalizes logged events plus impacted addresses.
  2. ms_token_accounting groups those events per token address and creates/updates documents in:
  3. tokens_token_addresses_v2 – aggregate supply, metadata URL, verification info, last processed block height.
  4. tokens_links_v3 – holdings per account/contract/public key (with canonical IDs).
  5. ms_metadata enqueues newly discovered metadata URLs for retrieval.

Token addresses are created lazily: the first observed transfer/mint/burn event for a (contract, token_id) pair results in a new document.

Verification tiers

  • Verified Fungible / Verified Non-Fungible – token addresses listed in tokens_tags, curated by CCDExplorer operators.
    These often include issuer metadata, price feeds, and icons.
  • Unverified – any active token not yet tagged. Still fully tracked, but presented with an “unverified” badge in the Explorer.

Verification feeds into the Explorer API via /tokens/fungible and /tokens/non-fungible endpoints, allowing clients to filter by trust level.

Metadata retrieval

  • CIS-2 metadata lives off-chain (typically JSON over HTTPS).
  • ms_metadata fetches each URL, validates the payload, and writes it into the token_metadata field.
  • Failed fetches use exponential backoff, and the dagster_recurring jobs can force a retry when an issuer updates their metadata.

CIS-7 Protocol-level tokens (PLTs)

Transactions can emit PLT events (e.g. release amounts). ms_plt processes those events and feeds dashboards plus on-chain analytics. PLTs share the same canonical storage (token addresses + links) so APIs treat them uniformly.

Downstream usage

  • Explorer account pages leverage tokens_links_v3 to show balances on the Fungible/NFT tabs.
  • For PLTs we maintain plts_tags and plts_links.
  • Notification services watch token events to alert users about transfers impacting their canonical address.
  • Dagster analytics jobs (realized prices, holders, transaction fees) query the token collections to track supply, holder counts, and verified issuer stats.

Example documents

See ms_token_accounting for sample MongoDB documents representing token addresses and account links.***