Gradido account: Technical architecture, special features and current status

Executive Summary

The Gradido account is an unprecedented software project in its conception and technical implementation, combining elements of a community currency system, a decentralized communication platform and a modern distributed ledger technology (DLT) in a way that would not be fully mappable with any conventional blockchain architecture. This report analyzes and verifies the key technical claims about the Gradido account, compares blockchain alternatives, and evaluates the architectural choices made.

1. the Gradido account: Conceptual basics

1.1 The threefold creation of money and the active basic income

The Gradido system is based on the concept of Natural economy of life, which has been developed by Bernd Hückstädt and Margret Baier at the Gradido Academy for Economic Bionics since 2000. The model provides for three equivalent money creations of 1,000 gradido (GDD) per person per month:

1. Active Basic Income (AGE): 1,000 GDD per month for public welfare contributions

2. Public budget: 1,000 GDD per capita per month for state benefits

3. Equalization and Environmental Fund (AUF): 1,000 GDD per month for nature and the environment

Currently, only the first money creation (the active basic income) has been productively implemented. The roadmap envisages the second and third money creation (public budget + equalization and environmental fund) for 2027. 

1.2 Active basic income through unconditional participation

The active basic income does not function as an unconditional income in the traditional sense, but as a performance-related appreciation for contributions to the common good. Each participant can receive up to 20 GDD per hour worked for the community, up to a maximum of 50 hours per month, which corresponds to a maximum of 1,000 GDD. The term Unconditional participation means that participation (not consideration) is unconditional - everyone can take part.

2 Why not a standard blockchain? Technical analysis

2.1 The fundamental database problem: Continuous transience

Probably the most important technical reason why a conventional blockchain is unsuitable for Gradido lies in the planned transience of 50% in the year, which is to be calculated continuously and to the second.

How blockchains store data: A blockchain is an unchangeable, append-only ledger. Transactions are stored in blocks and cannot be subsequently changed. Bitcoin uses the UTXO (Unspent Transaction Output) model, where each transaction consumes existing UTXOs as inputs and generates new ones as outputs. Ethereum uses an account model in which account balances are stored as a global state.

The problem: With Gradido, an account balance of 100 GDD would continuously decrease without any further transaction due to transience. A UTXO model (Bitcoin) cannot map this because no transaction has taken place - there is no input, no output. The account model (Ethereum) would have to permanently update the state, which would mean millions or billions of automatic state changes per second for all accounts worldwide - technically and economically unfeasible in a public blockchain.

The perishability formula is not trivial: a simple division of 50% by 12 does not give the correct monthly percentage, as the amount to be allocated becomes smaller and smaller. The correct monthly rate of perishability is approximately 5.61%, so that 100 GDD drops to 50 GDD after twelve months. The calculation at second level requires a high-precision mathematical library.

2.2 The problem of community verification

Gradido requires social verification: moderators who know members personally and confirm their contributions to the common good. Blockchains are designed to verify transactions without trust through mathematical proof (trustless design). Gradido's logic reverses this principle: Trust is the design. People confirm people.

Smart contracts on Ethereum could implement social governance, but they are limited to on-chain data and cannot verify whether a person has been actually has completed one hour of collaborative work. This requires off-chain systems and human moderation, which can be better mapped in a flexible database architecture.

2.3 Bitcoin and the proof-of-work: energy consumption

Bitcoin consumes enormous amounts of energy through proof-of-work because many computing tasks have to be solved. A single Bitcoin transaction consumes an average of 1,200-1,450 kWh of electricity (as of 2025/2026). According to official Hedera data from 2021, consumption was 1,736.85 kWh per Bitcoin transaction compared to 0.00017 kWh for Hedera. The total annual Bitcoin network consumption is 150-200 TWh, comparable to Poland's electricity consumption. The proof-of-work consensus mechanism accounts for more than 99% of this consumption.

2.4 Modern DLT alternatives: a comparison of energy efficiency

There are now modern, much more energy-efficient blockchains. Ethereum, for example, reduced its energy consumption by 99.95% after switching to proof-of-stake in September 2022. Algorand only consumes around 0.000008 kWh per transaction - around 150 million times less than Bitcoin. Nevertheless, structural incompatibilities with the Gradido logic remain (see above).

2.5 Bitcoin transaction speed

The Bitcoin network only processes about 7 transactions per second and typically requires 6 block confirmations for final security - this takes an average of 60 minutes. In comparison, Hedera achieves transaction finality in 3-5 seconds.

3. the Gradido architecture: database + federation + DLT

3.1 Relational database as core system

The Gradido account uses a relational database system (MariaDB/MySQL) with a GraphQL/Business Logic layer as the backend. This architecture offers several advantages over a pure blockchain solution:

• Flexibility: Account balances can be efficiently updated to the second using calculations without creating an on-chain transaction

• Complex social logic: Moderator workflow, public good contributions and community governance can be naturally mapped in relational databases

• Scalability: For small and medium-sized communities, a database is much more efficient than a blockchain

3.2 Decentralized community servers and federation

Gradido 2.0 introduced decentralized community servers that each community can operate autonomously, provided it has the technical knowledge. The source code is open source and available on GitHub. The concept of federation - servers that recognize each other and exchange encrypted data - corresponds to established protocols such as ActivityPub, which is already used for the decentralized Fediverse (Mastodon, Pixelfed, etc.). The Gradido circle communication platform was launched in June 2024 and is integrated into the Gradido account.

3.3 Cross-community transactions

Gradido enables cross-community transactions. According to the roadmap, cross-community transactions via link are to go live in May 2026, with email notifications. Protection against man-in-the-middle attacks (encryption) was already implemented in July 2025. This is a technically challenging solution, as community servers have different data repositories and a secure, verified exchange across server areas had to be implemented.

3.4 Gradido circles: Communication platform

A communication platform (Gradido circles) with manageable groups (so-called circles) with two to three moderators who know their members. Larger communities can contain many circles, e.g. clubs, initiatives, fire departments, church communities, etc.

The Gradido Circles started as a prototype in the Gradido Academy in May 2024. An AI assistant („Crea“) for moderators was introduced in March 2025.

4th Hedera Hashgraph / Hiero as DLT audit layer

4.1 What is Hedera Hashgraph?

Hedera Hashgraph (or Hiero as an open source version) is a distributed ledger technology (DLT) of the latest generation. Transactions are extremely fast (3-5 seconds) and require around one millionth of the energy of Bitcoin.

• Hiero has been an official open source project of the Linux Foundation since 2024 under the umbrella of LF Decentralized Trust. Since February 2025, the Hedera network has been powered entirely by Hiero's open source codebase.

• Speed: Hedera/Hiero achieves transaction finality in 3-5 seconds and theoretically supports over 10,000 transactions per second (TPS).

• Energy consumption: According to official Hedera data, one Hedera transaction consumes 0.00017 kWh, compared to 1,736.85 kWh for Bitcoin - a ratio of 1 to about 10 million.

• Consensus algorithm: The hashgraph algorithm uses Asynchronous Byzantine Fault Tolerance (aBFT), the highest security standard for distributed systems. The gossip-about-gossip mechanism and virtual voting confirm transactions without energy-intensive mining.

Note on the energy statement: Gradido's statement „one millionth of the energy“ is even an understatement. According to Hedera, it is (1,736 / 0.00017 ≈ 10,200,000), i.e. around one ten-millionth. Hedera (Hiero) and Algorand are therefore by far the most energy-efficient public DLTs.

4.2 Hiero - Open Source under Linux Foundation

The transition from Hedera to Hiero began in 2024 with the transfer of the entire code base to the Linux Foundation. According to its own description, Hiero is „the first open-source distributed ledger technology developed in a fully vendor-neutral way“. 

4.3 The Inspector as an audit layer

Each booking is transferred to the hashgraph; an „inspector“ in the Gradido account is under development and will check bookings in future (audit layer with checkmark).

Classification: The concept of the audit layer - a secondary system that controls the primary one - is an established security concept in IT security and financial applications. The transfer of every Gradido booking to an unchangeable public ledger (hash graph) creates a tamper-resistant audit base that cannot be falsified by any individual admin or community operator. In December 2025, the old bookings were first imported into the hashgraph on an experimental basis and since March 2026 the current bookings have been transferred - also on an experimental basis.

5 The precision problem of transience: technical depth analysis

5.1 The problem described

Transience is calculated with varying degrees of accuracy in different software systems, which creates differences in the account balance - a problem when one system controls the other (audit layer). This was solved using the C programming language, integer numbers and a precise mathematical library.

5.2 Technical verification

This representation is technically completely plausible and correctly described. The transience is calculated continuously using an exponential function:

This is K0​ the initial account balance, $t$ the elapsed time in seconds and TYear the number of seconds in a year. This calculation in floating-point arithmetic (e.g. double in C or JavaScript) is not necessarily bit-identical on different systems and architectures because:

• floating point operations can be rounded depending on the platform

• JavaScript (V8 engine for frontend) and C++ (backend) have different accuracies

• Cumulative rounding errors over many calculation steps lead to measurable deviations

Solution by integer arithmetic: The use of integer representations (e.g. gradido amounts in micro-GDD or similar small units) and a high-precision math library in C eliminates these non-determinisms. This is an established procedure in the financial industry, where amount calculations are generally carried out in integer cents instead of floating point euros. The chosen solution (C + integer + precise math library) is state of the art for critical financial systems.

6. why no adapted blockchain: summary of incompatibilities

The following table summarizes why specific blockchain properties are structurally incompatible with the Gradido model:

The selected hybrid architecture - Database + Federation + DLT as audit layer - is, from a technical point of view, the most sophisticated solution for this specific application.

7. current development status (May 2026)

Based on the verified roadmap, the status is as follows:

8 Technical classification

The Gradido account, with its combination of a social verification system, a second-by-second money supply expiry calculation, decentralized community federation and DLT audit layer, is actually a system without a direct role model in the established fintech landscape. The technical decisions are well-founded and in line with the state of the art. The biggest challenge lies not in the technology itself, but in the social adoption process and in ensuring the economic viability of the living money model.

Conclusion

The Gradido account is a technically sophisticated project, unique in its requirements, which has rightly developed a customized architecture instead of adapting an existing blockchain. The decision to use a hybrid solution - conventional database architecture for the community logic, federation for decentralization and Hedera Hashgraph (Hiero) as an immutable audit layer - is technically sound and consistent. All central details of the request could be verified by independent sources. The project is at an advanced stage of development and has achieved significant milestones over the last two years, including cross-community transactions and DLT connectivity.