Constellation

Customer assets are pooled and reused, lent, posted as collateral, or traded, so the same units back more than one obligation at once.

What to look at: Read the custody and yield terms for language granting the venue the right to use, lend, or pledge assets. Ask whether balances are held in named or omnibus wallets and whether any regulator requires segregation for that entity. On-chain, look for regular movement between exchange-labeled addresses and affiliate or lender addresses, and check whether any proof-of-reserves exercise covers liabilities and was performed by an independent party.

One custodian, one signing arrangement, or one operations team stands between holders and their assets, so a single failure can be terminal.

What to look at: Establish who can sign, in what quorum, under what recovery procedure, and whether any independent party has tested the key ceremony and the disaster recovery plan. Check whether the custodian is a regulated trust company or similar, what its financial statements show, and whether it discloses subcustodians. Read the insurance policy's scope rather than the headline figure, since cause and wallet type limitations do most of the work.

A venue holding customer assets fails, and the balance shown in the account becomes a claim in a bankruptcy rather than an asset the customer controls.

What to look at: Read the terms of service on title, segregation, and what happens in insolvency, since the language is usually explicit once found. Check whether the venue publishes proof of reserves, whether that exercise includes liabilities, and who performed it. Withdrawal processing times during past stress, published financial statements if any, and the licensing regime that governs client money are all observable before the fact.

Self-custody puts the holder in charge of a secret that cannot be reset, so losing it or destroying the only backup is permanent.

What to look at: On-chain dormancy metrics show how much supply has not moved in many years, part of which is generally understood to be permanently inaccessible. For an individual arrangement, the testable facts are whether a restore has actually been performed from the backup, whether backups are geographically separated, whether any passphrase is recorded separately, and whether an inheritance procedure exists in writing. Wallet software support for the specific token standard and chain is also checkable in advance.

Attackers take assets by persuading holders to sign a transaction or reveal a secret, without breaking any cryptography or contract.

What to look at: Review outstanding token approvals with an allowance viewer, since standing approvals are the main mechanism and are visible on-chain. Check whether the wallet decodes calldata into a plain-language action and whether the project pins its front end to a content hash or serves it from a decentralized host. Domain hijacks, dependency compromises, and support-impersonation waves are usually documented publicly by the projects affected.

A large share of stake is operated by a few providers or on shared infrastructure, so one mistake can cause correlated penalties or systematic censorship.

What to look at: Look at stake share by operator, by liquid staking protocol, and by client software, and at the share of blocks produced through the largest relays and builders. Check the cloud provider and geographic distribution disclosed by large operators, and whether a liquid staking protocol's node operator set is permissioned or open. Slashing history and mass missed-attestation events are recorded on-chain.

Circulating supply is often a number supplied by the project, computed under rules that differ between data providers and can change without notice.

What to look at: Reconstruct supply from the token contract itself, subtracting balances in vesting contracts, identified treasury addresses, and burn addresses, then compare that with the provider's published figure. Read the provider's methodology document and its revision history, and check whether bridged or wrapped versions are double counted. Where a project publishes its own supply dashboard, compare it with the on-chain reconstruction rather than accepting it.

Most fee income comes from one application, one trading pair, or one temporary activity, so the income stream is far narrower than the totals suggest.

What to look at: Break fees down by application, by contract, and by trading pair rather than reading the chain-level or protocol-level total, and look at how concentrated gas consumption is across the top few contracts. Check whether the metric you are reading counts gross fees paid by users or only the share retained by the protocol, since dashboards label these differently. Look at how the composition changed across at least one full cycle of activity, including any period when a dominant application was launched or wound down.

Why it is listed here: No fee stream is tracked for this asset by our sources, so none of the fee-based measures on this site can be computed for it.

New units are created faster than demand to hold them grows, so each existing unit represents a smaller share of the same network.

What to look at: The emission schedule is in code and documentation and can be checked against realized issuance on-chain, and net issuance, burn rate, and the staking ratio are standard metrics. Compare issuance against fees actually paid by users to see how much of validator or provider income is subsidy rather than demand. Check whether emissions are fixed by protocol or adjustable by a governance vote, and whether any past vote changed them.

Why it is listed here: No maximum supply is written into this asset's protocol, so new units can keep being created indefinitely.

The payment that funds honest block production declines as issuance falls, and if fees do not replace it, the cost of attacking the chain falls with it.

What to look at: The security budget, meaning issuance plus fees paid to producers over a period, is computable from public data, as is the share of it contributed by fees rather than subsidy. For proof-of-work chains, compare the cost of renting hash power for an hour against the value that settles in that time; smaller chains with rentable hash power have observable reorganization histories. For proof-of-stake chains, look at the staking ratio and at the cost of acquiring a threshold share of stake given real market depth.

Decisions are made by a foundation, core developers, or private discussion, with token voting confirming outcomes rather than determining them.

What to look at: Read the foundation's own disclosures: treasury addresses and holdings, grant reports, employment of core developers, and whether it holds any protocol keys. Trace where proposals originate and how much changes between first draft and final vote, and check whether votes are binding on-chain or advisory signaling. Note who controls the primary domain, the default front end, and the documentation, since those determine what most users can reach.

Token votes decide protocol parameters, but only a small share of tokens usually votes, so a modest holding can carry a proposal.

What to look at: Read turnout as a share of circulating supply for each historical proposal rather than for a single flagship vote, and read the quorum rule and how it is calculated. Check whether voting power is snapshotted before a proposal is announced, whether tokens in lending markets can vote, and how concentrated delegate power is. Check whether a passed proposal executes immediately or after a timelock that allows users to exit.

Voting power is proportional to tokens held, so a few large holders can determine outcomes regardless of how many other participants disagree.

What to look at: Look at the distribution of voting power across the top delegates and holders, and compute how many addresses are needed to reach a majority of a typical vote, which is a governance analogue of a concentration coefficient. Check whether custodial addresses have ever voted, and whether any vote-incentive market exists for the asset. Reviewing which addresses decided each past proposal is the direct test and is fully public.

Digital asset markets trade without pause, so a move that equities would spread across sessions and halts can complete in minutes with nothing interrupting it.

What to look at: Compare depth and spread during weekend and overnight hours against weekday peaks on the same venue, and look at the largest observed short-interval ranges rather than at daily candles. Cross-venue price divergence during past stress windows is observable and shows where arbitrage stopped functioning. Read each venue's published policy on halts and on cancelling trades, since practice varies and some venues have unwound executions after the fact.

Most trading, price discovery, and often custody for an asset sit at one or two venues, so a venue's problem immediately becomes the asset's problem.

What to look at: Look at volume share by venue after filtering, at which venues feed the relevant index or oracle, and at whether the asset trades meaningfully in more than one regulatory jurisdiction. On-chain balances at exchange-labeled addresses show how much supply is custodied where, though labeling is heuristic and should be treated as approximate. Historical outages, withdrawal pauses, and maintenance windows at the dominant venue are documented in its own announcements.

Leveraged positions are force-closed automatically, and the resulting market orders trigger further force-closures in a self-reinforcing sequence.

What to look at: Compare open interest against spot order-book depth, since the ratio indicates how much forced flow a market may have to absorb. Funding rates at persistent extremes indicate crowded positioning, and aggregate liquidation prints show what actually cleared. Insurance fund balances, their drawdown history, and any past use of auto-deleveraging are published by major derivatives venues, and on-chain lending markets publish liquidation thresholds and the value sitting near them.

A venue can remove an asset for regulatory, compliance, or commercial reasons, cutting its liquidity and its fiat gateway in that market.

What to look at: Track listing status by venue and region over time, and read the venues' own delisting notices, which usually state a reason and a timetable. After a removal, look at the share of remaining filtered volume and at whether depth actually migrated or simply disappeared. Check whether regulated custodians still support the asset, since custody support often precedes and outlasts trading support.

Action against one critical intermediary, such as an issuer, custodian, bridge operator, or staking service, can disable a function the asset depends on.

What to look at: Map the intermediaries standing between the protocol and an ordinary user, including the issuer, the custodian, the fiat rails, the oracle operator, the sequencer, and the front-end host, then note where each is incorporated and what license it holds. For each, check whether a substitute exists and how quickly users could switch. Enforcement filings, consent orders, and company announcements are public and usually state precisely what activity must cease.

How staking rewards, forks, airdrops, wrapping, and lending are taxed varies by jurisdiction and is unsettled in places, creating liabilities that surprise holders.

What to look at: Read the specific published guidance for the relevant jurisdiction and note exactly which events it addresses and which it leaves open. Check whether venues and custodians issue tax statements and what basis method they apply, and whether the protocol produces per-epoch records adequate to reconstruct reward timing. On-chain data will usually support reconstruction, but only if reward accrual and claims are separately observable.

A trading venue may operate without licenses that would apply to a comparable regulated market, so customer protections differ from what the interface implies.

What to look at: Read which licenses the venue actually names, in which jurisdiction, and for which activity, then check whether client assets are segregated by rule or only by promise in the terms. Look for an independent auditor, a published market-surveillance policy, and whether the terms permit the venue or its affiliates to trade against customers. Enforcement actions and regulator warning lists are public and specific.

Most of the network runs a single software implementation, so one bug in that program becomes the network's bug rather than a contained failure.

What to look at: Client distribution dashboards report the share of nodes or stake by execution and consensus client, and the protocol's own thresholds give the reference points that matter, such as the one-third of stake that can delay finality and the two-thirds that can finalize. Check whether large staking operators disclose their client mix, and whether the chain has any incentive or policy encouraging minority clients. The number of independently funded client teams, and how recently each shipped a release, is public.

A defect in the consensus rules or in their implementation makes nodes disagree about valid history, halting the chain or splitting it into two.

What to look at: Look for a public incident history of halts, deep reorganizations, and emergency releases, and for whether the chain has a documented restart procedure. Client diversity data shows how many independent implementations validate the rules, and time-to-finality or confirmation-depth conventions show how long a reorganization can plausibly reach back. Post-incident write-ups, when they exist, are the most informative disclosure a chain publishes.

A hash function, signature scheme, or proving system that a network depends on proves weaker than assumed, undermining ownership, history, or validity.

What to look at: Identify which primitives and curves the chain uses, whether any proving system involved required a trusted setup and how many independent participants took part in the ceremony, and whether the circuits have been independently audited or formally verified. Check whether the protocol has any path to rotate signature schemes without a hard fork, such as account abstraction or a versioned address format. Public incident histories for wallet software show whether randomness or nonce handling has failed in that ecosystem before.

A sufficiently large error-corrected quantum computer would break the elliptic-curve signatures that authorize transactions, though no machine near that scale is known to exist.

What to look at: On-chain data shows how much supply sits at addresses whose public keys are already exposed through reuse or early output types, which is the directly measurable part of this exposure. Check whether the protocol has an upgrade path that allows new signature schemes without moving every coin, such as address versioning or account abstraction, and whether any core research or roadmap document addresses migration. Treat vendor claims of quantum readiness as a document to read rather than a fact, and check which specific scheme is proposed.

The data a full node must store and process grows over time, so fewer people can run one and verification concentrates in a smaller set of operators.

What to look at: Chain size, state size, and their growth rates are published, as are the hardware requirements in official documentation and the practical requirements for archive nodes. Count reachable full nodes and look at their geographic and hosting distribution, and look at how much application traffic reaches the chain through a small number of remote procedure call providers. Watch for repricing proposals, state expiry research, and pruning defaults, which indicate whether the issue is being managed.

A protocol upgrade or token migration goes wrong, splitting the network, stranding holders on an old contract, or breaking dependent applications.

What to look at: Read the activation mechanism and the share of nodes or stake signaling readiness before the fork block, and read client release notes, public testnet runs, and shadow-fork results to see how much rehearsal happened. For a token migration, check whether the old contract still has supply outstanding, whether the swap has a hard deadline, and which venues and custodians have confirmed support. After the event, a persistent minority chain or a lingering old-contract balance is an observable fact rather than a forecast.