Gradido-Konto: Technische Architektur, Besonderheiten und aktueller Stand

Executive Summary

Das Gradido-Konto ist ein in seiner Konzeption und technischen Umsetzung ein beispielloses Softwareprojekt, das Elemente eines Gemeinschaftswährungs-Systems, einer dezentralen Kommunikationsplattform und einer modernen Distributed-Ledger-Technologie (DLT) auf eine Art miteinander verbindet, die mit keiner herkömmlichen Blockchain-Architektur vollständig abbildbar wäre. Dieser Bericht analysiert und verifiziert die zentralen technischen Aussagen über das Gradido-Konto, vergleicht Blockchain-Alternativen und bewertet die gewählten Architekturentscheidungen.

1. Das Gradido-Konto: Konzeptionelle Grundlagen

1.1 Die dreifache Geldschöpfung und das aktive Grundeinkommen

Das Gradido-System basiert auf dem Konzept der Natürlichen Ökonomie des Lebens, das von Bernd Hückstädt und Margret Baier seit dem Jahr 2000 in der Gradido-Akademie für Wirtschaftsbionik entwickelt wurde. Das Modell sieht drei gleichwertige Geldschöpfungen von je 1.000 Gradido (GDD) pro Mensch pro Monat vor:

1. Aktives Grundeinkommen (AGE): 1.000 GDD monatlich für Gemeinwohl-Beiträge

2. Öffentlicher Haushalt: 1.000 GDD monatlich pro Kopf für staatliche Leistungen

3. Ausgleichs- und Umweltfonds (AUF): 1.000 GDD monatlich für Natur und Umwelt

Aktuell ist nur die erste Geldschöpfung (das aktive Grundeinkommen) produktiv implementiert. Die Roadmap sieht die zweite und dritte Geldschöpfung (öffentlicher Haushalt + Ausgleichs- und Umweltfonds) für 2027 vor. 

1.2 Aktives Grundeinkommen durch bedingungslose Teilhabe

Das aktive Grundeinkommen funktioniert nicht als bedingungsloses Einkommen im klassischen Sinn, sondern als leistungsbezogene Wertschätzung für Gemeinwohl-Beiträge. Jede Teilnehmerin und jeder Teilnehmer kann bis zu 20 GDD pro geleisteter Stunde für die Gemeinschaft erhalten, maximal 50 Stunden pro Monat, was einem Maximum von 1.000 GDD entspricht. Der Begriff bedingungslose Teilhabe bedeutet, dass die Teilnahme (nicht die Gegenleistung) bedingungslos ist – jeder Mensch darf mitmachen.

2. Warum keine Standard-Blockchain? Technische Analyse

2.1 Das fundamentale Datenbankproblem: Kontinuierliche Vergänglichkeit

Der wohl wichtigste technische Grund, warum eine herkömmliche Blockchain für Gradido ungeeignet ist, liegt in der geplanten Vergänglichkeit von 50% im Jahr, die auf die Sekunde genau und kontinuierlich berechnet werden soll.

Wie Blockchains Daten speichern: Eine Blockchain ist ein unveränderliches, append-only-Ledger. Transaktionen werden in Blöcken gespeichert und können nicht nachträglich geändert werden. Bitcoin verwendet das UTXO-Modell (Unspent Transaction Output), bei dem jede Transaktion bestehende UTXOs als Inputs verbraucht und neue als Outputs erzeugt. Ethereum verwendet ein Account-Modell, bei dem Kontostände als globaler Zustand gespeichert werden.

Das Problem: Bei Gradido würde ein Kontostand von 100 GDD ohne jede weitere Transaktion durch die Vergänglichkeit kontinuierlich kleiner werden. Ein UTXO-Modell (Bitcoin) kann das nicht abbilden, weil keine Transaktion stattgefunden hat – es gibt keinen Input, keinen Output. Das Account-Modell (Ethereum) müsste den Zustand dauerhaft aktualisieren, was Millionen oder Milliarden von automatischen Zustandsänderungen pro Sekunde für alle Konten weltweit bedeuten würde – technisch und wirtschaftlich nicht darstellbar in einer öffentlichen Blockchain.

Die Vergänglichkeitsformel ist dabei nicht trivial: Eine einfache Division von 50% durch 12 ergibt nicht den korrekten monatlichen Prozentsatz, da der zu vergebende Betrag immer kleiner wird. Der korrekte monatliche Vergänglichkeitssatz liegt bei ca. 5,61%, sodass 100 GDD nach zwölf Monaten auf 50 GDD sinken. Die Berechnung auf Sekundenebene erfordert eine hochpräzise mathematische Bibliothek.

2.2 Das Problem der gemeinschaftlichen Verifikation

Gradido erfordert soziale Verifikation: Moderatoren, die Mitglieder persönlich kennen und deren Gemeinwohl-Beiträge bestätigen. Blockchains sind darauf ausgelegt, Transaktionen ohne Vertrauen durch mathematischen Beweis zu verifizieren (Trustless Design). Die Gradido-Logik dreht dieses Prinzip um: Vertrauen ist das Design. Menschen bestätigen Menschen.

Smart Contracts auf Ethereum könnten zwar soziale Governance implementieren, sind aber auf On-Chain-Daten beschränkt und können nicht verifizieren, ob eine Person tatsächlich eine Stunde Gemeinschaftsarbeit geleistet hat. Das erfordert Off-Chain-Systeme und menschliche Moderation, die besser in einer flexiblen Datenbankarchitektur abgebildet werden können.

2.3 Bitcoin und der Proof-of-Work: Energieverbrauch

Bitcoin verbraucht durch Proof-of-Work enorme Energiemengen, weil viele Rechenaufgaben gelöst werden müssen. Eine einzelne Bitcoin-Transaktion verbraucht durchschnittlich 1.200–1.450 kWh Strom (Stand 2025/2026). Nach offiziellen Hedera-Daten von 2021 lag der Verbrauch bei 1.736,85 kWh pro Bitcoin-Transaktion im Vergleich zu 0,00017 kWh bei Hedera. Der gesamte jährliche Bitcoin-Netzwerkverbrauch liegt bei 150–200 TWh, vergleichbar mit dem Stromverbrauch Polens. Mehr als 99% dieses Verbrauchs entfallen auf den Proof-of-Work-Konsensmechanismus.

2.4 Moderne DLT-Alternativen: Energieeffizienz im Vergleich

Es gibt inzwischen moderne, wesentlich energieeffizientere Blockchains. Ethereum zum Beispiel hat nach dem Wechsel zu Proof-of-Stake im September 2022 seinen Energieverbrauch um 99,95% reduziert. Algorand verbraucht nur etwa 0,000008 kWh pro Transaktion – das sind rund 150 Millionen Mal weniger als Bitcoin. Dennoch blieben strukturelle Inkompatibilitäten mit der Gradido-Logik bestehen (s.o.).

2.5 Bitcoin-Transaktionsgeschwindigkeit

Das Bitcoin-Netzwerk verarbeitet nur etwa 7 Transaktionen pro Sekunde und erfordert typischerweise 6 Blockbestätigungen für endgültige Sicherheit – das dauert im Schnitt 60 Minuten. Im Vergleich dazu erreicht Hedera Transaktionsfinalität in 3–5 Sekunden.

3. Die Gradido-Architektur: Datenbank + Federation + DLT

3.1 Relationale Datenbank als Kernsystem

Das Gradido-Konto nutzt als Backend ein relationales Datenbanksystem (MariaDB/MySQL) mit einer GraphQL/Business-Logic-Schicht. Diese Architektur bietet mehrere Vorteile gegenüber einer reinen Blockchain-Lösung:

• Flexibilität: Kontostände können sekundengenau und effizient durch Berechnungen aktualisiert werden, ohne eine On-Chain-Transaktion zu erzeugen

• Komplexe soziale Logik: Moderatoren-Workflow, Gemeinwohl-Beiträge und Community-Governance lassen sich in relationalen Datenbanken natürlich abbilden

• Skalierbarkeit: Für kleine und mittlere Communities ist eine Datenbank deutlich effizienter als eine Blockchain

3.2 Dezentrale Community-Server und Federation

Mit Gradido 2.0 wurden dezentrale Community-Server eingeführt, die jede Community autonom betreiben kann, sofern sie über die technischen Kenntnisse verfügt. Der Quellcode ist Open Source und auf GitHub verfügbar. Das Konzept der Federation – Server, die sich gegenseitig erkennen und verschlüsselt Daten austauschen – entspricht etablierten Protokollen wie ActivityPub, das bereits für das dezentrale Fediverse (Mastodon, Pixelfed u.a.) genutzt wird. Die Gradido-Kreise-Kommunikationsplattform wurde im Juni 2024 gestartet und ist in das Gradido-Konto integriert.

3.3 Cross-Community-Transaktionen

Gradido ermöglicht Community-übergreifende Transaktionen. Laut Roadmap sollen Cross-Community-Transaktionen via Link noch im Mai 2026 produktiv geschaltet werden, mit E-Mail-Benachrichtigungen. Die Absicherung gegen Man-in-the-Middle-Angriffe (Verschlüsselung) erfolgte bereits im Juli 2025. Dies ist eine technisch anspruchsvolle Lösung, da Community-Server verschiedene Datenhaltungen haben und ein sicherer, verifizierter Austausch über Serverbereiche hinweg implementiert werden musste.

3.4 Gradido-Kreise: Kommunikationsplattform

Eine Kommunikationsplattform (Gradido-Kreise) mit überschaubaren Gruppen (so genannte Kreise) mit zwei bis drei Moderatoren, die ihre Mitglieder kennen. Größere Communities können viele Kreisen enthalten, z.B. Vereine, Initiativen, Feuerwehr, Kirchengemeinden etc.

Die Gradido-Kreise starteten als Prototyp in der Gradido-Akademie im Mai 2024. Im März 2025 wurde ein KI-Assistent (“Crea”) für Moderatoren eingeführt.

4. Hedera Hashgraph / Hiero als DLT-Audit-Layer

4.1 Was ist Hedera Hashgraph?

Hedera Hashgraph (bzw. Hiero als Open Source Version) ist eine Distributed Ledger Technologie (DLT) der neuesten Generation. Transaktionen sind extrem schnell (3–5 Sekunden) und brauchen etwa ein Millionstel der Energie von Bitcoin.

• Hiero ist seit 2024 ein offizielles Open-Source-Projekt der Linux Foundation unter dem Dach von LF Decentralized Trust. Seit Februar 2025 wird das Hedera-Netzwerk vollständig durch Hiero’s Open-Source-Codebase betrieben.

• Geschwindigkeit: Hedera/Hiero erreicht Transaktionsfinalität in 3–5 Sekunden und unterstützt theoretisch über 10.000 Transaktionen pro Sekunde (TPS).

• Energieverbrauch: Nach offiziellen Hedera-Daten verbraucht eine Hedera-Transaktion 0,00017 kWh, verglichen mit 1.736,85 kWh bei Bitcoin – ein Verhältnis von 1 zu etwa 10 Millionen.

• Konsensalgorithmus: Der Hashgraph-Algorithmus nutzt Asynchronous Byzantine Fault Tolerance (aBFT), den höchsten Sicherheitsstandard für verteilte Systeme. Durch den Gossip-about-Gossip-Mechanismus und virtuelles Voting werden Transaktionen ohne energieintensives Mining bestätigt.

Hinweis zur Energieaussage: Gradidos Aussage “ein Millionstel Energie” ist sogar noch untertrieben. Laut Angaben von Hedera sind es (1.736 / 0,00017 ≈ 10.200.000) also etwa ein Zehnmillionenstel. Hedera (Hiero) und Algorand sind damit mit Abstand die energieeffizientesten öffentlichen DLTs.

4.2 Hiero – Open Source unter Linux Foundation

Der Übergang von Hedera zu Hiero begann 2024 mit der Übergabe der gesamten Codebasis an die Linux Foundation. Hiero ist laut eigener Beschreibung “the first open-source distributed ledger technology developed in a fully vendor-neutral way”. 

4.3 Der Inspector als Audit-Layer

Jede Buchung wird auf den Hashgraph übertragen; ein “Inspector” im Gradido-Konto ist in Entwicklung und soll in Zukunft Buchungen prüfen (Audit-Layer mit Häkchen).

Einordnung: Das Konzept des Audit-Layers – ein sekundäres System, das das primäre kontrolliert – ist in der IT-Sicherheit und in Finanzanwendungen ein etabliertes Sicherheitskonzept. Die Übertragung jeder Gradido-Buchung auf ein unveränderliches öffentliches Ledger (Hashgraph) schafft eine manipulationsresistente Prüfbasis, die von keinem einzelnen Admin oder Community-Betreiber verfälscht werden kann. Im Dezember 2025 wurden zunächst die alten Buchungen experimentell in den Hashgraph importiert und und seit März 2026 werden – ebenfalls noch experimentell – die aktuellen Buchungen übertragen.

5. Das Präzisionsproblem der Vergänglichkeit: Technische Tiefenanalyse

5.1 Das geschilderte Problem

Die Vergänglichkeit wird in unterschiedlichen Softwaresystemen unterschiedlich genau berechnet, was Differenzen im Kontostand erzeugt – ein Problem, wenn ein System das andere kontrolliert (Audit-Layer). Gelöst wurde dies mit der Programmiersprache C, Integer-Zahlen und einer präzisen mathematischen Library.

5.2 Technische Verifikation

Diese Darstellung ist technisch vollständig plausibel und korrekt beschrieben. Die Vergänglichkeit wird kontinuierlich per Exponentialfunktion berechnet:

Dabei ist K0​ der Ausgangskontostand, $t$ die vergangene Zeit in Sekunden und TJahr die Anzahl der Sekunden in einem Jahr. Diese Berechnung in Floating-Point-Arithmetik (z. B. double in C oder JavaScript) ist auf verschiedenen Systemen und Architekturen nicht zwingend bit-identisch, weil:

• Gleitkommaoperationen plattformabhängig gerundet werden können

• JavaScript (V8-Engine für Frontend) und C++ (Backend) unterschiedliche Genauigkeiten haben

• Kumulierte Rundungsfehler über viele Berechnungsschritte zu messbaren Abweichungen führen

Lösung durch Integer-Arithmetik: Die Verwendung von Integer-Darstellungen (z. B. Gradido-Beträge in Mikro-GDD oder ähnlichen Kleinsteinheiten) und einer hochpräzisen Mathematikbibliothek in C eliminiert diese Nicht-Determinismen. Dies ist ein etabliertes Verfahren in der Finanzindustrie, wo Betragsberechnungen grundsätzlich in Integer-Cent statt in Floating-Point-Euro durchgeführt werden. Die gewählte Lösung (C + Integer + präzise Math-Library) ist State-of-the-Art für kritische Finanzsysteme.

6. Warum keine adaptierte Blockchain: Zusammenfassung der Inkompatibilitäten

Die folgende Tabelle fasst zusammen, warum spezifische Blockchain-Eigenschaften mit dem Gradido-Modell strukturell inkompatibel sind:

Die gewählte hybride Architektur – Datenbank + Federation + DLT als Audit-Layer – ist aus technischer Sicht die durchdachteste Lösung für diesen spezifischen Anwendungsfall.

7. Aktueller Entwicklungsstand (Mai 2026)

Auf Basis der verifizierten Roadmap ergibt sich folgender Stand:

8. Technische Einordnung

Das Gradido-Konto ist in seiner Kombination aus sozialem Verifikationssystem, sekundengenauer Geldmengenverfallsberechnung, dezentraler Community-Federation und DLT-Audit-Layer tatsächlich ein System ohne direktes Vorbild in der etablierten Fintech-Landschaft. Die technischen Entscheidungen sind gut begründet und entsprechen dem Stand der Technik. Die größte Herausforderung liegt nicht in der Technologie selbst, sondern im gesellschaftlichen Adoptionsprozess und in der Sicherstellung wirtschaftlicher Tragfähigkeit des Lebensgeldmodells.

Fazit

Das Gradido-Konto ist ein technisch anspruchsvolles, in seinen Anforderungen einzigartiges Projekt, das zu Recht eine maßgeschneiderte Architektur entwickelt hat, statt eine bestehende Blockchain zu adaptieren. Die Entscheidung für eine hybride Lösung – konventionelle Datenbankarchitektur für die Community-Logik, Federation für Dezentralisierung und Hedera Hashgraph (Hiero) als unveränderlicher Audit-Layer – ist technisch fundiert und konsequent. Alle zentralen Angaben der Anfrage konnten durch unabhängige Quellen verifiziert werden. Das Projekt befindet sich in einem fortgeschrittenen Entwicklungsstadium und hat in den letzten zwei Jahren bedeutende Meilensteine erreicht, darunter Cross-Community-Transaktionen und DLT-Anbindung.