David & Fran
April 16, 2025

Safura Risk Evaluation Framework

1. Introduction

Safura is a decentralized protection protocol designed to provide coverage for Web3 users and projects against a wide array of risks, including exploits, cyberattacks, and smart contract vulnerabilities. Backed by a community-governed DAO and expert-led assessments by security researchers at AuditOne, Safura ensures that only rigorously vetted projects are offered protection. This document outlines our structured risk evaluation framework and premium modeling methodology that determines eligibility and pricing for coverage.

2. Risk Assessment Criteria

The first step in evaluating Web3 projects for coverage is a thorough assessment of various technical, governance, and reputational risk factors. These inputs are used to generate a comprehensive and weighted risk score that feeds into both eligibility determination and premium pricing.

2.1 Smart Contract Security (60%)

This factor focuses purely on protocol security:

  • Audit History: Evaluation of third-party audit frequency, scope, and severity of findings. Projects with repeated critical findings or no re-audits post-major upgrades a pose significantly higher risk than those that strictly adhere to a tight auditing schedule, ensuring full audit coverage at any given time. Diversity in audit firms and participation in audit contests or public bug bounty platforms also adds security credibility.
  • Formal Verification: The Presence of mathematically verified proofs, especially for complex or high-value logic, significantly reduces risk. Formal verification is weighted heavily for financial oracles, derivatives, algorithmic systems, and any other protocol that relies on complex math or logic flows.
  • Code Complexity & Update Frequency: Simpler codebases (e.g., ERC-20 tokens) are inherently easier to secure. Frequent code changes require tighter scrutiny and a well-defined re-auditing process. Projects with agile development cycles but no secure SDLC processes are red-flagged.
  • Emergency and Security Mechanisms: The existence and robustness of pause mechanisms, upgradability with timelocks, kill switches, circuit breakers, and any other mechanism that could be used to limit the impact of a security incident. Additional on-chain monitoring solutions (e.g., Forta, Chainalysis alerts) are considered.
  • Third-Party Integrations: Secure implementation and choice of external services (oracles, bridges, AMMs) are assessed. Reliance on low-quality or unverified integrations increases the surface area for attacks.

2.2 Protocol Governance (6%)

Governance design impacts the protocol’s resilience to internal threats:

  • Ownership Model: Centralized control (EOAs or multisigs) is evaluated for key risk exposure. Decentralized protocols are assessed for timelocks, multi-step upgrade processes, and transparency in on-chain execution.
  • Governance Token Distribution: We analyze the voting power distribution, proposal history, and participation rates. Whale-dominated voting or low proposal throughput is considered governance centralization.
  • Decision-Making Structure: DAO efficiency, proposal voting thresholds, delay mechanisms, and execution security are reviewed.

2.3 Liquidity & TVL Exposure (6%)

Economic incentives play a major role in determining attack motivation:

  • TVL (Total Value Locked): The TVL of any given project will be assessed, and projects with high TVL but low security scores will most likely remain ineligible for coverage.
  • Transaction Frequency & Size: Projects processing high-value or high-frequency transactions are scrutinized for Flash-Loan protections, sandwich attack resistance, and overall slippage control. While a certain amount of slippage is unavoidable, protocols should make use of slippage control mechanisms in a way that helps to reduce the slippage in a controlled way.
  • Liquidity Pool Composition: We assess pair volatility, pool depth, and impermanent loss mitigation strategies.

2.4 Historical Security Incidents (5%)

Security maturity is gauged through a protocol’s past:

  • Exploit History: Details of past incidents, incident handling (including time to mitigate and notify and the effectiveness of the placed mitigations), and further actions (public disclosure, lessons learned, funds reimbursement, etc.) will be evaluated.
  • Disclosure Practices: Transparency, incident response time, and communication channels (e.g., public post-mortems, timelines).
  • Fork History: If the protocol is forked or forks others, the exploit record of sibling/forked protocols is taken into account.

2.5 PR & Reputation (10%)

Reputational and ecosystem credibility influences both trust and long-term viability:

  • Brand Recognition: Established names attract more public and institutional trust but also more attackers.
  • Investor Backing: Backing from reputable VCs or security firms adds an additional layer of due diligence assurance.
  • Security Partnerships: Ongoing engagements (monitoring, advisory roles) with reputable security firms with a proven track record enhance perceived and real security postures.
  • Negative Media Presence: Involvement in legal, regulatory, or ethical controversies flags potential systemic risk.
  • Team Screening: Founders and leadership are screened for criminal records, fraud allegations, and controversial affiliations.

3. Risk Scoring Model

3.1 Weighting of Risk Factors

Risk Factor Weight
Smart Contract Security 60%
Codebase & Complexity 13%
Protocol Governance 6%
Liquidity & TVL Exposure 6%
Historical Incidents 5%
PR & Reputation 10%
Total Weighted Score 100%

Each sub-factor is scored from 1–10 based on the expert’s qualitative assessment, with:

  • 7–10: Low risk
  • 4–6: Medium risk
  • 1–3: High risk

The total weighted score is calculated as:

Risk Score = Σi=1n (Risk Factor Scorei × Weighti)

3.2 Risk Tier Classification

Score Range Risk Tier Coverage Eligibility
9 – 10 Low Risk Eligible for minimal premium (≈ 0.5–1%)
7 – 8.99 Acceptable Risk Eligible for coverage
< 7 High Risk Most likely ineligible for coverage. These will be studied on a case-by-case basis.

Comparisons are made with other providers like Nexus Mutual to benchmark relative risk and pricing, especially for well-known projects already insured.

4. Premium Calculation

RAMM: Risk-Adjusted Market Maker

The final pricing is dynamically determined by Safura’s on-chain RAMM mechanism:

  • Premiums are adjusted in real time based on demand, available coverage capital, and cumulative risk exposure across the ecosystem.
  • RAMM helps maintain solvency while ensuring competitive pricing.

5. Role of Expert Evaluators

Each risk assessment is conducted by a senior security researcher from AuditOne, leveraging years of industry experience. Final coverage recommendations also include a subjective summary, which will try to answer the following question:

“Would you recommend coverage for this project based on the assessment and industry context?”

These insights support DAO decisions and RAMM fine-tuning and serve as additional due diligence records.

6. Conclusion

The Safura Risk Evaluation Framework blends rigorous technical assessment, economic risk modeling, and decentralized governance to deliver credible, transparent protection in Web3. By combining expert evaluations with adaptive pricing via RAMM, Safura protects users and protocols while preserving capital efficiency.

Interested in Coverage?

Contact us at hello(at)safura.io or please fill out the attached form, and our team will get back to you shortly: https://www.safura.io/coverage-request

Get exclusive content
right in your inbox.

No spam. Only the good stuff.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.