Crypto trust score metrics are the measurable inputs used to assess a project or asset. The most useful groups are security, liquidity, tokenomics, control and governance, transparency, development quality, incident history, and data freshness. None is a guarantee on its own. The value comes from seeing the evidence, timestamp, and limitation behind each signal.
This page focuses on how the metrics are measured and interpreted. If you first need the meaning and limits of the overall score, read our pillar guide to how crypto Trust Scores work.
Disclosure: Forvest publishes this guide and operates the Forvest Trust Score. The examples below explain a general, auditable metric framework; they are not a disclosure of an unpublished Forvest formula or factor weights. Last reviewed: August 9, 2026.
Crypto trust score metrics: quick map
| Metric group | Useful evidence | Freshness target | Main limitation |
|---|---|---|---|
| Security | Deployed code, privileges, audit scope, open findings | After every material upgrade | An audit or verified contract cannot prove safety |
| Liquidity | Spread, depth, price impact, credible venues, withdrawals | Live or recent market snapshot | Reported volume can be inflated |
| Tokenomics | Circulating supply, unlocks, emissions, treasury, utility | Latest schedule and on-chain state | Labels and circulating-supply estimates may differ |
| Concentration | Economically independent holders and voting power | Current block or recent snapshot | Exchange, bridge and treasury wallets need classification |
| Governance and control | Admin keys, multisig, timelock, voting and upgrade rules | Current deployed contracts | Public governance can still be concentrated |
| Transparency | Official documents, legal entity, disclosures, source links | As of the score date | A polished website is easy to manufacture |
| Development quality | Releases, code review, security policy, dependency controls | Rolling 90–180 days plus releases | Commit counts do not measure code quality |
| Incidents | Exploit record, postmortems, remediation, user impact | Continuously monitored | No known incident may mean limited history |
A model should also record the data source, retrieval time, coverage, and missing-data rule. Without that context, a precise-looking number may be impossible to audit.
1. Smart-contract and security metrics
Security is not a binary “audited or not audited” field. Start with the exact deployed contracts and chain, then inspect several separate signals.
| Security signal | How to measure it | What not to assume |
|---|---|---|
| Source verification | Match published source and build settings to deployed bytecode | Verified source does not mean vulnerability-free code |
| Audit coverage | Match report date, audited commit/address and components to the live system | An old or partial audit does not cover later upgrades |
| Finding status | Count critical/high findings and verify remediation evidence | “Resolved” in a PDF is not enough without implementation evidence |
| Privileged functions | Identify mint, pause, upgrade, fee, blacklist and asset-transfer powers | Decentralized branding does not remove administrator power |
| Key controls | Check signer count, multisig threshold, timelock and emergency path | A multisig is weak if signers are related or threshold is low |
| Security operations | Review bug bounty, disclosure policy, monitoring and incident response | A bounty badge does not show its scope or payout reliability |
Ethereum’s official guide to smart-contract verification distinguishes source-code verification from formal verification. Matching source to deployed bytecode makes the contract inspectable, but it does not prove the business logic is correct or free of exploitable behavior.
Investor interpretation: reward evidence that applies to the current deployed system. Penalize unresolved critical findings, unclear proxy implementations, single-key control, or upgrades that bypass a meaningful delay. If the contract address cannot be confirmed, mark the security component unknown rather than inferring safety from a project name.
2. Liquidity and market-quality metrics
Liquidity measures the ability to trade a realistic position without an unacceptable change in price. Daily volume is only one input and is often the easiest one to misread.
- Bid-ask spread: the difference between the best ask and best bid, divided by their midpoint.
- Order-book depth: the value available within a defined distance—such as 1%—of the midpoint.
- Price impact: the price change caused by a trade of a specified size.
- Venue concentration: the share of credible liquidity that depends on one exchange or pool.
- Volume consistency: whether volume patterns align with depth, price movement, and comparable markets.
- Transfer availability: whether deposits and withdrawals work for the asset and network.
Spread % = (best ask − best bid) ÷ midpoint × 100
Venue concentration % = largest credible venue liquidity ÷ total measured credible liquidity × 100
For an automated score, define the trade size before calculating impact. A $1,000 trade and a $100,000 trade can produce very different conclusions. Uniswap’s explanation of price impact notes that larger pools generally produce less impact, while the rate changes as pool liquidity changes.
Reported volume should be cross-checked rather than accepted at face value. CoinGecko’s current exchange Trust Score methodology uses volume consistency and order-book depth relative to reference markets because reported exchange volume can be inflated. That methodology scores exchanges, not individual projects, but the data-quality lesson also applies to token markets.
Failure mode: a token can show high volume while having a wide spread, shallow executable depth, unreliable withdrawals, or most activity on one questionable venue. A strong liquidity component should respond to executable conditions, not just a headline number.
3. Token supply, emissions, and unlock metrics
Tokenomics metrics measure current dilution risk and the incentives created by future supply. Record both the published schedule and the observable on-chain state.
- circulating, total and maximum supply, with the source and definition for each;
- annualized gross issuance or emissions under current rules;
- burns or other supply reductions;
- team, investor, foundation, ecosystem and treasury allocations;
- the next material unlock and cumulative 30-, 90- and 365-day unlocks;
- vesting conditions, cliffs and any authority that can change the schedule;
- token utility, fee capture and incentives that may create buying or selling pressure.
30-day unlock ratio = tokens scheduled to unlock in 30 days ÷ current circulating supply × 100
Net annual supply growth = (new issuance − burned tokens) ÷ starting circulating supply × 100
These are exposure indicators, not predictions. A large unlock does not guarantee a sale, and a burn does not guarantee demand. Compare the unlock’s potential value with credible market depth, not only with market capitalization.
Failure mode: the circulating-supply figure may exclude controlled or technically unlocked tokens, while a marketing page may show only the distant maximum supply. If the official schedule and on-chain movement disagree, record the discrepancy and reduce confidence.
4. Holder and voting-power concentration
A raw “top 10 holders” percentage is often misleading. Large addresses can belong to exchanges, bridges, staking contracts, liquidity pools, burn addresses, vesting contracts, or the project treasury. Classify addresses before interpreting concentration.
Adjusted top-holder concentration = tokens controlled by the largest economically independent holders ÷ adjusted circulating supply × 100
Calculate several views when possible:
- top 1, top 5 and top 10 independent-holder share;
- team, investor and treasury-controlled share;
- voting-power concentration, which may differ from token ownership;
- the change in concentration over 30 or 90 days;
- liquid versus locked holdings.
For proof-of-stake networks, validator concentration and delegated stake may matter more than token-holder count. For governance tokens, inspect proposal and quorum rules as well as turnout: broad ownership does not help if a small group consistently controls executable votes.
Failure mode: unlabeled addresses create false positives, while related wallets can create false decentralization. Address classification should show its source and confidence level.
5. Governance and privileged-control metrics
Governance metrics ask who can change the system, how quickly, and with what checks. This can be measured even when the project calls itself decentralized.
| Control question | Measurable field | Lower-risk evidence |
|---|---|---|
| Who can upgrade contracts? | Controller address and upgrade path | Documented multisig, independent signers and meaningful timelock |
| Who can move treasury assets? | Wallet type, threshold and signer set | Transparent policy, adequate threshold and on-chain history |
| Can transfers or withdrawals be paused? | Pause scope and emergency authority | Narrow scope, public trigger conditions and review path |
| Can supply or fees change? | Mint cap, fee ceiling and controlling role | Hard limits or delayed, visible governance |
| Can token holders govern effectively? | Proposal threshold, quorum, turnout and delegation | Distributed voting power and executable process |
A timelock duration is only useful if stakeholders can detect the queued change and react before execution. A multisig signer count is only useful when signers are operationally independent. Record the deployed addresses and date rather than relying on documentation that may describe an earlier configuration.
6. Transparency and accountability metrics
Transparency should measure verifiable disclosure, not the amount of marketing content. A practical completeness score can test whether specific evidence exists and is internally consistent.
- exact legal entity and operating jurisdiction;
- official contract addresses and supported chains;
- current technical documentation and change log;
- audits, findings and remediation links;
- token allocation, unlock and treasury reporting;
- governance, admin-key and upgrade disclosures;
- security contact and responsible-disclosure process;
- incident reports that explain impact and remediation.
Evidence completeness % = verified required fields ÷ applicable required fields × 100
“Not applicable” must be justified, not used to improve the percentage. Contradictory claims should reduce data confidence even if every field is filled. A named team can improve accountability, but identity alone is not proof of competence or honest behavior. Conversely, a pseudonymous contributor history can still provide verifiable evidence.
Failure mode: logos, testimonials, follower counts and a long whitepaper can create the appearance of transparency without exposing who controls contracts, supply or funds.
7. Development and open-source quality signals
Repository activity can support a trust assessment, but commit count is a weak standalone metric. One meaningful reviewed release can matter more than hundreds of cosmetic commits.
Useful fields include:
- repository ownership and its connection to the deployed product;
- release frequency and whether releases map to live contracts or binaries;
- number of independent maintainers with recent substantive contributions;
- code review, branch protection and signed-release practices;
- security policy, dependency updates, testing and vulnerability handling;
- unresolved critical issues and time to remediate them.
The OpenSSF Scorecard provides automated security-practice checks for open-source repositories. Its own documentation warns that the checks are heuristics with possible false positives and false negatives, and that an aggregate repository score cannot show which individual behaviors are present. Use it as supporting evidence—not as a crypto-project safety certificate.
Failure mode: an active public repository may be unrelated to the deployed contract, while important code may remain private. Always connect the repository, release, build and deployed address.
8. Incident history and response quality
An incident metric should capture severity and response, not just a yes/no history flag.
- date and type: exploit, key compromise, oracle failure, bridge incident, withdrawal halt or governance attack;
- maximum assets at risk and realized user loss;
- time to detect, contain, disclose and restore service;
- root-cause quality and independent evidence;
- remediation, compensation and recurrence;
- whether the same privileged architecture remains.
A past incident can reveal strong response practices, while a project with no known incident may simply be new or lightly used. Use exposure time and value secured as context. Critical unresolved controls should continue to affect the score after a public apology.
How to normalize and weight different metrics
Raw inputs use different units: spread is a percentage, depth is currency, audits are categorical, and unlocks are token quantities. A scoring model must normalize them before combining them.
- Threshold scoring: map defined ranges to scores. It is simple to explain but creates cliffs near boundaries.
- Percentile scoring: rank an asset against a relevant peer group. It adapts to the market but is relative, not absolute.
- Continuous transformation: convert the raw value through a capped linear or logarithmic formula. It is smoother but harder to explain.
- Evidence-state scoring: classify verified, conflicting, missing or not applicable evidence. This is useful for qualitative controls.
Weights should match the object being assessed. A DeFi protocol may require greater security and admin-control emphasis; a widely traded asset may need deeper market-quality analysis. CoinGecko’s August 2026 methodology, for example, weights liquidity at 50% in its centralized-exchange score and recalculates weekly. Those weights should not be copied into a token or protocol score because the scored object and risk question are different.
A weighted average also needs critical gates. If an unaudited single key can drain user assets, strong social activity should not average away that risk.
How to handle stale, missing, and conflicting data
Missing data is not automatically bad, but it is never automatically good. A robust output separates metric quality from metric value.
| Data state | Recommended treatment | Reader display |
|---|---|---|
| Verified and current | Use in the score with its timestamp | Value, source and last checked date |
| Stale | Reduce confidence or exclude after a defined expiry | Stale warning and original date |
| Missing | Mark unknown; apply a disclosed rule | Unknown, not zero or safe |
| Conflicting | Prefer primary evidence or reduce confidence | Show the discrepancy |
| Not applicable | Remove from denominator only with justification | N/A and reason |
| Model-derived | Separate inference from observed data | Estimate label and method |
Each metric should have an expiry policy based on how fast it can change. Liquidity may need live or daily measurement; contract privileges after every upgrade; token unlock schedules when official terms or contracts change; team and documentation on a slower review cycle.
Worked example: from evidence to an auditable score
Consider a hypothetical protocol. This is an educational example, not a Forvest rating. The model scores four components from 0 to 100 and uses disclosed weights.
| Component | Evidence summary | Score | Weight | Contribution |
|---|---|---|---|---|
| Security | Verified proxy; recent audit; unresolved medium issue; 2-of-3 upgrade multisig | 58 | 35% | 20.30 |
| Liquidity | Tight spread for small trades; high impact at target position size; one dominant venue | 62 | 25% | 15.50 |
| Tokenomics | Clear schedule; 18% of circulating supply unlocks within 90 days | 45 | 20% | 9.00 |
| Transparency and governance | Current docs; named entity; short timelock; concentrated voting power | 55 | 20% | 11.00 |
| Weighted result | Before any critical-risk override | 100% | 55.80 |
Weighted score = Σ(component score × component weight)
The calculation is reproducible, but it remains a model. The result depends on thresholds, weights, evidence quality, and the date. The useful conclusion is not merely “55.8.” It is that upgrade control, target-size liquidity and a large near-term unlock require further investigation. A score without this breakdown would hide the decision-relevant information.
How investors should use the metric breakdown
- Open the Forvest Trust Score and record the asset, score, signal and date.
- Inspect the available underlying details instead of stopping at the headline number.
- Match each material metric to a primary source and timestamp.
- Identify critical failure modes that an average might hide.
- Compare unresolved risks with your position size, holding period, liquidity needs and custody plan.
- Repeat the review after an upgrade, incident, major unlock, listing, delisting or governance change.
For the wider research sequence, follow our crypto due-diligence framework and connect the result to the controls in our crypto investment risk guide.
Final takeaway
Good crypto trust score metrics are specific, sourced, timestamped and limited. Security should refer to the live system; liquidity to executable conditions; tokenomics to observable supply and future unlocks; concentration to classified controllers; transparency to verifiable disclosure; and development activity to the code that actually reaches production.
Use the aggregate score to filter. Use the metric breakdown to decide what must be verified before investing. When data is missing, stale or conflicting, reduce confidence rather than replacing evidence with certainty.
Educational note: This framework provides general information only. It is not financial, legal, investment or security advice, and no metric or score can guarantee safety or returns.
