# Sicherheits- und Transparenzregeln

## Unveränderliche Zusagen

### BDAGBurnVault

- Öffentliche, freiwillige Einzahlung als normale native BDAG-Übertragung oder
  über `burn(bytes32 burnReference)`.
- Jeder nicht ausdrücklich dokumentierte Funktionsaufruf schlägt fehl.
- Nullwertige Aufrufe schlagen fehl.
- Keine Adresse erhält Sonderrechte.
- Keine Wallet-Freigabe, kein `transferFrom` und kein automatischer Einzug.
- Es existiert kein Codepfad für Auszahlung, externe Calls, Deployment anderer
  Contracts, Upgrades oder Selbstzerstörung.
- Die optionale Referenz ist untrusted Metadaten und keine Autorisierung.
- Eine erzwungene Wertübertragung kann den Kontostand ohne Vault-Event erhöhen;
  Bilanzdifferenzen dürfen deshalb nie als eindeutiger Burn-Beleg dienen.

### ChainpulsEvidenceAnchor

- Nur die bei Deployment gesetzte Publisher-Adresse darf neue Releases ankern.
- Der Publisher kann nicht ausgetauscht werden.
- Ein Release-Hash kann nur einmal eingetragen werden.
- Bereits veröffentlichte Events und Mapping-Einträge können nicht entfernt werden.
- Direkte ETH-Übertragungen und unbekannte Aufrufe schlagen fehl.

## Transparenzanforderungen

Vor dem ersten produktiven Burn müssen öffentlich zugänglich sein:

- beide vollständigen Solidity-Quelldateien,
- Compiler-Version und Optimizer-Einstellungen,
- BDAG Creation- und Runtime-Bytecode-Hashes,
- vollständiger Referenz-Block-Hash des ausgewählten 1404-Branches,
- BDAG-Vertragsadresse und Deployment-Transaktion,
- Ethereum-Ankeradresse, Publisher-Adresse und Ankertransaktion,
- die bytegenaue `PUBLICATION.json` und ihr auf Ethereum verankerter SHA-256,
- das `RELEASE-MANIFEST.json`, `SHA256SUMS`, der Source-Archiv-Hash und das
  maschinenlesbare Prüfprotokoll,
- klarer Hinweis, dass native Coins gesperrt werden, nicht ein protokollweiter
  `totalSupply`-Wert verändert wird.

## Vor produktiver Nutzung offen

- Unabhängiges Smart-Contract-Audit.
- Frischer Preflight der ausgewählten `engineering-lineage` über RMS ChainPulse,
  WelshDAG und den Engineering-Explorer.
- Zwei öffentliche RPCs und der Engineering-Explorer mit identischem
  historischen Branch-Fingerprint.
- Festlegung der Ethereum-Publisher-Adresse, vorzugsweise Multisig.
- Öffentliche Source-Ablage und bestehender Chainpuls-Website-Zugang.
- Verifizierter Kleinbetragstest aus einer ausdrücklich dafür bestimmten
  Community-Test-Wallet.

## Regeln der öffentlichen Burn-Oberfläche

- Vor jeder Signatur müssen Vertrag, Betrag, Chain ID und Branch-Fingerprint
  sichtbar und erfolgreich geprüft sein.
- Die Seite darf niemals Seeds, Private Keys oder Wallet-Passwörter verlangen.
- Sie darf erst nach einer bewussten Wallet-Verbindung Kontozugriff anfragen.
- Sie muss den vollständigen historischen Referenzhash über den im Wallet
  aktiven RPC prüfen, weil Chain ID 1404 allein nicht genügt.
- Sie muss den vollständigen Runtime-Bytecode des Vaults bytegenau vergleichen.
- Direkte Burns verwenden leere Calldata; unbekannte Daten dürfen nicht gesendet
  werden.
- Erfolg darf nur nach bestätigter Transaktion und passendem
  `NativeBDAGPermanentlyLocked`-Event angezeigt werden.
- Kein Webseitenbetreiber und keine Multisig besitzt einen Auszahlungsweg aus
  dem Vault.

## Lieferkette

- Der Release verwendet nur fest gepinnte Entwicklungsabhängigkeiten.
- Installationsskripte fremder Pakete werden mit `npm ci --ignore-scripts`
  deaktiviert.
- Die Test-EVM ist ausschließlich ein Offline-Entwicklungswerkzeug und wird
  weder auf der Website noch in einem Contract bereitgestellt.
- Die veröffentlichte Website und die Contracts haben keine
  Produktionsabhängigkeiten. `npm audit --omit=dev --audit-level=high` muss ohne
  Befund enden. Befunde in lokalen Entwicklungswerkzeugen werden einzeln mit
  Reichweite und Mitigation im Prüfbericht dokumentiert; sie dürfen nie in
  Website- oder Contract-Laufzeit gelangen.
- Solidity-Quellhashes und Compiler-Einstellungen sind über die angehängten
  IPFS-Metadaten zusätzlich an den Bytecode gebunden.
- Der Compiler ist auf `evmVersion: london` festgelegt. Beide ausgewählten
  BlockDAG-RPCs müssen den vollständigen Deployment-Bytecode mit
  `eth_estimateGas` ausführen können; ein Opcode-Kompatibilitätsfehler sperrt
  die Signatur.

## Meldung von Schwachstellen

Keine sensiblen Details, Seeds oder Private Keys öffentlich melden. Bis ein
offizieller Chainpuls-Sicherheitskontakt veröffentlicht ist, darf die Seite
keinen erfundenen Kontakt anzeigen.