Product analysis · Native Protocol Cover: for teams

The team buys,
users are covered.

In plain words

For protocol teams, not retail: the team buys one cover for its users, up to $25M. Pays on exploits and defined economic failures, claim via team post-mortem. Trap doors: own admin actions causing loss are excluded, and the payout must reach the users.

Native Protocol Cover is the builder product in the Nexus lineup: a protocol team (DPTM) buys one cover that protects the protocol TVL, or a portion of it, up to $25M per the documentation. Users buy nothing and hold nothing; the team files the claim with a technical post-mortem. This analysis reads Part A of the cover terms and maps where the protection reaches and where it stops. Facts, not advice.

63/100 Limited

Structurally the most interesting Nexus product for builders: one purchase covers all users, proof of loss switches from per-wallet signatures to a team post-mortem, and non-EVM deployments can be included, which retail Protocol Cover excludes. The limits are equally structural: payout remains a discretionary assessor vote, losses caused by the team using its own admin controls are excluded (a real tension in incident response), the recovery must be passed to users or the cover is void, and pricing plus annex scope are bespoke and not public. No individually documented Part A payout was verifiable in public sources.

Data confidence: medium · Assessment as of 2026-07-16 · Methodology: Assecura Score

How to read this page: where each value comes from

On-chain Read from contracts, verifiable by anyone at any time.
Contract doc From a binding written document, off-chain but checkable.
Provider claim Stated by the provider, off-chain: a matter of trust.
Third party From a third-party source, off-chain: a matter of trust.
Our assessment Our judgement under the Assecura methodology.

Only on-chain values are verifiable without trusting anyone. Everything off-chain, including binding documents, ultimately relies on trust in the source.

Profile

Provider Nexus Mutual (see provider profile for legal nature, claims, capital) Our assessment
Product Native Protocol Cover: Part A of the Protocol Cover Terms (dedicated wording read from IPFS) Contract doc
Buyer Designated Protocol Team Member (DPTM) only. Claims by anyone else render the cover invalid (Part A) Contract doc
Who is protected The protocol users: cover bought without user knowledge, or recovery not intended for the users, is void (clause 10.12) Contract doc
Maximum coverage Up to $25M of the protocol TVL or a portion thereof (per documentation); sub-limits per covered event possible via annex Provider claim
Chains Non-EVM deployments can be in scope under Part A (clause 10.1.1): a genuine differentiator vs. retail Protocol Cover Contract doc
Deductible / waiting period 5% deductible, 14-day cool-down, 35-day grace period, payout redemption within 30 days (as in the wording; annex can adjust) Contract doc
How to buy Not listed in the app: bespoke engagement via the Nexus team (contact form), terms fixed in a per-deal annex Provider claim

The structural trade: One purchase, all users covered, and the proof of loss switches from per-wallet cryptographic evidence to a team post-mortem with transaction references: far more practical after a protocol-wide exploit. In exchange, the team accepts two clauses with teeth. Clause 10.11: if the team uses its own admin controls, including pausing functions, and that leads to loss of user funds, the loss is excluded, which sits uncomfortably against real incident response. Clause 10.12: the recovery must be intended for the users; a team keeping the payout voids the cover.

What is covered Contract doc

Part A applied. The covered events match the retail Protocol Cover (same definitions, same thresholds); what changes is who buys, how loss is proven, and two team-specific exclusions. The annex can additionally carve out covered events per deal.

Real-risk fit

Main risk: Smart contract exploit of the protocol covered

The single risk most likely to hurt here is inside the cover.

4 covered 2 conditional 5 excluded ringed = main risk
Does it fit you?

Pick what you actually want protection from; the list below highlights your answer. Runs in your browser only, nothing is sent.

Even "covered" is not a payment guarantee: every claim is decided by the mutual's members (claims assessors). A risk not listed here is most likely not part of the wording at all. No advice.

Pick your risks above and only those appear here, with the verdict: covered or not.

Conditions attached Contract doc

Proof of loss Part A replaces per-wallet cryptographic evidence with a detailed post-mortem: technical cause, evidence of fund extraction, references to the relevant transactions
Loss valuation At the time of loss, minus reimbursements, at coingecko.com rates; economic events over a 2-hour window
Recoveries / subrogation Recovery rights are assigned to the Terrapin International Foundation within 20 days of payout; no double recovery
Material change in risk Nexus can deny claims if the team materially changed the risk profile within its own control (clause 17)
Who can buy Nexus membership (KYC) required; the buyer must be an active contributor to the protocol (DPTM definition)

Who decides on claims Provider claim

Same decision machinery as every Nexus claim: the three-member Claims Committee reviews, votes (2 of 3), 72-hour voting window, 24-hour cool-down, re-filing on denial. What differs is the evidence: the committee reviews the team post-mortem and the on-chain history of the protocol instead of per-wallet proofs. The mutual has paid protocol-exploit claims under the retail wording (CREAM, Rari, Euler); an individually documented payout under Part A specifically was not verifiable in public sources.

Assecura Score Our assessment

A structured assessment across seven categories, 0 to 100 points in total. The score is an opinion based on the sources below, not a probability of payout and not a guarantee.

Score perspective: the buyer of this product is a protocol team, not a retail user. It is scored on the builder rubric: team criteria such as scope control, user outcome (does the payout reach the users?) and transparency to users, instead of the retail categories. The rubric assumes the team buys protection for its users, the most common goal; if your goal differs (e.g. a pure treasury backstop), the category notes say how to read the score for your case. Not 1:1 comparable with retail covers.

Coverage clarity & scope control 13/20

The event definitions and thresholds are as precise as the retail wording, Part A itself is short and readable, and the team can shape its scope (chains, sub-limits) in the annex. Deductions: that same private annex can carve out covered events, and the 10.11 admin-action boundary is genuinely fuzzy in an incident.

Capital & payout capacity 15/20

Same shared pool as the provider profile, on-chain verifiable in real time, with the MCR ratio as solvency yardstick. A $25M native cover is a meaningful single point of accumulation against that pool.

Claims process & incident fit 9/15

Documented committee process and paid precedents under the retail wording; the post-mortem evidence path is what a team actually needs after a protocol-wide exploit. Deductions: no public Part A payout precedent, and the decisive boundary questions (10.11) are untested.

User outcome 11/15

The builder question: does the payout reach the protocol users? Clause 10.12 answers it structurally: the recovery must be intended for the users, otherwise the cover is void; the team is a trustee, not the owner. Deduction: how distribution works and who verifies it in practice is untested (see open questions).

Governance & conflicts (inherited) 6/10

Provider governance unchanged: member votes, Advisory Board override powers, delegation concentration.

Legal enforceability (inherited) 3/10

Discretionary cover, no enforceable claim: identical to the provider profile. For teams the 10.12 void condition adds a further way to lose the cover entirely.

Transparency to users 6/10

The full wording is public on IPFS and the claims machinery is documented: users CAN read what native cover promises. Deductions: the annex, pricing and the list of teams holding native cover are private, so a user cannot verify whether their protocol actually has one and what it covers.

Total 63/100 · Limited

Red flags Our assessment

01

Payout remains discretionary: the provider-level warning applies in full, now with a $25M-scale decision resting on a 3-person committee vote.

02

Clause 10.11 excludes losses caused by the team using its own admin controls, including pausing. In a live exploit, the line between the attacker damage and the response damage decides the claim, and it has never been tested.

03

Clause 10.12 voids the cover if the recovery is not intended for the users: the team is a trustee of the payout, not its owner.

04

The effective protection lives in a private annex (carved-out events, chains, sub-limits). The public wording alone does not tell a user what their protocol team actually bought.

05

No public Part A payout precedent, no public pricing, no public list of teams holding native cover: the product is real per the wording, but its market is invisible from outside.

06

One shared capital pool backs all Nexus products: a large native cover both depends on that pool and, if claimed, drains it for everyone else.

Open questions Our assessment

Points this analysis could not verify. Anyone buying significant cover should clarify these first.

Sources

This analysis is free, for teams and their users alike. If it saved you work, the nicest thank-you is passing it on.

Share on X →
0x6f18218A87CFb169EB40D301D4a5Df7b5d24145F

Analysis as of 2026-07-16. Not affiliated with Native Protocol Cover: for teams. Informational only, no legal, investment or insurance advice.