Whitepaper

1. Zusammenfassung

Global Foundation Coin (GFC) entwickelt aktuell den GFC Token / Economic Layer auf Base. Bis einschließlich Q1 2027 ist die operative Arbeit auf belastbare Presale- und Mainnet-Readiness dieses Produkts ausgerichtet. Transparenz, Governance, Verifikation, Testing, Security, Smart Contracts, Legal, Website, Marketing, Partnerschaften und Funding unterstützen diesen Fokus. Ab Q2 2027 soll der Ausbau schrittweise zum breiteren GFC-System und langfristig zur Accountability Infrastructure rund um den Token und perspektivisch darüber hinaus zunehmen. Diese langfristige Richtung ist eine Roadmap und keine Darstellung bereits aktiver Funktionen.

Ziel ist nicht, Vertrauen durch Marketing zu ersetzen, sondern möglichst viele verifizierbare Elemente öffentlich zugänglich zu machen: technische Regeln, Contract-Versionen, Wallet-Rollen, Governance-Entscheidungen, finanzielle Bewegungen und – wo realistisch – unterstützende Nachweise realer Wirkung.

Das Kernmodell

GFC versteht Transparenz als Kette: Regel → Entscheidung → finanzielle Ausführung → Nachweis → berichtete Wirkung. Je nach Prozess können unterschiedliche Teile dieser Kette technisch oder durch Dokumentation verifiziert werden.

Verifizierungsdisziplin: Eine Behauptung ist kein Nachweis. Bei jeder wesentlichen Behauptung gilt: Was ist sichtbar? Was beweist es? Was bleibt unbelegt?

2. Das Problem

Bei Charity-, Impact- und öffentlich kommunizierten Finanzierungsprojekten sind Informationen häufig auf getrennte Systeme, Dokumente und Kanäle verteilt. Dadurch kann zwar sichtbar sein dass Geld bewegt wurde, ohne dass ebenso klar ist warum eine Entscheidung getroffen wurde, wer sie autorisiert hat und welche Nachweise später für das Ergebnis verfügbar sind.

Fragmentierte Informationen

Wallets, Entscheidungen, Projektberichte, Contract-Regeln und rechtliche Informationen lassen sich mitunter nur schwer miteinander verknüpfen.

Unklare Kontrolle

Prozentsätze oder öffentliche Versprechen allein zeigen nicht, wer Vermögenswerte tatsächlich bewegen oder Regeln ändern kann.

On-Chain ohne Kontext

Eine Transaktion kann öffentlich sichtbar sein, ohne den Grund der Entscheidung, ihren Zweck oder den anschließenden Off-Chain-Prozess zu erklären.

Wirkung ohne Nachweiskette

Ein Ergebnisbericht ist nicht automatisch verifiziert, nur weil die vorherige Zahlung auf einer Blockchain stattgefunden hat.

3. Der GFC-Ansatz

GFC trennt vier Ebenen, die gemeinsam ein nachvollziehbareres öffentliches Gesamtbild schaffen sollen.

1. Finanzielle Ausführung

Welche Vermögenswerte wurden wann, in welcher Höhe und zwischen welchen öffentlichen Adressen bewegt?

2. Governance-Nachweise

Welche Regel, Entscheidung oder Freigabe legitimierte die Handlung und welche Rollen waren beteiligt?

3. Unterstützende Nachweise

Welche Dokumente, Rechnungen, Liefer- oder Empfängerbestätigungen, Projektaufzeichnungen, messbaren Meilensteine oder unabhängigen Prüfungen stützen die anschließende Verwendung?

4. Impact-Verifizierung

Welche konkrete Wirkung wird behauptet, welche Kennzahlen gelten und lautet der Nachweisstatus verifiziert, ausstehend, unvollständig oder nicht verifiziert?

Nachweiskette: Eine sichtbare Transaktion ist der Anfang einer Nachweiskette — nicht ihr Ende.

4. Was Blockchain verifizieren kann – und was nicht

Technisch verifizierbar

Transaktionen und Zeitstempel;
Wallet-Adressen und Token-Bewegungen;
veröffentlichter Smart-Contract-Code;
bestimmte programmierte Regeln und Rollen;
bestimmte Governance-Handlungen, sofern sie on-chain ausgeführt werden.

Nicht automatisch verifizierbar

ob ein reales Projekt wie behauptet umgesetzt wurde;
ob ein Dokument inhaltlich wahr ist;
ob eine Organisation effizient arbeitet;
ob eine Zahlung die behauptete gesellschaftliche Wirkung erzeugt hat;
ob Off-Chain-Daten vollständig oder unverändert sind.

GFC behandelt Blockchain daher als eine Verifizierungsebene, nicht als universelle Wahrheitsmaschine. Reale Wirkung erfordert zusätzliche Nachweise und, wo angemessen, unabhängige Prüfung.

Sichtbar ≠ verifiziert ≠ vollständig bewiesen. Die Belastbarkeit einer Schlussfolgerung hängt von der konkreten Behauptung und den dafür erforderlichen Nachweisen ab.

5. Aktueller Entwicklungsstatus

GFC unterscheidet konsequent zwischen spezifiziert, in Entwicklung, Testnet/Pilot, geplant und produktiv aktiv.

Bis einschließlich Q1 2027 ist der GFC Token / Economic Layer das primäre Produkt. Der operative Schwerpunkt liegt auf belastbarer Presale- und Mainnet-Readiness; unterstützende Systembereiche werden nur insoweit als gegenwärtig dargestellt, wie sie tatsächlich veröffentlicht, spezifiziert oder im Test/Pilot verfügbar sind.

Auf kleinen Bildschirmen horizontal scrollen, um alle Spalten zu sehen.

Komponente	Status	Bedeutung
GFC Token / Economic Layer	primärer Fokus	Primäres Produkt bis einschließlich Q1 2027; Presale- und Mainnet-Readiness in Arbeit.
Öffentlicher Base-Sepolia-PoC / Pilot-Contracts	Testnet / Pilot	Öffentliche Entwicklungs-, Test- und Transparenzreferenzen; keine Assets zum Kauf.
Transparenzportal	veröffentlicht / im Ausbau	Zentrale öffentliche Status- und Verifizierungsreferenz.
Produktiver GFC-Token	nicht deployed	Derzeit nicht auf Base Mainnet aktiv.
Öffentlicher Presale	nicht aktiv	Kein produktiver Kaufprozess und keine Einzahlungsadresse.
Staking	geplant	Mechanismus und finale Parameter sind noch nicht produktiv.
Erweiterte Accountability-/Impact-Ebene	ab Q2 2027 / langfristig	Zunehmender Ausbau ab Q2 2027; langfristige Accountability Infrastructure rund um den Token und perspektivisch darüber hinaus.

Der öffentliche Base-Sepolia-PoC erzeugt Entwicklungsnachweise. Testnet-Deployments sind keine Produktionsprodukte, keine Kaufadressen und nicht der produktive GFC-Token. Das Transparenzportal ist maßgeblich für den aktuellen Produktionsstatus, offizielle Adressen und versionierte Referenzen.

6. GFC Token / Economic Layer und Utility

Der GFC Token / Economic Layer ist aktuell das primäre GFC-Produkt. Technisch ist GFC als ERC-20-Token auf Base Mainnet geplant; „Coin“ ist die Projekt- und Markenbezeichnung und bezeichnet keine eigene native Blockchain. Bis einschließlich Q1 2027 liegt der operative Fokus auf belastbarer Presale-/Mainnet-Readiness. Eine Funktion darf erst dann als implementierte Utility bezeichnet werden, wenn Mechanismus, Teilnahmeberechtigung, Zeitpunkt, Grenzen, Änderungsbefugnisse und Produktionsstatus öffentlich definiert und verifizierbar sind.

Auf kleinen Bildschirmen horizontal scrollen, um alle Spalten zu sehen.

Produktstatus	Primäres GFC-Produkt bis einschließlich Q1 2027; Produktionsdeployment noch ausstehend.
Netzwerk	Base Mainnet geplant
Standard	ERC-20, 18 Dezimalstellen geplant
Gesamtmenge	1.000.000.000 GFC
Zusätzliches Minting	Nach dem Produktions-Deployment nicht vorgesehen
Kaufgebühr	0 % geplant
Verkaufsgebühr	1 % geplant; finale technische Definition vor Aktivierung erforderlich

Operative Rolle des Tokens

Innerhalb definierter GFC-Mechanismen soll der Coin als übertragbares digitales Asset und später für ausgewählte Teilnahme- oder Ökosystemfunktionen dienen.

Keine rhetorische Utility

Begriffe wie „Zugang“, „Governance“ oder „Teilnahme“ gelten erst dann als konkrete Utility, wenn Mechanismus, Teilnahmeberechtigung, Zeitpunkt und Grenzen veröffentlicht wurden.

7. Tokenomics und Allokationen

Die geplante feste Gesamtmenge beträgt 1.000.000.000 GFC. Allokation ist eine Governance-Entscheidung und nicht bloß ein Prozentdiagramm: Sie verteilt Zugang, Liquidität, Anreize und potenziellen Einfluss. Jede Allokation benötigt deshalb Zweck, Kontrolle, Beschränkungen und zeitliche Logik.

Auf kleinen Bildschirmen horizontal scrollen, um alle Spalten zu sehen.

Allokation	Anteil	Menge	Primärer Zweck
Impact Vault	25 %	250.000.000 GFC	Langfristige Charity- und Impact-Allokation.
Guardian Growth Fund	20 %	200.000.000 GFC	Community, Guardians, Kampagnen und Teilnahme.
Presale	15 %	150.000.000 GFC	Geplante Allokation für den öffentlichen Presale.
Treasury Reserve	15 %	150.000.000 GFC	Entwicklung, Betrieb, Sicherheit und Ausbau.
Liquidity Reserve	15 %	150.000.000 GFC	Zukünftige Liquiditäts- und Marktzugangsmaßnahmen.
Ecosystem Growth	5 %	50.000.000 GFC	Integrationen, Tools und Ökosystementwicklung.
Core Team	5 %	50.000.000 GFC	Geplantes lineares Vesting über 19 Jahre.

Prozentsätze allein sind kein Nachweis für Governance. Finale Wallets, Contract-Adressen, Begünstigte, Freigaberegeln und administrative Rechte müssen separat veröffentlicht und technisch verifizierbar gemacht werden.

8. Locking und Vesting

Dauer allein ist kein Nachweis für Schutz. Eine Aussage über einen 50-jährigen Lock oder 19-jähriges Vesting wird erst glaubwürdig, wenn Startzeitpunkt, Freigabelogik, privilegierte Rollen, Änderungsrechte und etwaige Notfallpfade technisch und öffentlich verifizierbar sind.

Impact Vault

250.000.000 GFC sind einer langfristigen Impact-Struktur zugeordnet. Ab einem Startzeitpunkt, der vor dem Produktions-Deployment verbindlich definiert werden muss, ist eine Bindung über 50 Jahre vorgesehen.

Core Team

Für 50.000.000 GFC ist lineares Vesting über 19 Jahre geplant. Startzeitpunkt, Freigabeintervall, mögliche Cliff-Regeln und der Umgang mit noch nicht gevesteten Token müssen im finalen Contract definiert werden.

Vor Produktionsaktivierung offenzulegen

Startzeitpunkt und exakte Zeitlogik;
Freigabeintervalle und maximale Freigaben;
ob ein Schutzzeitraum nur verlängert — und nicht verkürzt — werden kann, sofern ein solcher Extension-Only-Schutz Bestandteil des finalen Designs ist;
Begünstigte und kontrollierende Rollen;
Änderungs-, Verlängerungs- und Notfallrechte;
Umgang mit ungenutzten oder noch nicht gevesteten Token;
öffentliche Contract- und Wallet-Referenzen.
sämtliche produktiven Locking- und Vesting-Regeln müssen vor Aktivierung öffentlich der deployten Contract-Version und den kontrollierenden Rollen zugeordnet werden.

9. Governance und Machtverteilung

Governance bedeutet bei GFC zunächst nicht „jeder Token ist eine Stimme“, sondern die präzise Definition technischer und organisatorischer Entscheidungsbefugnisse.

Auf kleinen Bildschirmen horizontal scrollen, um alle Spalten zu sehen.

Kontrollbereich	Ziel	Erforderliche Offenlegung
Treasury	Mehrparteienkontrolle kritischer Transfers	Signer, Schwellenwert, Rollen und Ausnahmen
Contract-Änderungen	Keine versteckten oder unbegrenzten Upgrade-Pfade	Upgrade-Rechte, Timelock und unveränderliche Grenzen
Vault-Freigaben	Regelgebundene, nachvollziehbare Freigaben	Zweck, Grenzen, Freigabe und Nachweise
Notfallmaßnahmen	Eng begrenzte Sicherheitsreaktionen	Auslöser, Dauer, Rollen und Rückkehr zum Normalbetrieb
Zukünftige Community-Governance	Nur für klar autorisierte Entscheidungsbereiche	Quorum, Stimmgewicht, Delegation und Schutzmechanismen

Kontrollhinweis: Ein Multisig kann Signaturen verteilen, ohne unabhängige Entscheidungsfindung zu garantieren. Mehrere Signer können weiterhin derselben Organisation unterstehen; daher sind Identität und Zugehörigkeit der Signer, Schwellenwert und Interessenkonflikte relevant.

10. Governance-Beschränkungen

Prinzip: Relevante Befugnisse sollen sichtbar, begrenzt, regelgebunden und überprüfbar sein. Derselbe Maßstab muss letztlich auch für GFC selbst gelten.

Explizite Befugnisse

Jede kritische administrative Befugnis soll benannt und öffentlich nachvollziehbar sein.

Trennung von Rollen

Kritische Funktionen sollen nicht unnötig in einer einzelnen Wallet oder Rolle konzentriert werden.

Begrenzte Upgrade-Fähigkeit

Änderungen dürfen es nicht ermöglichen, wesentliche Schutzverpflichtungen nachträglich willkürlich zu entfernen.

Vorhersehbare Ausnahmen

Notfall- und Ausnahmewege müssen im Voraus definiert und anschließend öffentlich dokumentiert werden.

Timelocks

Kritische Änderungen sollen – soweit technisch und aus Sicherheitssicht angemessen – nicht unsichtbar und sofort wirksam werden.

Nur Verlängerung, wo angemessen

Langfristige Schutz- oder Lock-Zeiträume sollen, sofern das Modell dies vorsieht, verlängerbar statt nachträglich verkürzbar sein.

11. Transparenzarchitektur

Das Whitepaper beschreibt wie Transparenz funktionieren soll. Das Transparenzportal zeigt welche konkreten Daten, Contracts, Statusinformationen und Nachweise aktuell verfügbar sind.

Status

Komponenten werden als geplant, in Entwicklung, Testnet/Pilot, produktiv, ersetzt oder außer Betrieb gekennzeichnet.

Referenzen

Contracts, Wallets, Source Code, Explorer-Links und Berichte sollen auf eindeutig identifizierte Versionen verweisen.

Änderungshistorie

Wesentliche Änderungen sollen Datum, Grund, verantwortliche Entscheidung oder Befugnis, betroffene Referenz/Version und den daraus resultierenden Status ausweisen, damit die Historie überprüfbar bleibt, statt stillschweigend überschrieben zu werden.

Transparenzportal öffnen

12. Technische Architektur

GFC ist zunächst als Ethereum-kompatible Infrastruktur auf Base geplant. Eine eigene Blockchain ist nicht Teil des Startmodells.

Vereinfachter Daten- und Verifizierungsfluss:

Nutzer / öffentliche Oberfläche – Status und Interaktionen.
GFC Smart Contracts – definierte On-Chain-Regeln.
Base – öffentliche Ausführung und Transaktionshistorie.
Registry- / Referenzebene – Zuordnung offizieller Komponenten und Versionen.
Nachweisebene – Off-Chain-Dokumente, Berichte und Bestätigungen.
Transparenzportal – konsolidierte öffentliche Darstellung.

13. Smart-Contract-Prinzipien

Smart Contracts lösen Governance nicht automatisch. Ihr Wert liegt darin, bestimmte Regeln technisch durchsetzbar zu machen und den verbleibenden menschlichen Ermessensspielraum klarer zu begrenzen.

feste oder klar begrenzte Token-Regeln statt versteckter Sonderrechte;
öffentliche Source-Code-Verifizierung produktiver Contracts;
explizite Rollen und Berechtigungen;
Audit-Bericht, Audit-Umfang, exakt geprüfte Code-Version/Commit und die zugehörige Produktionsadresse müssen öffentlich eindeutig einander zugeordnet werden können;
kritische Ausnahmen und Pause-Funktionen müssen dokumentiert sein;
Produktionsadressen werden ausschließlich über offizielle Referenzen veröffentlicht.

14. Presale-Architektur

Der geplante Presale ist ein Finanzierungsmechanismus innerhalb des aktuell primären GFC Token / Economic Layer. Er ist derzeit nicht aktiv. Bis einschließlich Q1 2027 liegt der operative Fokus auf belastbarer Presale- und Mainnet-Readiness. Operative Teilnahme, verbindliche Bedingungen, offizielle Produktionsreferenzen und eine etwaige spätere Kaufanleitung gehören auf die separate Presale-Seite und in das Transparenzportal.

Auf kleinen Bildschirmen horizontal scrollen, um alle Spalten zu sehen.

Allokation	150.000.000 GFC
Preis	0,05 € pro GFC
Geplante Dauer	8 Wochen
Soft Cap	250.000 €
Monetärer Hard Cap	Kein separater Hard Cap geplant; begrenzt durch die Token-Allokation.
Geplante Zahlungsassets	ETH, USDC und DAI auf Base.
Contract-Modell	Unveränderlicher Presale-Contract geplant; verbindlich erst mit veröffentlichter, verifizierter und den finalen Teilnahmebedingungen eindeutig zugeordneter Produktionsversion.
Verteilung	Unmittelbare Token-Zuteilung über den finalen Presale-Contract geplant.
Soft Cap nicht erreicht	Refund vorgesehen; genaue Behandlung bereits zugeteilter GFC muss vor Aktivierung verbindlich veröffentlicht und verifiziert werden.
Aktueller Status	nicht aktiv

Da der aktuelle Spezifikationsstand zugleich eine unmittelbare Token-Verteilung vorsieht, muss vor Aktivierung verbindlich festgelegt werden, wie bereits zugeteilte GFC behandelt werden, falls das Soft Cap nicht erreicht wird. Zu definieren sind insbesondere die Transferierbarkeit vor Abschluss des Presales, die Refund-Berechtigung bei bereits erfolgter Token-Zuteilung sowie die technische Rückgabe-, Burn-, Escrow- oder Claim-Logik. Die konkrete Lösung ist noch offen und muss vor einer Teilnahme veröffentlicht und verifiziert sein.

Vor Aktivierung erforderlich

verbindliche Refund- und Rückabwicklungslogik für bereits unmittelbar zugeteilte GFC;
finale technische und rechtliche Bedingungen;
eingefrorene Produktions-Contract-Version zur Prüfung;
unabhängige Prüfung kritischer Produktions-Contracts;
Behebung oder Offenlegung relevanter Feststellungen;
Veröffentlichung von Bericht, Adresse und Source-Code-Referenz;
öffentliche Aktivierung erst danach.

Aktuellen Presale-Status ansehen

15. Staking

Als Teil der langfristigen Token-Architektur ist ein hybrides, nicht-inflationäres Staking-Modell geplant, derzeit ist es jedoch nicht aktiv. Es gibt keine garantierte Rendite und keine final veröffentlichte APY.

die Quelle der Rewards muss vor Aktivierung vollständig offengelegt werden;
Rewards dürfen keine zusätzliche Token-Inflation erfordern;
Lock-Zeiträume und Auszahlungsregeln müssen technisch definiert sein;
Governance- oder Community-Vorteile müssen konkret statt rhetorisch beschrieben werden;
Smart-Contract-, Liquiditäts- und Marktpreisrisiken bleiben bestehen;
Slashing ist derzeit kein bestätigter Bestandteil des Modells.

16. Ausbau ab Q2 2027: Protokoll- und Impact-Ebene

Ab Q2 2027 soll GFC zunehmend zum breiteren System rund um den Token ausgebaut werden. Dazu gehören insbesondere stärker integrierte Transparenz-, Governance-, Verifikations- und Impact-Strukturen. Langfristig ist die Entwicklungsrichtung eine Accountability Infrastructure rund um den Token und perspektivisch darüber hinaus. Diese Erweiterung ist kein Startversprechen und keine Darstellung bereits aktiver Funktionen.

Projekt- und Nachweisstrukturen

Standardisierte Einreichung, Dokumentation, Statushistorie und Nachweise sollen vergleichbarer und nachvollziehbarer werden.

GFC Verified

Ein möglicher dokumentierter Prüfstatus darf nicht als staatliche Genehmigung oder als Garantie für Integrität, Sicherheit, Wirkung oder wirtschaftlichen Erfolg dargestellt werden.

Kriterien, Prüfumfang, Interessenkonflikte, Nachweisklassen, Verifizierungsstatus, Widerruf, Aktualisierungen und Gültigkeitsdauer müssen vor jeder öffentlichen Nutzung eines solchen Status vollständig veröffentlicht werden. Ein Label „GFC Verified“ wäre keine staatliche Genehmigung und würde weder Integrität noch Sicherheit, Wirkung oder wirtschaftlichen Erfolg garantieren.

17. Sicherheit

interne Tests vor dem Produktions-Deployment;
ein Audit sollte erst dann als öffentlich eindeutig zugeordnet gelten, wenn Audit-Bericht, Audit-Umfang, exakt geprüfte Code-Version/Commit und die zugehörige Produktionsadresse öffentlich einander zugeordnet werden können;
unabhängige Prüfung finaler kritischer Produktions-Contracts;
öffentliche Source-Code-Verifizierung;
Trennung kritischer operativer Rollen;
Mehrparteienfreigabe, wo angemessen;
dokumentierte Notfall- und Wiederherstellungsverfahren;
klare Regeln für offizielle Links, Wallets und Contract-Adressen;
Responsible-Disclosure-Prozess für Sicherheitsmeldungen.

Ein Audit ist keine Sicherheitsgarantie. Key-Management, Frontend-Integrität, Governance, Dritte und Nutzerverhalten bleiben eigenständige Risikobereiche.

18. Risiken und Nicht-Ziele

Dieses Whitepaper ist ein Projektinformationsdokument. Es stellt keine Anlage-, Finanz-, Rechts-, Steuer- oder Kaufberatung dar.

Wesentliche Risiken

Entwicklungs- und Umsetzungsrisiken;
Smart-Contract- und Infrastrukturausfälle;
Key- und Governance-Risiken;
regulatorische Änderungen;
Markt-, Liquiditäts- und Wertverlustrisiken;
unvollständige oder fehlerhafte Off-Chain-Nachweise;
Abhängigkeiten von Dritten.

GFC ist nicht dafür konzipiert, …

Charity-Organisationen vollständig zu ersetzen;
reale Wirkung allein durch Blockchain zu „beweisen“;
menschliche Governance vollständig abzuschaffen;
Renditen oder Wertsteigerungen zu garantieren;
jede Information öffentlich on-chain zu speichern;
sensible personenbezogene Daten unnötig dauerhaft offenzulegen.

19. Entwicklungs-Roadmap

Die Roadmap beschreibt technische Reifestufen statt spekulativer Marktziele.

Aktuelle Position und Zeitlogik: GFC befindet sich in Phase 2 (öffentlicher Base-Sepolia-PoC/Test) mit Vorbereitung auf Phase 3 (Härten). Bis einschließlich Q1 2027 ist die operative Arbeit auf belastbare Presale- und Mainnet-Readiness des GFC Token / Economic Layer ausgerichtet. Ab Q2 2027 soll der Ausbau der Transparenz-, Governance-, Verifikations- und weiteren Systemkomponenten rund um den Token zunehmen. Langfristig ist die Accountability Infrastructure rund um den Token und perspektivisch darüber hinaus die Entwicklungsrichtung. Phase 4 und alle späteren Produktionsschritte bleiben von technischer, rechtlicher, operativer und sicherheitsbezogener Bereitschaft abhängig.

Phase 1 — Spezifizieren

Terminologie, Nicht-Ziele, Token-Modell, Governance-Beschränkungen und Architektur konsolidieren.

Phase 2 — Testen

Base-Sepolia-Contracts, öffentliche Referenzen und Verifizierungsprozesse testen.

Phase 3 — Härten

Produktions-Contracts einfrieren, testen, prüfen und dokumentieren; Presale- und Mainnet-Readiness belastbar vorbereiten.

Phase 4 — Produktionsaktivierung: Mainnet & Presale

Erst nachdem technische, rechtliche, operative und sicherheitsbezogene Voraussetzungen erfüllt sind.

Phase 5 — Breiteres GFC-System ab Q2 2027

Transparenz-, Governance-, Verifikations-, Treasury-, Vesting- und Nachweisstrukturen rund um den Token stärker integrieren.

Phase 6 — Langfristig: Accountability Infrastructure

Langfristiger Ausbau standardisierter Projekt-, Nachweis-, Governance- und Verifizierungsmechanismen rund um den Token und perspektivisch darüber hinaus.

20. Dokumentationshierarchie und Änderungsprotokoll

Nicht jede Information gehört auf dieselbe Ebene. GFC unterscheidet bewusst zwischen zugänglicher Gesamtdokumentation, normativen Spezifikationen, technischer Implementierung und aktuellen Verifizierungsdaten.

Erklärt Problem, Prinzipien, Systemarchitektur, Token-Modell, Governance, Grenzen, Risiken und Entwicklungsrichtung.

Technische Spezifikationen

Der aktuelle interne Spezifikationsstand umfasst Glossar, Nicht-Ziele, Architektur, Governance-Beschränkungen, Transparenz- und Presale-Anforderungen sowie eigene Token- und Allokationsspezifikationen. Als öffentliche kanonische Referenz gilt eine Spezifikation erst, wenn eine eindeutige versionierte Release- oder Commit-Referenz veröffentlicht und hier verlinkt ist.

Smart Contracts & Source Code

Zeigen die tatsächliche technische Implementierung einer konkret identifizierten Version.

Transparenzportal

Zeigt den aktuellen öffentlichen Status, offizielle Referenzen, Contract-Versionen und verfügbare Verifizierungsdaten.

Normative Dokumente

specs/README.md — Spezifikationsindex, Statusmodell und Release-Regeln
specs/glossary.md — gemeinsame Terminologie
specs/non-goals.md — bewusste Ausschlüsse und nicht unterstützte Interpretationen
specs/architecture.md — übergeordnete Architektur und Beschränkungen
specs/governance-constraints.md — Governance- und Befugnisbeschränkungen
specs/transparency-model.md — Nachweis-, Verifizierungs- und Offenlegungsanforderungen
specs/presale.md — Presale-Regeln und Teilnehmerschutz
specs/token.md — Token-Modell, feste Angebotslogik und technische Token-Anforderungen
specs/allocations.md — Allokationen, Zweckbindungen, Beschränkungen und zeitliche Logik

Repository-Dokumente

SECURITY.md — Leitfaden für Sicherheitsmeldungen
CHANGELOG.md — Änderungshistorie auf Repository-Ebene

Die unten genannten Dateinamen beschreiben das aktuelle interne Spezifikationsset des Projekts. Sie sind auf dieser Website derzeit nicht als öffentliche versionierte Repository-Referenzen verlinkt. Erst eine veröffentlichte, eindeutige Release- oder Commit-Referenz macht eine Spezifikation zur öffentlich kanonischen technischen Quelle. Potenzielle zukünftige Spezifikationen — darunter eigene Treasury-, Vesting-, Staking- oder Impact-Methodik-Spezifikationen — dürfen erst dann als bestehend dargestellt werden, wenn sie erstellt und versioniert wurden.

Änderungsprotokoll

26. August 2026 — Version 4.3 DE: Produktpriorisierung und Q1-/Q2-2027-Zeitlogik aktualisiert; öffentlichen Base-Sepolia-PoC präzisiert; Presale-Contract- und Refund-Offenpunkte ergänzt; deutsche Zahlenformate sowie Spezifikationsreferenzen bereinigt; HTML, Metadaten und PDF-Export synchronisiert.
18. August 2026 — Version 4.2 DE: Dokumentationshierarchie um die bestehenden Token- und Allokationsspezifikationen ergänzt; Audit-Zuordnung vereinheitlicht; Versions- und Statusangaben aktualisiert; PDF-Export auf denselben Dokumentstand v4.2 DE vom 18. August 2026 synchronisiert.
13. August 2026 — Version 4.1 DE: Verifizierungsmotive mit „Krypto erklärt“ und dem Transparenzportal harmonisiert; Statushinweis und Testnet-/Mainnet-Trennung gestärkt; Formulierungen zu Utility, Allokation, Locking, Governance, Audit und Impact-Nachweisen geschärft; Roadmap-Position präzisiert; aktuelle Spezifikationshierarchie korrigiert; mobiles Inhaltsverzeichnis und versionierter PDF-Download ergänzt.
8. August 2026 — Version 4.0 DE: Whitepaper strukturell neu geordnet; Verifizierungsgrenzen, Coin-Utility, Governance-Beschränkungen, technische Architektur, Nicht-Ziele und Dokumentationshierarchie als eigene Kernabschnitte ergänzt. Einige Detailinhalte wurden in technische Modals verschoben.
5. August 2026 — Version 3.2 DE: Testnet-/Mainnet-Trennung sowie Aussagen zu Kontrollen, Treasury, Vesting, Presale, Sicherheit und Impact-Nachweisen präzisiert.
12. Juli 2026 — Version 3.1 DE: Formulierungen zum inaktiven Presale und Projektstatus standardisiert.
5. Juli 2026: Aktuelles Allokationsmodell von 25 % / 20 % / 15 % / 15 % / 15 % / 5 % / 5 % übernommen.

Aktuelle Referenzen prüfen Technische Grundlagen erklärt