Frequently asked questions

Both are ways to attach a name, symbol, and decimals to a CashTokens category. They answer different questions and use very different mechanisms:

• BCMR (CHIP-BCMR) is the BCH ecosystem's metadata registry standard. Issuers publish a JSON file (icon, description, links, NFT types, extensions) at a URI, then commit the URI + a sha256 of the JSON body inside an on-chain OP_RETURN BCMR locator on their token's authchain. We walk that authchain ourselves directly from the chain (no third-party indexer) and verify the body's hash against the on-chain commit before showing the metadata anywhere on the site.
• CRC-20 (crc20.cash) is a permissionless on-chain naming convention. The symbol, decimals, and name are encoded inside a 21-byte CashScript covenant in the token's genesis transaction. We detect it directly from chain data — no third-party registry, no publisher, no DNS dependency.

The big practical difference: BCMR is self-asserted (any issuer can declare any symbol they like in their JSON), while CRC-20 is first-come-first-served on chain, with one canonical winner per symbol determined by a deterministic sort (max(commit_block, reveal_block − 20), ties broken by category id). A token can have BCMR alone, CRC-20 alone, both, or neither. When both exist, the on-chain CRC-20 bytes win on authenticity (you can verify them against the genesis tx); BCMR wins on richness (icons, descriptions, social links).

Browse all CRC-20 tokens at /crc20 — the page splits canonical winners from non-canonical contenders so you can see where symbols are contested.

CashToken categories come in three shapes based on the kinds of outputs the token appears on:

• FT — fungible only. Every output has an amount but no NFT commitment. Tokens you count — balances are interchangeable. Example: a BCH-denominated stablecoin.
• NFT — non-fungible only. Every output has an NFT commitment (arbitrary bytes identifying the unique item). No fungible balance. Example: a collectible series.
• FT+NFT — hybrid. The same category has both fungible balances AND unique NFTs under the same category id. Unlike ERC-20 vs ERC-721, BCH CashTokens let one category carry both semantics simultaneously.

Typical FT+NFT pattern: a project mints a governance token (FT) alongside membership badges (NFT) under the same brand. At our last snapshot roughly 18% of the ecosystem uses this hybrid pattern — see the breakdown on /stats.

A token's market cap is price × circulating supply, and the price we have comes from its Cauldron AMM pool. When a pool holds only a few dollars of liquidity, a single dust-sized swap can move that price by orders of magnitude — and multiplying it by a billion-unit supply yields a "cap" that looks enormous but means nothing. Left in the rankings, those numbers shove genuinely-traded tokens down the page.

So we hide the MCap figure for any token whose Cauldron TVL is below the average TVL of the top half of currently listed tokens. The threshold is recomputed on every page load — as more deep pools get listed the bar rises; if liquidity dries up across the top end it falls. No hardcoded dollar floor to age out.

The token itself is unchanged: price, TVL, supply, holders, sparkline, and the detail page are all still shown. Only the misleading derived figure is withheld. Tokens with no Cauldron pool at all never had a derivable market cap in the first place.

We strip emoji from token names, symbols, and descriptions at display time. In a dense directory full of rows, emoji turn into visual noise — they compete with the real name, bloat mobile line-heights, and make it hard to tell a serious project from a lookalike that copied the same glyph. Removing them keeps the grid scannable.

The on-chain data isn't touched. BCMR metadata is stored exactly as the issuer published it; the emoji filter runs only in the browser-facing render path. If you need the raw string, the /api/tokens endpoint returns it unmodified.

Token icons come from BCMR metadata that issuers publish themselves — typically as ipfs:// URIs anyone on the network can fill with anything. We don't render those URLs directly in your browser; instead, every icon goes through a small safety pipeline before it's served, and only icons that clear every gate end up visible on the site.

What we check

• Size. Anything larger than 2 MiB is rejected outright — both to keep page weight reasonable and to short-circuit decompression-bomb images.
• Format. PNG, JPEG, WebP, and GIF first-frame are supported as static rasters. SVG is rasterized server-side via resvg before serving — your browser never sees the SVG XML, so embedded scripts, event handlers, and external href references can't reach you. Animated GIF/APNG render their first frame only.
• Adult content. Each icon is run through Google Cloud Vision's SafeSearch classifier. Scores above a configured threshold are auto-blocked; borderline scores route to an operator-reviewed queue.
• CSAM. Cloudflare's CSAM Scanning Tool runs against every icon the moment it transits their edge — backed by NCMEC + IWF hash databases. Matches are blocked at the network edge and reported automatically per US/EU mandatory-reporting law.

How we serve them

Icons that pass every gate are transcoded to a static WebP, content-addressed by their SHA-256 hash, and served from /icons/<hash>.webp behind a long cache. We never hot-link to the issuer's IPFS gateway from your browser — all bytes go through our origin, scanned and cached.

Why some tokens show a grey placeholder

Default-deny: until an icon is scanned and cleared, you see the placeholder. Reasons a token might still show grey:

• The icon is queued for scanning but hasn't been processed yet (new mints flip from grey to real within ~15 minutes).
• The fetch failed (IPFS gateway timeout) — we retry on a future tick.
• The icon was rejected for one of the reasons above.
• The token has no BCMR icon at all — the issuer never published one.

Privacy

The classifier sees only the icon bytes — anonymous, no user identifier, no IP, no session. Bytes are processed in transit and not retained by Google for SafeSearch calls. We keep the SHA-256 hash and a score; we don't keep the bytes ourselves once they're either cleared (transcoded copy on disk) or blocked (deleted).

Spotted an icon that looks wrong (false-blocked legitimate art, or a harmful image that slipped through)? Email [email protected] with the token's category hex and we'll triage.

The Total TVL pill in the header sums BCH-side reserve across every pool on every AMM venue we index — Cauldron plus Fex.cash. The number is quoted in USD using the live BCH spot price.

The Cauldron portion comes from indexer.cauldron.quest's canonical ecosystem TVL — the same number the /stats page shows on its "Cauldron AMM" card. We cache it for 30 minutes via our sync-cauldron-stats worker so the homepage doesn't pay a network round-trip on every render.

The Fex portion is summed locally: our Fex worker enumerates every pool on the BCH chain via a scantxoutset against the AssetCovenant P2SH and stores both the per-category canonical pool (for directory price + spread display) and the sum across all pools per category (for the headline TVL).

Tapswap is deliberately excluded — its open offers are P2P intent, not pooled liquidity, so summing them as TVL would double-count or mislead. We use the conservative single-side convention everywhere (BCH-side reserve only, not the doubled both-sides figure that the wider DeFi industry typically reports).

The Txs 24h pill in the header — and the matching Token-bearing txs card on /stats — counts every transaction in the last 24 hours that emits at least one CashToken-bearing output. A tx that mints a new category, transfers existing tokens, or moves multiple token types in a single tx all count as one entry. Coinbase transactions are excluded.

We derive the count purely from on-chain data — no DB lookup, no external API. Our sync-tail worker reads the verbose JSON of every new block from our local BCHN node, scans each transaction's outputs for any tokenData field, and stores a per-block tally in the blocks.token_tx_count column. The headline number is just SUM(token_tx_count) WHERE time > now() - INTERVAL '24 hours'. Roughly 144 blocks land in any 24-hour window at BCH's 10-minute target spacing, so a fresh deploy might briefly show a partial number while the rolling window fills.

The companion New categories card on /stats uses a stricter detection: per the CashTokens CHIP, a transaction creates a new token category if it spends a previous transaction's output at index 0 and emits a token_data vout whose category id matches that parent's transaction id. The category id IS the parent UTXO's txid by spec, so we can detect new categories without consulting a database — every chain participant can verify the same number.

What this number is not: it is not BCH transaction volume, not USD volume, and not a measure of trade activity specifically. A token's whole UTXO set being reorganised by its issuer counts the same as a real user-driven transfer. If you want trading-specific signal, look at the Cauldron 24h volume on /stats or Tapswap's open-listing depth.

BCMR (Bitcoin Cash Metadata Registry) is how a CashToken tells wallets + explorers what its name, symbol, icon, and description are. Without a BCMR publication, your token shows up as a 16-char hex string — useless for any kind of brand or community use. The Publish BCMR wizard at tokenstork.com walks you through publishing one on-chain.

Who can publish? Only the wallet holding your category's authority NFT — the NFT created at genesis that anchors the authchain. The wizard automatically detects which categories your connected wallet can publish for and rejects anything else. This is the CashTokens-protocol way of preventing impersonation: if someone else minted the token, they can't publish metadata on your behalf, and vice versa.

How does the wizard work? Six steps:

1. Enter the identity: name, ticker (symbol), decimals, description.
2. Paste an icon URI (https:// or ipfs://) or skip.
3. We generate the canonical BCMR JSON and compute its sha256 — that hash will be committed on-chain alongside your publication URL.
4. Upload the JSON to your own IPFS / Pinata / Lighthouse / any HTTPS host, paste the URL, and we sha256-verify the returned bytes. Your own host is the canonical source. Optionally, opt into a tokenstork-hosted backup mirror (operator-approved; serves at https://tokenstork.com/bcmr/<hash>.json as a fallback).
5. We build the unsigned transaction that spends your authority NFT, emits a new one (preserving the NFT's commitment + capability), and attaches the OP_RETURN BCMR locator with your content hash + URL. You sign in your wallet and paste the signed hex.
6. We broadcast to BCH. Done.

What happens after broadcast? Our on-chain BCMR walker runs hourly, and on its next tick it'll see your new authchain hop, fetch the JSON from your host, verify the hash matches, and update the token's metadata across the directory. Typically your token's name and icon appear within an hour of broadcast.

Why does my IPFS host need to keep the JSON? The on-chain locator points at your URL — that's the canonical reference for the metadata. If your host goes down, any cached copy (including ours, if you opted in) still works, but the publisher-of-record is you. Start a publication →

The "Most upvoted / downvoted / controversial" leaderboards on the homepage don't just count raw ↑ and ↓ clicks. Each vote contributes a weighted score, and the leaderboard sorts on the sum of those weights. The directory's ?sort=upvoted / downvoted / controversial options use the same weights.

Two things shape a single vote's weight:

1. How long the voter has been around. Each wallet's tenure is the number of distinct UTC days on which it has cast at least one vote action. A vote from a brand-new wallet contributes 1.0; a vote from a wallet that's been active 30 days contributes 5.0; a year-tenured wallet contributes about 8.5. Growth is logarithmic (log₂(tenure_days + 2)) — established voters get more say, but a tireless contributor doesn't dominate.
2. How recently the vote was cast. Vote weight halves every 7 days (0.5^{age_days / 7}). A vote cast today is worth 1.0×, last week's is worth 0.5×, two weeks old is 0.25×, a month-old vote is about 0.05×. Old enthusiasm fades; the leaderboard reflects the current mood.

Multiplied together, the formula favours consistent votes from established voters, and naturally pushes raid-style bursts of fresh wallets toward the bottom of the ranking. The raw ↑ / ↓ counts shown next to each token are still the simple totals — only the ordering uses the weighted score.

Each wallet may cast, change, or retract at most 20 vote actions per UTC day. That's well above any organic per-day activity but tight enough that a script-controlled wallet can't shove a token to the top in one sitting. The counter resets at 00:00 UTC.

Sign in with your wallet, navigate to a token you hold (any FT balance or NFT counts), and click Airdrop on the token detail page. Pick a recipient token — the wizard will airdrop your token to every wallet that currently holds the recipient token.

Two split modes. Equal divides your total amount evenly across all recipients (truncation residue stays with you). Weighted sends each recipient a share proportional to their balance + NFT count of the recipient token. Sender's own wallet is always filtered out of the recipient list.

Recipient lists come from our local token_holders snapshot (refreshed every 6 h by the enrich worker), so a brand-new token minted in the last few hours may not have all its holders indexed yet. The wizard surfaces the snapshot timestamp so you can decide whether to wait.

Big airdrops are split into chunks of up to 600 recipients per transaction. Your wallet signs each chunk in sequence (paste the signed hex back into the wizard); a wallet rejection on chunk K leaves earlier chunks intact and lets you retry K from the receipt page. If our holder snapshot advances mid-airdrop (an enrich tick fires), remaining chunks halt with a "redraft" prompt rather than send to a possibly-stale set.

Privacy heads-up: like every UTXO transaction, an airdrop reveals your sender wallet to every recipient via the tx-input. Your wallet's public key hash is visible in any block explorer.