Vermittco-Coin (VCC) — Whitepaper

1 Zusammenfassung

Der Vermittco-Coin (VCC) ist das Bonuspunkte-System des Marktplatzes Vermittco — aufgebaut mit den Prüf- und Schutzverfahren öffentlicher Blockchains. Jede Buchung wird in einer append-only Hash-Kette festgeschrieben, die auf Datenbank-Ebene gegen jede nachträgliche Änderung gesperrt ist. Überweisungen sind nur mit einer ECDSA-Signatur möglich, deren privater Schlüssel ausschließlich auf dem Gerät des Nutzers liegt — der Betreiber kann keine Überweisung fälschen. Ein Merkle-Baum über alle Buchungs-Hashes ermöglicht Einzelnachweise, und ein tägliches Commitment wird über OpenTimestamps in der Bitcoin-Blockchain verankert. Die Höchstmenge von 21.000.000 VCC, eine Abzugs-Bremse für den Betreiber und weitere Grundregeln sind in einer unveränderlichen, selbst in der Kette verankerten Verfassung festgeschrieben. Jede Person kann die Kette in ihren Strukturfeldern herunterladen und die lückenlose Verkettung sowie die Merkle-Wurzel im eigenen Browser unabhängig nachrechnen. VCC ist bewusst ein geschlossenes System: Coins werden nicht gegen Geld verkauft, nicht ausgezahlt und nicht umgetauscht.

2 Einleitung & Motivation

Klassische Bonuspunkte-Systeme haben ein Vertrauensproblem: Der Betreiber führt das Punktekonto allein, kann Guthaben still ändern, Regeln unangekündigt anpassen und Punkte unbegrenzt ausgeben. Der Nutzer kann nichts davon prüfen — er muss glauben.

Öffentliche Blockchains haben gezeigt, wie sich dieses Problem technisch lösen lässt: durch ein unveränderliches, öffentlich prüfbares Kassenbuch, durch kryptografische Signaturen statt bloßer Server-Entscheidungen und durch eine fest begrenzte Gesamtmenge. Der Vermittco-Coin überträgt genau diese Verfahren auf ein Bonuspunkte-System — ohne dessen rechtlichen Rahmen zu verlassen.

Das Ergebnis ist eine bewusste Kombination: zentrale Buchführung (schnell, stornierbar, mit klarer Verantwortung des Betreibers) plus kryptografische Härtung (fälschungssicher und öffentlich nachprüfbar wie eine Blockchain). Der Betreiber kann eingreifen — etwa bei Missbrauch —, aber niemals heimlich: Jeder Eingriff steht unlöschbar im Kassenbuch, und Überweisungen kann er prinzipbedingt nicht fälschen, weil ihm die privaten Schlüssel der Nutzer fehlen.

Auf dezentrale Block-Erzeugung verzichtet das System bewusst. Ein Bonuspunkte-System braucht ein Storno-Recht und einen rechtlich verantwortlichen Betreiber; beides verträgt sich nicht mit einem führerlosen Netzwerk. Alle übrigen Bausteine öffentlicher Blockchains — Hash-Kette, Merkle-Nachweise, Proof-of-Work, Halbierung, Mengenbegrenzung, öffentliche Struktur-Prüfung und externe Verankerung — sind vorhanden und in Betrieb. Was dieses System nicht kann, steht ebenso ausdrücklich in diesem Dokument: Abschnitt 28 nennt jede Grenze beim Namen.

3 Systemarchitektur

3.1 Das Kassenbuch als Hash-Kette

Alle VCC-Bewegungen — Willkommensbonus, Überweisungen, Mining-Belohnungen, Gebühren-Verbrennung, Verwaltungs-Eingriffe — landen in einem einzigen Journal. Es kennt 24 Buchungsarten — 21 davon in der laufenden Datenbank, drei reine Wirtschafts-Marker kommen mit dem nächsten Einspielen dazu; welche davon Guthaben bewegen und welche reine Marker sind, zeigt die Übersicht in Abschnitt 14. Jede Buchung erhält eine fortlaufende Nummer (seq) und einen SHA-256-Hash über eine kanonische Vorlage: eine byte-genau festgelegte Textform aller Buchungsfelder, die auch den Hash der vorherigen Buchung (prev_hash) enthält. Die erste Buchung verkettet gegen den festen Genesis-Wert vccoin-genesis.

Dadurch entsteht eine Kette: Wer auch nur ein Feld einer alten Buchung ändert, verändert deren Hash — und damit passt jede spätere Buchung nicht mehr. Eine Manipulation der Vergangenheit ist ohne Neuberechnung der gesamten Folgekette mathematisch unmöglich und würde sofort auffallen.

3.2 Unveränderlichkeit auf Datenbank-Ebene

Die Kette ist nicht nur logisch, sondern physisch geschützt: Datenbank-Trigger verbieten UPDATE, DELETE und TRUNCATE auf dem Journal — für alle Rollen, einschließlich der Administrations- und Service-Rollen des Betreibers selbst. Es gibt genau eine Buchungsfunktion, die neue Zeilen anhängt; sie läuft unter einem globalen Ketten-Lock, sodass Wettlauf-Situationen (etwa zwei gleichzeitige Buchungen um dieselbe Sequenznummer) ausgeschlossen sind. Korrekturen erfolgen nie durch Ändern, sondern ausschließlich durch neue Gegenbuchungen — sichtbar für alle.

3.3 Signatur-Fluss einer Überweisung

Eine Überweisung entsteht auf dem Gerät des Nutzers: Die Wallet baut die kanonische Nachricht, signiert sie mit dem privaten Schlüssel (der das Gerät nie verlässt) und sendet Nachricht plus Signatur an den Server. Der Server prüft Signatur, Nonce und Deckung — und erst dann schreibt die Buchungsfunktion den Vorgang samt Client-Signatur in die Kette. Die Signatur wird Teil der kanonischen Vorlage und ist damit selbst unveränderlich dokumentiert.

3.4 Versionierte Kanonformen

Die kanonischen Vorlagen sind Verträge: Sie sind versioniert (vccoin1 → vccoin2, Hash-Kette v1 → v2) und werden an allen Stellen, die eine Vorlage nachrechnen — Buchungsfunktion, Ketten-Nachprüfung des Teams und Wallet-Selbstprüfung im Browser — byte-identisch verwendet. Die öffentliche Prüfung im Browser rechnet dagegen keine Vorlagen nach, sondern die Struktur der Kette (Abschnitt 20). Ein fester Umstellungspunkt (Cutover je Sequenznummer) stellt sicher, dass historische Buchungen für immer nach ihrer damaligen Regel prüfbar bleiben. Die vollständige Referenz steht im Anhang.

4 Kryptografie

4.1 Signaturverfahren

VCC verwendet ECDSA über der Kurve P-256 mit SHA-256, umgesetzt über die WebCrypto-Schnittstelle des Browsers. Signaturen liegen im P1363-Format vor (64 Byte, hex-kodiert). Signiert wird immer die kanonische Nachricht der jeweiligen Aktion — Überweisung, Schlüssel-Rotation, Token-Transfer oder Ketten-Bezeugung.

4.2 Schlüssel-Hoheit beim Nutzer

Der private Schlüssel wird auf dem Gerät des Nutzers erzeugt und als nicht-exportierbares WebCrypto-Objekt in der lokalen IndexedDB gespeichert. Er kann von dort nicht ausgelesen werden — auch nicht von der Vermittco-Software selbst. Der Server kennt ausschließlich den öffentlichen Schlüssel.

4.3 Wiederherstellungscode und Backup

Damit ein Gerätewechsel oder -verlust nicht zum Aussperren führt, erhält jeder Nutzer einen Wiederherstellungscode aus 16 Zeichen eines 31er-Alphabets — ein Rechenraum von 31¹⁶, rund 79 Bit. Aus diesem Code wird per PBKDF2-SHA256 mit 310.000 Runden ein Schlüssel abgeleitet, der ein AES-GCM-256-verschlüsseltes Backup des Wallet-Schlüssels sichert. Der Server speichert nur den Geheimtext — den Klartext des Codes oder des Schlüssels sieht er zu keinem Zeitpunkt. Einzelheiten in Abschnitt 10.

Verliert ein Nutzer Gerät und Code, kann ein Administrator lediglich den hinterlegten öffentlichen Schlüssel zurücksetzen; der Nutzer richtet sein Wallet danach neu ein. Auch dabei erhält niemand Zugriff auf private Schlüssel.

4.4 Wiederholungs-Schutz

Jedes Konto führt eine Ausgaben-Sequenz (spend_seq). Jede signierte Aktion enthält die Nonce spend_seq + 1; der Server akzeptiert jede Nonce genau einmal. Eine abgefangene Signatur lässt sich daher nicht wiederverwenden (Replay-Schutz). Token-Konten führen jeweils eine eigene Sequenz.

5 Konsens & Verifizierbarkeit

5.1 Proof-of-Work-Mining

Nutzer können VCC durch echtes Proof-of-Work verdienen: Der Server erzeugt Challenges, die den aktuellen Kettenkopf als Zeugnis enthalten; das Gerät sucht per SHA-256 eine Nonce, deren Hash die geforderte Zahl führender Null-Bits erreicht. Die Schwierigkeit regelt sich selbst auf eine Ziel-Lösungszeit von etwa 45 Sekunden (im Korridor von 16 bis 30 Bits). Die Belohnung beträgt 0,05 VCC und halbiert sich nach dem Bitcoin-Prinzip in festen Stufen. Tageslimits — 2 VCC je Nutzer, 500 VCC global — begrenzen die Ausgabe zusätzlich.

Ein Nebeneffekt macht das Mining doppelt nützlich: Weil jede Challenge den Kettenkopf enthält, bezeugt jede eingereichte Lösung zugleich den damaligen Kettenstand.

5.2 Merkle-Baum und Einzelnachweise (SPV)

Über die Hashes aller Buchungen wird ein Merkle-Baum gebildet. Die Paarregel lautet: parent = sha256hex(links_hex + rechts_hex); ein ungerader letzter Knoten steigt unverändert auf. Zu jeder eigenen Buchung liefert das System auf Anfrage einen Einzelnachweis (SPV-Pfad): die Geschwister-Hashes vom Blatt bis zur Wurzel. Damit lässt sich mit wenigen Hash-Operationen beweisen, dass eine konkrete Buchung Teil des verankerten Gesamtbestands ist — ohne die ganze Kette zu laden.

5.3 Tägliche Bitcoin-Verankerung

Einmal täglich (Cron-Eintrag 50 3 * * *) bildet das System ein Commitment aus Kettenkopf und Merkle-Wurzel:

commitment = sha256( kopf_hash | merkle_wurzel )

Dieses Commitment wird an drei OpenTimestamps-Kalender übermittelt und damit in der Bitcoin-Blockchain verankert. Der Status jedes Ankers — „Eingereicht" bis „In Bitcoin bestätigt" — ist öffentlich im Explorer einsehbar. Ab dem Moment der Bestätigung kann selbst der Betreiber den damaligen Kettenstand nicht mehr unbemerkt umschreiben: Jede Abweichung würde dem in Bitcoin dokumentierten Commitment widersprechen.

5.4 Öffentliche Prüfung im Browser

Jede Person — auch ohne Konto — kann im Explorer die komplette Kette in ihren Strukturfeldern herunterladen und im eigenen Browser unabhängig prüfen: lückenlose Verkettung ab dem Genesis-Wert und Neuberechnung der Merkle-Wurzel mit Abgleich gegen den verankerten Stand. Die Merkle-Paarregel ist in der Datenbank und im Browser byte-identisch umgesetzt. Personenbezogene Daten sind in diesem Export nicht enthalten. Was sich von außen prüfen lässt und was nicht, steht ausführlich in Abschnitt 20.

5.5 Netzwerk-Wächter

Zusätzlich beobachten die Geräte der Nutzer die Kette dauerhaft: Sie speichern den zuletzt gesehenen Kettenstand lokal, erkennen ein Umschreiben bekannter Hashes ebenso wie ein Zurückspringen der Kette und bezeugen den geprüften Stand mit einer eigenen Signatur. Ungültige Bezeugungen werden gespeichert und niemals verworfen — sie sind das Alarmsignal des Systems. So entsteht die ehrliche Entsprechung des Blockchain-Prinzips „jeder Knoten prüft mit", ohne dezentrale Block-Erzeugung vorzutäuschen.

6 Ökonomie

6.1 Feste Höchstmenge und kleinste Einheit

Es wird niemals mehr als 21.000.000 VCC geben. Diese Grenze ist kein Versprechen, sondern Code: Ein Cap-Guard in der einzigen Buchungsfunktion prüft jede mengenerhöhende Buchung unter dem globalen Ketten-Lock — wettlauffrei und quellenübergreifend (Willkommensbonus, Verwaltung, Mining, Staking-Abschluss, Bezeugung). Die kleinste Einheit beträgt 0,00000001 VCC (8 Nachkommastellen); alle Beträge werden als gleitkommafreie fix8-Zeichenketten geführt, um Rundungsfehler auszuschließen.

6.2 Emission und Halbierung

Es gibt genau fünf Wege, auf denen ein VCC entsteht — Willkommensbonus, Team-Vergabe, Mining, Anlage-Belohnung und Wächter-Belohnung (Abschnitt 14). Im laufenden Betrieb ist Mining der Hauptweg. Die Grund-Belohnung von 0,05 VCC halbiert sich in festen Stufen nach dem Bitcoin-Prinzip; die Emission flacht dadurch immer weiter ab und nähert sich der Höchstmenge, ohne sie je zu erreichen.

6.3 Netzwerkgebühr mit Verbrennung

Jede Überweisung kostet eine Netzwerkgebühr von 0,0001 VCC, die nicht an den Betreiber fließt, sondern verbrannt wird: Sie verlässt den Umlauf dauerhaft und ist als eigene Buchungsart in der Kette dokumentiert. Der Vorgabewert ist 0.0001; der Wert 0 schaltet die Gebühr ab. Das System ist damit auf der Gebührenseite deflationär. Der genaue Ablauf steht in Abschnitt 13.

6.4 Staking

Nutzer können VCC für feste Laufzeiten anlegen: 30, 90 oder 180 Tage mit den Staffel-Faktoren ×1,0, ×1,25 und ×1,5 auf einen Basis-Satz von 5 % pro Jahr. Die Bonus-Gutschrift wird beim Start fest zugesagt und beim Abschluss gutgeschrieben; sie unterliegt derselben Höchstmengen-Prüfung wie jede andere Ausgabe. Angelegte Coins bleiben durchgehend Eigentum des Nutzers und werden nach Laufzeitende in jedem Fall wieder verfügbar. Da VCC Bonuspunkte ohne Geldwert sind, ist dieser Satz eine Systemregel des Punkteprogramms — keine Verzinsung von Geld und keine Renditeaussage. Das Anlegen hängt an einem eigenen Schalter, dessen Vorgabewert aus ist; Formel, Staffel und Freigabe-Regeln stehen in Abschnitt 16.

6.5 Zahlungsanforderungen

Nutzer können Anforderungs-Links erzeugen („bitte sende mir N VCC"), die der Empfänger mit einem vorbefüllten, signierten Transfer erfüllt. Auch hier gilt der Nonce-Mechanismus aus Abschnitt 4.4 — jede Signatur ist genau einmal gültig. Dieser Weg läuft heute, wird aber mit der Einspielung der Wallet-Adresse (Abschnitt 11) abgeschaltet: Das Anlegen und Abrufen einer Anforderung verliert dann seine Freigabe, bestehende Zeilen bleiben lesbar.

7 Die Verfassung

Die Grundregeln des Systems sind nicht nur dokumentiert, sondern selbst Teil der Kette: Die Vermittco-Coin-Verfassung liegt in einer unveränderlichen Tabelle (mit demselben Trigger-Schutz wie das Journal), wird kanonisch gehasht, als eigene Buchung in der Kette verbucht und damit automatisch in Bitcoin mitverankert. Fassung v1 ist Buchung #10 der Kette. Die sechs Artikel lauten wörtlich:

1. Die Höchstmenge beträgt 21.000.000 VCC — technisch erzwungen, für jeden prüfbar.
2. Coins werden nicht gegen Geld verkauft und nicht ausgezahlt, solange keine rechtliche Freigabe vorliegt.
3. Das Kassenbuch ist unveränderlich, öffentlich prüfbar und wird täglich in der Bitcoin-Blockchain verankert.
4. Der Betreiber kann keine Überweisung fälschen — private Schlüssel liegen ausschließlich bei den Nutzern.
5. Team-Abzüge sind global auf das Abzugs-Limit je 24 Stunden begrenzt (revoke_limit_24h). Eine Änderung ist nur als neue, öffentliche Verfassungs-Fassung möglich.
6. Jeder Eingriff des Betreibers (Abzug, Einfrieren) erscheint unlöschbar im Kassenbuch und im öffentlichen Aktivitäts-Feed.

7.1 Die Abzugs-Bremse

Artikel 5 ist technisch erzwungen: Das Abzugs-Limit beträgt in Fassung v1 1.000 VCC je 24 Stunden — global über alle Team-Abzüge zusammen. Die Abzugs-Funktion selbst prüft vor jeder Buchung die Summe aller Abzüge der letzten 24 Stunden gegen das Verfassungs-Limit und verweigert darüber hinausgehende Abzüge. Das Limit lässt sich nicht per Einstellung ändern, sondern ausschließlich durch eine neue Verfassungs-Fassung — die wiederum öffentlich in der Kette landet und verankert wird. Ein „stiller" Zugriff des Betreibers auf Nutzerguthaben ist damit doppelt ausgeschlossen: technisch begrenzt und lückenlos dokumentiert.

7.2 Hash-Verankerung der Verfassung

Jede Fassung wird über die Kanonform vcverfassung1|<version>|<artikel-json> mit SHA-256 gehasht; der Hash steht als Referenz in der zugehörigen Ketten-Buchung. Wer die Verfassung liest, kann also kryptografisch prüfen, dass genau dieser Wortlaut verbucht und über die Kette in Bitcoin verankert wurde.

8 Token-Ebene

Nach dem Vorbild von Solana ist VCC die native Grundwährung einer Kette, auf der weitere Coins leben können: Firmen können eigene Coins als Tokens auf derselben Kette herausgeben — mit eigenem Namen, Symbol, eigenen Nachkommastellen und eigener Höchstmenge (jeweils mit eigenem Cap-Wächter). Alle Token-Buchungen laufen durch dieselbe Hash-Kette und werden vom selben täglichen Bitcoin-Anker erfasst; die Token-Übersicht ist als öffentliche Registry im Explorer einsehbar.

8.1 Rechte-Modell

• Prägen kann nur der Eigentümer des Tokens — bis zu seiner selbst festgelegten Höchstmenge.
• Kunden-Guthaben bewegen kann nur der Kunde: Jeder Token-Transfer benötigt die ECDSA-Signatur des sendenden Kunden. Die herausgebende Firma kann Kundenguthaben zu keinem Zeitpunkt bewegen.
• Eigene Nonce je Token-Konto: Der Wiederholungs-Schutz aus Abschnitt 4.4 gilt getrennt für jedes Token-Konto.

9 Rechtlicher Rahmen

Der Vermittco-Coin ist ein geschlossenes Bonuspunkte-System der Plattform Vermittco. Er ist kein Geld, kein E-Geld, kein Zahlungsmittel und kein Finanzinstrument. Daraus folgen bewusste, technisch erzwungene Grenzen:

• Kein Kauf: VCC können nicht gegen Euro oder andere Währungen erworben werden. Der entsprechende Schalter (purchasable) ist technisch fest deaktiviert und von keiner Funktion des Systems setzbar; ein Kaufpfad würde erst nach anwaltlicher Freigabe überhaupt gebaut.
• Kein Verkauf, keine Auszahlung, kein Umtausch: VCC lassen sich nicht in Geld oder geldwerte Leistungen außerhalb der Plattform zurücktauschen.
• Keine Wert- oder Renditeaussagen: VCC haben keinen Markt- oder Geldwert. Alle Mengenregeln dieses Dokuments (Höchstmenge, Halbierung, Verbrennung, Staking-Staffeln) sind Systemregeln eines Punkteprogramms — keine Aussagen über einen Wert.

Diese Grenzen sind zugleich Artikel 2 der Verfassung (Abschnitt 7) und damit selbst kryptografisch verankert. Sollte sich der rechtliche Rahmen ändern, wäre jede Regeländerung nur als neue, öffentliche und in der Kette dokumentierte Verfassungs-Fassung möglich.

10 Wallet und Schlüssel

Das Wallet ist kein Konto beim Betreiber, sondern ein Schlüsselpaar auf dem Gerät. Alles, was Guthaben bewegt, hängt an diesem Schlüssel — und er ist die einzige Stelle des Systems, an die der Betreiber technisch nicht herankommt.

10.1 Wie der Schlüssel entsteht

Das Paar wird über die WebCrypto-Schnittstelle des Browsers erzeugt: ECDSA über der Kurve P-256. Es entsteht einmalig in exportierbarer Form, wird als pkcs8 ausgelesen — und aus diesen Bytes wird sofort die eigentliche Arbeitskopie nicht auslesbar zurückgelesen. Danach existiert der Schlüssel im Browser nur noch als Objekt, das signieren kann, dessen Inhalt aber niemand mehr abfragen kann, auch die Vermittco-Software nicht.

Abgelegt wird dieses Objekt in der IndexedDB des Geräts (Datenbank vc-wallet, Version 2, Ablage keys, geschlüsselt nach Nutzer-Kennung). Der Grund für die IndexedDB statt des einfacheren Web-Speichers ist technischer Natur und zugleich der Sicherheitsgewinn: Schlüssel-Objekte lassen sich nicht in Text verwandeln, wohl aber strukturiert kopieren — nur so liegt Schlüsselmaterial zu keinem Zeitpunkt als Bytes im Seiten-Kontext. Die pkcs8-Bytes selbst werden nie in die IndexedDB geschrieben.

Fehlt dem Browser WebCrypto oder IndexedDB, verweigert das Wallet den Dienst. Es gibt bewusst keinen Ersatzweg mit schwächerer Kryptografie.

10.2 Der Wiederherstellungscode

Ein Gerät kann verloren gehen. Deshalb erzeugt das Wallet im Browser einen Wiederherstellungscode und verschlüsselt damit ein Backup des Schlüssels. Der Code selbst geht nie an den Server — dorthin wandern nur der öffentliche Schlüssel, der Fingerabdruck und der fertige Geheimtext.

Dieses Alphabet ist nicht dasselbe wie das der Wallet-Adresse: Der Wiederherstellungscode lässt das U zu, die Crockford-Kodierung der Adresse (Abschnitt 11) nicht.

Ein falsch eingegebener Code scheitert nicht an einem Vergleich, sondern an der Integritätsprüfung von AES-GCM: Das Backup lässt sich schlicht nicht entschlüsseln, und das Wallet meldet „Der Code ist nicht richtig." Der Eingabe-Umgang ist nachsichtig — Kleinschreibung, Trenner und ein mitgetipptes „VC-" werden vor der Prüfung entfernt.

Ein Code-Wechsel entschlüsselt das Backup mit dem alten Code und verschlüsselt es mit dem neuen; gespeichert wird erst nach Bestätigung. Der Schlüssel selbst bleibt dabei derselbe — es ändert sich nur das Schloss um ihn herum.

10.3 Schlüssel wechseln, Schlüssel verlieren

Ein Nutzer kann seinen Schlüssel wechseln (Rotation). Dabei signiert das alte Gerät die Kanonform vccoin2|rotate|… mit dem neuen Fingerabdruck; der Server rechnet den Fingerabdruck aus dem übergebenen Schlüssel nach und weist Abweichungen ab.

Gehen Gerät und Code verloren, kann niemand das alte Schlüsselmaterial wiederherstellen — auch der Betreiber nicht, denn er besitzt keines. Ein Administrator kann das Wallet lediglich schlüssellos stellen: Guthaben und Ausgaben-Sequenz bleiben unverändert stehen, der Nutzer richtet ein neues Schlüsselpaar ein. Einen zweiten Willkommensbonus gibt es dabei nicht.

11 Wallet-Adresse und QR-Code

Nutzer-Kennungen sind 36-stellige Zeichenketten — unhandlich zum Vorlesen, Abtippen oder Aufdrucken. Deshalb hat jedes Wallet eine kurze, tippbare Adresse mit eingebauter Prüfsumme.

Ableitung (Vertrag)

koerper  = 'VCC1' || B32C( sha256('vccaddr1|' || user_id)[1..16] )
pruef    =           B32C( sha256('vccsum1|'  || koerper)[1..3]  )[1..4]
adresse  = koerper || pruef                        →  immer 34 Zeichen

B32C ist Crockford-Base32 über das Alphabet 0123456789ABCDEFGHJKMNPQRSTVWXYZ — ohne I, L, O und U, damit Verwechslungen beim Abschreiben nicht möglich sind. Kodiert wird höchstwertiges Bit zuerst und ohne Polsterzeichen: 16 Byte ergeben 26 Zeichen, 3 Byte ergeben 5 Zeichen, von denen die ersten 4 die Prüfsumme bilden.

11.1 Warum die Adresse stabil bleibt

Die Adresse hängt an der Nutzer-Kennung, nicht am Schlüssel. Sie übersteht damit eine Schlüssel-Rotation ebenso wie ein Zurücksetzen durch das Team — anders als der Fingerabdruck, der sich bei jedem Schlüsselwechsel ändert. In der Datenbank steht die Adresse zwar auch als Spalte, aber nur zur Anzeige und als Suchindex: Die Wahrheit bleibt die Ableitung.

11.2 Eingabe, QR-Code und Auflösung

Vor jeder Prüfung wird die Eingabe normalisiert: Trennzeichen und Leerzeichen entfallen, Kleinschreibung wird zu Großschreibung, und die Crockford-Verwechslungen werden geglättet (I und L werden zu 1, O wird zu 0). Die QR-Kurzform mit dem Präfix vcc: wird ebenfalls akzeptiert.

Die Prüfsumme wird an zwei Stellen gerechnet: Der Browser rechnet sie sofort bei der Eingabe nach — mit einer eigenen, gleichlaufenden SHA-256-Umsetzung, damit die Prüfung ohne Wartezeit im Tippfluss stattfinden kann. Verbindlich entscheidet der Server, der dieselbe Rechnung noch einmal ausführt, bevor irgendetwas gebucht wird.

Die Auflösung einer Adresse zu einem Empfänger ist absichtlich karg: höchstens 30 Anfragen je 5 Minuten, Namen werden maskiert, und ein Wallet, das nicht existiert, eingefroren oder gesperrt ist, meldet ununterscheidbar „nicht gefunden". Aus der Antwort lässt sich also nicht ablesen, ob eine Adresse zu einem gesperrten Konto gehört.

12 Überweisungen

Eine Überweisung ist der einzige Vorgang, bei dem ein Nutzer fremdes Guthaben nicht, eigenes Guthaben aber vollständig bewegt. Entsprechend eng ist der Weg.

Signierte Kanonform

vccoin2|transfer|<from_uid>|<to_uid>|<amount fix8>|<nonce>|<memo>

12.1 Beträge ohne Gleitkomma

Beträge sind im gesamten System Zeichenketten mit genau 8 Nachkommastellen (fix8), niemals Gleitkommazahlen. Die zulässige Form ist festgelegt als ^(0|[1-9][0-9]{0,12})\.[0-9]{8}$: ganzzahliger Teil ohne führende Nullen, danach exakt acht Stellen. Der geprüfte Text wandert unverändert weiter in die Buchung — er wird nie in eine Zahl umgewandelt und wieder zurück.

Auch das Wallet rechnet mit Zeichenketten. Gibt jemand mehr als acht Nachkommastellen ein, rundet das Wallet nicht, sondern meldet einen Fehler. Stilles Runden wäre der bequemere Weg und genau deshalb ausgeschlossen: Ein gerundeter Betrag wäre ein anderer als der signierte.

12.2 Was geprüft wird, bevor gebucht wird

Wichtig für eine ehrliche Darstellung: Die Signaturprüfung findet ausschließlich in der Prüfschicht statt. Die buchenden Datenbank-Funktionen sind für angemeldete Nutzer gesperrt und ausschließlich vom Dienst-Konto aufrufbar; sie vertrauen dieser vorgelagerten Prüfung. Die Kanonform wird dort nicht vom Client übernommen, sondern aus geprüften Server-Werten neu zusammengesetzt — eine manipulierte Nachricht passt dann nicht mehr zur Signatur.

Kontostand und Journal ändern sich in derselben Datenbank-Transaktion. Sie können deshalb nicht auseinanderlaufen: Entweder es entsteht eine Buchung und der Kontostand ändert sich, oder es geschieht nichts.

12.3 Der Wiederholungs-Zähler im Detail

Jedes Wallet führt genau einen Zähler. Überweisung, Schlüssel-Rotation und Ketten-Bezeugung verbrauchen denselben — eine abgefangene Signatur ist damit auch dann wertlos, wenn sie zu einer anderen Aktionsart gehört. Token-Konten führen jeweils einen eigenen Zähler.

Das Wallet holt die Nonce immer frisch vom Server, nie aus dem Offline-Vorrat. Der Offline-Abzug enthält den Zähler bewusst gar nicht — ein zwischengespeicherter Wert würde den Wiederholungs-Schutz aushebeln (siehe Abschnitt 26).

13 Netzwerkgebühr und Verbrennung

Jede Überweisung kostet eine Netzwerkgebühr. Sie fließt nicht an den Betreiber, sondern verschwindet: Es gibt kein Gegenkonto, keine Gutschrift, keinen Empfänger.

Geprüft wird die Gebühr gegen das freie Guthaben: Kontostand minus fest angelegte Menge muss Betrag und Gebühr decken. Wer sein gesamtes Guthaben angelegt hat, kann also auch die Gebühr nicht bezahlen.

13.1 Was Verbrennen für die Höchstmenge bedeutet

Die Höchstmenge von 21.000.000 VCC bleibt durch das Verbrennen unberührt — sie ist ein fester Wert. Was sich ändert, ist der Abstand zu ihr: Weil die Mengenprüfung gegen die Summe aller Kontostände rechnet, gibt jede verbrannte Menge exakt diesen Betrag als Prägespielraum zurück. Verbranntes ist also nicht für immer aus der Welt, sondern schafft Raum für spätere Prägungen. Dasselbe gilt für jeden Team-Abzug, der ebenfalls ohne Gegenkonto bucht.

Wie viel insgesamt verbrannt wurde, ist öffentlich einsehbar.

14 Die Buchungsarten des Kassenbuchs

Das Journal kennt 24 Buchungsarten. Neun davon bewegen VCC-Guthaben, fünf davon lassen neue Coins entstehen, die übrigen fünfzehn sind Marker: Sie halten ein Ereignis fest, ohne einen Kontostand anzurühren. Alle vierundzwanzig laufen durch dieselbe Buchungsfunktion, stehen in derselben Hash-Kette und werden vom selben täglichen Bitcoin-Anker erfasst.

Ehrlich dazugesagt: In der laufenden Datenbank sind heute 21 davon erlaubt. Die drei Wirtschafts-Marker eco_formula, eco_index und ent_register kommen mit dem nächsten Einspielen dazu; sie sind in der Tabelle unten eigens gekennzeichnet. An der Vorlage, am Hash und an der bestehenden Kette ändert dieses Einspielen nichts — nur die Liste der erlaubten Arten wächst.

Die vier Token-Buchungsarten bewegen bewusst kein VCC — die Token-Guthaben werden daneben geführt, in derselben Transaktion und unter demselben Ketten-Lock. Die drei Wirtschafts-Marker tragen den Betrag 0 und stehen in keiner Mengenliste; sie prägen nichts.

14.1 Was „Umlauf" genau bedeutet

Der Umlauf ist die Summe aller Kontostände — nicht die Summe aller je ausgegebenen Coins. Daraus folgt dreierlei, und alles drei ist so beabsichtigt:

• Fest angelegte Coins zählen mit. Sie bleiben Eigentum des Nutzers und verlassen sein Konto nicht.
• Der Bestand des Gründer-Tresors zählt mit. Er ist ein Teil des Umlaufs, kein Sonderraum daneben.
• Verbranntes und Abgezogenes ist heraus — und gibt damit Prägespielraum unter der Höchstmenge zurück.

Daneben wird eine zweite Größe geführt: die insgesamt je ausgegebene Menge als Summe über alle fünf Prägungsarten. Sie kennt kein Zurück und wächst nur. Öffentlich ausgewiesen wird sie heute nur für den Mining-Anteil; die Summe über alle fünf Wege kommt mit der Mengen-Übersicht der Wirtschafts-Schicht (Abschnitt 24).

14.2 Die Mengenprüfung

Vor jeder prägenden Buchung — und nur bei diesen fünf Arten — prüft die Buchungsfunktion unter dem globalen Ketten-Lock, ob die Summe aller Kontostände zuzüglich des neuen Betrags die Höchstmenge überschreiten würde. Ist das der Fall, bricht sie mit einer klaren Meldung ab:

wenn Buchungsart ∈ { welcome, admin_grant, mining_reward,
                     stake_reward, witness_reward }  und  Betrag > 0:

    wenn  Summe(alle Kontostände) + Betrag  >  Höchstmenge:
        Abbruch: „Höchstmenge erreicht — es können keine neuen Coins mehr entstehen."

Die Prüfung liegt hinter dem Ketten-Lock und vor der Vergabe der Buchungsnummer. Weil der Lock alle Schreiber der Kette hintereinander stellt, kann kein Wettlauf zwei Prägungen gleichzeitig durchlassen. Die Höchstmenge selbst ist kein Parameter irgendeiner Verwaltungsfunktion — es gibt keinen Aufruf, mit dem das Team sie anheben könnte.

14.3 Die fünf Wege, auf denen ein Coin entsteht

Eine Feinheit beim Willkommensbonus verdient Erwähnung, weil sie eine Nutzerfalle vermeidet: Ist die Höchstmenge erschöpft, bricht die Wallet-Einrichtung nicht ab. Die Bonus-Buchung läuft in einem eigenen, abgesicherten Schritt; scheitert sie, entsteht das Wallet trotzdem, nur eben ohne Bonus.

15 Mining

Mining ist echter Rechenaufwand, kein Klickspiel. Der Ablauf hat drei Schritte: Aufgabe holen, rechnen, einlösen.

15.1 Aufgabe holen

Der Server stellt die Aufgabe — nicht das Gerät. Er baut ein Präfix aus dem aktuellen Kettenkopf, einem frischen Zufallswert und dem Ausgabezeitpunkt:

präfix = vcpow1|<uid>|<head_hash>|<salt_hex>|<issued_epoch>

Weil der Kettenkopf im Präfix steht, lässt sich eine Aufgabe nicht im Voraus rechnen, und jede eingereichte Lösung bezeugt zugleich den damaligen Kettenstand. Die Aufgabe läuft nach einer festgelegten Zeit ab (Vorgabewert 180 Sekunden, gedeckelt auf 30 bis 3.600 Sekunden), und das Holen ist ratenbegrenzt.

15.2 Rechnen und einlösen

Gesucht ist eine Zahl, die an das Präfix gehängt einen SHA-256-Hash mit genügend führenden Null-Bits ergibt:

gültig, wenn  sha256( präfix|nonce )  mindestens  difficulty_bits  führende Null-Bits hat

Beim Einlösen prüft der Server: Gehört die Aufgabe dem Nutzer? Ist sie noch nicht eingelöst? Ist sie noch gültig? Hat die Zahl die zulässige Form (nur Ziffern, höchstens 16 Stellen, im sicheren Zahlenbereich)? Erfüllt der Hash die Schwierigkeit? Danach erst nimmt er den Ketten-Lock, wiederholt alle Prüfungen unter dem Lock und entwertet die Aufgabe in einem einzigen Schreibvorgang, der nur greift, solange sie unentwertet ist. Eine doppelte Einlösung ist damit ausgeschlossen, auch bei gleichzeitigen Versuchen.

15.3 Die Schwierigkeit regelt sich selbst

Bei jeder Aufgaben-Ausgabe schaut das System auf den geglätteten Abstand zwischen den letzten Funden und stellt nach:

wenn geglätteter Abstand < Zielzeit × 0,5  →  Schwierigkeit + 1 Bit   (doppelter Aufwand)
wenn geglätteter Abstand > Zielzeit × 2    →  Schwierigkeit − 1 Bit
sonst                                       →  unverändert

danach auf den erlaubten Korridor geklemmt

Der Abstand ist ein gleitender Mittelwert: Jeder neue Fund geht mit 30 Prozent, der bisherige Stand mit 70 Prozent ein. Ausreißer werden vorher geklemmt — nach unten auf 0,05 Sekunden, nach oben auf das Zwanzigfache der Zielzeit —, damit ein einzelner Glückstreffer oder eine lange Pause die Schwierigkeit nicht verreißt. Beim allerersten Fund wird der Mittelwert auf die Zielzeit gesetzt.

15.4 Halbierung und Belohnungshöhe

Die Halbierungsstufe hängt an der geschürften Menge, nicht an der Zeit und nicht an einer Blockzahl:

stufe      = abrunden( geschürft_gesamt / halbierungs_abstand )
halbierung = grund_belohnung / 2^stufe          (Stufe gedeckelt bei 64)

belohnung  = kleinster Wert aus:
             halbierung
             Tageslimit_Nutzer  − heute selbst geschürft
             Tageslimit_gesamt  − heute insgesamt geschürft
             Höchstmenge        − Umlauf

Daraus folgt eine saubere Randbedingung: Der letzte Coin wird anteilig ausgezahlt. Es gibt keinen Fund, der über die Höchstmenge hinausschießt und dann abgewiesen werden müsste — die Belohnung schrumpft stattdessen auf genau den verbleibenden Rest.

15.5 Wenn der Vorrat erschöpft ist

Ist der Rest bis zur Höchstmenge aufgebraucht oder die Halbierung unter die kleinste Einheit gefallen, wird gar keine Aufgabe mehr ausgegeben. Die Antwort trägt dann eine Vorschau-Belohnung von 0 und einen Erschöpft-Vermerk — getrennt vom Vermerk für ein erreichtes Tageslimit, damit ein Nutzer die beiden Fälle auseinanderhalten kann. Auch die Anzeige zeigt in diesem Zustand eine Belohnung von 0.

Dieser Zustand ist nicht endgültig: Weil gegen den Umlauf gerechnet wird und nicht gegen die je ausgegebene Menge, öffnen verbrannte Gebühren und Team-Abzüge das Mining wieder.

16 Coins fest anlegen

Nutzer können Coins für eine feste Laufzeit binden und erhalten dafür am Ende eine Bonus-Gutschrift. Der Schalter dafür hat den Vorgabewert aus.

16.1 Laufzeiten und Staffel

Es gibt genau drei Laufzeiten, und sie sind doppelt abgesichert: einmal als Bedingung an der Datenbank-Spalte, einmal als Prüfung beim Anlegen. Ein vierter Wert ist nicht eingebbar.

faktor    = 30 Tage → 1,0   ·   90 Tage → 1,25   ·   180 Tage → 1,5
belohnung = betrag × (satz / 100) × (tage / 365) × faktor      auf 8 Stellen gerundet

16.2 Das Guthaben bewegt sich nicht

Anlegen verschiebt nichts. Die beiden Buchungsarten stake_lock und stake_release stehen in keiner der beiden Salden-Listen — sie sind reine Marker in der Kette. Der Kontostand bleibt beim Anlegen und beim Auflösen unverändert; die Bindung wirkt rein rechnerisch, indem an genau zwei Stellen die Summe der laufenden Anlagen abgezogen wird: bei der Überweisung und beim nächsten Anlegen.

Das ist der Grund, warum angelegte Coins Teil des Umlaufs bleiben: Sie liegen unverändert auf dem Konto des Nutzers, sie sind nur nicht frei verfügbar.

16.3 Auflösen

Auflösen kann nur der Eigentümer, nur eine laufende Anlage und nicht vor dem Ablaufzeitpunkt. Einen vorzeitigen Ausstieg gibt es nicht — und folglich auch keine Strafgebühr dafür. Die Belohnung steht schon beim Anlegen fest; eine spätere Änderung des Satzes berührt laufende Anlagen nicht.

17 Netzwerk-Wächter

Eine Hash-Kette schützt gegen nachträgliche Änderungen nur dann wirksam, wenn jemand hinsieht. Genau das übernehmen die Geräte der Nutzer — freiwillig und lokal zuschaltbar.

17.1 Was ein Gerät prüft

Ein teilnehmendes Gerät führt ein eigenes Wach-Protokoll in der lokalen IndexedDB — höchstens 300 gemerkte Stände — und prüft bei jedem Blick auf die Kette zwei Dinge:

1. Umschreib-Erkennung. Ein Hash, der zu einer bestimmten Buchungsnummer einmal gesehen wurde, darf sich nie wieder ändern.
2. Kein Rückwärtsspringen. Die Kette darf nie kürzer sein als zuletzt beobachtet.

Schlägt eine der beiden Prüfungen an, wird nicht bezeugt — das wäre eine falsche Bestätigung — sondern eine Warnung angezeigt.

17.2 Die Bezeugung

Ist alles stimmig, signiert das Gerät den geprüften Stand:

vccoin2|witness|<uid>|<seq>|<head_hash>|<merkle_root>|<nonce>

Der Server prüft die Nonce wie bei jeder signierten Aktion und gleicht danach beides gegen seine eigenen Werte ab: den Kopf-Hash gegen die Journal-Zeile und die Merkle-Wurzel gegen die frisch berechnete Wurzel bis zu dieser Buchungsnummer.

Der Ketten-Stand, gegen den die Geräte prüfen, stammt aus derselben öffentlichen Abfrage, die auch der Explorer nutzt. Und eine Klarstellung gehört dazu: Wächter geben keine Buchungen frei. Sie bezeugen einen Stand, sie entscheiden nichts. Das System täuscht damit keine dezentrale Block-Erzeugung vor.

18 Merkle-Bäume und Einzelnachweise

Über die Hashes aller Buchungen wird ein Baum gebildet, dessen Wurzel den gesamten Bestand in 64 Zeichen zusammenfasst. Zwei Eigenheiten der Regel sind wichtig, weil sie über die Vergleichbarkeit mit anderen Umsetzungen entscheiden.

Paarregel (Vertrag)

Blätter  = die Buchungs-Hashes als Hex-Text, in der Reihenfolge ihrer Nummern
Eltern   = sha256hex( utf8( links_hex || rechts_hex ) )

→ verkettet werden die HEX-ZEICHENKETTEN, nicht die Rohbytes
→ ein ungerader letzter Knoten steigt UNVERÄNDERT auf (er wird nicht verdoppelt)
→ bei einer einzigen Buchung ist die Wurzel deren Hash

Das Verdoppeln des letzten Knotens, wie es andere Systeme kennen, findet hier bewusst nicht statt. Die Datenbank und der Browser rechnen diese Regel zeichengleich.

18.1 Commitment

commitment = sha256hex( utf8( head_hash || '|' || merkle_root ) )

Ältere Anker, die noch vor der Einführung der Merkle-Wurzel entstanden sind, bleiben gültig: Dort war der Kopf-Hash selbst das Commitment, und die Prüfung fällt für diese Anker auf genau diese Regel zurück.

18.2 Der Einzelnachweis

Zu einer Buchung liefert das System Blatt, Position, die Geschwister-Hashes mit ihrer jeweiligen Seite, die Wurzel und den zugehörigen Anker. Drei Eigenschaften sind bemerkenswert:

• Nur für eigene Buchungen. Nachweise gibt es zur eigenen Buchung oder zu einer Verankerungs-Buchung. Für fremde Buchungen lautet die Antwort ununterscheidbar „nicht gefunden" — es lässt sich also nicht abtasten, ob eine bestimmte Buchungsnummer jemand anderem gehört.
• Selbstkontrolle. Rechnet der Nachweis auf eine Wurzel, die vom Anker abweicht, bricht die Auskunft ab, statt einen unstimmigen Nachweis herauszugeben.
• Stichprobe im Wallet. Das Wallet prüft von sich aus die fünf neuesten eigenen Buchungen gegen ihre Nachweise.

19 Verankerung in Bitcoin

Die Verankerung nutzt OpenTimestamps. Das ist die ehrliche Beschreibung dessen, was geschieht: Es gibt keine eigene Blockchain, keine Bitcoin-Transaktion und kein Bitcoin-Wallet auf Seiten von Vermittco. Verankert wird ein Zeitnachweis für 32 Bytes.

Der Ausfall-Fall verdient die Betonung: Lieber gar kein Anker als ein Anker, der etwas behauptet, was kein Kalender bestätigt hat. Ebenso beim Aufgeben — ein Anker, der nach zwei Wochen keine Bestätigung hat, wird als fehlgeschlagen ausgewiesen und nicht stillschweigend aus der Anzeige entfernt.

Im Wallet und im Explorer erscheint daraus eine einzige, gut verständliche Aussage: „verankert bis Buchung #…" — die Buchungsnummer des jüngsten Ankers, der in Bitcoin bestätigt ist. Alles bis zu dieser Nummer kann selbst der Betreiber nicht mehr unbemerkt umschreiben.

20 Öffentliche Prüfbarkeit

Prüfbarkeit ist nur dann etwas wert, wenn auch ihre Grenze benannt wird. Deshalb zuerst die Grenze, dann der Umfang.

20.1 Was sich von außen nicht nachrechnen lässt

Die Einzel-Hashes einer Buchung lassen sich von außen nicht nachrechnen. Der Grund ist kein Versäumnis, sondern Datenschutz: Die kanonische Vorlage enthält Felder, die nicht öffentlich sind — Beteiligte, Nachricht, Signatur. Wer sie nachrechnen könnte, könnte sie auch erraten.

Was von außen geprüft wird, ist deshalb die Struktur der Kette, nicht der Inhalt jeder einzelnen Zeile.

20.2 Was jede Person prüfen kann

• Lückenlosigkeit: ob die Buchungsnummern ohne Loch aufsteigen und die erste gegen den Genesis-Wert verkettet.
• Verkettung: ob der prev_hash jeder Buchung dem hash ihres Vorgängers entspricht.
• Merkle-Wurzel: ob sich aus den veröffentlichten Hashes dieselbe Wurzel ergibt, die der Anker nennt.
• Bitcoin-Nachweis: ob der hinterlegte OpenTimestamps-Beweis zu diesem Commitment gehört — unabhängig von Vermittco prüfbar.

Der Ketten-Export ist auch ohne Anmeldung abrufbar und gibt je Zeile ausschließlich seq, Zeitpunkt, Buchungsart, Betrag, hash und prev_hash heraus — höchstens 1.000 Zeilen je Seite, keine Nutzer, keine Nachrichten.

20.3 Was der öffentliche Überblick zeigt

Die Linie zwischen öffentlich und nicht öffentlich ist im Code ausdrücklich begründet: Betrag und Art ohne Beteiligte sind über den Überblick ohnehin sichtbar; alles, was Personen zuordenbar macht, bleibt draußen.

21 Gründer-Tresor

Der Gründer-Tresor ist ein einzelnes System-Wallet mit eigenem Anmelde-Konto. Er ist bewusst so gebaut, dass er keine Sonderrechte im Kassenbuch hat.

21.1 Was er nicht darf

• Keine eigene Buchungsart. Die Reserve entsteht über dieselbe Team-Vergabe wie jede andere Gutschrift — öffentlich sichtbar und unter der Höchstmenge.
• Keine eigene Kanonform. Ausgaben aus dem Tresor sind gewöhnliche Überweisungen mit ECDSA-Signatur, derselben Nonce-Kette und derselben Netzwerkgebühr wie bei jedem Nutzer.
• Kein Willkommensbonus. Bei der Einrichtung entsteht nur der Marker für ein angelegtes Wallet, mit Betrag 0.
• Keine gelockerte Abzugs-Bremse. Die Verfassungs-Grenze gilt unverändert.

Es gibt genau eine Sonderregel, und sie ist rein technisch: Die Sperrprüfung liefert für den Tresor immer „nicht gesperrt", weil das System-Konto keine Profilzeile besitzt und die Grundregel „kein Profil heißt gesperrt" sonst jede Tresor-Überweisung blockieren würde.

21.2 Schlüssel und Einmaligkeit

Der private Schlüssel des Tresors liegt nur auf dem Einrichtungs-Gerät und auf Papier. Anders als bei Nutzer-Wallets verwahrt der Server hier bewusst kein verschlüsseltes Backup — das Backup-Feld bleibt leer, und die Einrichtungsfunktion erzwingt das.

Der Tresor lässt sich genau einmal einrichten: Die Einrichtung nimmt den Ketten-Lock und bricht mit „Tresor existiert bereits" ab, sobald ein Tresor eingetragen ist.

21.3 Was öffentlich ist

Nach außen erscheinen nur zwei Angaben: der Bestand als Betrag und die Tatsache, dass ein Tresor existiert. Die Kennung des Tresors wird nie öffentlich ausgegeben — auch in der Mengen-Übersicht steht er nur als Betrag, nie als Kennung. Jeder Einblick des Teams in den Tresor wird protokolliert, weshalb die zugehörige Abfrage bewusst nicht als reine Leseoperation gilt.

22 Wie eine Verfassungs-Fassung entsteht

Abschnitt 7 nennt den Wortlaut der geltenden Fassung. Hier steht, wie eine Fassung technisch zustande kommt — und warum sie sich nicht zurücknehmen lässt.

22.1 Die Tabelle ist unveränderlich

Die Verfassung liegt in einer eigenen Tabelle mit Fassungsnummer, Artikeln, kanonischem Text, Hash und der Nummer der zugehörigen Ketten-Buchung. Sie ist für jeden lesbar — auch ohne Anmeldung — und durch dieselbe Art von Schutz gesichert wie das Journal: kein Ändern, kein Löschen, kein Leeren, für keine Rolle.

22.2 Der Ablauf einer Änderung

1. Prüfung, ob der Aufrufer zum Team gehört.
2. Prüfung, ob die übergebenen Artikel ein gültiges Objekt sind.
3. Pflichtfeld: Das Abzugs-Limit muss vorhanden und mindestens 0 sein. Die Bremse lässt sich nicht durch Weglassen abschalten.
4. Ketten-Lock nehmen.
5. Neue Fassungsnummer bilden: höchste vorhandene Nummer plus eins. Es wird nie überschrieben, nur angehängt.
6. Kanonform bilden und mit SHA-256 hashen. Weil die Datenbank die Artikel in eine geordnete Normalform bringt, ist der Hash reproduzierbar.
7. Zuerst die Ketten-Buchung schreiben — mit dem Hash als Verweis. Die Fassung steht damit in derselben Hash-Kette wie jede Zahlung und läuft im täglichen Bitcoin-Anker mit.
8. Danach die Fassung eintragen, mit der Nummer der eben entstandenen Buchung.
9. Vorgang im Team-Protokoll festhalten.

kanon = vcverfassung1|<version>|<artikel-json>
hash  = sha256hex(utf8(kanon))

22.3 Die Abzugs-Bremse im Detail

Vor jedem Team-Abzug liest die Abzugs-Funktion das Limit aus der jeweils höchsten Verfassungs-Fassung und summiert alle Abzüge der letzten 24 Stunden dagegen. Vier Eigenschaften machen die Bremse belastbar:

In der geltenden Fassung stehen neben den sechs Artikeln drei feste Zahlenwerte: das Abzugs-Limit von 1.000 VCC je 24 Stunden, die Höchstmenge von 21.000.000 und der Kauf-Schalter mit dem Wert aus. Wie viel vom Tageslimit bereits verbraucht ist, kann jede Person öffentlich abfragen.

23 Coins angeschlossener Unternehmen

Es gibt zwei getrennte Wege, auf denen ein Unternehmen mit dem System zu tun haben kann: ein eigener Token auf derselben Kette (Abschnitt 8) und ein Anschluss ans Wirtschafts-Netzwerk. Beide sind streng davon getrennt, VCC zu erzeugen.

23.1 Firmen-Token auf derselben Kette

Die vier Token-Buchungsarten — anlegen, prägen, überweisen, vernichten — laufen durch dieselbe Buchungsfunktion und stehen damit in derselben Hash-Kette und im selben Bitcoin-Anker. Sie bewegen dabei bewusst kein VCC: Die Token-Guthaben werden daneben geführt, in derselben Transaktion und unter demselben Ketten-Lock. Ein Token-Transfer braucht die Signatur des sendenden Kunden und verbraucht eine eigene, je Token-Konto getrennte Nonce:

vccoin2|tokentransfer|<uid>|<token_id>|<to>|<amount fix8>|<nonce>|<memo>

23.2 Das Anschluss-Paket

Für den Anschluss ans Wirtschafts-Netzwerk gibt es ein offenes Paket unter MIT-Lizenz. Es enthält eine sprachunabhängige Protokoll-Beschreibung — maßgeblich ist dieses Dokument, nicht eine bestimmte Programmiersprache —, eine Anbindungs-Bibliothek ohne Fremdabhängigkeiten in zwei Modulformaten, eine Schema-Vorlage für die eigene Datenbank, vier Beispiele und einen Selbsttest, der die Bibliothek gegen einen eingebauten Attrappen-Server prüft: ohne Netz und ohne Schlüssel.

Die Schema-Vorlage läuft in der eigenen Datenbank des Unternehmens: eigener Kategorienbaum, eigenes Token-Register, eigene Kennzahlen mit Datenständen, ein Lieferprotokoll. Sie berührt keine Vermittco-Tabelle, hat keinen Fremdschlüssel dorthin, erzeugt kein VCC und kennt keinen Kurs. Die Verbindung geht ausschließlich vom Firmen-Server aus; es gibt keinen Weg von Vermittco in das Firmensystem.

23.3 Was geliefert wird

Ein Grundschema aus 17 Kennzahlen dient als gemeinsame Sprache; niemand muss alle liefern, und eigene Namen sind erlaubt. Für Kennzahlen, bei denen ein höherer Wert schlechter ist — Erstattungen, Ausfall-, Betrugs- und Stornoquote, Beschwerden, Meldungen, Rückläufer —, ist die Richtung fest hinterlegt und nicht vom Unternehmen wählbar.

23.4 Vom Anschluss zur Wirkung

Ein Unternehmen durchläuft feste Zustände: registriert → geprüft → Testphase → aktiv, aus jedem Zustand heraus gesperrt, mit Rückwegen aus Testphase und Sperre zurück auf geprüft und von aktiv zurück in die Testphase. Nur das Team schaltet um. Vor der Testphase muss ein Zugangsschlüssel existieren; für aktiv muss die Testphase abgelaufen und mindestens eine Periode Kennzahlen geliefert sein. Kennzahlen werden erst ab geprüft überhaupt angenommen. Die Aufnahme selbst erscheint als Marker mit Betrag 0 in der Kette.

Der Einfluss eines Unternehmens ergibt sich aus fünf Faktoren:

beitrag = eigener Index  ×  Vertrauenswert/100  ×  Zeitfaktor  ×  Risiko  ×  Testphase

Vertrauenswert : 0 bis 100, Vorgabe 50 — wird ausschließlich vom Team gesetzt
Zeitfaktor     : gelieferte Perioden / 12, höchstens 1
Risiko         : sinkt mit offenen Risiko-Ereignissen der letzten 90 Tage
Testphase      : steigt linear über 90 Tage von 0 auf 1; außerhalb der Testphase 1

Der eigene Index eines Unternehmens ist der Mittelwert über die Rangplätze seiner eigenen Kennzahlen im eigenen Zeitfenster. Liegen für eine Kennzahl weniger als drei Perioden vor, gilt der neutrale Wert 50 — es wird kein guter und kein schlechter Wert erfunden.

23.5 Die Einfluss-Kappung

Damit ein großes Unternehmen das Netzwerk nicht dominiert, wird das Gewicht in vier Schritten gebildet: Roh-Gewicht aus dem gemeldeten Volumen, Normalisierung auf einen Anteil, Kappung nach der Normalisierung auf höchstens 25 Prozent, und Umverteilung der frei gewordenen Masse proportional auf die ungekappten. Steigt dabei jemand über die Grenze, wird erneut gekappt — begrenzt auf höchstens so viele Runden, wie es Unternehmen gibt, plus eine.

Ein im Code hinterlegtes Zahlenbeispiel zeigt die Wirkung: Drei Unternehmen mit den Rohanteilen 80, 15 und 5 Prozent landen bei einer Kappungsgrenze von 25 Prozent bei je einem Drittel — also beim schlichten Mittelwert. Einfluss wächst mit Historie, nicht mit Größe.

Wer in einer Periode keine Kennzahlen liefert, dessen alter Beitrag wird auf null gesetzt statt weitergezählt — und das Team bekommt einen Hinweis, keine automatische Herabstufung.

23.6 Warum ein Unternehmen keine VCC erzeugen kann

• Alle Schnittstellen-Funktionen sind für angemeldete Nutzer gesperrt und ausschließlich über die vorgelagerte Prüfschicht erreichbar.
• Die einzige Buchung, die aus diesem gesamten Bereich entstehen kann, ist der Aufnahme-Marker mit Betrag 0. Sämtliche Buchungen dieses Bereichs tragen Betrag 0 und bewegen kein Guthaben.
• Ein Umwandlungs-Antrag wird ausschließlich protokolliert. Die Antwort trägt ausdrücklich „nicht ausgeführt" und den Satz, dass eine Umwandlung nur nach gesonderter, versionierter Freigabe erfolgt.
• Die Kennung des Unternehmens stammt immer aus dem geprüften Zugangsschlüssel, nie aus der Anfrage. Eine fremde Kennung im Rumpf wird abgewiesen; verglichen wird konstantzeitig.
• Zugangsschlüssel werden nur als Hash gespeichert, und die Schlüssel-Tabelle hat gar keine Lese-Regel — kein Client bekommt je einen Hash zu sehen.
• Kurs- oder Umrechnungsangaben zu VCC in gelieferten Token-Angaben werden mit einem Fehler abgewiesen.

Zusätzlich ist die Rechtelage als Daten hinterlegt und öffentlich lesbar. Die Matrix beantwortet zehn Fragen mit Nein: eigene Token selbst in VCC umwandeln; VCC erzeugen, vergeben oder verbrennen; die Höchstmenge verändern; Formel, Gewichte oder Rechenweg des Index ändern; den eigenen Vertrauenswert oder die eigene Kappungsgrenze setzen; den Netzwerk-Index dominieren; gelieferte Kennzahlen rückwirkend ändern; Daten anderer Unternehmen einsehen; Nutzerdaten der Plattform abrufen; einen Preis oder Kurs für VCC festlegen. Sieben weitere Zeilen beantwortet sie mit Ja — darunter ausdrücklich, dass ein Umwandlungs-Antrag gestellt werden darf, ohne dass daraus eine Umwandlung folgt.

Öffentlich sichtbar ist je Unternehmen nur Name, Kennung, Zustand, der eigene Index und der gekappte Beitrag; zusammengefasste Aktivität erscheint erst ab drei beitragenden Unternehmen. Jede Antwort der Schnittstelle führt zwei feste Texte mit: den Pflicht-Rechtshinweis und den Satz, dass der Index eine Messgröße ist und keine Preisgarantie.

24 Das Wirtschaftssystem

Über dem Kassenbuch liegt eine zweite Schicht, die etwas ganz anderes tut als Coins zu bewegen: Sie misst. Monat für Monat entsteht aus internen Plattform-Zahlen und öffentlichen Wirtschaftsdaten eine einzige Zahl zwischen 0 und 100 — der Economic Index.

24.1 Die Formel

Eine neue Fassung entsteht nur unter harten Bedingungen: mindestens zwei Bereiche, jedes Gewicht eine Zahl und mindestens 0, Summe exakt 100, Fassungsnummer gleich der höchsten plus eins. Alte Fassungen bleiben stehen, und bereits gerechnete Läufe werden nie neu bewertet. Auch die Formel-Fassung selbst wird als Marker in der Hash-Kette verbucht.

24.2 Die Kennzahlen

Das Register umfasst heute 75 Kennzahlen: 30 interne, 32 aus den Sachgebieten und 13 externe. Bei den Sachgebieten liefern sechs je fünf Kennzahlen; das Sachgebiet Dienstleistungen liefert nur zwei, weil es dort keine eigene Angebots-Tabelle und keinen eigenen Suchtyp gibt — und das steht so im Register, statt still zwei Nullen einzutragen.

24.3 Wie aus Rohzahlen ein Punktwert wird

Rohzahlen sind unvergleichbar — Euro neben Prozent neben Stückzahlen. Deshalb wird jede Kennzahl in einen Punktwert von 0 bis 100 überführt, und zwar in dieser Reihenfolge:

1. Zielband (nur für die Teuerung): Der Wert 2 Prozent ergibt 100 Punkte, ein Wert ab 6 Prozent oder bis −2 Prozent ergibt 0. Diese Kennzahl braucht keine Vergleichsverteilung.
2. Zu wenig Vergleich: Liegen weniger als zwei Vergleichswerte vor, ist das Ergebnis 50 — neutral. Es wird nie ein guter oder schlechter Wert erfunden, wo keine Verteilung existiert.
3. Kappung vor jeder Normalisierung: Die Verteilung und der zu bewertende Wert werden am 1. und 99. Perzentil gekappt, damit ein einzelner Ausnahmemonat nicht die ganze Skala verzieht.
4. Verfahren: in der Regel der Rangplatz — der Anteil der Vergleichswerte, die nicht größer sind. Daneben stehen Standardabweichung und Spannweiten-Normierung zur Verfügung; ist die Verteilung entartet, ist das Ergebnis wieder 50.
5. Abschluss: auf 0 bis 100 klemmen, bei umgekehrter Richtung spiegeln, auf vier Stellen runden.

Anschließend werden die letzten Perioden zeitgewichtet zusammengefasst: Das Gewicht eines Wertes halbiert sich alle drei Perioden. Wichtig dabei — erst wird gegen dieselbe Verteilung normalisiert, dann geglättet, nicht umgekehrt. Das Vergleichsfenster umfasst 36 Monate.

24.4 Fehlende Werte werden nicht erfunden

Fehlt einer Komponente jede Messung, wird sie nicht als 0 gewertet — das wäre die schlechteste denkbare Bewertung für ein fehlendes Datum. Stattdessen wird ihr Gewicht proportional auf die vorhandenen Komponenten umgelegt, und die fehlende Komponente wird mit ihrem ursprünglichen Gewicht und dem Grund im Lauf protokolliert. Gibt es überhaupt keine Kennzahl, bricht der Lauf ab, statt eine Zahl zu erfinden.

24.5 Woher die externen Daten kommen

Abgeschaltete Reihen tragen ihre Begründung im Datensatz: ein Reihenschlüssel, der gegengeprüft werden muss; ein Einheitencode, der ein Basisjahr enthält; eine Kennung, die eine Version trägt; ein Dienst, der zeitweise nicht erreichbar ist; oder schlicht eine Lizenzpflicht. Der Leitsatz dazu steht wörtlich im Code: „Eine falsche Reihe wäre schlimmer als eine fehlende."

Die lizenzpflichtigen Quellen sind doppelt abgesichert: nicht nur im Register abgeschaltet, sondern zusätzlich in der abrufenden Schicht gesperrt, die außerdem nur eine feste Liste erlaubter Rechnernamen anspricht. Weitere harte Grenzen: 60 Monate Rückblick, 60 Reihen je Lauf, 72 Beobachtungen je Reihe, 15 Sekunden je Abruf, 250 Millisekunden Pause dazwischen.

24.6 Point-in-Time: Zahlen werden nie überschrieben

Wirtschaftsdaten werden nachträglich korrigiert — das ist normal. Ein System, das die Korrektur einfach über die alte Zahl schreibt, kann hinterher nicht mehr sagen, was es damals wusste. Hier ist der Datenstand deshalb Teil des Schlüssels: Eine Beobachtung wird durch Reihe, Periode und Datenstand identifiziert, und ein Schutz weist Ändern und Löschen für alle Rollen ab. Der Grundsatz steht wörtlich im Code: „Eine Korrektur ist immer ein neuer Datenstand."

• Erste Meldung → Datenstand 1.
• Gleicher Wert erneut gemeldet → gar keine neue Zeile.
• Abweichender Wert → neuer Datenstand mit Verweis auf den abgelösten.
• Ein Veröffentlichungsdatum aus der Zukunft wird auf jetzt gesetzt; ein neuer Datenstand darf nie ein älteres Veröffentlichungsdatum tragen als der abgelöste.

Die Abfrage zu einem Stichtag liefert daher genau den Wert, der an diesem Tag bekannt war — und nichts, wenn damals nichts bekannt war. Sie wirft nie einen Fehler. Auch beim Veröffentlichungsdatum wird bewusst konservativ gerechnet: Nennt eine Quelle keines, gilt der Zeitpunkt des Abrufs. Es wird nie behauptet, eine Zahl sei früher bekannt gewesen, als sie es war.

Beim Einlesen prüft eine eigene Stufe jede Zahl: Ist die Reihe bekannt und aktiv? Ist die Periode lesbar und nicht in der Zukunft? Liegt ein Zahlenwert vor? Liegt er im hinterlegten Plausibilitätsband? Ist der Sprung zur letzten früheren Periode erklärbar — wobei eine Korrektur derselben Periode ausdrücklich kein Sprung ist? Jeder Fehlschlag schreibt eine Notiz, und die Zahl wird nicht übernommen. Die Rohantwort der Quelle wird vor dem Auswerten unverändert abgelegt; der rechnende Teil geht selbst nie ins Netz.

24.7 Vom Lauf bis in die Bitcoin-Blockchain

Läufe sind unveränderlich und je Periode und Formel-Fassung nur einmal möglich; ein bereits vorhandener Lauf wird unverändert zurückgegeben, statt neu gerechnet zu werden. Ein noch laufender Monat wird gar nicht erst berechnet. Aus allen Eingangswerten entsteht ein Eingangs-Hash, der jede benutzte Zahl mit ihrem Datenstand festschreibt.

24.8 Bereiche unter der Höchstmenge

Die Höchstmenge ist rechnerisch in acht Bereiche aufgeteilt: ein Kernbereich für normale VCC und sieben Sachgebiete.

Die Zuordnung einer Buchung zu einem Bereich ist eine reine Rechnung ohne Tabellenzugriff — deshalb lässt sich für jede Zeile des Kassenbuchs rückwirkend nachrechnen, welcher Bereich sie getragen hat.

24.9 Die Korb-Regel

Eine unveränderliche, gehashte und in der Kette verankerte Regel hält fest, was für einen etwaigen künftigen Umtausch gälte: kein fester Eins-zu-eins-Kurs; ein Umtausch dürfte den Gesamtvorrat nie erhöhen und nie über 21.000.000 hinausgehen; nur innerhalb der festgelegten Anteile; nur nach öffentlich hinterlegter, versionierter Regel; und erst nach ausdrücklicher Freigabe. Neue Sachgebiete und angeschlossene Unternehmen bekommen keinen Anteil aus dem Korb. Der Schlusssatz der Regel lautet wörtlich: Diese Regel ist eine wirtschaftliche Festlegung — kein Preis, keine Garantie, kein Anspruch auf Auszahlung.

Umtausch-Buchungen sind bewusst nicht gebaut.

25 Schutz vor Manipulation

Eine Wirtschafts-Messgröße lädt zum Aufblähen ein: Wer viele Konten anlegt und im Kreis handelt, könnte Zahlen schöner aussehen lassen. Dagegen läuft eine Mustererkennung auf den vorhandenen Bestellungen und Buchungen.

25.1 Die Risikobewertung

Zu einem Konto lässt sich eine Bewertung aus sieben Einzelsignalen abrufen, jedes von 0 bis 100 und alle einzeln ausgewiesen: Kontoalter (Gewicht 15), offene Hinweise und Fälle (25), Meldungen (15), Erstattungsquote (15), Zahlungsrisiko (15), Sperrliste (10) und Coin-Durchlauf (5). Unter 30 gilt als niedrig, unter 60 als mittel, darüber als hoch. Die Antwort sagt ausdrücklich dazu: Es hängt keine Sperre und kein Limit daran.

25.2 Was bewusst nicht gebaut ist

• Zwei weitere Muster — Datenmanipulation und Ausreißer in externen Datenreihen — sind bewusst nicht umgesetzt, mit Begründung und benanntem Andockpunkt. Für externe Reihen greift stattdessen die Prüfung beim Einlesen (Abschnitt 24.6).
• Geldwäsche-Durchsetzung ist als Schalter vorhanden, steht auf aus und wird an keiner Stelle ausgewertet: Diese Schicht blockiert heute keinen einzigen Transfer. Die Felder für Tages- und Monatslimits sind Notizfelder, die kein Programmteil liest.
• Die Quarantäne ist bereitgestellt und für das Unternehmens-Netzwerk wirksam; auf den Vermittco-Index wirkt sie heute nicht.
• Der Durchlauf der Mustererkennung ist heute kein Nachtlauf, sondern wird vom Team angestoßen.

26 Offline-Betrieb und Turbo

Das Wallet bleibt auch ohne Verbindung benutzbar — allerdings nur so weit, wie es ohne Wahrheitsverlust geht.

26.1 Der Offline-Abzug

Auf dem Gerät liegt ein kleiner Abzug für die Anzeige: Kontostand, angelegte Menge, die letzten zehn eigenen Buchungen und ein Zeitstempel. Was er bewusst nicht enthält, ist der Wiederholungs-Zähler: Ein zwischengespeicherter Zähler würde den Replay-Schutz aushebeln. Die Nonce wird deshalb ausnahmslos frisch vom Server geholt.

26.2 Der Postausgang

Eine Überweisung, die offline entsteht, wandert in einen Postausgang von höchstens fünf Einträgen und wird gesendet, sobald die Verbindung zurück ist. Zwei Vorkehrungen verhindern dabei Doppelzahlungen: Die Abarbeitung läuft unter einer geräteweiten Sperre, sodass zwei geöffnete Tabs nicht denselben Eintrag senden, und ein Erfolg wird sofort festgeschrieben, noch innerhalb der Schleife, statt erst am Ende.

26.3 Turbo

Für Leseanfragen gibt es einen verschlüsselten Zwischenspeicher auf dem Gerät (AES-GCM-256 in einer eigenen IndexedDB) mit einer Haltbarkeit je Abruf — Vorgabe 30 Sekunden, Untergrenze 1 Sekunde; der öffentliche Explorer nutzt 55 Sekunden. Die Hausregel dazu steht wörtlich im Code und ist für ein Guthaben-System entscheidend:

Ergänzend hält ein Hintergrunddienst versionierte Dateien vor, sodass die Oberfläche auch bei schlechter Verbindung schnell steht. Beides betrifft ausschließlich Darstellung und Ladezeit — nie eine Buchung.

27 Datenschutz: was öffentlich ist und was nie

Dieser Abschnitt sagt unbequeme Dinge, weil ein Whitepaper, das nur die Verschlüsselung aufzählt, den Leser täuscht. Verschlüsselt ist am Coin genau eine Sache — alles andere steht im Klartext in der Datenbank des Betreibers.

27.1 Was der Betreiber kann und was nicht

Jede dieser Handlungen hinterlässt eine unlöschbare Zeile im Kassenbuch. Der Unterschied zu einem gewöhnlichen Punktesystem liegt also nicht darin, dass der Betreiber nichts könnte — sondern darin, dass er nichts heimlich kann.

27.2 Auf dem eigenen Gerät

Auch dort liegt nicht alles verschlüsselt. Im Klartext in der lokalen Datenbank stehen der Offline-Abzug, der Postausgang und das Wach-Protokoll. Die herunterladbare Datei mit dem Wiederherstellungscode ist eine unverschlüsselte Textdatei — sie gehört behandelt wie ein Schlüssel, nicht wie eine Notiz. Verschlüsselt im engeren Sinn ist auf dem Gerät nur der private Schlüssel selbst, und zwar dadurch, dass er als nicht auslesbares Objekt vorliegt; ein zusätzliches Passwort schützt ihn nicht.

28 Grenzen des Systems

Ein Whitepaper ist nur so glaubwürdig wie sein ehrlichster Abschnitt. Hier steht, was VCC nicht ist und was heute noch nicht wirkt.

28.1 Was es nicht gibt

• Keine eigene Blockchain und keine Bitcoin-Transaktionen. Verankert wird ein Zeitnachweis über OpenTimestamps — kein Bitcoin-Wallet, keine Gebühr, keine Kette im Netzwerk-Sinn.
• Kein Konsens über Buchungen. Es gibt Proof-of-Work als Ausgabeweg für Coins, aber kein Netzwerk, das über die Gültigkeit von Buchungen abstimmt. Wächter bezeugen einen Stand — sie geben nichts frei.
• Keine Mehrgeräte-Synchronisation von Schlüsseln, keine vorwärtsgerichtete Geheimhaltung, keine Unterstützung für Hardware-Schlüssel.
• Kein Kauf-, Verkaufs- oder Kurs-Pfad. Der Kauf-Schalter ist ein reiner Platzhalter mit dem Wert aus, den keine Funktion des Systems setzen kann — er ist in jeder Fassung der Einstellungs-Funktion ausdrücklich ausgenommen.
• Kein Euro-Feld, kein Preis, kein Wechselkurs in irgendeiner Coin-Tabelle oder Antwort. Umtausch-Buchungen sind bewusst nicht gebaut.

28.2 Wo die Prüfbarkeit endet

• Die Einzel-Hashes lassen sich von außen nicht nachrechnen, weil die kanonische Vorlage nicht-öffentliche Felder enthält. Geprüft wird die Struktur.
• Die Signaturprüfung findet ausschließlich in der vorgelagerten Prüfschicht statt; die buchenden Datenbank-Funktionen vertrauen ihr.
• Bei der Ersteinrichtung eines Wallets prüft der Server nur die Form des Fingerabdrucks, nicht dessen Zugehörigkeit zum übergebenen Schlüssel. Beim Schlüsselwechsel und bei der Tresor-Einrichtung wird sie dagegen nachgerechnet. Die Auswirkung bliebe auf das eigene Wallet beschränkt, weil Signaturen ohnehin gegen den gespeicherten öffentlichen Schlüssel geprüft werden — aber der Satz „der Server prüft das immer" wäre falsch, und deshalb steht er hier nicht.

28.3 Gebaut, aber heute ohne Wirkung

28.4 Was ein Nutzer selbst verlieren kann

Gehen Gerät und Wiederherstellungscode gemeinsam verloren, ist das Schlüsselmaterial fort — endgültig, für alle. Das Guthaben bleibt bestehen, aber es lässt sich erst wieder bewegen, nachdem das Team das Wallet schlüssellos gestellt hat und ein neues Schlüsselpaar eingerichtet wurde. Das ist der Preis der Schlüssel-Hoheit: Wer allein signieren kann, kann sich auch allein aussperren.

29 Anhang: Kanonformen-Referenz

Die folgenden Kanonformen sind Verträge des Systems: Sie werden an allen Prüfstellen byte-identisch verwendet und niemals stillschweigend geändert. Spitze Klammern bezeichnen Platzhalter; fix8 bezeichnet einen gleitkommafreien Betrags-String mit exakt 8 Nachkommastellen.

Signatur-Kanonformen (vccoin2 — ECDSA P-256 / SHA-256, P1363 64 Byte hex)

Überweisung       vccoin2|transfer|<from_uid>|<to_uid>|<amount fix8>|<nonce>|<memo>
Schlüssel-Wechsel vccoin2|rotate|<uid>|<neuer_fingerprint>|<nonce>
Token-Transfer    vccoin2|tokentransfer|<uid>|<token_id>|<to>|<amount fix8>|<nonce>|<memo>
Bezeugung         vccoin2|witness|<uid>|<seq>|<head_hash>|<merkle_root>|<nonce>

nonce = spend_seq + 1 des jeweiligen Kontos (je Token-Konto eigene Sequenz);
jede Nonce wird genau einmal akzeptiert (Replay-Schutz).
Der Gründer-Tresor benutzt exakt die transfer-Form mit seiner eigenen Kennung
als Absender — es gibt für ihn KEINE eigene Kanonform.

amount fix8 = ^(0|[1-9][0-9]{0,12})\.[0-9]{8}$   — verbatim, nie als Gleitkommazahl
memo        = höchstens 140 Zeichen, keine Steuerzeichen

Wallet-Adresse

koerper  = 'VCC1' || B32C( sha256('vccaddr1|' || user_id)[1..16] )
pruef    =           B32C( sha256('vccsum1|'  || koerper)[1..3]  )[1..4]
adresse  = koerper || pruef                        →  immer 34 Zeichen

B32C = Crockford-Base32 über 0123456789ABCDEFGHJKMNPQRSTVWXYZ
       (ohne I, L, O, U), MSB-first, ohne Polsterzeichen
       16 Byte → 26 Zeichen · 3 Byte → 5 Zeichen, davon die ersten 4

Gegenprobe   11111111-2222-3333-4444-555555555555
          →  VCC1H1M0EZB8ZFAA978FZFB62391CGCDVW

Eingabe: Trenner entfallen, Großschreibung, I→1, L→1, O→0;
QR-Kurzform mit dem Präfix "vcc:" wird akzeptiert.
Die Adresse wird VOR dem Signieren zur Kennung aufgelöst —
die Kanonformen enthalten weiterhin Kennungen, keine Adressen.

Journal-Preimage (Hash-Kette)

preimage = seq|prev_hash|ts_us|kind|from|to|amount|<utf8len(memo)>:memo|ref|client_sig
hash     = sha256hex(utf8(preimage))

ts_us   = Zeitstempel UTC im Format YYYY-MM-DD"T"HH24:MI:SS.US"Z"
amount  = v1 (seq < Cutover): Format FM…0.00 (2 Nachkommastellen)
          v2 (ab Cutover):    Format FM…0.00000000 (8 Nachkommastellen)
memo    = mit UTF-8-Byte-Längen-Präfix (octet_length == TextEncoder-Länge)
Genesis = prev_hash der ersten Buchung ist der feste Wert "vccoin-genesis"
seq     = max(seq)+1 unter dem Ketten-Lock — lückenlos, bewusst keine Sequence
kind    = eine von 24 Buchungsarten (21 in der laufenden Datenbank erlaubt,
          3 Wirtschafts-Marker kommen mit dem nächsten Einspielen dazu);
          alle laufen durch dieselbe Vorlage

Merkle-Paarregel und Anker-Commitment

Blätter    = journal.hash (hex) in seq-Ordnung
parent     = sha256hex( utf8( links_hex || rechts_hex ) )
ungerader letzter Knoten steigt unverändert auf

commitment = sha256hex( head_hash || "|" || merkle_root )
→ die 32 Rohbytes des Commitments gehen an 3 OpenTimestamps-Kalender (täglich 03:50)

Proof-of-Work (Mining)

präfix = vcpow1|<uid>|<head_hash>|<salt_hex>|<issued_epoch>
msg    = präfix|nonce
gültig, wenn sha256hex(msg) mindestens difficulty_bits führende Null-Bits hat;
difficulty stammt aus der gespeicherten Server-Challenge (Ziel ~45 s, 16–30 Bits).

Merkle-Paarregel (Ergänzung)

Verkettet werden die HEX-ZEICHENKETTEN, nicht die Rohbytes.
Ein ungerader letzter Knoten steigt UNVERÄNDERT auf (kein Verdoppeln).
Bei genau einer Buchung ist die Wurzel deren Hash.
Anker ohne merkle_root (Alt-Bestand) bleiben gültig: dort war der head_hash
das Commitment; die Prüfung fällt für diese Anker auf jene Regel zurück.

Verfassung

kanon = vcverfassung1|<version>|<artikel-json>
hash  = sha256hex(utf8(kanon))  →  als Referenz in der Ketten-Buchung (kind "verfassung")

Die Artikel werden als geordnete JSON-Normalform gehasht — der Hash ist damit
reproduzierbar. Eine Fassung wird nie überschrieben: neue Version = max + 1.

Wirtschafts-Formel und Korb-Regel

Formel  vcecoformel1|<version>|<komponenten-json>
        → sha256hex; Summe der Gewichte muss exakt 100 sein
        → als Ketten-Buchung (kind "eco_formula") verbucht

Korb    vcecokorb1|1|<korb-json>
        → sha256hex; unveränderlich, ebenfalls in der Kette verankert

Eingangs-Hash eines Index-Laufs

je Kennzahl eine Zeile:
vcecolauf1|<periode>|<formel_version>|<metric_key>|<quelle>|<datenstand>
          |<rohwert>|<normalisiert>|<gewicht>|<beitrag>

Rohwert  mit 'FM999999999990.00000000' (leer, wenn nicht vorhanden),
die drei Bewertungszahlen mit 'FM999999999990.0000'.
Zeilen aufsteigend sortiert, mit \n verbunden, sha256hex → inputs_hash
Zahlformate fest; der Lauf bucht kind "eco_index" (Betrag 0) ZUERST in die Kette
und schreibt sich erst DANACH in die Lauf-Tabelle.

Mengenprüfung (kein Kanonform, aber Vertrag)

prägende Buchungsarten:
  welcome · admin_grant · mining_reward · stake_reward · witness_reward

Summe(alle Kontostände) + Betrag  ≤  21.000.000
geprüft unter dem Ketten-Lock, vor der Vergabe der Buchungsnummer.
Die Höchstmenge ist Parameter keiner Verwaltungsfunktion.