WINkLink

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.

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.

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.

A small set of keys can pause, upgrade, mint, or move assets, so the system's safety depends on those keyholders and their operational security.

What to look at: Enumerate the privileged roles in the deployed contracts and resolve each to an address, then check whether that address is an externally owned account, a multisig, or a timelock, and what the multisig threshold and signer count are. Check whether signers are publicly identified, whether they are independent of one another, and whether they use separate hardware and jurisdictions. Read what the pause and mint functions can actually do, since a pause that also blocks withdrawals is a different instrument from one that only stops deposits.

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.

The contract that holds funds can be pointed at new code, so the audited behavior of today is not necessarily the behavior of tomorrow.

What to look at: Check whether the address is a proxy by reading the standard implementation and admin storage slots, then identify who holds the upgrade right and whether upgrades pass a timelock. Count how many times the implementation has changed and compare the currently deployed implementation against the specific commit that was audited. Where a timelock exists, its queue of pending changes is public and can be monitored.

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.

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.

Whether a token is treated as a security, a commodity, or something else remains unresolved in several jurisdictions, and the answer changes who may list or hold it.

What to look at: Check whether the asset has been named in enforcement filings, registration statements, or approved regulated products, and how regulated venues and custodians in each jurisdiction actually treat it. Look at whether an identifiable issuing entity exists and continues to fund development, since a live promoter is central to most tests. Exchange listing terms and product disclosures often state the venue's own classification assumption in plain language.

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.

A protocol reads a price from an external feed, and someone moves that price cheaply in order to trigger borrowing, liquidations, or settlement in their favor.

What to look at: Read the oracle configuration: how many independent sources feed it, whether it is a spot read or a time-weighted average and over what window, what deviation and heartbeat thresholds trigger an update, and what the contract does when the feed goes stale. Compare the depth of the underlying market for a collateral asset against the maximum amount borrowable against it, since manipulation cost scales with that depth. Governance records often show when a market was listed with parameters set before its liquidity existed.

A flaw in deployed contract code lets funds be moved, locked, or destroyed in ways the designers never intended.

What to look at: Check whether the deployed bytecode matches published verified source, when the implementation last changed, and how much value the contract has held without incident, since value held multiplied by time live is a cruder but harder-to-fake signal than an audit badge. Look at how many independent audits exist, whether findings were fixed or formally accepted, and whether a funded bug bounty with a published scope and payout history is in place. An immutable contract and an upgradeable one carry different failure modes, so establish which you are looking at before reading anything else.