Whitepaper

1. Zusammenfassung

Global Foundation Coin (GFC) entwickelt aktuell den GFC-Token / Wirtschaftsebene auf Base. Bis einschließlich Q1 2027 ist die operative Arbeit auf belastbare Vorverkaufs- und Produktionsreife dieses Produkts ausgerichtet. Transparenz, Entscheidungsstruktur, Verifikation, Tests, Sicherheit, Smart Contracts, Recht, Internetseite, Marketing, Partnerschaften und Finanzierung unterstützen diesen Fokus. Ab Q2 2027 soll der Ausbau schrittweise zum breiteren GFC-System und langfristig zur Nachweisinfrastruktur rund um den Token und perspektivisch darüber hinaus zunehmen. Diese langfristige Richtung ist ein Entwicklungsplan 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, Smart-Contract-Versionen, Wallet-Rollen, Entscheidungen der Entscheidungsstruktur, 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 Gemeinnützigkeit-, Wirkungs- 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, Smart-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.

auf der Blockchain ohne Kontext

Eine Transaktion kann öffentlich sichtbar sein, ohne den Grund der Entscheidung, ihren Zweck oder den anschließenden außerhalb der Blockchain-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. Nachweise zu Entscheidungsbefugnissen

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. Wirkungsprüfung

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 Handlungen der Entscheidungsstruktur, sofern sie auf der Blockchain 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 außerhalb der Blockchain-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, Testnetz/Pilot, geplant und produktiv aktiv.

Bis einschließlich Q1 2027 ist der GFC-Token / Wirtschaftsebene das primäre Produkt. Der operative Schwerpunkt liegt auf belastbarer Vorverkaufs- und Produktionsreife; 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 / Wirtschaftsebene	primärer Fokus	Primäres Produkt bis einschließlich Q1 2027; Vorverkaufs- und Produktionsreife in Arbeit.
Öffentlicher Base-Sepolia-Machbarkeitsnachweis / Pilot-Smart-Contracts	Testnetz / Pilot	Öffentliche Entwicklungs-, Test- und Transparenzreferenzen; keine Vermögenswerte zum Kauf.
Transparenzportal	veröffentlicht / im Ausbau	Zentrale öffentliche Status- und Verifizierungsreferenz.
Produktiver GFC-Token	nicht bereitgestellt	Derzeit nicht auf Base Mainnet aktiv.
Öffentlicher Vorverkauf	nicht aktiv	Kein produktiver Kaufprozess und keine Einzahlungsadresse.
Staking	geplant	Mechanismus und finale Parameter sind noch nicht produktiv.
Erweiterte Rechenschaft-/Wirkungsebene	ab Q2 2027 / langfristig	Zunehmender Ausbau ab Q2 2027; langfristige Nachweisinfrastruktur rund um den Token und perspektivisch darüber hinaus.

Der öffentliche Base-Sepolia-Machbarkeitsnachweis erzeugt Entwicklungsnachweise. Testnetz-Bereitstellungen 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 / Wirtschaftsebene und Nutzen

Der GFC-Token / Wirtschaftsebene 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 Vorverkaufs- und Produktionsreife. Eine Funktion darf erst dann als implementierter Nutzen 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-Bereitstellung 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 Nutzen

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

7. Token-Wirtschaftsmodell und Zuteilungen

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

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

Zuteilung	Anteil	Menge	Primärer Zweck
Wirkungstresor	25 %	250.000.000 GFC	Langfristige Zuteilung für Gemeinnützigkeit und Wirkung.
Schutz- und Wachstumsfonds	20 %	200.000.000 GFC	Gemeinschaft, Schutzrollen, Kampagnen und Teilnahme.
Vorverkauf	15 %	150.000.000 GFC	Geplante Zuteilung für den öffentlichen Vorverkauf.
Finanzreserve	15 %	150.000.000 GFC	Entwicklung, Betrieb, Sicherheit und Ausbau.
Liquiditätsreserve	15 %	150.000.000 GFC	Zukünftige Liquiditäts- und Marktzugangsmaßnahmen.
Ökosystem-Wachstum	5 %	50.000.000 GFC	Integrationen, Tools und Ökosystementwicklung.
Kernteam	5 %	50.000.000 GFC	Geplantes lineares Freigabemodell über 19 Jahre.

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

8. Sperrung und Freigabemodell

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

Wirkungstresor

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

Kernteam

Für 50.000.000 GFC ist lineares Freigabemodell über 19 Jahre geplant. Startzeitpunkt, Freigabeintervall, mögliche Regeln für anfängliche Sperrfristen und der Umgang mit noch nicht freigegebenen Token müssen im finalen Smart 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 Nur verlängerbar-Schutz Bestandteil des finalen Designs ist;
Begünstigte und kontrollierende Rollen;
Änderungs-, Verlängerungs- und Notfallrechte;
Umgang mit ungenutzten oder noch nicht freigegebenen Token;
öffentliche Smart-Contract- und Wallet-Referenzen.
sämtliche produktiven Sperr- und Freigaberegeln müssen vor Aktivierung öffentlich der bereitgestellten Smart-Contract-Version und den kontrollierenden Rollen zugeordnet werden.

9. Entscheidungsstruktur und Machtverteilung

Entscheidungsstruktur 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
Finanzreserve	Mehrparteienkontrolle kritischer Übertragungen	Signer, Schwellenwert, Rollen und Ausnahmen
Änderungen an Smart Contracts	Keine versteckten oder unbegrenzten Aktualisierungspfade	Aktualisierungsrechte, Zeitsperre 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 Gemeinschaft-Entscheidungsstruktur	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. Beschränkungen der Entscheidungsstruktur

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 Aktualisierbarkeit

Ä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.

Zeitsperren

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

Nur Verlängerung, wo angemessen

Langfristige Schutz- oder Sperrzeiträ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, Smart Contracts, Statusinformationen und Nachweise aktuell verfügbar sind.

Status

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

Referenzen

Smart Contracts, Wallets, Quellcode, 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 auf der Blockchain-Regeln.
Base – öffentliche Ausführung und Transaktionshistorie.
Verzeichnis- / Referenzebene – Zuordnung offizieller Komponenten und Versionen.
Nachweisebene – außerhalb der Blockchain-Dokumente, Berichte und Bestätigungen.
Transparenzportal – konsolidierte öffentliche Darstellung.

13. Smart-Contract-Prinzipien

Smart Contracts lösen Entscheidungsstruktur 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 Quellcode-Verifizierung produktiver Smart Contracts;
explizite Rollen und Berechtigungen;
Prüfbericht, Prüfumfang, exakt geprüfte Code-Version/Versionskennung 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. Vorverkaufsarchitektur

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

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

Zuteilung	150.000.000 GFC
Preis	0,05 € pro GFC
Geplante Dauer	8 Wochen
Mindestziel	250.000 €
Monetärer Höchstgrenze	Kein separater Höchstgrenze geplant; begrenzt durch die Token-Zuteilung.
Geplante Zahlungsassets	ETH, USDC und DAI auf Base.
Smart-Contract-Modell	Unveränderlicher Vorverkaufsvertrag geplant; verbindlich erst mit veröffentlichter, verifizierter und den finalen Teilnahmebedingungen eindeutig zugeordneter Produktionsversion.
Verteilung	Unmittelbare Token-Zuteilung über den finalen Vorverkaufsvertrag geplant.
Mindestziel nicht erreicht	Rückerstattung 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 Mindestziel nicht erreicht wird. Zu definieren sind insbesondere die Transferierbarkeit vor Abschluss des Vorverkaufs, die Rückerstattungsberechtigung bei bereits erfolgter Token-Zuteilung sowie die technische Rückgabe-, Token-Vernichtung-, Treuhand- oder Anspruchslogik. Die konkrete Lösung ist noch offen und muss vor einer Teilnahme veröffentlicht und verifiziert sein.

Vor Aktivierung erforderlich

verbindliche Rückerstattung- und Rückabwicklungslogik für bereits unmittelbar zugeteilte GFC;
finale technische und rechtliche Bedingungen;
eingefrorene Smart-Contract-Produktionsversion zur Prüfung;
unabhängige Prüfung kritischer Produktionsverträge;
Behebung oder Offenlegung relevanter Feststellungen;
Veröffentlichung von Bericht, Adresse und Quellcode-Referenz;
öffentliche Aktivierung erst danach.

Aktuellen Vorverkaufsstatus 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 Jahresrendite.

die Quelle der Belohnungen muss vor Aktivierung vollständig offengelegt werden;
Belohnungen dürfen keine zusätzliche Token-Inflation erfordern;
Sperrzeiträume und Auszahlungsregeln müssen technisch definiert sein;
Entscheidungsstruktur- oder Gemeinschaft-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 Wirkungsebene

Ab Q2 2027 soll GFC zunehmend zum breiteren System rund um den Token ausgebaut werden. Dazu gehören insbesondere stärker integrierte Transparenz-, Entscheidungsstruktur-, Verifikations- und Wirkungs-Strukturen. Langfristig ist die Entwicklungsrichtung eine Nachweisinfrastruktur 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-Bereitstellung;
eine Prüfung sollte erst dann als öffentlich eindeutig zugeordnet gelten, wenn Prüfbericht, Prüfumfang, exakt geprüfte Code-Version/Versionskennung und die zugehörige Produktionsadresse öffentlich einander zugeordnet werden können;
unabhängige Prüfung finaler kritischer Produktionsverträge;
öffentliche Quellcode-Verifizierung;
Trennung kritischer operativer Rollen;
Mehrparteienfreigabe, wo angemessen;
dokumentierte Notfall- und Wiederherstellungsverfahren;
klare Regeln für offizielle Links, Wallets und Smart-Contract-Adressen;
Responsible-Disclosure-Prozess für Sicherheitsmeldungen.

Eine Prüfung ist keine Sicherheitsgarantie. Key-Management, Benutzeroberfläche-Integrität, Entscheidungsstruktur, 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 Entscheidungsstruktur-Risiken;
regulatorische Änderungen;
Markt-, Liquiditäts- und Wertverlustrisiken;
unvollständige oder fehlerhafte Nachweise außerhalb der Blockchain;
Abhängigkeiten von Dritten.

GFC ist nicht dafür konzipiert, …

Gemeinnützigkeit-Organisationen vollständig zu ersetzen;
reale Wirkung allein durch Blockchain zu „beweisen“;
menschliche Entscheidungsstruktur vollständig abzuschaffen;
Renditen oder Wertsteigerungen zu garantieren;
jede Information öffentlich auf der Blockchain zu speichern;
sensible personenbezogene Daten unnötig dauerhaft offenzulegen.

19. Entwicklungsplan

Die Entwicklungsplan beschreibt technische Reifestufen statt spekulativer Marktziele.

Aktuelle Position und Zeitlogik: GFC befindet sich in Phase 2 (öffentlicher Base-Sepolia-Machbarkeitsnachweis/Test) mit Vorbereitung auf Phase 3 (Härten). Bis einschließlich Q1 2027 ist die operative Arbeit auf belastbare Vorverkaufs- und Produktionsreife des GFC-Token / Wirtschaftsebene ausgerichtet. Ab Q2 2027 soll der Ausbau der Transparenz-, Entscheidungsstruktur-, Verifikations- und weiteren Systemkomponenten rund um den Token zunehmen. Langfristig ist die Nachweisinfrastruktur 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, Beschränkungen der Entscheidungsstruktur und Architektur konsolidieren.

Phase 2 — Testen

Base-Sepolia-Verträge, öffentliche Referenzen und Verifizierungsprozesse testen.

Phase 3 — Härten

Produktionsverträge einfrieren, testen, prüfen und dokumentieren; Vorverkaufs- und Produktionsreife belastbar vorbereiten.

Phase 4 — Produktionsaktivierung: Produktivnetz & Vorverkauf

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

Phase 5 — Breiteres GFC-System ab Q2 2027

Transparenz-, Entscheidungsstruktur-, Verifikations-, Finanzreserve-, Freigabe- und Nachweisstrukturen rund um den Token stärker integrieren.

Phase 6 — Langfristig: Nachweisinfrastruktur

Langfristiger Ausbau standardisierter Projekt-, Nachweis-, Entscheidungsstruktur- 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, Entscheidungsstruktur, Grenzen, Risiken und Entwicklungsrichtung.

Technische Spezifikationen

Der aktuelle interne Spezifikationsstand umfasst Glossar, Nicht-Ziele, Architektur, Beschränkungen der Entscheidungsstruktur, Transparenz- und Vorverkaufsanforderungen sowie eigene Token- und Zuteilungsspezifikationen. Als öffentliche kanonische Referenz gilt eine Spezifikation erst, wenn eine eindeutige versionierte Veröffentlichungs- oder Versionsreferenz veröffentlicht und hier verlinkt ist.

Smart Contracts & Quellcode

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

Transparenzportal

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

Normative Dokumente

specs/README.md — Spezifikationsindex, Statusmodell und Veröffentlichung-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 — Entscheidungsstruktur- und Befugnisbeschränkungen
specs/transparency-model.md — Nachweis-, Verifizierungs- und Offenlegungsanforderungen
specs/presale.md — VorverkaufsRegeln und Teilnehmerschutz
specs/token.md — Token-Modell, feste Angebotslogik und technische Token-Anforderungen
specs/allocations.md — Zuteilungen, Zweckbindungen, Beschränkungen und zeitliche Logik

Quellcode-Archiv-Dokumente

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

Die unten genannten Dateinamen beschreiben das aktuelle interne Spezifikationsset des Projekts. Sie sind auf dieser Internetseite derzeit nicht als öffentliche versionierte Quellcode-Referenzen verlinkt. Erst eine veröffentlichte, eindeutige Veröffentlichungs- oder Versionsreferenz macht eine Spezifikation zur öffentlich kanonischen technischen Quelle. Potenzielle zukünftige Spezifikationen — darunter eigene Finanzreserve-, Freigabemodell-, Staking- oder Wirkungsmethodik-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-Machbarkeitsnachweis präzisiert; Vorverkaufsvertrag- und offene Rückerstattungsfragen 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 Zuteilungsspezifikationen ergänzt; Prüfzuordnung 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 Testnetz-/Produktivnetz-Trennung gestärkt; Formulierungen zu Nutzen, Zuteilung, Sperrung, Entscheidungsstruktur, Prüfung und Wirkungsnachweisen geschärft; Entwicklungsplan-Position präzisiert; aktuelle Spezifikationshierarchie korrigiert; mobiles Inhaltsverzeichnis und versionierte PDF-Datei zum Herunterladen ergänzt.
8. August 2026 — Version 4.0 DE: Whitepaper strukturell neu geordnet; Verifizierungsgrenzen, Coin-Nutzen, Beschränkungen der Entscheidungsstruktur, 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: Testnetz-/Produktivnetz-Trennung sowie Aussagen zu Kontrollen, Finanzreserve, Freigabemodell, Vorverkauf, Sicherheit und Wirkungsnachweisen präzisiert.
12. Juli 2026 — Version 3.1 DE: Formulierungen zum inaktiven Vorverkauf und Projektstatus standardisiert.
5. Juli 2026: Aktuelles Zuteilungsmodell von 25 % / 20 % / 15 % / 15 % / 15 % / 5 % / 5 % übernommen.

Aktuelle Referenzen prüfen Im Accountability Explorer untersuchen Technische Grundlagen erklärt