Security
Exchanges Methodology
How the CEX Probability of Loss (PoL) Score Works
PoL is a structured risk assessment framework designed to estimate the likelihood that users, token holders, or a counterparty of a centralized crypto exchange may experience a financially material loss, excluding losses caused solely by market price fluctuations.
How the Score is Calculated
PoL Score is calculated in 4 steps, ensuring ...
Solvency
Transparency
Score Conversion
Some data may not be publicly available and will need to be submitted directly by the Exchange.
Calculation ScoreSecuritySolvencyTransparency
Metric
Sub-metric
Condition
Sub-score
Server Security
Metric Weight
6%
Sub-metric
Condition
Sub-score
SSL/TLS Certificate
A+
10
A
9
A-
8
B
6
C
5
D
3
E
2
F
1
T or M
0
WAF and CDN Presence
Yes
10
No
0
Email & DNS Security
SPF Record Found
2.5
DKIM Setup Found
2.5
DMARC Setup Found
2.5
DNSSEC Setup Found
2.5
Neither is found
0
HTTP Headers
A
10
B
8
C
6
D
4
E
2
F
0
Cookie Flags
HTTP Only set
5
Secure set
3
SameSite set
2
None
0
User Security
Metric Weight
7.5%
Sub-metric
Condition
Sub-score
2-factor Authentication
Yes
10
No
0
Password Requirements
Length >= 8 characters
3
Length over 64 character
1
Block breached & common passwords
3
Allow copy/paste & password managers
3
Device Management
List of current sessions
5
Terminate other session
5
Anti-phishing Code
Yes
10
No
0
Withdrawal Whitelist
Yes
10
No
0
Captcha
Yes
10
No
0
Certifications
Metric Weight
10%
Sub-metric
Condition
Sub-score
ISO 27001
Yes
10
No
0
CCSS
Level 1
5
Level 2
10
Level 3
10
No
0
Bug Bounty
Whether the exchange has a clear vulnerability disclosure policy and whether its bug bounty program is self-hosted or managed by a trusted third-party platform, reflecting transparency and maturity in handling security reports.
Metric Weight
12.5%
Sub-metric
Condition
Sub-score
Hosting
3d party hosted
10
Self-hosted
5
No
0
Penetration Test
Metric Weight
12.5%
Sub-metric
Condition
Sub-score
Comprehensive Scope
The penetration test must cover all critical components of the exchange, including the trading platform, wallet systems, user authentication mechanisms, databases, and all APIs. If the exchange offers a web interface or mobile applications, these must also undergo thorough security assessments.
Realistic Testing Scenarios
Testing must be performed using methodologies based on recognized industry standards (e.g., OWASP, NIST, PTES, and relevant blockchain security guidelines). The test should simulate real-world attack scenarios and reflect current threat landscapes.
Internal, External and Cloud Testing
The penetration test should assess security from multiple perspectives, including attacks by external threat actors against internet-facing services, risks arising from internal misuse or compromised credentials, and common cloud-specific misconfigurations.
Reporting and Remediation Guidance
A comprehensive report detailing all vulnerabilities discovered, their severity levels, proof-of-concept examples, and actionable recommendations for remediation. The company must demonstrate that all findings were fixed.
Tester Independence and Qualifications
The penetration test must be conducted by an independent, qualified third party with demonstrable expertise in blockchain and web application security. The provider should present relevant certifications or accreditations (PCI DSS, NIST, OWASP, PTES, MITRE ATT&CK, SANS, OSSTMM).
Relevance of the report
A penetration testing report is considered outdated after one year from the date it was performed.
Testing environment
Penetration testing should ideally be conducted in a non-production environment that accurately mirrors the production system. The report should contain an Environment Validation section. If a staging environment is unavailable, testing may proceed directly against production systems.
Insurance Fund
A reserve fund used to cover financial losses due to hacks or other security breaches, providing a safety net for users' assets.
Metric Weight
1.5%
Sub-metric
Condition
Sub-score
Insurance Fund
Yes
10
No
0
Metric
Sub-metric
Condition
Sub-score
Proof of ownership
We need to ensure that the audited funds genuinely belong to the exchange. If the report does not provide this confirmation, both the User Scope and Reserves Assets Scope will receive 0 points.
Sub-metric
Condition
Sub-score
Confirmed
Yes
No
Users scope
The audit must be conducted for the entire user base.
Metric Weight
15%
Sub-metric
Condition
Sub-score
Coverage
100%
10
75%
0
50%
0
Asset Composition in Total Reserves
High quality assets should be dominating in the reserves structure
Metric Weight
6%
Sub-metric
Condition
Sub-score
Composition
High quality assets
10
1:1 coverage
10
Reliance on own token
0
Mixed quality composition
7
Low quality composition
3
Frequency
If the Proof of Reserves audit is conducted only once a year, half of the User Scope and Reserves Assets Scope score is subtracted. If the report is older than one year, the entire score is subtracted.
Sub-metric
Condition
Sub-score
Cadence
Less than once per year
0
Once a year
0.5
Twice a year
1
Quarterly
1
On a monthly basis
1
Daily
1
Live
1
Merkle tree
The Merkle tree must be presented for users, ensuring it is impossible or irrational to manipulate the user scope.
Metric Weight
9%
Sub-metric
Condition
Sub-score
Implementation
Self developed
5
Self developed audited
10
Third party developed
10
Metric
Sub-metric
Condition
Sub-score
Live reserves wallets tracking
Metric Weight
10%
Sub-metric
Condition
Sub-score
Submitted list of wallets
Live access to this information will make the exchange transparent enough for users to be confident
10
Proof of Ownership
Yes
x1
No
x0
Incident response quality
Assessment of the exchange's cooperation with law enforcement and responsiveness to security incidents.
Metric Weight
10%
Response Time3%
Data disclosure4%
Actions taken3%
Sub-metric
Condition
Sub-score
Response Time
High
3
Moderate
2
Low
1
Data disclosure
KYC details
2
Transaction flow
2
Actions taken
Funds freeze
3
Withdrawal cooldown
2
KYT
1
Last liabilities snapshot value
Live access to this information will make the exchange transparent enough for users to be confident
Coverage ratio
Live access to this information will make the exchange transparent enough for users to be confident
Reserves assets distribution
Live access to this information will make the exchange transparent enough for users to be confident
The final calculation score is inverted to represent the Probability of Loss (PoL) score.
PoL ScoreInverse(Calculation Score)
- Calculation score 0–25 maps to PoL grade D (PoL range 75–90).
- Calculation score 25–30 maps to PoL grade DD (PoL range 70–75).
- Calculation score 30–40 maps to PoL grade DDD (PoL range 60–70).
- Calculation score 40–45 maps to PoL grade C (PoL range 55–60).
- Calculation score 45–50 maps to PoL grade CC (PoL range 50–55).
- Calculation score 50–60 maps to PoL grade CCC (PoL range 40–50).
- Calculation score 60–65 maps to PoL grade B (PoL range 35–40).
- Calculation score 65–70 maps to PoL grade BB (PoL range 30–35).
- Calculation score 70–80 maps to PoL grade BBB (PoL range 20–30).
- Calculation score 80–85 maps to PoL grade A (PoL range 15–20).
- Calculation score 85–90 maps to PoL grade AA (PoL range 10–15).
- Calculation score 90–100 maps to PoL grade AAA (PoL range 0–10).
- Security score of 80% or higher
- Solvency score of 80% or higher
- Verified proof of reserves and financial stability based on disclosed data
- Submission of wallets for on-chain tracking within the CORE3 platform
CoinGecko Trust Score Impact
Please note that CoinGecko's Cybersecurity metric is calculated based on the CORE3 Security Section score.
Liquidity
3.5
Scale
1.0
Cybersecurity
2.0
Cybersecurity
Score
CoinGecko
TrustScore
Cybersecurity
Score
<55–77–88–10
CoinGecko
TrustScore
011.52
API
0.5
Team
0.5
Incident
1.0
PoR
1.0
Have questions about CORE3 Methodology?
Contact us, and we'll provide more information
