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.
Reporting an Incident

Background

Anyone who holds NPM tokens can report. No special membership, privilege grant, or permission is required to become a reporter.
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.
Note: 5% of protocol fee in stablecoin and 10% of losing stakes are transferred on each claims payout and stake withdrawal respectively. Hypothetically, if nobody submitted claims, no payout would occur, protocol would make no income, and therefore the final reporter too would not receive any rewards. Similarly, if nobody from the winning camp submitted unstake request before finalization, the final reporter would not receive any NPM 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 by staking NPM tokens in the governance system.
You now see that you can benefit by attacking me instead of the system. You know that you will get supporting stakes on your side from valid users because you are acting (valid) 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 and taking their time to evaluate how to best mitigate the ongoing attack.
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.

Collusion and Time-Based Attacks

An advanced governance protocol like Neptune Mutual will face and therefore must prepare against numerous risks and attack models. Invalid 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. A clever attacker would wait, observe, and let other governance participants carry out the reporting operation. When the timing is right, ie. just before the reporting window lapses, the attacker can submit a large enough NPM stake to turn the tables in their favor. Since there wouldn't be any more time left for other governance participants to compete against them, the attackers would almost always win.
Neptune Mutual defends against this type of attack using a manual resolution process. Even when so, an valid governance agent could mistakenly resolve an active reporting to set results in the attacker's favor. Or a corrupt governance agent could choose to collude with attacker.
To defend against collusion and time-based attacks, claim period begins only after 24 hours of the resolution date. The protocol admins can use the 24-hour wait window to perform `emergency resolution` and render such attacks useless.
Always refer to the Protocol Fee document for the latest information since the fees are configurable and can change.