Gradido konto: Teknisk arkitektur, specialfunktioner och aktuell status

Sammanfattning

Gradido-kontot är ett mjukvaruprojekt utan motstycke i sin utformning och tekniska implementering, som kombinerar element från ett gemensamt valutasystem, en decentraliserad kommunikationsplattform och modern teknik för distribuerade liggare (DLT) på ett sätt som inte fullt ut kan kartläggas med någon konventionell blockkedjearkitektur. Denna rapport analyserar och verifierar de viktigaste tekniska påståendena om Gradido-kontot, jämför blockkedjealternativ och utvärderar de arkitektoniska val som gjorts.

1. Gradido-kontot: Konceptuella grunder

1.1 Det trefaldiga skapandet av pengar och den aktiva basinkomsten

Gradido-systemet är baserat på konceptet Naturlig ekonomi i livet, som har utvecklats av Bernd Hückstädt och Margret Baier vid Gradido Academy for Economic Bionics sedan 2000. Modellen innebär tre motsvarande penningskapelser om 1.000 Gradido (GDD) per person och månad:

1. Aktiv basinkomst (AGE): 1.000 GDD per månad för bidrag till allmän välfärd

2. Offentlig budget: 1.000 GDD per capita och månad för statliga förmåner

3. Utjämnings- och miljöfonden (AUF): 1.000 GDD per månad för natur och miljö

För närvarande har endast den första penningskapande åtgärden (den aktiva basinkomsten) genomförts på ett produktivt sätt. Enligt färdplanen ska det andra och tredje penningskapandet (offentlig budget + utjämnings- och miljöfond) ske 2027. 

1.2 Aktiv basinkomst genom ovillkorligt deltagande

Den aktiva basinkomsten fungerar inte som en ovillkorlig inkomst i traditionell mening, utan snarare som en prestationsbaserad belöning för bidrag till det gemensamma bästa. Varje deltagare kan få upp till 20 GDD per arbetad timme för samhället, upp till maximalt 50 timmar per månad, vilket motsvarar maximalt 1.000 GDD. Begreppet Villkorslöst deltagande innebär att deltagande (inte hänsynstagande) är ovillkorligt - alla kan delta.

2 Varför inte en standardblockkedja? Teknisk analys

2.1 Det grundläggande databasproblemet: Kontinuerlig förgänglighet

Det förmodligen viktigaste tekniska skälet till att en konventionell blockkedja är olämplig för Gradido ligger i planerad övergång av 50% under året, som ska beräknas kontinuerligt och med en noggrannhet på sekunden.

Hur blockkedjor lagrar data: En blockkedja är en oföränderlig liggare som endast innehåller bilagor. Transaktioner lagras i block och kan inte ändras i efterhand. Bitcoin använder UTXO-modellen (Unspent Transaction Output), där varje transaktion förbrukar befintliga UTXO:er som input och genererar nya som output. Ethereum använder en kontomodell där kontosaldon lagras som ett globalt tillstånd.

Problemet är..: Med Gradido skulle ett kontosaldo på 100 GDD kontinuerligt minska utan några ytterligare transaktioner på grund av transiens. En UTXO-modell (Bitcoin) kan inte kartlägga detta eftersom ingen transaktion har ägt rum - det finns ingen input, ingen output. Kontomodellen (Ethereum) skulle behöva uppdatera tillståndet permanent, vilket skulle innebära miljontals eller miljarder automatiska tillståndsändringar per sekund för alla konton i hela världen - tekniskt och ekonomiskt ogenomförbart i en offentlig blockkedja.

Formeln för förgänglighet är inte trivial: en enkel division av 50% med 12 ger inte den korrekta månatliga procentsatsen, eftersom den mängd som ska fördelas blir mindre och mindre. Den korrekta månatliga förgänglighetsgraden är cirka 5,61%, så att 100 GDD sjunker till 50 GDD efter tolv månader. Beräkningen på den andra nivån kräver ett matematiskt bibliotek med hög precision.

2.2 Problemet med verifiering av gemenskapen

Gradido kräver social verifiering: moderatorer som känner medlemmarna personligen och bekräftar deras bidrag till det gemensamma bästa. Blockkedjor är designade för att verifiera transaktioner utan tillit genom matematiska bevis (trustless design). Gradidos logik vänder på denna princip: Förtroende är designen. Människor bekräftar människor.

Smarta kontrakt på Ethereum skulle kunna implementera social styrning, men de är begränsade till data på kedjan och kan inte verifiera om en person har faktiskt har slutfört en timmes gemensamt arbete. Detta kräver system utanför kedjan och mänsklig moderering, som bättre kan kartläggas i en flexibel databasarkitektur.

2.3 Bitcoin och proof-of-work: energiförbrukning

Bitcoin förbrukar enorma mängder energi genom proof-of-work eftersom många beräkningsuppgifter måste lösas. En enda Bitcointransaktion förbrukar i genomsnitt 1 200-1 450 kWh el (från och med 2025/2026). Enligt officiell Hedera-data från 2021 var förbrukningen 1 736,85 kWh per Bitcoin-transaktion jämfört med 0,00017 kWh för Hedera. Den totala årliga förbrukningen i Bitcoin-nätverket är 150-200 TWh, vilket kan jämföras med Polens elförbrukning. Konsensusmekanismen proof-of-work står för mer än 99% av denna förbrukning.

2.4 Moderna DLT-alternativ: en jämförelse av energieffektivitet

Det finns nu moderna, mycket mer energieffektiva blockkedjor. Ethereum minskade till exempel sin energiförbrukning med 99,95% efter att ha gått över till proof-of-stake i september 2022. Algorand förbrukar endast cirka 0,000008 kWh per transaktion - cirka 150 miljoner gånger mindre än Bitcoin. Trots detta kvarstår strukturella inkompatibiliteter med Gradido-logiken (se ovan).

2.5 Bitcoin transaktionshastighet

Bitcoinnätverket behandlar endast cirka 7 transaktioner per sekund och kräver vanligtvis 6 blockbekräftelser för slutlig säkerhet - detta tar i genomsnitt 60 minuter. I jämförelse uppnår Hedera transaktionsfinalitet på 3-5 sekunder.

3. Gradido-arkitekturen: databas + federation + DLT

3.1 Relationsdatabas som kärnsystem

Gradido-kontot använder ett relationsdatabassystem (MariaDB/MySQL) med ett GraphQL/Business Logic-lager som backend. Denna arkitektur erbjuder flera fördelar jämfört med en ren blockchain-lösning:

• Flexibilitet: Kontosaldon kan effektivt uppdateras till den andra med hjälp av beräkningar utan att skapa en transaktion på kedjan

• Komplex social logik: Moderatorernas arbetsflöde, bidrag till det allmänna bästa och samhällsstyrning kan på ett naturligt sätt kartläggas i relationsdatabaser

• Skalbarhet: En databas är mycket mer effektiv än en blockkedja för små och medelstora samhällen

3.2 Decentraliserad samhällsserver och federation

Gradido 2.0 introducerade decentraliserade communityservrar som varje community kan driva självständigt, förutsatt att de har den tekniska kunskapen. Källkoden är öppen och finns tillgänglig på GitHub. Konceptet med federation - servrar som känner igen varandra och utbyter krypterad data - motsvarar etablerade protokoll som ActivityPub, som redan används för det decentraliserade Fediverse (Mastodon, Pixelfed, etc.). Kommunikationsplattformen Gradido circle lanserades i juni 2024 och är integrerad i Gradido-kontot.

3.3 Transaktioner mellan olika samhällen

Gradido möjliggör transaktioner mellan olika samhällen. Enligt färdplanen ska transaktioner mellan communities via länk gå live i maj 2026, med e-postaviseringar. Skydd mot man-in-the-middle-attacker (kryptering) implementerades redan i juli 2025. Detta är en tekniskt utmanande lösning, eftersom samhällets servrar har olika datalager och ett säkert, verifierat utbyte mellan serverområden måste implementeras.

3.4 Gradido-cirklar: Kommunikationsplattform

En kommunikationsplattform (Gradido-cirklar) med hanterbara grupper (s.k. cirklar) med två till tre moderatorer som känner sina medlemmar. Större samhällen kan innehålla många cirklar, t.ex. klubbar, initiativ, brandkårer, kyrkliga samfund etc.

Gradido Circles startade som en prototyp i Gradido Academy i maj 2024. En AI-assistent („Crea“) för moderatorer introducerades i mars 2025.

4. Hedera Hashgraph / Hiero som DLT-auditlager

4.1 Vad är Hedera Hashgraph?

Hedera Hashgraph (eller Hiero som en open source-version) är en distribuerad liggarteknik (DLT) av den senaste generationen. Transaktionerna är extremt snabba (3-5 sekunder) och kräver cirka en miljondel av Bitcoins energi.

• Hiero har varit ett officiellt open source-projekt inom Linux Foundation sedan 2024 under paraplyet LF Decentraliserad Trust. Sedan februari 2025 har Hedera-nätverket drivits helt och hållet av Hieros kodbas med öppen källkod.

• Hastighet: Hedera/Hiero uppnår transaktionsfinalitet på 3-5 sekunder och stöder teoretiskt över 10.000 transaktioner per sekund (TPS).

• Energiförbrukning: Enligt officiell Hedera-data förbrukar en Hedera-transaktion 0,00017 kWh, jämfört med 1 736,85 kWh för Bitcoin - ett förhållande på 1 till cirka 10 miljoner.

• Algoritm för samförstånd: Hashgraph-algoritmen använder Asynkron byzantinsk feltolerans (aBFT), den högsta säkerhetsstandarden för distribuerade system. Mekanismen gossip-about-gossip och virtuell röstning bekräftar transaktioner utan energikrävande gruvdrift.

Notering om energideklarationen: Gradidos uttalande „en miljondel av energin“ är till och med en underdrift. Enligt Hedera är siffran (1.736 / 0,00017 ≈ 10.200.000), dvs. cirka en tiomiljondel. Hedera (Hiero) och Algorand är därför de överlägset mest energieffektiva publika DLT:erna.

4.2 Hiero - öppen källkod under Linux Foundation

Övergången från Hedera till Hiero inleddes 2024 med att hela kodbasen överfördes till Linux Foundation. Enligt sin egen beskrivning är Hiero „den första distribuerade huvudbokstekniken med öppen källkod som utvecklats på ett helt leverantörsneutralt sätt“. 

4.3 Inspektören som revisionslager

Varje bokning överförs till hashgrafen; en „inspektör“ i Gradido-kontot är under utveckling och kommer att kontrollera bokningar i framtiden (revisionslager med kryss).

Klassificering: Begreppet revisionslager - ett sekundärt system som kontrollerar det primära - är ett etablerat säkerhetskoncept inom IT-säkerhet och finansiella applikationer. Överföringen av varje Gradido-bokning till en oföränderlig offentlig huvudbok (hashgraf) skapar en manipulationsresistent revisionsbas som inte kan förfalskas av någon enskild administratör eller communityoperatör. I december 2025 importerades de gamla bokningarna först till hashgrafen på experimentell basis och sedan mars 2026 har de nuvarande bokningarna överförts - också på experimentell basis.

5 Förgänglighetens precisionsproblem: teknisk djupanalys

5.1 Beskrivning av problemet

Transiensen beräknas med varierande noggrannhet i olika mjukvarusystem, vilket skapar skillnader i kontosaldot - ett problem när det ena systemet kontrollerar det andra (revisionslager). Detta löstes med hjälp av programmeringsspråket C, heltal och ett exakt matematiskt bibliotek.

5.2 Teknisk verifiering

Denna representation är tekniskt sett helt rimlig och korrekt beskriven. Övergångstiden beräknas kontinuerligt med hjälp av en exponentiell funktion:

Detta är K0​ det ursprungliga saldot på kontot, $t$ den förflutna tiden i sekunder och TYår antalet sekunder under ett år. Denna beräkning i aritmetik med flyttal (t.ex. dubbel i C eller JavaScript) är inte nödvändigtvis identisk på olika system och arkitekturer eftersom:

• flyttalsoperationer kan avrundas beroende på plattform

• JavaScript (V8-motor för frontend) och C++ (backend) har olika noggrannhet

• Kumulativa avrundningsfel under många beräkningssteg leder till mätbara avvikelser

Lösning med heltalsaritmetik: Genom att använda heltalsrepresentationer (t.ex. gradidobelopp i mikro-GDD eller liknande små enheter) och ett matematiskt högprecisionsbibliotek i C elimineras dessa icke-determinismer. Detta är ett etablerat förfarande inom finansbranschen, där beloppsberäkningar i allmänhet utförs i heltalscent i stället för i euro med flyttal. Den valda lösningen (C + heltal + exakt matematikbibliotek) är "state of the art" för kritiska finansiella system.

6. Varför ingen anpassad blockkedja: sammanfattning av inkompatibiliteter

Följande tabell sammanfattar varför specifika blockchain-egenskaper är strukturellt inkompatibla med Gradido-modellen:

Den valda hybridarkitekturen Databas + Federation + DLT som revisionslager - är den mest sofistikerade lösningen för denna specifika applikation ur teknisk synvinkel.

7. Aktuell utvecklingsstatus (maj 2026)

Följande status är baserad på den verifierade färdplanen:

8 Teknisk kategorisering

I sin kombination av ett socialt verifieringssystem, en beräkning av mängden pengar som löper ut inom några sekunder, decentraliserad community federation och ett DLT revisionslager är Gradido-kontot faktiskt ett system utan en direkt förebild i det etablerade fintech-landskapet. De tekniska besluten är välgrundade och i linje med den senaste tekniken. Den största utmaningen ligger inte i själva tekniken, utan i den sociala adoptionsprocessen och i att säkerställa den ekonomiska bärkraften i modellen med levande pengar.

Slutsats

Gradido-kontot är ett tekniskt sofistikerat projekt som är unikt i sina krav och som med rätta har utvecklat en skräddarsydd arkitektur istället för att anpassa en befintlig blockkedja. Beslutet att använda en hybridlösning - konventionell databasarkitektur för communitylogiken, federation för decentralisering och Hedera Hashgraph (Hiero) som ett oföränderligt revisionslager - är tekniskt sunt och konsekvent. Alla centrala detaljer i förfrågan kunde verifieras av oberoende källor. Projektet befinner sig i ett avancerat utvecklingsstadium och har uppnått betydande milstolpar under de senaste två åren, inklusive transaktioner mellan olika samhällen och DLT-anslutning.