> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Bug Bounty > Das Programm von Intention zur koordinierten Offenlegung für Sicherheitsforscher – Umfang, Einstufung nach Schweregrad, Prämienrahmen, Verhaltensregeln und wie eine Feststellung eingereicht wird. Diese Seite ist die erste Anlaufstelle für Sicherheitsforscher. Das Programm von Intention zur koordinierten Offenlegung existiert, um Schwachstellen im Protokoll zu finden und zu beheben, bevor sie gegen die Menschen eingesetzt werden, die darauf handeln. Wir wollen, dass ernsthafte Forscher jede Schicht des Systems ansehen – vom deterministischen Kernel, der Orders ausführt, bis zu den Bridge-Verträgen, die Sicherheiten halten –, und wir sind bereit, entsprechend zu zahlen, wenn sie etwas Echtes finden. Das Programm wird derzeit formalisiert. Rahmen, Umfang, Schweregradmodell und Einreichungsprozess auf dieser Seite sind die Arbeitsstruktur, die mit dem ersten auditierten Mainnet-Release live geht. Konkrete Prämienbeträge sind als vorläufig gekennzeichnet, bis das Programm offiziell öffnet, aber die Struktur selbst steht, und **jede berechtigte Feststellung, die in der Zeit vor dem Start verantwortungsvoll offengelegt wird, wird nach dem Rahmen auf dieser Seite honoriert**. Die Prämienrahmen unten sind vorläufig und werden durch endgültige Werte ersetzt, wenn das Programm zusammen mit dem ersten auditierten Release startet. Umfang, Schweregradmodell und Einreichungsregeln sind nicht vorläufig – das sind die Regeln, die heute gelten.

Umfang

Im Umfang

Alles, womit ein Angreifer Nutzergelder stehlen, das Protokoll anhalten, finalisierten Zustand verfälschen oder die Eigenschaften brechen könnte, auf denen die Architektur beruht – reproduzierbare [Ausführung](/de/protocol/architecture/kernel), [Preise, die in dem Block zertifiziert sind, der sie verbraucht](/de/protocol/architecture/oracle), [Risiko, das atomar mit dem Matching läuft](/de/protocol/architecture/clearinghouse) oder [Zustandsänderungen, die sich auf die verursachende Transaktion zurückführen lassen](/de/protocol/architecture/state/model) –, fällt standardmäßig in den Umfang. Konkret: * **[IntentionKernel](/de/protocol/architecture/kernel)** – Ausführungssemantik, der geschlossene Befehlssatz, die Disziplin der Reihenfolgebildung, Byte-Determinismus. Alles, was die Ausführung eines Validators von der eines anderen abweichen lässt oder einer Transaktion eine Wirkung erlaubt, die in der Protokollspezifikation nicht vorgesehen ist. * **[IntentionBFT](/de/protocol/architecture/intention-bft)** – Sicherheit und Lebendigkeit des Konsenses, Leader-Wahl, kanonische Festlegungen auf die Reihenfolge, Signaturaggregation und der Migrationspfad zur Post-Quanten-Kryptografie. * **[Oracle und Preis-Quorum](/de/protocol/architecture/oracle)** – Einreichung von Beobachtungen, MAD-basierte Ausreißerabweisung, die Hülle des zertifizierten Preises und jeder Weg, auf dem eine Transaktion einen Preis liest, der nicht im selben Konsensereignis festgeschrieben wurde. * **[Cross-Chain-Bridge](/de/protocol/architecture/bridge)** – der von Validatoren attestierte Ein- und Auszahlungsablauf, die On-Chain-Bridge-Verträge auf den unterstützten Zielchains, das Threshold-Signing und die Schlüsselverwaltung sowie die operativen Kontrollen darum herum. * **Trading-Engine** – Matching, Mark-Preis-Bildung, Liquidationskaskaden, der Versicherungsfonds, ADL, die Funding-Abrechnung und die protokollnative Risiko-Pipeline. * **Öffentliche API-Schnittstellen** – REST- und WebSocket-Endpunkte, Authentifizierung, Signieren, Rate-Limits und jeder aus dem Internet erreichbare Codepfad. * **Validator-Software** – die Node-Binary, der Umgang mit Schlüsseln, der Peer-to-Peer-Transport und jedes Betriebswerkzeug, das ein Validator produktiv betreibt.

Außerhalb des Umfangs

Die folgenden Kategorien sind ausdrücklich vom Bounty-Programm ausgenommen. Meldungen zu diesen Zielen werden bestätigt, sind aber nicht prämienberechtigt. * Volumetrische Denial-of-Service-Angriffe gegen Validator-Infrastruktur oder öffentliche RPC-Endpunkte. Die Abwehr dagegen liegt in operativen Maßnahmen am Netzwerkrand, nicht in Protokoll-Patches. * Probleme in Software, Abhängigkeiten oder Diensten Dritter, die Intention nicht kontrolliert. * Feststellungen, die physischen Zugang zu Validator-Hardware, Social Engineering gegen Mitarbeiter von Intention Labs oder Supply-Chain-Angriffe auf intern genutzte Werkzeuge voraussetzen. * Self-XSS, Content-Spoofing ohne Sicherheitswirkung, fehlende Security-Header und andere Probleme mit geringer Wirkung auf der Marketingsite oder dieser Dokumentationssite. * Fehler in Software, die formell außer Dienst gestellt wurde und auf keinem Validator und in keinem Produktivdienst mehr läuft. * Theoretische Angriffe, die unwahrscheinliche Vorbedingungen erfordern (zum Beispiel eine Kompromittierung von 51 % des ehrlichen Stakes), ohne konkreten Weg, diese Vorbedingungen herbeizuführen.

Einstufung nach Schweregrad

Feststellungen werden auf einer vierstufigen Skala bewertet. Die Stufe ergibt sich aus der Kombination von **Wirkung** (was ein Angreifer erreichen kann) und **Wahrscheinlichkeit** (wie realistisch das Angriffsszenario ist, einschließlich nötiger Vorbedingungen und Ressourcen). Bei jeder Feststellung, die Nutzergelder berührt, ist das gefährdete Vermögen der ausschlaggebende Faktor für die Wirkung. | Stufe | Was sie bedeutet | Beispiele | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Kritisch** | Direkter Diebstahl, dauerhafter Verlust oder unbefugtes Minting von Nutzergeldern; Verletzung der Konsenssicherheit; Oracle-Fälschung, die sich persistieren lässt. | Ein Pfad durch den Kernel, über den eine Transaktion einem Konto etwas gutschreibt, wofür sie nicht gezahlt hat. Ein Fehler in der Signaturaggregation, der `$f$` Validatoren einen Block festschreiben lässt. Eine Bridge-Auszahlung, die Token auf der Zielchain ohne entsprechende Sperre mintet. | | **Hoch** | Verlust begrenzt auf eine Teilmenge der Nutzer oder einen bestimmten Markt; Stillstand der Konsens-Lebendigkeit; Griefing-Angriffe auf die Bridge; gezielte Zwangsliquidation. | Ein Pfad in der Liquidations-Engine, der sich gegen eine bestimmte Position auslösen lässt, ohne dass die Margin tatsächlich verletzt ist. Eine Bridge-Zustandsmaschine, die sich so verklemmen lässt, dass Auszahlungen für eine Chain nicht mehr verarbeitet werden. Rechteausweitung gegen Validator-Software unterhalb einer Konsenskompromittierung. | | **Mittel** | Kein direkter Mittelverlust, aber ein bedeutsamer Bruch von Protokollgarantien oder betrieblicher Integrität. | Unbefugtes Lesen von Zustand, der privat sein sollte. Eine Umgehung des Rate-Limits, die die Kosten des Chain-Betriebs spürbar erhöht. Ein Weg, den [Ausführungsstrom](/de/help/glossary) dazu zu bringen, Ereignisse auszugeben, die nicht zum finalisierten Zustand passen. | | **Niedrig** | Probleme mit begrenzter Wirkung, ohne Weg zu Mittelverlust oder Konsensstörung. | Wirkungslose Informationspreisgabe. Inkonsistente Fehlerantworten der öffentlichen API. Kleinere betriebliche Probleme ohne Ausnutzungspfad. | Über den Schweregrad entscheidet das Sicherheitsteam von Intention in Abstimmung mit dem Melder. Das Team begründet seine Einstufung zu jeder Feststellung schriftlich, und Melder können der Einstufung mit neuen Belegen widersprechen.

Prämienrahmen

Alle Prämien werden in **USDC** an eine vom Melder benannte Wallet-Adresse gezahlt. Ein nativer Token ist nicht beteiligt. | Stufe | Vorläufiger Prämienrahmen | | -------- | ------------------------------------ | | Kritisch | `TBD — high five to six figures` | | Hoch | `TBD — mid four to low five figures` | | Mittel | `TBD — low four figures` | | Niedrig | `TBD — symbolic / swag` | Die Rahmen sind Platzhalter, bis das Programm öffnet. Die endgültige Matrix wird auf dieser Seite veröffentlicht, sobald das erste auditierte Release ausgeliefert ist. Für jede Auszahlung gelten einige Regeln: * **Eine Prämie je eigenständiger Schwachstelle.** Erzeugt dieselbe Grundursache mehrere Feststellungen, fasst das Team sie zu einer einzigen Prämie im höchsten zutreffenden Schweregrad zusammen. * **Wer zuerst meldet, gewinnt.** Doppelmeldungen zu einem bereits in Triage befindlichen Problem werden bestätigt, aber nicht prämiert. * **Keine Prämie für bekannte Probleme.** Feststellungen, die Punkten aus dem internen Backlog des Sicherheitsteams entsprechen oder bereits von einem veröffentlichten Audit abgedeckt sind, sind nicht berechtigt. Das Team nennt in diesem Fall die entsprechende Referenz. * **Die Prämie setzt Kooperation voraus.** Öffentliche Offenlegung vor der Behebung, Ausnutzung über einen minimalen Proof of Concept hinaus oder jeder Schaden für Nutzer lässt den Anspruch entfallen.

Verhaltensregeln

Forscher, die am Programm teilnehmen, akzeptieren die folgenden Einschränkungen. Sie schützen Nutzer, sie schützen andere Forscher, und sie sorgen dafür, dass Intention das Programm dauerhaft betreiben kann. * **Keine Tests gegen die Produktion mit echten Nutzergeldern.** Nutzen Sie das öffentliche Testnet (sobald es live ist) oder einen privaten Fork. Lässt sich eine Feststellung nur in der Produktion reproduzieren, wenden Sie sich zuerst an `contact@intention.xyz` und führen Sie den Proof of Concept erst aus, wenn das Sicherheitsteam die Anfrage bestätigt hat. * **Kein Social Engineering.** Greifen Sie Mitarbeiter, Auftragnehmer, Validatoren oder Partner von Intention Labs nicht mit Phishing, Pretexting oder anderen sozialen Angriffen an. * **Keine volumetrischen Angriffe.** Kein Denial-of-Service durch Traffic-Fluten, keine Angriffe auf gemeinsam genutzte Infrastruktur, die Ressourcen erschöpfen. * **Nur ein minimaler Proof of Concept.** Zeigen Sie die Wirkung mit der kleinstmöglichen Handlung. Exfiltrieren Sie keine Nutzerdaten, bewegen Sie keine Mittel über den zum Nachweis nötigen Betrag hinaus, und bleiben Sie nach Abschluss des Proof of Concept nicht auf dem System. * **Keine öffentliche Offenlegung vor der Behebung.** Koordinierte Offenlegung ist der Standard. Das Sicherheitsteam stimmt mit Ihnen einen Zeitplan für die öffentliche Offenlegung ab, sobald der Fix ausgerollt ist. * **Geltendes Recht einhalten.** Die Safe-Harbor-Zusage unten gilt für gutgläubige Forschung nach diesen Regeln. Handlungen, die Computerstrafrecht in einer betroffenen Rechtsordnung verletzen, sind nicht geschützt.

Wie eingereicht wird

Ein vollständiger Bericht enthält: eine klare schriftliche Beschreibung der Schwachstelle, die betroffene Komponente und Version, eine Schritt-für-Schritt-Reproduktion, einen minimalen Proof of Concept (Code oder Transaktions-Hashes), die Wirkung, die Sie dem Problem zuschreiben, und etwaige Vorschläge zur Behebung. Je klarer der Bericht, desto schneller läuft die Triage. Senden Sie den Bericht per E-Mail an `contact@intention.xyz`, mit **Security** in der Betreffzeile. Ein PGP-Schlüssel für verschlüsselte Einreichungen wird mit dem Programmstart veröffentlicht – bis dahin senden Sie die erste Mail im Klartext, und das Team verlagert sensible Details beim ersten Austausch in einen verschlüsselten Kanal. Veröffentlichen Sie keinen Teil der Feststellung, bevor das Team sie bestätigt hat. Das Sicherheitsteam bestätigt jede Einreichung binnen zwei Werktagen. Die Bestätigung quittiert den Eingang, fragt fehlende Angaben nach und benennt einen Verantwortlichen für die Triage. Falls Sie nach 72 Stunden keine Bestätigung erhalten haben, senden Sie die Meldung bitte erneut. Bestätigte Feststellungen gehen in die Behebung. Das Sicherheitsteam arbeitet mit den zuständigen Entwicklungsverantwortlichen an einem Fix und informiert den Melder in regelmäßigem Takt über den Fortschritt. Das Team kann um Klarstellung oder zusätzliche Reproduktionsschritte bitten; Antworten kommen üblicherweise binnen eines Werktags. Sobald der Fix ausgerollt und das Problem nicht mehr ausnutzbar ist, wird die Prämie in USDC an die vom Melder angegebene Adresse gezahlt. Der Melder wird im Post-mortem und in jeder späteren Offenlegung mit seinem Einverständnis genannt. Vollständige Post-mortems werden veröffentlicht, wenn das die Nutzer keinem Restrisiko aussetzt. ## Safe Harbor Gutgläubige Sicherheitsforschung innerhalb der obigen Regeln wird von Intention Labs nicht rechtlich verfolgt. Die Safe-Harbor-Zusage deckt Forscher ab, die: * im Umfang und in den Verhaltensregeln dieser Seite bleiben * auf Nutzerdaten nicht über das zum Nachweis der Wirkung strikt Nötige hinaus zugreifen, sie nicht verändern und nicht zerstören * Feststellungen vertraulich melden und den Zeitplan der koordinierten Offenlegung einhalten * Feststellungen nicht zum eigenen Vorteil oder für Zwecke jenseits des Bounty-Programms ausnutzen Handlungen außerhalb dieser Regeln – zum Beispiel Nutzerguthaben zu exfiltrieren, eine Feststellung als Druckmittel zurückzuhalten oder vor der Behebung an die Öffentlichkeit zu gehen – sind nicht vom Safe Harbor gedeckt und können rechtliche Schritte nach sich ziehen, unabhängig von der Stichhaltigkeit der zugrunde liegenden Feststellung. Die konkrete Rechtsformulierung begleitet den formellen Programmstart und wird von dieser Seite aus verlinkt. Das Bounty-Programm ist noch nicht formell eröffnet. Melden Sie trotzdem alles, was Sie finden. Jede berechtigte Feststellung, die in der Zeit vor dem Start verantwortungsvoll offengelegt wird, wird nach dem Rahmen auf dieser Seite honoriert, und der Melder wird nach derselben Matrix ausgezahlt, sobald das Programm live geht.

Kontakt

**E-Mail:** `contact@intention.xyz`. Setzen Sie für eine Schwachstellenmeldung **Security** in die Betreffzeile; alles andere – Supportfragen, Presse, Partnerschaften oder Fragen zum Programm, die keine Meldungen sind – geht ohne diesen Betreff an dieselbe Adresse. Danke, dass Sie sich die Zeit nehmen, hinzusehen. Das Protokoll wird durch jeden ehrlichen Forscher besser, der es liest.