Für Protokoll-Teams, nicht Retail: Das Team kauft ein Cover für seine Nutzer, bis $25M. Zahlt bei Exploits und definierten ökonomischen Fehlern, Claim per Team-Post-Mortem. Fallstricke: eigene Admin-Aktionen mit Verlustfolge sind ausgeschlossen, und die Auszahlung muss bei den Nutzern ankommen.
Native Protocol Cover ist das Builder-Produkt im Nexus-Sortiment: Ein Protokoll-Team (DPTM) kauft ein Cover, das die TVL des Protokolls oder einen Teil davon schützt, laut Doku bis $25M. Nutzer kaufen nichts und halten nichts; das Team reicht den Claim mit technischem Post-Mortem ein. Diese Analyse liest Part A des Cover-Wordings und kartiert, wohin der Schutz reicht und wo er endet. Fakten, keine Beratung.
Für wen: Protokoll-Teams, die ihre NUTZER gegen einen Exploit des eigenen Protokolls absichern
Strukturell das interessanteste Nexus-Produkt für Builder: Ein Kauf deckt alle Nutzer, der Schadennachweis wechselt von Wallet-Signaturen zum Team-Post-Mortem, und Non-EVM-Deployments können eingeschlossen werden, was das Retail-Protocol-Cover ausschließt. Die Grenzen sind ebenso strukturell: Die Auszahlung bleibt ein Ermessens-Vote der Assessoren, Verluste durch eigene Admin-Aktionen des Teams sind ausgeschlossen (ein echtes Spannungsfeld in der Incident Response), die Auszahlung muss an die Nutzer weitergereicht werden, sonst ist das Cover nichtig, und Preis plus Annex-Umfang sind bespoke und nicht öffentlich. Ein einzeln dokumentierter Part-A-Payout war in öffentlichen Quellen nicht verifizierbar.
Lesehilfe: Woher jeder Wert stammt
Nur On-Chain-Werte sind ohne Vertrauen in irgendjemanden nachprüfbar. Alles Off-Chain, auch verbindliche Dokumente, hängt am Ende am Vertrauen in die Quelle.
Der strukturelle Deal: Ein Kauf, alle Nutzer gedeckt, und der Schadennachweis wechselt von Wallet-Signaturen zum Team-Post-Mortem mit Transaktions-Referenzen: nach einem protokollweiten Exploit deutlich praktikabler. Im Gegenzug akzeptiert das Team zwei Klauseln mit Zähnen. Klausel 10.11: Nutzt das Team eigene Admin-Rechte, inklusive Pausieren von Funktionen, und führt das zu Nutzer-Verlusten, ist der Verlust ausgeschlossen, was in echter Incident Response unbequem werden kann. Klausel 10.12: Die Auszahlung muss für die Nutzer bestimmt sein; behält das Team sie, ist das Cover nichtig.
Part A angewandt. Die gedeckten Ereignisse entsprechen dem Retail-Protocol-Cover (gleiche Definitionen, gleiche Schwellen); was sich ändert, ist wer kauft, wie der Schaden bewiesen wird, und zwei team-spezifische Ausschlüsse. Der Annex kann je Abschluss zusätzlich Covered Events herausnehmen.
Wähle, wovor du wirklich Schutz willst; die Liste unten hebt deine Antwort hervor. Läuft nur in deinem Browser, nichts wird gesendet.
Auch "gedeckt" ist keine Zahlungsgarantie: Über jeden Claim entscheiden die Mitglieder der Mutual (Claims-Assessoren). Ein Risiko, das hier nicht gelistet ist, ist vermutlich gar nicht Teil des Wordings. Keine Beratung.
Wähle oben deine Risiken, dann erscheinen genau die hier, mit dem Urteil: gedeckt oder nicht.
Gleiche Entscheidungsmaschinerie wie bei jedem Nexus-Claim: Das dreiköpfige Claims Committee prüft, stimmt ab (2 von 3), 72 Stunden Voting, 24 Stunden Cool-down, Neueinreichung bei Ablehnung. Anders ist die Beweisführung: Das Komitee prüft das Team-Post-Mortem und die On-Chain-Historie des Protokolls statt Wallet-Nachweisen. Die Mutual hat Protokoll-Exploit-Claims unter dem Retail-Wording bezahlt (CREAM, Rari, Euler); ein einzeln dokumentierter Payout unter Part A war in öffentlichen Quellen nicht verifizierbar.
Eine strukturierte Einschätzung über sieben Kategorien, insgesamt 0 bis 100 Punkte. Der Score ist eine Meinung auf Basis der unten verlinkten Quellen, keine Auszahlungswahrscheinlichkeit und keine Garantie.
Hinweis: Dieses Produkt kauft ein Protokoll-Team, kein Endnutzer. Wir bewerten es deshalb mit unserer Team-Rubrik, die die Fragen eines Teams stellt. Die wichtigste davon: Kommt das Geld im Ernstfall wirklich bei den Nutzern an? Vergleiche diesen Score nur mit anderen Team-Produkten, nicht mit der Retail-Liste.
Die Ereignis-Definitionen und Schwellen sind so präzise wie im Retail-Wording, Part A selbst ist kurz und lesbar, und das Team kann seinen Scope (Chains, Sub-Limits) im Annex gestalten. Abzüge: Derselbe private Annex kann Covered Events herausnehmen, und die 10.11-Grenze zu Admin-Aktionen ist im Ernstfall wirklich unscharf.
Gleicher gemeinsamer Pool wie im Anbieterprofil, on-chain in Echtzeit prüfbar, mit der MCR-Quote als Solvenz-Maßstab. Ein $25M-Native-Cover ist ein spürbarer einzelner Kumulpunkt gegen diesen Pool.
Dokumentierter Komitee-Prozess und bezahlte Präzedenzfälle unterm Retail-Wording; der Post-Mortem-Beweisweg ist genau das, was ein Team nach einem protokollweiten Exploit braucht. Abzüge: kein öffentlicher Part-A-Präzedenzfall, und die entscheidenden Grenzfragen (10.11) sind ungetestet.
Die Builder-Frage: Erreicht die Auszahlung die Nutzer des Protokolls? Klausel 10.12 beantwortet das strukturell: Die Auszahlung muss für die Nutzer bestimmt sein, sonst ist das Cover nichtig; das Team ist Treuhänder, nicht Eigentümer. Abzug: Wie die Verteilung praktisch läuft und wer sie prüft, ist ungetestet (siehe offene Fragen).
Anbieter-Governance unverändert: Mitglieder-Votes, Advisory-Board-Eingriffsrechte, Delegations-Konzentration.
Discretionary Cover, kein einklagbarer Anspruch: identisch zum Anbieterprofil. Für Teams kommt mit 10.12 ein weiterer Weg hinzu, das Cover ganz zu verlieren.
Das volle Wording ist öffentlich auf IPFS, die Claims-Maschinerie dokumentiert: Nutzer KÖNNEN nachlesen, was Native Cover verspricht. Abzüge: Annex, Preis und die Liste der Teams mit Native Cover sind privat, ein Nutzer kann also nicht prüfen, ob sein Protokoll eines hat und was es deckt.
Die Auszahlung bleibt Ermessenssache: Die Warnung von der Anbieter-Ebene gilt voll, jetzt mit einer Entscheidung in $25M-Größenordnung bei einem 3-Personen-Komitee.
Klausel 10.11 schließt Verluste durch eigene Admin-Aktionen des Teams aus, inklusive Pausieren. Im laufenden Exploit entscheidet die Grenze zwischen Angreifer-Schaden und Reaktions-Schaden über den Claim, und sie wurde nie getestet.
Klausel 10.12 macht das Cover nichtig, wenn die Auszahlung nicht für die Nutzer bestimmt ist: Das Team ist Treuhänder der Auszahlung, nicht ihr Eigentümer.
Der effektive Schutz steht in einem privaten Annex (abgewählte Events, Chains, Sub-Limits). Das öffentliche Wording allein sagt einem Nutzer nicht, was sein Protokoll-Team tatsächlich gekauft hat.
Kein öffentlicher Part-A-Präzedenzfall, kein öffentlicher Preis, keine öffentliche Liste von Teams mit Native Cover: Das Produkt ist laut Wording real, aber sein Markt ist von außen unsichtbar.
Ein gemeinsamer Kapitalpool deckt alle Nexus-Produkte: Ein großes Native Cover hängt an diesem Pool und leert ihn im Claim-Fall zugleich für alle anderen.
Punkte, die diese Analyse nicht verifizieren konnte. Wer nennenswertes Cover kauft, sollte sie vorher klären.
Analyse per 2026-07-16. Keine Verbindung zu Native Protocol Cover: for teams. Nur zur Information, keine Rechts-, Anlage- oder Versicherungsberatung.