How a Reference Price Is Built
The CantonCap API recalculates every asset's reference price about once a minute, in each currency it publishes. Its inputs are the prices public Canton venues quote for the asset: each market's ticker, or the state of its pool where a market publishes no ticker. A price quoted in another asset, such as a stablecoin or Canton Coin, is converted through that asset's own reference price, so no stablecoin is assumed to be worth exactly one dollar.
A reference price is built only from observations that are fresh, liquid enough to be meaningful, and reachable in the requested currency. Venue pool state, executable order-book levels and settled venue trades can each act as a direct constituent. Currency-labelled external references may convert those observations to a target currency, but do not normally become standalone price constituents themselves.
A quote counts only within the bounds the operator sets: enough liquidity behind it, no further from its peers than an outlier allows, a spread and a price impact within limits, a cap on how much any one venue can move the result, a limit on conversion steps, and a maximum age. The quotes that pass are weighted into one figure. Each asset is calculated on its own, so a failure on one never holds back another.
Canton Coin's USD price is the median of three independent centralised exchange references, Bybit CC/USDT, OKX CC/USDT and Kraken CC/USD, with the USDT legs converted through Kraken's USDT/USD rate as an exact decimal. It is published as one tagged aggregate carrying its three sources, and it is both a conversion edge and a direct constituent.
The Basis Beside Each Price
Every asset page shows what the venues are quoting: each venue's latest price for the asset, the spread between the lowest and the highest, and their median. Only markets where the asset is the base are used, in the one quote asset with the most markets, because prices in different quote assets cannot share an axis.
With an even number of venues the median is the lower of the two middle quotes rather than their average, so it is always a price a venue actually quoted. The basis is a public check on the reference price, not the calculation itself, whose weights and exclusions are administrative records.
Price Origins
- AMM poolvenue_pool
- Derived from on-chain pool reserves at a Canton venue.
- Order bookvenue_book
- Derived from executable order-book levels at a Canton venue.
- Venue tradevenue_trade
- Taken from settled trades in the venue trade journal.
- External referenceexternal_reference
- A currency-labelled reference used to convert, not to set the price directly.
- Derivedderived
- Computed from other admitted observations rather than observed directly.
What Every Observation Is Checked Against
Before an observation can support a published figure it is scored against 15 checks. A failure is recorded as a quality incident naming the stage and the check.
These records are administrative rather than public: the public API publishes the surviving value and the time it was last updated, not the audit trail. What a public consumer can inspect directly is the spread across venues, see any asset page.
- Decimal validitydecimal_validity
- The reported value did not parse as an exact decimal.
- Timestamp validitytimestamp_validity
- The observation carried a missing or implausible time.
- Identity resolutionidentity_resolution
- The record could not be tied to a known asset or market.
- Price validityprice_validity
- The price was non-positive or outside the bounds the instrument can take.
- Reserve validityreserve_validity
- Pool reserves were inconsistent with the curve they claim to follow.
- Crossed bookbook_crossed
- The best bid exceeded the best ask, so the book was not internally consistent.
- Empty bookbook_empty
- One or both sides of the book carried no levels to price against.
- Sequence gapsequence_gap
- The source's sequence numbers skipped, so at least one update was missed.
- Stalenessstaleness
- The observation was older than the freshness window for this calculation.
- Price outlierprice_outlier
- The price sat outside the accepted dispersion band for its peers.
- Supply jumpsupply_jump
- Reported token supply moved further between observations than issuance allows.
- OHLC invariantohlc_invariant
- A candle broke its own invariants — high below open, low above close, or similar.
- Duplicate eventduplicate_event
- The same source event arrived twice and was counted once.
- Volume reconciliationvolume_reconciliation
- Reported volume did not agree with the trades observed over the same window.
- Dependency unavailabledependency_availability
- An input this figure depends on was not available when it was calculated.
Liquidity and the Liquidity Score
An AMM pool's liquidity is the USD value of its reserves: each reserve at its asset's reference price, matched by Canton identity. A reserve whose asset has no price leaves the figure empty rather than guessed; an empty pool is zero. An order book is measured by its depth instead, so an order-book market has no single liquidity figure.
Depth within 2% is the USD value that can be bought or sold before the price moves 2% from the reference: read from the book's own levels on an order book, and modelled from the pool's stored state, fee included, on an AMM. A modelled depth measures the curve; it is not a quote and not a promise of execution.
The liquidity score rates a market from 0 to 100 by what trading there would cost. The API simulates buys and sells of $100, $500, $1,000, $5,000 and $10,000 against the market's current state, fees excluded, and turns their price impact, and whether each could be filled, into one score. A market without enough inputs has no score, which is never the same as a score of zero.
An asset's score is the mean of its three highest market scores, on either side of the pair, or of every scored market when it has fewer, so an asset with one scored market takes that market's score. A venue's is the mean across its markets. The Most Liquid view ranks assets by the asset score.
24-Hour Volume
Volume has one definition across the site, so a table and a total cannot disagree. A market's 24-hour volume in USD is the API's activity measurement for it where one exists; otherwise the USD volume the venue reports on its ticker; otherwise its volume in the quote asset at that asset's reference price. An asset's volume is the sum over every market it trades in, on either side of the pair; a venue's is the sum over its markets; the network's counts every market once.
The activity measurement chooses one notional for each period, preferring USD derived from exchange-anchored prices no more than three minutes old, and never adds a venue's reported volume to the volume observed in its trades. It is rolled up from hourly slices, with a new snapshot every five minutes.
A volume figure carries its caveats. When a refresh has no usable value, the API keeps the latest one with its own time; once that time is more than an hour old, the figure is shown muted with the time it is from, never as current. A partial figure covers only part of the 24 hours and says so, and an estimate is marked as one. Unknown is never shown as zero, and a total that contains older, partial or estimated figures says how many.
Rocky's reported volume is shown on its own markets, muted with the reason, and left out of every total until it reconciles with its trades: its first figures ran to several times the supply of the assets it lists.
Fully Diluted Valuation
FDV is the exact decimal product of the admitted reference price and the latest policy-compatible total-supply observation from an approved registrar. Where the supply observation is older than the maximum age the methodology accepts, or where no approved registrar has published one, FDV is not calculated and the reason is stated in place of the number.
Total supply is the figure an approved registrar publishes for the instrument, kept exactly as reported: never rounded, rescaled or interpolated. A supply that moves further between two observations than issuance allows is flagged by the supply-jump check. Circulating and maximum supply are not published.
Market Capitalisation
Market capitalisation is not published. It requires a circulating-supply figure, and no reviewed circulating-supply methodology exists for Canton instruments, distinguishing circulating from locked, treasury-held and contractually restricted supply is a governance question rather than a data one.
The API states this in the payload rather than returning an empty field: the global metrics response carries market_cap.semantics = "unavailable_circulating_supply". Until that methodology exists, a market capitalisation for a Canton asset is a guess, and this product does not publish guesses.
Rank and Ratios
The rank orders every listed asset from its FDV, the liquidity in its pools and its rolling 24-hour volume. It is computed once over the whole listing, so an asset holds the same rank on every page, in every currency and under every sort.
Liquidity / FDV divides the USD liquidity in an asset's AMM pools by its FDV, each eligible pool counted once. Order-book depth is not in it. It is not capped: a small valuation with deep pools can pass 100%.
Volume / FDV divides the asset's best available rolling 24-hour volume in USD, reported or observed trades but never their sum, by its FDV: the share of the valuation that changed hands in a day.
Either ratio is left out when FDV is missing, stale or zero, or when there is nothing to divide: an asset with no pool has no liquidity ratio. Each carries its coverage, so a figure built on part of the markets says so.
Both read on one scale of four bands, marked by the bars beside each figure.
| Band | Range | Liquidity / FDV | Volume / FDV |
|---|---|---|---|
| Thin, Quiet | Under 1% | Thin | Quiet |
| Shallow, Light | 1% to 5% | Shallow | Light |
| Moderate, Active | 5% to 10% | Moderate | Active |
| Deep, Heavy | 10% and over | Deep | Heavy |
Charts: Candles and the Line
Candles show the asset's open, high, low and close in USD, aggregated by the API across the markets it prices the asset from, with volume underneath where it was published. The chips choose what one candle covers: 15m, 1h, 4h, 24h, 1W or 1M. The three shortest read about two hundred candles back, 24h reads a year, and 1W and 1M read the whole history.
The API serves candles up to a week long, so a monthly candle is built from daily ones, by calendar month in UTC: it opens at the month's first open, closes at its last close, spans the highest high and the lowest low, and sums the volume its days published.
Candles are joined into one continuous record: each opens where the one before it closed, and an interval in which nothing traded is a flat candle at the previous close, with no volume, rather than a gap. A candle's high and low widen to hold its open, so a body never leaves its wick.
The line plots the reference price itself, over 24h, 1W, 1M, 1Y or All, at one point per interval, the latest price in it: every 15 minutes over 24 hours, hourly over a week, every 4 hours over a month, and daily over a year or longer. It reads green above the range's first point and red below it.
A chart reaches back only as far as the API holds history and the site's access allows, and it is read in windows of at most 31 days. Where a source's history begins when CantonCap started observing it, earlier periods do not exist. The small line in each table row is the asset's last 24 hours of reference prices, hourly.
Update Cadence and Timestamps
Venues are read every 30 seconds to 5 minutes, depending on what each allows, and reference prices are recalculated about once a minute. The site reuses each answer for a short window: 30 seconds for source status, a minute for prices, listings and markets, and five minutes for volume, venues, charts and sparklines. An open market table checks for new prices every 45 seconds.
Every time the API publishes is in UTC, and the site prints its times in UTC. A calculated price carries the time it was calculated; a measurement over a window carries the end of the window it covers, not the time it was read. Windows include their start and exclude their end. Each figure's age is shown beside it, and the app marks prices as delayed once the newest is half an hour old. The app's chart prints its axis in the phone's own time.
Sample and Live Data
Every figure is read from the CantonCap API when the page is built, and every read records whether it came back live. In production an unreachable API gives an error or an honest absence, never a page of invented figures.
Development and preview builds can show a fixed sample dataset when the API is out of reach. A page drawn from it always carries a sample-data banner saying why, and its figures are illustrative, not a market feed. Sample data is never presented as real.
Watchers, Sentiment and Issuer Posts
“On N watchlists” counts the members who currently keep an asset on their watchlist, from signed-in members' lists only. It is a total; no list is ever shown. The site refreshes it at most once a minute.
The sentiment gauge counts members, each once per asset. A member's bullish or bearish vote on the asset's page counts for seven days from when it was given; a member who has not voted counts by the lean of their latest first post on the asset in the last seven days, leaving out replies, hidden posts and deleted posts. The bullish share of the members who took a side is placed on a dial of five equal zones, from strongly bearish to strongly bullish. It is a tally of opinions, not a signal, and it stays empty when nobody leaned.
An issuer feed shows the posts an issuer or asset provider publishes on X, only where the API lists an approved association between that issuer and the asset; no feed is chosen by matching a symbol. Posts appear as published, with their time in UTC and a link to the original. An edited post shows its latest version, and withheld, protected and deleted posts are removed. An open page checks again every 30 seconds and never shows a post from an answer more than 90 seconds old. CantonCap does not endorse what issuers post.
Coverage and Scope
Canton enforces sub-transaction privacy: a party receives only the parts of a transaction that apply to it. A venue that is visible to an integrator key is not visible publicly, and a party-scoped execution record is not visible to anyone else. Each figure therefore carries the scope it was observed under.