Incident Reporting

Reporting an incident is the first step to initialize a cover contract for governance. The reporting process has the following functionalities:

• Yes: Report an Incident (The first and only user to report an incident becomes the Incident Reporter or simply Reporter**)
• No: Disagree with the above Incident by Adding a Dispute (The first and only user who disputes the above incident becomes the Candidate Reporter**)
• Yes: Support the Incident by Adding an Attestation (Any number of users can vote to support the reported incident)
• No: Disagree with the above Incident by Adding a Refutation (Any number of users can vote to reject the reported incident)

** At the end of a week-long reporting period, whoever gets the majority support gets the reward. The other reporter's stake is forfeited.

Incident Date#

Please take note of the following key differences:

Event Date or Observed Date

The date and time the event took place in the real world. It is also referred to as the event date.

Incident Date

The incident date is the timestamp at which an event report is submitted. Only if the incident date falls within a policyholders coverage period and successfully resolved, will they receive a payout.

Warning#

Please thoroughly review the cover rules, cover exclusions, and standard exclusions before submitting this report. If the resolution does not go in your favour, you will lose your entire stake. You will only be able to unstake and receive your NPM if and only if the following conditions are met:

• Incident resolution is in your favor
• after the reporting period has ended

Background#

The first person who finds an incident to have occurred can earn 5% of the protocol fees (in stablecoin) by reporting an incident. Users are incentivized to act fast and competitively to become first reporter. The first reporter needs to stake at least 250 NPM tokens (or as specified by a cover creator) while supporters can stake any amount of NPM tokens.

To discourage bad actors, the platform forfeits all stakes of invalid reporters. To encourage competition and fast reporting, the protocol rewards the first reporter with 5% of the platform stablecoin earnings and additional 10% of the forfeited stakes. If a cover is resolved to have false reporting, the first user who disputed the reporting will get 10% of invalid stakes, no stablecoin rewards.

How Does Consensus Work?#

Consensus rules are triggered by someone adding a report--the first report. As soon as the first report is submitted, the cover in question opens up for governance and a week-long reporting period begins. Witnesses and/or supporters can also participate in the reporting by adding supporting stakes.

The people who disagree about a reported incident can stake NPM tokens and report against or refute the submitted incident report. The first person to dispute an already-reported incident is referred to as "candidate reporter". Just like the reporter, a candidate reporter needs to stake at least 250 NPM tokens or as configured by the cover creator.

During the reporting period, users can stake their NPMs to vote on any side they prefer. Upon resolution, participants on the winning side collectively receive 60% of invalid camp's stake, flat 10% stake is transferred to the final reporter, and the remaining 30% stake is burned.

Consensus Attacks#

Sybil Attacks#

Sybil attacks are observed on networks or services (such as social media) where bad actors can gain unfair advantage by creating multiple pseudonymous entries or identities (or wallets) and use that to obtain a favorable outcome. This kind of attack is possible if an attacker can produce numerous pseudonymous identities for cheap.

In Neptune Mutual

To perform Sybil attack on Neptune Mutual cover pool, an attacker needs to first generate multiple identities or wallets. Each of the wallets not only needs to individually hold NPM tokens but has to stake NPM tokens in the governance pool and wait for a week to witness a resolution. The achieved resolution must be in the favor of the attacker. Otherwise, the stake is forfeited.

Attacker's Dilemma

Imagine, you and me--we are both capable of being an attacker. Let's say, I chose to perform an attack by staking NPM tokens in the governance system.

You now see that you can benefit by attacking me instead of the system. You believe that you will get supporting stakes on your side from other honest users because you are acting honest yourself.

For me, you may or may not attack my attack (thereby defending the protocol) but I will always be fearful of conducting a Sybil attack because of the upfront capital requirement, the need to wait for a week to achieve resolution, and the possibility of losing all of my invested capital.

Summary

Sybil attacks are not possible in Neptune Mutual because an attacker has to spend a large upfront capital to purchase NPM tokens and has to wait for a week to get a favorable outcome. The risks outweigh benefits.

51% Attacks#

A 51% attack is a potential risk mainly seen in Proof of Work blockchains where bad actors take control of the majority of the hash rate and then cause service unavailability, selection of transaction inclusion, disruptions of services, double spending, etc.

The likelihood of 51% attack is highly dependent on the opportunity of economic benefit. It is also very likely that an attacker will instead choose to participate in securing the network if the economic benefit of doing so is higher than attacking the network.

In Neptune Mutual

The Neptune Mutual Protocol is a proof of stake platform. Before an attacker can perform 51% attack on the protocol, they will need to purchase 51% of the NPM tokens. This requires an attacker to invest a large upfront capital while bearing the risk of NPM tokens price drop. Unlike relatively low-hash or unsecured PoW networks, it is too expensive to perform a 51% against the Neptune Mutual platform.

There is also a massive risk of the governance committee pausing the protocol (or just the cover in question) or performing emergency resolution that can reverse the decision ignoring the amount staked.

Summary

A 51% attack, although possible, is highly unlikely because it is quite expensive to accumulate 51% of the NPM tokens (which may not even be available to purchase in the first place). An attacker would not have in their best financial interest to exploit a protocol which they hold majority stake of. If the price of NPM tokens drops, so does the attacker's portfolio. The Proof of Stake consensus incentivizes the token holders to protect the network from such situation.

Timing Attacks#

Pre-Reporting Attacks#

Neptune Mutual relies on the tokenholder community to report incidents. Prior to reporting an incident, a potential reporter is likely to buy a coverage first. The attackers may deplete the cover's liquidity pool by paying a tiny amount in policy premium since the result of the resolution is already known at this time. In addition to this, the incentive design of the Neptune Mutual protocol means that reporters will also get a commission on protocol fees.

Mitigation#

Coverage Lag

Neptune Mutual's coverage typically begins at UTC EOD the next day. If you purchased a policy on Monday, coverage will begin at midnight UTC on Tuesday. This is often referred to as the "coverage lag".

Coverage lag is a specified time period that can be set globally or on a per-cover basis to delay the start of coverage. The coverage of a policy begins at the EOD timestamp of the policy purchase date plus the coverage lag.

Blacklist

Blacklisted accounts are unable to claim their cxTokens. Cover managers can use the blacklist feature to prohibit an account from claiming their cover. This usually happens when we suspect a policyholder of being the attacker. After performing KYC, we may be able to lift the blacklist.

Collusion and Last Block Attacks#

Neptune Mutual, being a cutting-edge governance protocol, will have to deal with a wide range of threats and attack models. Malicious actors can collude to perform a timing attack or time-based attacks on Neptune Mutual.

The risk arises from the fact that there is a reporting window (of 7 days) during when governance participants come together and stake their tokens to support each camp. An intelligent attacker would observe the reporting process while it's being carried out by other members of the governance team, and then seize the opportunity at the last minute.

This attack's timing is critical, since the attacker may submit a high enough stake just before the reporting window expires, giving the attacker the upper hand in the last block. This attack would almost always work because other governance members wouldn't have time to fight back.

Corrupt Governance Agent

It is possible for an honest governance agent to set outcomes in favor of the attacker by unknowingly, accidentally, or mistakenly resolving an active report. Alternatively, a corrupt governance agent may collude together with the attacker to deplete the liquidity pool rapidly.

Mitigation#

Neptune Mutual defends against this type of attack using a manual resolution process.

The claim period begins only 24 hours after the resolution date to combat collusion and time-based attacks. Protocol administrators can utilize the 24-hour wait window to perform "emergency resolution", rendering such attacks completely ineffective.