Skip to main content
What is the Safety Score?
Jonathan Blackburn avatar
Written by Jonathan Blackburn
Updated over 2 months ago

Our Safety Score filter is a bespoke metric designed to evaluate the security of ERC-20 tokens by analyzing multiple aspects of each token's smart contract.

This comprehensive score leverages over 35 different factors, incorporating both on-chain and off-chain data to provide a thorough assessment of a token's security. These factors range from contract vulnerabilities and audit results to transaction patterns and liquidity metrics.

The Token Safety Score is regularly updated to ensure it reflects the most current information and trends, providing an up-to-date security assessment for users.

How is the Security Score calculated?

Our Token Safety Score leverages over 35 distinct metrics to provide a comprehensive analysis of an ERC-20 token's security. Below are some of the key metrics used in the scoring process:

  • Sell Tax: This metric assesses whether a fee is applied to tokens when they are sold. High or modifiable sell taxes can indicate potential risks, such as attempts to disincentivize selling or manipulate token value.

  • Buy Tax: Similar to the sell tax, this metric evaluates if a fee is imposed when purchasing tokens. High buy taxes can be used to exploit buyers or fund malicious activities.

  • Tax Modifiable: This metric checks whether the contract allows for tax rates to be changed after deployment. The ability to modify tax rates post-deployment can be a red flag, as it may enable the contract owner to impose unexpected fees.

  • Mintable: This metric determines if new tokens can be created after the contract is deployed. A mintable contract could potentially dilute token value or be used to manipulate the token supply.

  • Honeypot: This crucial metric identifies whether a contract might be a honeypot—a type of scam that traps users by preventing them from selling tokens after purchase. Honeypots are a serious risk in the crypto space and are a primary focus in our security assessment.

  • Token Percentage of Owner: This metric measures the proportion of the total token supply that is owned by the contract owner. A high percentage suggests a centralized control, which can be risky if the owner decides to sell or manipulate the market.

  • Is Airdrop Scam: This metric evaluates whether the token is part of a suspected airdrop scam. Airdrop scams often involve distributing worthless tokens to users, which can then be used to phish for sensitive information or trick users into buying more tokens.

  • Addresses Related to Honeypot: This metric flags any addresses associated with known honeypot scams. By identifying these connections, we can assess whether a token is potentially linked to fraudulent activities.

  • Phishing Activities: This metric checks for any involvement of the token's contract in phishing schemes. Tokens associated with phishing activities pose significant risks to users, and this metric helps to highlight such dangers.

These metrics, along with many others, are combined to form a holistic view of a token's security, ensuring that users are better protected from potential threats in the decentralized finance ecosystem.

What criteria must a token meet to receive a security score?

As soon as a token begins trading, it qualifies for analysis and will be assigned a safety score based on the available data. Depending on the availability of data, the token will typically be scored within a few minutes of its first trade.

How do you handle tokens with insufficient data for a safety score?

If a supported token cannot be fully analyzed due to insufficient data, it will default to a score of '0'.

Can a token’s safety score change over time?

Yes, a token’s safety score is dynamic and can change over time. After a token is initially analyzed and assigned a score, this score remains valid for one week. After this period, the token will be re-analyzed upon its next trade. If the token is not traded for another month, it will not be re-analyzed until a new trade occurs.

Did this answer your question?