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.
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.
How to read this page: where each value comes from
Only on-chain values are verifiable without trusting anyone. Everything off-chain, including binding documents, ultimately relies on trust in the source.
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.
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.
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.
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.
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.
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.
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.
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.
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).
Provider governance unchanged: member votes, Advisory Board override powers, delegation concentration.
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.
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.
Payout remains discretionary: the provider-level warning applies in full, now with a $25M-scale decision resting on a 3-person committee vote.
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.
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.
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.
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.
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.
Points this analysis could not verify. Anyone buying significant cover should clarify these first.
This analysis is free, for teams and their users alike. If it saved you work, the nicest thank-you is passing it on.
0x6f18218A87CFb169EB40D301D4a5Df7b5d24145FAnalysis as of 2026-07-16. Not affiliated with Native Protocol Cover: for teams. Informational only, no legal, investment or insurance advice.