Das Team kauft ein Cover für alle, die die gelisteten Contracts nutzen. Es zahlt bei einem Hack genau dieser Contracts, abzüglich 5% der Cover-Summe, und die Auszahlung muss an die Nutzer weitergegeben werden, sonst ist das Cover nichtig.
Teller ist ein Lending-Protokoll rund um ein offenes Orderbuch-Modell, bei dem Kreditgeber eigene Kriterien setzen und Kapital gezielt an Märkte binden, statt sich auf einen einzigen gepoolten Zins zu verlassen. Nexus listet dafür ein Native Protocol Cover: der Produkttyp, bei dem das Team ein Cover kauft und seine Nutzer die geschützte Partei sind, mit einem Wording, das das Team zur Weitergabe einer Auszahlung verpflichtet. Das ist derzeit das einzige aktive Listing dieses Typs auf Nexus. Sein Annex ist der präziseste im ganzen Set: Er benennt jeden gedeckten Contract einzeln und pinnt sie auf einen bestimmten GitHub-Commit. Diese Analyse liest diesen Annex und prüft die Passung. Fakten, keine Beratung.
Für wen: Das Teller-Team, zum Schutz seiner NUTZER (Kreditgeber und -nehmer auf den gedeckten Contracts) vor einem Smart-Contract-Versagen
Die stärkste Struktur für Nutzer in der ganzen Team-Familie, und die mit den schärfsten Kanten. Zwei Dinge heben sie ab. Erstens leistet das Basis-Wording, was kein Annex kann: Klausel 10.12 macht die Auszahlung zum Eigentum der Nutzer, ein Team, das sie behält, macht das Cover nichtig, und der Schadennachweis wechselt von Wallet-Signaturen zum Team-Post-Mortem, also zu dem, was nach einem Exploit tatsächlich passiert. Zweitens ist der Annex ungewöhnlich streng: Er listet jeden gedeckten Contract namentlich, pinnt die gedeckte Version auf den GitHub-Commit 38c87ae und stellt fest, dass das Cover weder teilweise noch ganz auf einen Contract außerhalb dieser Liste angewendet werden kann. Das ist überprüfbarer Scope, und das ist selten. Dieselbe Strenge ist das Risiko. Ein gepinnter Commit altert: Jeder Contract, der danach deployed oder aktualisiert wurde, und jeder Markt- oder Peripherie-Contract, der nicht auf der Liste steht, liegt außerhalb des Covers, und ein Lending-Protokoll ist ein bewegliches Ziel. Dazu Klausel 10.11, die Verluste ausschließt, die das Team durch eigene Admin-Rechte verursacht, inklusive Pausieren, und man hat ein Cover, das im sauberen Fall hervorragend ist (ein Bug in einem gelisteten Contract in der gepinnten Version) und im unsauberen dünn (ein Vorfall über neueren Code, oder einer, bei dem das Team eingreift, um Schaden zu begrenzen). Mit fixen 4,05% pro Jahr und 5% Selbstbehalt ist es zudem das teuerste der von uns analysierten nutzer-schützenden Listings, was zur Gefahr passt, aber eine bewusste Entscheidung sein sollte.
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.
Lese die Chain…
Ein gepinnter Commit ist die beste und zugleich sprödeste Scope-Definition, die es gibt: Die meisten Cover-Wordings beschreiben das gedeckte System in Prosa, was nach einem Vorfall Auslegungsspielraum lässt. Dieser Annex macht das Gegenteil: Er benennt neun Contracts, fixiert ihre gedeckte Version auf einen einzigen Commit-Hash und sagt ausdrücklich, dass das Cover weder teilweise noch ganz auf irgendetwas außerhalb dieser Liste ausgedehnt werden kann. Jeder kann den Scope an einem Nachmittag überprüfen, und nach einem Exploit gibt es wenig zu streiten, ob der betroffene Contract drin war. Der Preis dieser Präzision ist, dass sich das Protokoll weiterbewegt und der Commit nicht. Ein nach einem Upgrade neu deployter Contract, ein neuer Markt, ein Peripherie-Helfer, ein nach einem Audit ausgelieferter Fix: Jedes davon liegt außerhalb der gepinnten Version, solange der Annex nicht aktualisiert wird. Die Frage zu diesem Cover lautet also nie nur "gibt es Cover", sondern "entspricht der deployte Code noch dem Commit, gegen den das Cover geschrieben wurde".
Das Native-Protocol-Cover-Wording plus der Teller-Annex. Das gedeckte Ereignis ist ein Verlust von Nutzergeldern durch ein Versagen der gelisteten Contracts in der gepinnten Version, oberhalb eines Selbstbehalts von 5% der Cover-Summe.
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.
Gleicher Kernprozess wie bei jedem Nexus-Claim (Claims Committee, Assessor-Voting), aber der Typ Native Protocol Cover ändert den praktischen Teil: Der Schadennachweis ist ein Team-Post-Mortem mit Transaktions-Referenzen statt Wallet-Signaturen je Nutzer, was nach einem protokollweiten Exploit deutlich handhabbarer ist. Die gepinnte Contract-Liste verengt außerdem, worüber gestritten werden muss: Ob der versagende Contract im Scope war, ist hier fast eine Tatsachenfrage statt einer Auslegungsfrage. Kein Teller-Claim ist dokumentiert.
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 Prämie ist das Preisurteil der Bürgen: vor allem, wie wahrscheinlich ein Claim ist. Der Raccoon-Score misst, wie gut das Cover ist: Passung, Klarheit, Kapital, Claims. Wo beide auseinanderlaufen, lohnt der zweite Blick.
Die beste Scope-Definition im Set: neun einzeln benannte Contracts, die gedeckte Version auf einen Commit-Hash gepinnt, und die ausdrückliche Feststellung, dass nichts außerhalb der Liste gedeckt ist. Das kann jeder überprüfen. Abzug: Der gepinnte Commit altert mit jedem Upgrade, und der Annex sagt nicht, wie oder ob er nachgezogen wird.
Gleicher gemeinsamer Pool wie im Anbieterprofil, on-chain prüfbar, live oben. Zugelassen zum Zeichnen sind mehrere Pools, tatsächlich Kapazität tragen aber nur wenige. Maßgeblich ist die zweite Zahl: Eine Auszahlung hängt an den Managern, die wirklich gezeichnet haben, nicht an denen, die es dürften. Die Zahl der Zulassungen allein überzeichnet die Streuung.
Die beste Ernstfall-Tauglichkeit aller Team-Produkte hier: ein Cover für alle Nutzer, Schadennachweis per Post-Mortem statt Wallet-Signaturen, und ein Scope so präzise, dass die Drin-oder-draußen-Frage weitgehend Tatsachenfrage ist. Minus: ungetestet, und Klausel 10.11 bestraft genau das Eingreifen, das ein Vorfall verlangt.
Die Builder-Frage: Erreicht die Auszahlung die Nutzer des Protokolls? Klausel 10.12 beantwortet das strukturell, und das ist das einzige Listing im aktiven Team-Set, bei dem das gilt: Die Auszahlung muss für die Nutzer bestimmt sein, sonst ist das Cover nichtig, das Team ist also Treuhänder, nicht Eigentümer. Abzug: Wie die Verteilung praktisch läuft und wer sie prüft, ist ungetestet.
Nexus-Seite unverändert. Team-Seite: Dieselben Admin-Rechte, die 10.11 greifen lassen, braucht ein Team auch, um auf einen Angriff zu reagieren, das Wording setzt das Team also im denkbar schlechtesten Moment in einen Konflikt. Ob der Annex nach Upgrades aktuell gehalten wird, ist ebenso allein die Entscheidung des Teams.
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 Stärkste hier: Der Annex ist öffentlich, die gedeckten Contracts sind benannt, die Version ist ein überprüfbarer Commit, und die aktive Cover-Summe ist über die Nexus-API sichtbar. Reduziert, weil ein Nutzer weiter nicht sehen kann, ob der heute deployte Code dem gepinnten Commit entspricht, und genau diese Tatsache entscheidet, ob das Cover greift.
Klausel 10.11 schließt Verluste aus, die das Team durch eigene Admin-Rechte verursacht, inklusive Pausieren: Die übliche Incident Response kann den Verlust aus dem Cover schieben.
Die gedeckte Version ist auf Commit 38c87ae gepinnt: Danach aktualisierte oder deployte Contracts sind nicht gedeckt, solange der Annex nicht nachgezogen wird, und nichts zeigt Nutzern diesen Zustand.
Uneinbringliche Forderungen sind nicht gedeckt: Das Alltagsrisiko eines Lending-Protokolls, ein ausfallender Kreditnehmer oder nicht ausreichende Sicherheiten, ist Kreditrisiko und bleibt beim Kreditgeber.
Die Auszahlung bleibt Ermessenssache: Der Verlust wird per Assessor-Voting entschieden, die Warnung von der Anbieter-Ebene gilt unverändert.
Klausel 10.12 macht das Cover nichtig, wenn die Auszahlung nicht für die Nutzer bestimmt ist: starker Schutz für Nutzer, und ein realer Weg für ein Team, durch falschen Umgang mit der Auszahlung alles zu verlieren.
Das Teuerste der vier von uns analysierten mit fixen 4,05% pro Jahr plus 5% Selbstbehalt: der Preis dafür, aktives Smart-Contract-Risiko zu decken statt eines seltenen Tail-Ereignisses.
Punkte, die diese Analyse nicht verifizieren konnte. Wer nennenswertes Cover kauft, sollte sie vorher klären.
Analyse per 2026-07-19. Live-Zahlen aktualisieren sich alle 5 Minuten aus den Contracts. Keine Verbindung zu Native Protocol Cover: Teller. Nur zur Information, keine Rechts-, Anlage- oder Versicherungsberatung.