We get asked a lot about how we do our Risk Assessments, and how that results in our security score and rating. Whilst we are not auditors, the process is very similar.
We take into account a lot of different aspects, not just the code, but also the team, community and ecosystems that the protocols are based in.
For example, it is hard to give a high-security rating to a project that is closed-source with an anonymous team.
A Security Rating from 1 to 5 stars will be assigned to each protocol in order to measure the risk associated with it. A higher Security Rating means the protocol is more secure and the likelihood of an occurrence of a hack, bug or exploit or the severity of such an event is low.
As we refine this model and work with auditor partners, we can fine-tune this assessment and premium calculation to be as inclusive as possible. Our assessments may not always align with public perception, however, we are extremely thorough in our research.
Risk assessments are also quite dynamic, we update them regularly following updates to the projects, wider ecosystems, and of course recent hacks on both the protocols and other similar protocols.
The Security Rating is calculated based on 5 factors with weights stated below:
1. Project Implementation (10%)
- Project nature & technical difficulties
- Roadmap and future changes
- Back-end chain: some chains are seen as more reliable than others. This may be coincidental, but certain chains have had many more attacks than others.
- Is it a layer 1, 2, or 3 project
2. Project Operation (15%)
- Project age… the longer the better
- Operation history… including development and time the team has been working together on other projects
- TVL… typically we require a minimum of $10m
- Existing insurance coverage
3. Team Qualification (5%)
- Team anonymity
- Team experience especially in programming
- Operations and management
4. Audit (40%)
- Transparency and scope
- Findings and vulnerabilities
- Trust score
- Frequency and updates
- Number of audits, and by how many different auditors
- Quality of audit… Again this may be coincidental, but some auditing firms have a higher number of hacks after their audits than others.
5. Code Quality (30%)
- Is it Open-sourced?
- Is there a Bug bounty program?
- Are there issues raised on Github or by the community?
- Is there good Documentation?
- Has there been regular Testing?
- Readability of code
- Architecture of code
- Oracle, oracles used, and how they are used are factors
- Layer-2 solution adoption
- Integrations with other ecosystems and protocols
- Access control management
- Security administration
- Do they have Multi-signature?
As you can see, there are many factors that go into one of our risk assessments. This is to keep our users as safe as possible, as well as provide accurate insurance premiums.
Not all projects that we look at are accepted. A lot of the time however we can work with them to improve some aspects they may not have passed. Other times we may ask them to assume some of the risk themselves by staking funds against their listing on our app, therefore spreading the risk between us and them.
About InsurAce.io
InsurAce.io is a decentralized multi-chain insurance protocol, to empower the risk protection infrastructure for the DeFi community. InsurAce.io offers portfolio-based insurance products with optimized pricing models to substantially lower the cost; launches insurance investment functions with flexible underwriting mining programs to create sustainable returns for the participants; and provides coverage for cross-chain DeFi projects to benefit the whole ecosystem.
At the time of writing, InsurAce.io has provided coverage to 80+ protocols, safeguarding over $110M DeFi assets on 10+ public chains.
InsurAce.io is backed by DeFiance Capital, Parafi Capital, Alameda Research, Hashkey group, Huobi DeFiLabs, Hashed, IOSG, Signum Capital, LongHash Ventures and a dozen of other top funds.
Join InsurAce.io community:
Website | Twitter | Telegram | LinkedIn | Announcements | Medium
