Understand the importance of reporting hacks and exploits. Discover the process of how incident reporting works and the rewards that can come with it.

Without a doubt, blockchain technology is inherently secure, however, the same cannot be said of the smart contracts built on top of it that offer so much opportunity.

Smart contract code imperfections and vulnerabilities expose projects to hacks and exploits that can shift a project’s trajectory and of course the balance of those holding the digital assets that have been hacked.

Most DeFi protocol and Web3 project developers work tirelessly to reinforce their project’s code, however it is challenging to close all possible loopholes, and there are a wide range of attack vectors for cyber criminals, of which smart contract code is just one. Together with their communities, project developers continuously identify and fix potentially exploitable bugs and glitches. However, cybercriminals and syndicates are motivated by the prospect of stealing huge sums of crypto, or other digital assets, from crypto exchanges and projects. As we see repeatedly in media headlines, the results of this can be truly devastating.

But, why should you concern yourself with this problem? How does it affect you? And what does it mean for the greater crypto community?

What Are the Incidents That Need to Be Reported?#

At Neptune Mutual, we refer to hack or exploit events as “incidents” if it is considered by the Neptunite community that they may have triggered the parameters of a cover pool policy in the Neptune Mutual marketplace. Simply put, incidents are hacks or exploits that cover pool policies are designed to protect against.

There are many types of hacks such as: governance attacks; economic attacks; front-end attacks, like DDoS attacks; and collision & timing attacks that take advantage of system hash rates and input speeds. Routing attacks abuse project vulnerabilities found in router software and/or authentication. Last but not least, there are phishing attacks which use deception and social engineering in order to mislead and trick individuals with false information.

Monetary losses are not the only thing that makes hacks and exploits dangerous. Projects can suffer significant reputational damage if their communities feel that they have not done enough before and after such incidents to protect them; a subject we discussed in depth in the article Bootstrapping Decentralized Cover Pool Liquidity.

There’s no doubt though that these incidents can affect users particularly severely, at times, destabilising or losing significant portions of their savings, hence why it is important to understand the essentials of how exposed digital assets are. The key messages are firstly to do your very best to avoid them, and secondly, and above all, to take actions to mitigate these risks so that you are protected if they occur.

As a way to mitigate such risks, DeFi, CeFi and Metaverse projects can create cover protocols to protect projects and exchanges.

Neptune Mutual is an on-chain parametric cover protocol designed to protect digital assets. By creating project specific dedicated cover pools, projects and exchanges can create cover policies for their users to purchase. In the event of an incident, the community decides whether an incident complies with all the parameters of the policy, thereby opening up the process of guaranteed claims payout to anyone with that specific policy.

A User-driven Solution#

The incident reporting process was tested by the Neptunite community when the Neptune Mutual testnet went live in March 2022. It is a community driven consensus-based solution to validating incidents. A number of mechanisms have been designed to drive honest voting behaviour and there is a backstop mechanism to safeguard against the unlikely risk of a 51% attack on the reporting system.

Users are encouraged to report hacks and exploits of projects on the Neptune Mutual platform as it is crucial that there is timely reporting and resolution of reported incidents. Reporting an incident is the first step to initialise the incident reporting process.

What Is an Incident Reporter?#

Anyone with sufficient NPM tokens can report hacks and exploits from within the Neptune Mutual application. The First Reporter (the first reporter to report an incident) and Candidate Reporter (the first reporter to dispute a reported incident) are required to stake at least 250 NPM tokens, or as configured by the cover creator.

The incident reporting feature gives potential reporters the following choices:

• Report an Incident.
  This option is given to the user if they want to be the First Reporter of a unique incident. There is only one First Reporter for every incident reported.
• Disagree with Reported Incident.
  If another user believes the First Reporter’s reported incident to be false or invalid in relation to the parameters specified by the cover pool, they can add a dispute. Like the First Reporter, being the first to dispute an incident makes you the only Candidate Reporter of the incident.
• Support an Incident.
  Reporters can support an incident if it’s already been reported. Any number of users can attest to the validity of a reported incident.
• Support a Dispute.
  Just as users can support a reported incident, reporters can also support a dispute. Any number of users can reject a reported incident.

After the duration of the reporting period, typically 7 days, there is a “cooling off” period of 24 hours before the incident is resolved either way.

Incident Reporters with the most votes become Valid Reporters because their votes determined the validity of the incident. As for the group with the least number of votes, they are then called Invalid Reporters.

How You Can Earn Rewards with Incident Reporting#

During the reporting period, users can stake their NPM tokens either to validate or refute a reported incident. Upon resolution, participants on the winning side collectively receive 60% of the invalid reporters’ staked tokens. Participants will earn pro-rata in relation to the number of tokens they staked.

30% of the invalid camp tokens are burned.

The remaining 10% of the invalid reporters’ staked tokens are allocated to the Final Reporter. The Final Reporter is either the First Reporter or the Candidate Reporter depending on whether the incident is validated or not. The 10% reward allocated to the Final report is substantial because it is important to incentivise users to be the first person to report or dispute an incident to ensure the system responds rapidly to events. In addition, if the Final Reporter is the First Reporter (and not the Candidate Reporter), this person will earn 5% of the cover pool protocol fees (in stablecoin) as a reward for being the first to report the incident.

If the Final Reporter is the Candidate Reporter, then this person will receive 10% of the invalid camp’s staked tokens as well as a pro-rata portion of the 60% invalid camp staked tokens, but will not receive any portion of the protocol fee in stablecoin.

All other valid reporters will earn a pro-rata portion of the 60% of tokens of the Invalid Reporters. In addition, all valid reporters will be credited with the NPM tokens they staked.

What happens when users report incidents that don’t conform to the parameters of the cover pool policy or insufficient evidence has been posted?

If users report incidents that don’t conform to the parameters of a cover pool policy they lose the NPM tokens they staked when reporting the incident.

Explore the step-by-step process of how you can report or dispute an incident on the Neptune Mutual platform in this video.

How Neptune Mutual Protects Policyholders from Consensus and Timing Attacks#

One example of a consensus attack is called a Sybil attack. These attacks are typically observed on networks or social media channels. Bad actors attempting to perform a Sybil attack make multiple pseudonymous identities (or wallets) to get an unfair advantage in the decision-making behind a consensus, usually to put the outcome in their favour for monetary gain, or to avoid loss. This kind of consensus attack is possible if the attacker/s can create an abundance of pseudonymous identities relatively cheaply.

A Sybil attack would be extremely difficult to achieve in the Neptune Mutual system because an attacker would have to spend a large amount to purchase sufficient NPM tokens to outvote the incident reporting community. Even if an attacker was willing to invest sufficient capital to mount such a threat, the attacker would not only have to wait for a week i.e. the duration of the resolution of the incident, but most importantly, the governance of the reporting process allows, under exceptional circumstances, for the reporting to be frozen to allow investigation of suspected malicious voting practises. If a Sybil attack was revealed to have taken place by the governance committee the attacker would risk losing all the NPM tokens staked in the attempted sybil reporting attack.

Another type of consensus attack is a 51% attack, or otherwise called, majority attack. The risk of 51% attacks is usually found in proof-of-work blockchains. These attacks intend to take control of the majority of the hash rate to cause service unavailability, double spending, service disruptions, amongst other things.

Although possible, a 51% attack of the Neptune Mutual project is extremely unlikely because it would be expensive to accumulate more than 50% of NPM tokens, and above all it is unlikely that sufficient tokens would be available for purchase, and finally the project team would be well placed to defend against this type of attack. Moreover, it is counterintuitive to exploit a project the attacker holds a majority stake of.

Timing attacks, in the form of pre-reporting and collusion and last block attacks are also risky and unfavourable to carry out. We’ll go further to explain how the risks of consensus and timing attacks are mitigated in a future blog.

Quick Summary#

• Incidents are hack or exploit events which reporters consider have triggered the parameters of a cover pool policy.
• Anyone with sufficient NPM tokens can report an incident, or vote on a reported incident.
• 60% of staked NPM tokens from the invalid reporters are rewarded to the winning group of valid reporters. 10% goes to the Final Reporter, and 30% of the invalid reporters’ tokens are burned.
• If the Final Reporter was the First Reporter, then this person gets 5% of the protocol fees from the reported incident, paid out in stablecoin.

Note: Neptune Mutual’s incident reporting and voting system requires the staking of NPM tokens and so shall be implemented following the public sale of NPM tokens. In addition to the reporting and voting utility of the NPM token, the Neptune Mutual team is working on developing other important utility functions of the NPM token, and for this reason it is expected that mainnet launch of the cover pool marketplace application will take place prior to the launch of the NPM token; more information will be released prior to mainnet about the voucher system that will be used for incident reporting and resolution.

Why Incident Reporting Matters#

Through the power of the Neptunite community, incidents can be assessed in relation to a much wider variety of parameters than a system limited to onchain data. When providing digital asset protection, it is important that cover creators have the flexibility to fine tune the parameters of the cover pool policy to meet the specific security risks relevant to their own community.

The incident reporting and voting mechanism has been designed with the same principles in mind as the rest of the marketplace, that is to say: maximise security, minimise risk, maximise scalability and maximise user experience.

We hope that you’ll join the Neptunite community and participate in reporting and voting on incidents, and spreading awareness about the benefits of making financial protection mainstream.