# Chainpuls BDAG Burn Vault Dieses Paket veröffentlicht einen freiwilligen Burn-Vault für native BDAG und einen unveränderlichen Nachweisvertrag für Ethereum Mainnet. ## Zweck - Jeder Nutzer entscheidet selbst, ob und wie viele eigene BDAG er dauerhaft sperrt. - Chainpuls kann keine Wallet öffnen, keine Freigabe anfordern und keine Coins automatisch einziehen. - Der Betreiber muss keine eigenen BDAG verbrennen. Das Vault-Deployment überträgt \`0 BDAG\`; lediglich Netzwerkgebühren fallen für den Bereitsteller an. - Das Paket ist unabhängig von Spielen oder anderen Produkten nutzbar. ## Was „Burn“ technisch bedeutet Native BDAG besitzen keine ERC-20-\`burn()\`-Funktion. Der \`BDAGBurnVault\` nimmt native BDAG an, enthält aber keinen Codepfad, um Wert wieder herauszusenden. Freiwillig eingezahlte Coins werden damit unter der veröffentlichten Vertragslogik dauerhaft unzugänglich und aus dem nutzbaren Umlauf genommen. Ein protokollweiter \`totalSupply\`-Zähler wird dadurch nicht automatisch verändert. Ein späterer Hard Fork oder Eingriff eines Chain-Betreibers kann durch keinen Smart Contract ausgeschlossen werden. Diese Grenze wird öffentlich dokumentiert und nicht als technische Unmöglichkeit verschwiegen. ## Öffentliche Einzahlungswege 1. Eine normale native BDAG-Überweisung mit leerer Calldata erzeugt einen allgemeinen Burn mit der Referenz \`bytes32(0)\`. 2. \`burn(bytes32 burnReference)\` ermöglicht optional eine öffentliche Zuordnung. Die Referenz ist untrusted Metadaten und keine Autorisierung oder Identitätsprüfung. Jeder erfolgreiche Vorgang erzeugt \`NativeBDAGPermanentlyLocked(sender, burnReference, amount, newLockedBalance)\`. Ein Kontostand kann auf EVM-Netzen unter besonderen Umständen auch ohne Receive-Aufruf steigen. Deshalb ist nur das passende Contract-Event ein eindeutiger Beleg für einen über den Vault ausgeführten Burn. ## Sicherheitsmodell Der Vault besitzt: - keinen Owner, Admin oder Multisig-Zugriff, - keine Auszahlung, keinen externen Call und keine Genehmigungslogik, - keine Upgrade-, Proxy-, Create- oder Selfdestruct-Funktion, - keinen veränderbaren Storage, - eine feste Chain-ID-Prüfung auf \`1404\`, - eine abweisende Fallback-Funktion für unbekannte Calldata. Die Burn-Adresse selbst ist absichtlich keine Multisig-Wallet. Jede Auszahlungsberechtigung würde einem permanenten Burn widersprechen. Der \`ChainpulsEvidenceAnchor\`: - kann nur auf Ethereum Mainnet, Chain ID \`1\`, bereitgestellt werden, - hat einen beim Deployment endgültig festgelegten Publisher, - kann bestehende Release-Hashes weder ändern noch löschen, - nimmt kein ETH an und kann kein ETH senden, - ist nicht upgradefähig. Der Publisher darf ausschließlich neue Dokumentationsnachweise hinzufügen. Er erhält keinen Zugriff auf BDAG im Vault. ## Auswahl des BlockDAG-Branches Chain ID \`1404\` identifiziert die gewünschte Historie nicht eindeutig. Die Beobachtung vom 13. September 2026 zeigt zwei divergierende Historien ab Block 316002. Für diesen Release ist ausschließlich die \`engineering-lineage\` ausgewählt: - Referenzblock: \`316002\` - Referenzhash: \`0xcd4d2568e9cba6725329e8cf6d96217ace7acb03d71d9b519c8b2560bb6bb781\` - Engineering-Explorer-Beleg: \`https://explorer.blockdag.engineering/api/v2/blocks/316002\` - erster RPC: \`https://rms-bdag-rpc.de/api/rpc-live\` - unabhängiger zweiter RPC: \`https://rpc.welshdag.trade\` Unmittelbar vor jeder Signatur müssen beide RPC-Endpunkte sowie der Engineering-Explorer erneut Chain ID, Referenzblock und vollständigen Hash bestätigen. \`rpc.blockdag.works\` und \`rpc.bdagscan.com\` gehören zur abweichenden Historie und sind für dieses Deployment ausdrücklich gesperrt. Die öffentliche Burn-Seite prüft zusätzlich den Referenzblock des im Nutzer-Wallet aktiven RPCs, bevor sie eine Transaktion vorbereitet. Release 0.5.0 wurde wegen seiner falschen Auswahl der BDAGScan-Historie verworfen und niemals bereitgestellt. Release 0.6.0 korrigiert ausschließlich die Branch-Festlegung und die zugehörige Dokumentation; der geprüfte Contract-Bytecode bleibt unverändert. ## Offline prüfen Voraussetzung: Node.js 20 oder neuer. \`\`\`bash npm ci --ignore-scripts npm run build npm test npm run release:verify npm audit --omit=dev --audit-level=high \`\`\` Der Release nutzt voneinander getrennte Prüfwege: - Solidity Standard JSON und reproduzierbarer Bytecode, - dynamische Ausführung in EthereumJS VM, - getrennte Node- und Python-Opcode-Parser, - Node-SHA-256 plus \`sha256sum\`/OpenSSL, - fail-closed Tests für die öffentliche Wallet-Transaktion. - explizites Compiler-Ziel `london` ohne den von den beiden BlockDAG-RPCs abgewiesenen Shanghai-Opcode `PUSH0`, plus reale `eth_estimateGas`-Simulation. ## Deployment ohne Betreiber-Burn Der unsigned Deployment-Datensatz wird so erzeugt: \`\`\`bash npm run prepare:transaction -- bdag-vault \`\`\` Er enthält Chain ID \`1404\`, Empfänger \`null\`, Wert \`0x0\`, den vollständigen Creation-Bytecode und den erwarteten Runtime-Hash. Private Keys, Seed, Nonce, Gaspreis, Signatur und Broadcast sind nicht enthalten. Nach dem Deployment wird der Bytecode über beide freigegebenen RPCs bytegenau geprüft: \`\`\`bash BDAG_RPC_URL="https://rpc.example" \\ BDAG_VAULT_ADDRESS="0x..." \\ npm run verify:bdag \`\`\` ## Öffentliche Aktivierung Die Website zeigt erst dann eine Adresse und aktiviert die freiwillige Wallet-Übertragung, wenn alle Gates erfüllt sind: 1. zwei aktuelle RPC-Prüfungen für den ausgewählten Branch, 2. BDAG-Deployment mit Wert \`0\`, 3. exakter Runtime-Bytecode über beide RPCs, 4. öffentlich verifizierter Solidity-Quellcode, 5. Ethereum-Ankervertrag auf Mainnet, 6. vollständige \`PUBLICATION.json\` mit Source-, Manifest- und Prüfhash, 7. SHA-256 dieser unveränderten Datei im Ethereum-Anker, 8. bestätigte Explorer-Links auf der Transparenzseite. Die öffentliche Oberfläche fordert eine Wallet-Verbindung nur nach einem bewussten Klick an. Vor dem Senden prüft sie Chain ID, historischen Branch-Fingerprint, exakten Vault-Bytecode, Zieladresse, Betrag und leere Calldata. Der Nutzer bestätigt den irreversiblen Vorgang und signiert ausschließlich in seiner eigenen Wallet. ## Unveränderlichkeit der Dokumentation Eine Website bleibt durch ihre Administratoren technisch änderbar. Deshalb wird nicht behauptet, jede Kopie sei unveränderlich. Stattdessen sind alle Release-Dateien durch ein SHA-256-Manifest erfasst und die endgültige \`PUBLICATION.json\` wird auf Ethereum verankert. Eine spätere Änderung ist dadurch bytegenau erkennbar. Korrekturen erhalten immer eine neue Version und einen neuen Anker; alte Nachweise werden nicht überschrieben. ## Wichtige Sperre Das Paket signiert und sendet keine Transaktion. Vor der On-Chain-Veröffentlichung müssen Ziel-Branch, Deployment-Wallet, Ethereum-Publisher, Netzwerkgebühren und alle angezeigten Hashes auf einem zweiten Gerät geprüft werden. Seeds, Private Keys und Wallet-Passwörter gehören niemals in Dateien, Webseiten oder Umgebungsvariablen. ## Lizenz MIT. Ein externes Smart-Contract-Audit bleibt vor breiter produktiver Nutzung empfohlen und wird bis dahin nicht behauptet.