Qanovra ist ein eigenständiges Blockchain-Netzwerk aus Deutschland — entwickelt für Werte, die über Jahrzehnte Bestand haben sollen. Jede Version wird unabhängig geprüft, versiegelt und mit nachrechenbaren Prüfsummen veröffentlicht. Entscheidungsgrundlage sind Belege, nicht Versprechen.
Vier Fragen, vier kurze Antworten — ohne Vorwissen verständlich. Über den Schalter oben rechts erreichen Sie jederzeit die technische Fassung.
Ein Verzeichnis, das gleichzeitig auf vielen Computern geführt wird. Jeder neue Eintrag wird von allen Beteiligten gegengeprüft und mit dem vorherigen verkettet. Eine nachträgliche Änderung würde sofort auffallen, weil sie zu allen anderen Kopien im Widerspruch stünde.
Unsere eigene Blockchain. Nicht auf einer fremden aufgesetzt, sondern von Grund auf gebaut — und Stück für Stück von außen prüfen lassen, bevor irgendetwas als fertig gilt.
Die Einheit, in der auf dieser Kette gerechnet wird. Wer etwas überträgt, überträgt QNV. Vergleichbar mit dem Euro auf einem Konto, nur ohne Bank dazwischen.
Noch nicht. Die Software ist fertig und geprüft, das Netz läuft aber noch nicht. Was genau noch fehlt, steht weiter unten offen aufgelistet — inklusive der Punkte, die uns selbst noch aufhalten.
Vier Eigenschaften, auf die es ankommt, sobald echtes Vermögen im Spiel ist — für Privatpersonen genauso wie für Unternehmen.
Es gibt keine Stelle, die Ihr Guthaben einfrieren oder eine Überweisung zurückhalten kann. Der Schlüssel liegt bei Ihnen — und damit auch die Verantwortung dafür.
Ist ein Zustand unklar, bricht die Software den Vorgang ab, statt eine Annahme zu treffen. Eine Überweisung, die nicht ausgeführt wird, lässt sich wiederholen — eine falsche nicht.
Wer Werte über lange Zeiträume verwahren oder weitergeben will, braucht ein System, das auch nach Jahrzehnten unverändert nachvollziehbar ist. Darauf ist die Basis ausgelegt.
Jede veröffentlichte Datei trägt eine Prüfsumme, die sich lokal nachrechnen lässt. Unsere Angaben lassen sich unabhängig überprüfen.
Keine Entwürfe, keine Attrappen: echte Aufnahmen der laufenden Wallet v0.30.17 aus der Prüfumgebung. Die Oberfläche sagt an jeder Stelle, was gilt — Testnetz, kein Geldwert, öffentlicher Werttransfer weiterhin NO_GO.
Aufgenommen an der laufenden Browser-Erweiterung in der Chrome-for-Testing-Prüfumgebung, Stand v0.30.17 vom eingefrorenen Audit-Oberflächenpaket; die Bilddateien tragen SHA-256-Prüfsummen im Quellpaket. Vor dem Senden bestätigt die Wallet vier Prüfungen — zwei unabhängige Knoten, Empfängerstatus, Tageslimit, kryptografisch bestätigter Kontostand — und gibt erst dann per Passkey frei. Ansichten der Erbenlösung heritari folgen, sobald deren Neubindung an v3.7.5 abgeschlossen ist.
Dieselbe Eingabe führt immer zum selben Ergebnis — auf jedem Rechner, zu jeder Zeit. Nichts hängt vom Zufall ab.
Ist etwas unklar, passiert lieber gar nichts als das Falsche. Im Zweifel wird abgebrochen, nicht überwiesen.
Wir behaupten nichts, was Sie nicht selbst nachrechnen können. Zu jeder Version gehören Belege.
Jede Version bekommt einen Fingerabdruck und wird danach nicht mehr angefasst. Was darauf aufbaut, weiß genau, worauf es sich stützt.
Jede Schicht ist ein eigenständig geprüfter Stand mit eigener Versionslinie. Auswählen, um Details zu sehen.
Regelt, was mit digitalem Vermögen passiert, wenn jemand nicht mehr selbst handeln kann — nachvollziehbar und ohne dass eine einzelne Person allein entscheidet.
Die App, mit der man sein Guthaben sieht und Überträge freigibt — wie Online-Banking, nur ohne Bank dazwischen.
Ein Werkzeugkasten für Entwickler, die eigene Programme an die Kette anschließen wollen.
Die Technik rundherum, die das Netz am Laufen hält und laufend belegt, dass alles korrekt arbeitet.
Das Fundament: die eigentliche Kette. Sie speichert die Einträge und sorgt dafür, dass alle dieselbe Wahrheit sehen.
QNV ist die native Recheneinheit des Netzwerks. Die Gesamtmenge von 10 Milliarden QNV existiert vollständig ab dem ersten Block — es wird nichts nachträglich geschöpft oder „gemint“. Alle Werte stammen aus Whitepaper und Yellow Paper v2.4.2 zum eingefrorenen Stand v3.7.5.
Genesis-Verteilung: 51,75 % Community und Netzsicherheit, 15,00 % Treasury und Ökosystem, 15,00 % Founder, 8,00 % Kernteam, 0,25 % Botschafterprogramm, 10,00 % weitere kanonische Zuteilungen. Offen ausgewiesen: Die Founder-Zuteilung ist ab Genesis verfügbar und nicht protokollseitig gesperrt oder vestet — das damit verbundene Konzentrations- und Liquiditätsrisiko benennt das Whitepaper ausdrücklich. Für Kernteam-Zuteilungen sieht die Startpolitik 48 Monate mit 12 Monaten Cliff und danach monatlich linearer Freigabe vor; dass dies technisch erzwungen ist, darf erst nach Vorlage der kanonischen Vault-Nachweise behauptet werden. Die tatsächliche Vergütung ist durch die Finanzierung begrenzt und kann unter der Zielgröße liegen. Eine Rendite wird nicht zugesichert. Slashing trifft den gesamten gebundenen Einsatz eines Validators einschließlich der Delegationen — die Wahl des Validators ist damit eine Sicherheitsentscheidung, keine reine Renditefrage.
Qanovra stellt die erste unabhängige Validator-Kohorte zusammen — über Europa, Nordamerika, Südamerika, Asien und Afrika. Fünf Plätze, organisatorisch unabhängige Betreiber, Aufnahme auf Nachweis statt auf Absicht.
Das Aufnahmeverfahren ist fail-closed: Ein Platz bleibt offen, bis Betreiber, Host und Schlüsselverwahrung nachgewiesen sind. Vollständige Nachweise haben Vorrang vor einem schnellen Start.
Keine gemeinsamen Eigentümer, Mitarbeiter oder Infrastruktur mit Qanovra oder einem anderen Betreiber der Kohorte.
Validator-Signaturschlüssel in geprüftem HSM, KMS oder Vault. Nicht exportierbare Verwahrung, nachgewiesen.
Dokumentierter Host mit erklärter Region, Anbieter und Trennung. Geteiltes Consumer-Hosting qualifiziert nicht.
Die betreibende Gesellschaft wird öffentlich genannt. Anonyme Betreiber können nicht Teil einer Gründungskohorte sein.
Sie erhalten das Betreiberpaket: Runbooks, Gerätematrix, Build-Verifikation und die Vorlage für die Erklärung.
Sie erklären Gesellschaft, Region, Host, Anbieter und vorgesehene Schlüsselverwahrung. Nichts wird für Sie angenommen.
Beide Seiten prüfen Unabhängigkeit, Rechtsraum und betriebliche Passung. Beide können hier folgenlos abbrechen.
HSM-, Host- und Betreibernachweise werden erstellt und an SHA-256-Prüfsummen gebunden.
Das Gate öffnet erst bei vollständigen Nachweisen. Unvollständige Nachweise halten den Platz geschlossen.
Hier wird keine Vergütung, keine Notierung und keine Rendite versprochen. Die Staking- und Slashing-Politik ist im Whitepaper dokumentiert; die genaue Unbonding-Dauer ist noch aus der eingefrorenen Konfiguration zu übernehmen.
SDK installieren, Endpunkt setzen, ersten Aufruf machen. Alles Weitere steht in der Dokumentation.
# Qanovra SDK · Python pip install qanovra-sdk >>> from qanovra import Client >>> c = Client("https://rpc.qanovra.example") >>> c.status().height 148902
Heutige Signaturverfahren beruhen auf Rechenaufgaben, an denen normale Computer scheitern. Leistungsfähige Quantencomputer könnten genau diese Aufgaben lösen. Wer Werte über Jahrzehnte verwahrt, muss das einplanen, bevor die Kette startet — nicht danach.
Deshalb steht der Punkt hier. Er ist ein Vorhaben und keine Eigenschaft des eingefrorenen Stands v3.7.5. Verfahren, Zeitplan und Prüfung stehen aus.
Für v3.7.5 wird ausdrücklich keine Post-Quantum-Sicherheit behauptet — der Stand ist „migrationsvorbereitet“. Ein späterer Wechsel auf Nachfolgeverfahren wie ML-DSA oder SLH-DSA erfordert eine versionierte Protokollaktualisierung, neue Konformitätsvektoren, geordnete Schlüsselrotation für Validatoren und Systemschlüssel sowie einen authentifizierten Umbindungspfad für Nutzerkonten.
Von der fertigen Basis wurde ein digitaler Fingerabdruck genommen und veröffentlicht. Jeder kann nachrechnen, ob die Software vor ihm wirklich genau diese ist — ein einziges geändertes Zeichen, und der Fingerabdruck stimmt nicht mehr.
Kandidat-Archiv v3.7.5 · SHA-256Aus dem Genesis-Hash leitet sich die Chain-ID ab: „qnv-“ plus die ersten 24 Hexstellen. Ein Knoten darf keine abweichend konfigurierte Chain-ID akzeptieren.
Jede Komponente wird einzeln geprüft — mit ausdrücklich positiven und negativen Befunden, Verbesserungsvorschlägen und einem Remediation-Paket für die nächste Runde.
Die Kette selbst — der Teil, der die Einträge speichert und alle Teilnehmer auf denselben Stand bringt.
Alles, was den Betrieb absichert: Werkzeuge, Prüfungen und Belege, damit das Netz zuverlässig läuft.
Die Anwendung für Nutzerinnen und Nutzer: Guthaben ansehen und Überträge freigeben.
Die erste fertige Anwendung: eine Lösung für den digitalen Nachlass — sie übergibt Vermögen an die richtigen Personen, wenn die Zeit gekommen ist.
heritari kümmert sich darum, dass digitales Vermögen bei den richtigen Menschen ankommt, wenn man selbst nicht mehr kann. Man meldet sich regelmäßig kurz zurück. Bleibt die Rückmeldung aus, prüfen vorher benannte Vertrauenspersonen die Lage und geben die Übergabe frei.
Signatur und Broadcast bleiben fail-closed: Bleibt ein Zustand unklar, wird nicht ausgezahlt. heritari bindet an den versiegelten Stand v3.6.9 an und führt bewusst keinen eigenen handelbaren Token ein.
Jeder Stand durchläuft dieselben vier Schritte. Erst wenn alle Befunde geschlossen sind, wird versiegelt.
tools/release_gate.py prüft den Stand automatisiert. Bricht das Gate, gibt es kein Paket.
Eine externe Prüfung liefert Befunde mit ausdrücklich positiven und negativen Aspekten sowie Verbesserungsvorschlägen.
Handoff-Datei, Remediation-Report, tools/remediation_gate.py und das vorherige Audit unter external-audits/.
Evidenzpaket, SHA256SUMS, Self-Check und parity_probe. Der Digest ist ab dann die Referenz.
Sicherheit ist bei uns ein Prozess, kein Zustand. Wer eine Schwachstelle findet, soll sie melden können — vertraulich und ohne Risiko.
Whitepaper und Yellow Paper in der Fassung v2.4.2 vom 23. August 2026 — die finale, eingefrorene Publikationsfassung. Jede Datei trägt ihre SHA-256-Prüfsumme aus dem Freeze-Manifest und lässt sich vor der Lektüre lokal verifizieren.
Die strategische und institutionelle Beschreibung: Netzidentität, Ledger- und Supply-Integrität, QNV-Tokenomics mit vollständiger Genesis-Verteilung und Finanzierungshorizont, Staking- und Slashing-Politik, Sicherheitsarchitektur, Governance, Reifegrad und Risiken.
Die technische Spezifikation in 33 Abschnitten: Zustandsmodell, Transaktions- und Blocksemantik, Konsensquorum, Validatorwechsel, monetäre Buchführung, privilegierte Operationen, Replay-Schutz, Bedrohungsmodell und Konformitätsanforderungen.
Das Betreiber-Briefing zum Programm: Anforderungen, fünfstufige Aufnahme, Leistungen, Ökonomie und Risiken in Kürze, aktueller Gate-Status und der Bewerbungsweg — zwei Seiten, englisch.
Der Nachweis des Publikationsfreeze: kanonische Hashes aller vier Dokumentdateien, Herkunft der Fassung und die Regel, dass ab jetzt kein Byte mehr geändert wird.
Prüfsummen aller veröffentlichten Dokumente. Damit lässt sich jede Datei lokal verifizieren.
Ergebnisse der unabhängigen Prüfung, sobald das externe Sicherheitsgate abgeschlossen ist.
Aufbau der Erbenlösung. heritari v1.1 bleibt an L1 v3.6.9 gebunden; eine Repin-Prüfung auf v3.7.5 steht aus.
Rechtliche Einordnung und Kanzleiunterlagen.
Beide Papers stehen als PDF und DOCX bereit — byteidentisch mit den Kanon-Hashes des Freeze-Receipts vom 23. August 2026. Nach diesem Freeze wird an den Dokumenten kein Byte mehr geändert; jede künftige Änderung erhält eine neue Fassung mit neuen Prüfsummen.
Ohne Datumsversprechen, in fünf Phasen wie im White Paper v2.1. Eine Phase gilt erst als abgeschlossen, wenn die zugehörigen Nachweise vorliegen.
v3.7.5 bleibt ohne stille Änderungen an Konsens, Genesis, Tokenomics oder Laufzeit.
Unabhängige L1-Attestation, echte Schlüsselzeremonie, unabhängige Validatoren, geografische Wiederherstellungsübung sowie Sicherheits- und Rechtsgates.
Kontrollierte externe Teilnahme, Betriebsqualifikation und Integrationsnachweise.
Geregelte Go-/No-go-Entscheidung auf Basis technischer und realer Nachweise.
Integrationen, Anwendungen und Werkzeuge ausbauen, ohne die Änderungsdisziplin zu umgehen.
Dasselbe Board, mit dem wir intern arbeiten. Ein Gate gilt erst als geschlossen, wenn der Nachweis vorliegt — ein bestandener Test ist kein geschlossenes Realwelt-Gate.
Eingefrorener Stand, Prüfsumme des Kandidatenarchivs veröffentlicht.
Eingefrorene Linie, Audit mit Evidence Closure.
Software-Freeze, kein offener Software-Punkt.
Abgeschlossen.
Ausgeführt und abgeschlossen.
Dry Run bestanden mit 4 von 7 Signaturen, Beobachterattest und Negativkontrollen. Produktionszeremonie und Genesis Seal stehen aus.
Erneute Versiegelung gegen den aktuellen Quellstand erforderlich; der frühere plattformübergreifende Nachweis gilt nicht automatisch weiter.
Fünf Betreiberpakete vorbereitet, null Betreiber aufgenommen. Gate wartet auf reale Infrastruktur.
Zeremonie-KMS-Schlüssel dürfen nicht als Produktions-HSM-Nachweis umetikettiert werden.
Tatsächlicher Regionsausfall und gemessene Wiederherstellung stehen aus.
Vorgesehen, sobald reale Validatoren stehen.
Finaler externer Sign-off steht aus.
Regulatorische Prüfung für den vorgesehenen Start steht aus.
Die Reifegradmatrix im White Paper v2.1 hält für jeden Bereich fest, wo er heute steht und was vor einer breiteren Aktivierung fehlt: L1-Attestation gegen den exakten Kandidaten, Abgleich des Startartefakts mit Genesis-Hash und Chain-ID, Qualifikation von Wallet und Browser in echter Umgebung, produktive Ausbringung von Explorer, RPC und SDK, die reale 4-von-7-Zeremonie mit Beobachternachweis, unabhängige Validator-Betreiber, eine tatsächlich geografische Wiederherstellungsübung, das externe Sicherheitsgate und die rechtliche Prüfung.
Nein. Der aktuelle geprüfte Stand ist v3.7.5, das Testnetz ist in Vorbereitung. Wo das Projekt steht, zeigt die Roadmap.
Die Qanovra UG (haftungsbeschränkt) i. G. mit Sitz in Deutschland: Gründung eingeleitet am 13. August 2026, notariell beurkundet am 21. August 2026. Bis zur Eintragung ins Handelsregister firmiert das Projekt ausdrücklich als Gesellschaft in Gründung.
Nein. Es gibt keinen Verkauf und keine Vorverkaufsaktion. Wer Ihnen QNV anbietet, handelt nicht in unserem Auftrag.
Bei Qanovra wird nichts „gemint“: Alle 10 Milliarden QNV existieren vollständig ab dem ersten Block, verteilt auf die festgelegten Genesis-Zuteilungen. Die eigentliche Langfristfrage lautet daher: Woraus werden Staking-Vergütungen bezahlt, wenn die dafür vorgesehene Community-Zuteilung aufgebraucht ist? Das Whitepaper beziffert das offen: Würde die Zuteilung von 5,175 Milliarden QNV ausschließlich für die Vergütungskurve verwendet, reichte sie rechnerisch etwa 9,4 Jahre bei 55 % Staking-Beteiligung, etwa 10,4 Jahre bei 62,5 % und etwa 12,3 Jahre bei 70 %. Danach werden Vergütungen ausschließlich aus Gebührenerlösen oder anderen bereits gedeckten, ausdrücklich genehmigten Quellen bezahlt. Neue QNV zu schöpfen ist als Ausweg ausgeschlossen — sinkt die Finanzierung, sinkt die effektive Vergütung, nicht die Verlässlichkeit der Gesamtmenge.
Weil die Anforderungen einer Nachlasslösung — sehr lange Laufzeiten, fail-closed, austauschbare Kryptografie — bis in die Basis reichen. Diese Eigenschaften lassen sich nicht auf einer fremden Kette nachrüsten.
Vor jedem Release eine unabhängige externe Prüfung. Die Ergebnisse fassen wir zusammen und veröffentlichen sie unter „Papers“.
Dass die Kryptografie austauschbar gebaut ist und ein Migrationspfad vorliegt — nicht, dass heute schon jedes Verfahren umgestellt wäre. Details stehen im Post-Quantum-Paper.
Als Entwickler über SDK und Dokumentation, als Prüfer über eine Auditanfrage, als Interessent über den Zugang zum Invite-Testnetz.
Fast. Das Yellow Paper v2.1 legt die semantischen Regeln und zwanzig Sicherheitsinvarianten normativ fest. Zwölf byte-genaue Details — Transaktionsschema, State-Root-Konstruktion, Gebührenformel, Unbonding-Dauer und weitere — sind ausdrücklich als „aus dem Code zu übernehmen“ gekennzeichnet, statt sie zu erfinden. Erst danach kann jemand einen unabhängigen Klienten byte-kompatibel bauen.
Für Fragen zur Technik, zu einer unabhängigen Prüfung oder zum Betrieb eines Validators erreichen Sie uns direkt per E-Mail.