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.


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 20% of the protocol fees (in stablecoin) by reporting an incident. The users are incentivized to act fast and competitively to become the first reporter or simply "reporter". The first reporter needs to stake at least 250 NPM tokens while other reporters can stake any amount of NPM tokens.
To encourage competition and fast reporting, the protocol rewards the first reporter with 20% of the total platform fees. To discourage malicious actors, the platform will burn if the majority disagree with the incident. If this happens, the first user who reported on the other side will get the 20% reward instead.
As soon as the first report is submitted, the cover contract now opens up for governance and a week-long reporting period begins. Other witnesses can also participate in the governance system by submitting an incident report of their own.
The people who disagree about the reported incident can also stake NPM tokens and report against 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.
During the reporting period, users can stake their NPMs to vote. At the end of the reporting period, the side with the majority gets 75% of the minority's stake. The remaining 25% 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 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.
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 DAO. 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) and taking their time to evaluate how to best mitigate the ongoing attack.
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-based protocol like Neptune Mutual will face and therefore must prepare against numerous risks and attack models. Dishonest 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 attackers can submit a large enough NPM stake to turn the tables in their favor. Since there isn't any more time left for other governance participants to compete against them, the attackers will almost always win.
Neptune Mutual defends against this type of attack using a manual resolution process. However, a governance agent can still mistakenly resolve an active reporting which sets the results in the attacker's favor. To avoid this situation, the claim period begins only after 24 hours of resolution. The protocol admins can use the 24-hour wait window to override and render such decisions useless.
Always refer to the Protocol Fee document for the latest information since the fees are configurable and can change.
Last modified 1mo ago