German Foundation Coin (GFC)

1) Zusammenfassung

Der German Foundation Coin (GFC) ist ein transparenzorientierter ERC-20-Token auf der Base-Chain (L2, Chain-ID 8453). Ziel ist es, Mittel für Bildungs-, Jugend- und Sozialprojekte nachvollziehbar zu mobilisieren – beginnend in Deutschland. Internationale Förderungen sind perspektivisch möglich, jedoch ausschließlich über sorgfältig geprüfte, dokumentierte Partner und klar definierte Freigabeprozesse.

Status (Dokumentkontext v1.1): Token-, Lock- und Vesting-Contracts sind auf Base deployed und verlinkt (siehe Abschnitt 15.2). Weitere Komponenten – insbesondere Foundation-Vault- und Matching/Trigger-Logik – sind als Zielarchitektur beschrieben und werden schrittweise umgesetzt, inklusive externer Prüfungen (Audits). Der Presale ist für den Zeitraum 02.02.2026, 18:00 CET bis 16.03.2026, 18:00 CET vorgesehen (siehe Abschnitt 6).

GFC ist bewusst kein Meme-Coin. Ziel ist ein langfristig tragfähiges Förder-Ökosystem mit überprüfbarer Dokumentation, klaren Regeln und perspektivischer Erweiterung um Plattform-/App-Funktionen (Projektübersicht, Impact-Darstellung, Votings und Reporting).

2) Problem & Motivation

Trotz hoher Budgets berichten Kitas, Schulen, Jugendzentren und soziale Einrichtungen über Engpässe, ineffiziente Verfahren und geringe Transparenz. Spender und Unterstützer können häufig nicht unabhängig prüfen, wie Mittel eingesetzt wurden und welche Wirkung erzielt wurde.

• Informationslücke: Unübersichtliche Wege, fehlende oder schwer zugängliche Nachweise.
• Effizienzproblem: Hoher Verwaltungsaufwand, uneinheitliche Dokumentation.
• Vertrauensfrage: Rechenschaft ist oft schwer vergleichbar und nicht standardisiert.

Unsere Überzeugung: Ein transparentes, datenbasiertes System, das Prüfbarkeit priorisiert, kann Vertrauen und Wirksamkeit erhöhen. GFC ist dabei politisch neutral: Es werden konkrete Projekte gefördert, keine Parteien, Kampagnen oder politischen Initiativen.

3) Lösung: GFC

GFC verbindet on-chain Nachvollziehbarkeit (wo sinnvoll) mit öffentlicher Dokumentation (Berichte, Medien, Nachweise) und Community-Mitbestimmung. Perspektivisch werden diese Informationen über eine Plattform/App zugänglich gemacht – mit Projektübersichten, Impact-Ansicht und Voting-Modulen.

4) Tokenomics

Der Anteil „Dev & Weiterentwicklung“ umfasst u. a. die Founder-Allokation von 500 000 000 GFC (10 % des Gesamtsupply). Diese unterliegt einem strikt linearen Vesting über 50 Jahre (600 Monate). Pro Monat werden ca. 0,1667 % der Founder-Tokens freigegeben (≈ 0,01667 % des Gesamtsupply). Der Vesting-Contract kann ausschließlich verlängert, niemals jedoch zugunsten des Founders verkürzt werden.

Für Founder- sowie Projekt/Marketing-Vesting gilt ein klar definierter Zeitplan: Lock bis 31.03.2026, anschließend Vesting ab 01.04.2026. Das Founder-Vesting läuft bis 01.04.2076 (50 Jahre), das Projekt/Marketing-Vesting bis 01.04.2051 (25 Jahre). In beiden Fällen sind ausschließlich Verlängerungen möglich.

Umgang mit nicht verkauften Presale-Token

Sollten nach Abschluss des Presales Token unverkauft bleiben, werden diese einmalig und transparent gemäß festgelegter On-chain-Logik zugeordnet:

• 50 % → Staking-Pool
• 20 % → Charity / Foundation
• 10 % → Liquidität
• 10 % → Marketing
• 10 % → Burn

Tokenomics, Verteilungen und Policies werden versioniert veröffentlicht. Änderungen (falls jemals erforderlich) erfolgen ausschließlich nachvollziehbar, dokumentiert und im Transparenz-Portal referenziert.

5) Locks, Vesting & Spendenmechanismen

5.1 Charity-Allokation (Lock & Zielmechanik)

Die Charity-Allokation ist langfristig über einen CharityLock-Contract bis mindestens 01.04.2051 gelockt. Der Lock kann ausschließlich verlängert, jedoch nicht zum Vorteil des Projekts/Founders verkürzt werden. Während des Locks sind nur klar definierte, dokumentierte Ausnahmen vorgesehen (z. B. Matching-Transfers gemäß Zielarchitektur).

Der CharityLock ist als Multi-Asset-Lock konzipiert: Neben GFC können auch Assets wie ETH oder DAI verwahrt werden. Während GFC selbst der langfristigen Sperre unterliegt (Ausnahme: definierte Matching-Transfers), können ETH/DAI im Rahmen dokumentierter Regeln zur Finanzierung von Spenden-/Infrastrukturmaßnahmen in vorgesehene Strukturen weitergeleitet werden.

Hinweis: Die Zielarchitektur für Matching/Trigger wird separat implementiert, dokumentiert und extern geprüft (Audit). Der aktuelle Stand ist über die verlinkten Contracts/Repos transparent nachvollziehbar.

Zielbild (nach Deployment der Trigger-Mechanik): Eine Spende in den Foundation Vault löst automatisch einen on-chain Trigger aus, wodurch zusätzlich 30 % der gespendeten Menge aus dem CharityLock in denselben Vault übertragen werden.

Beispiel (Zielarchitektur): Spende von 1 000 GFC in den Foundation Vault ⇒ zusätzlich 300 GFC aus CharityLock in den Vault.

5.2 Foundation Vault (Multi-Sig & Freigaben)

Der Foundation Vault ist eine Multi-Signature-Struktur zur sicheren Verwahrung und kontrollierten Mittelvergabe. Auszahlungen sollen an definierte Prüf- und Freigabeprozesse gekoppelt sein.

1. Vorschlag & Community-Entscheidung: Projekte/Kategorien werden eingereicht, geprüft und abgestimmt.
2. Verifikation: Vor-Ort- oder Dokumentenprüfung nach Standard – durch GFC-Team und/oder geprüfte Partner.
3. Auszahlung: Freigabe und Auszahlung werden dokumentiert; wo möglich on-chain nachvollziehbar.

5.3 Founder-Vesting (50 Jahre)

Der Founder-Anteil (500 000 000 GFC) unterliegt strikt linearem Vesting über 50 Jahre. Der Vesting-Contract ist so gestaltet, dass der Zeitraum ausschließlich verlängert, jedoch niemals zugunsten des Founders verkürzt werden kann.

5.4 Founder-Ethik & freiwillige Abgaben (ohne Preisversprechen)

Zusätzlich zum Vesting verfolgt GFC ein Founder-Commitment: Der Founder kann ab bestimmten Wertstufen freiwillig einen Teil seines monatlichen Vestings (oder des Gegenwerts in ETH/USDC) für Spenden, Burns oder Reinvestitionen verwenden. Wichtig: Diese Orientierung ist kein Preisziel, kein Renditeversprechen und keine Prognose – sie beschreibt lediglich ein freiwilliges, transparentes Prinzip.

Beispielhafte Orientierung (nicht bindend, wird transparent konkretisiert):

• ab ca. 0,50 € pro GFC: mindestens 5 % des monatlichen Vestings
• ab ca. 1,00 € pro GFC: mindestens 10 %
• ab ca. 2,50 € pro GFC: mindestens 20 %
• ab ca. 5,00 € pro GFC: 30–50 %

Die konkrete Aufteilung (z. B. Charity, Burn, LP, Treasury) wird im Zeitverlauf transparent dokumentiert.

6) Presale & Finanzierung

Eine einsteigerfreundliche Übersicht (How to Buy, Rechner, Sicherheitsregeln) ist ergänzend auf der Presale-Seite verfügbar.

Rabattcodes oder OTC-Nachbuchungen sind optionale Sonderfälle und dienen ausschließlich der sauberen on-chain-Abbildung klar gekennzeichneter Ausnahmen. Es existieren keine verdeckten Team-Sonderkonditionen. Relevante Abweichungen werden transparent dokumentiert.

7) Treasury & Burn-Policy

7.1 Treasury

• Relevante Adressen werden veröffentlicht und verlinkt.
• Mittelverwendung für Förderzweck, Entwicklung, Audits, Infrastruktur und Resilienz (Rücklagen) – dokumentiert.
• Regelmäßige Berichte inkl. Exports (CSV/JSON) als Prüf-/Analysegrundlage (geplant).

7.2 Burn-Mechanik (Policy-basiert)

Burn ist ein optionales, policy-basiertes Instrument zur langfristigen Verknappung, ohne den Förderzweck zu gefährden. Final wird eine „Burn-Policy v1.0“ versioniert veröffentlicht; Governance kann spätere Anpassungen ermöglichen.

Obige Werte sind Beispiele. Final gilt ausschließlich die versionierte Burn-Policy.

8) Governance, Community & Tokenholder-Nutzen

• Vorschlagsrecht: Community kann Kategorien/Projekte vorschlagen (moderiert; Anti-Sybil-Ansatz).
• Abstimmungen: On-/Off-chain Votes (z. B. Snapshot) zu Prioritäten, Policies und Parametern.
• Transparenz: Ergebnisse werden veröffentlicht und verlinkt.

8.1 Konkreter Nutzen für Holder

• Mitbestimmung: Einfluss auf Förderkategorien, Prioritäten und Policies.
• Alignment mit Impact: Sichtbare Projekte stärken Vertrauen und Reichweite.
• Programme: Staking-/Community-Programme zur Förderung von langfristigem Engagement (geplant).

8.2 Team & Hintergrund (High-Level)

GFC wird von einem kleinen Kernteam initiiert. Ziel ist eine tragfähige Struktur, die in eine passende gemeinnützige Organisation überführt werden kann (z. B. gGmbH/Stiftung). Details zu Partnern/Advisors werden veröffentlicht, sobald rechtliche Rahmenbedingungen final sind.

9) Transparenz, Reporting & Audit

Preis-Widgets sind informativ; kritische Logik basiert nicht auf Drittanbieter-APIs.

10) Technische Architektur

• Chain: Base (L2, EVM), Chain-ID 8453
• Token: ERC-20 (18 Decimals)
• dApp/Plattform (geplant): Wallet-Connect, Presale/Spendenmodule, Reporting-Dashboards
• Oracles/Preise: UI-only (keine kritische On-chain-Abhängigkeit)
• Multi-Sig: Governance/Treasury-Kontrolle, definierte Signer-Policy

Presale-Einzahlungen verbleiben zunächst im Presale-Contract. Wird Softcap nicht erreicht, ist Refund vorgesehen. Wird Softcap erreicht, kann der Admin Mittel gemäß Contract-Logik abrufen (Withdraw) – auch vor Presale-Ende. Eine automatische Weiterleitung in Vaults ist nicht vorgesehen; die Verteilung erfolgt anschließend transparent dokumentiert.

Der folgende Spendenfluss beschreibt die Zielarchitektur nach Deployment der Lock/Vault/Trigger-Komponenten. Zwischenstufen werden dokumentiert.

Beispiel: Spendenfluss (Zielarchitektur)

1. Spende in den Foundation Vault (Multi-Sig).
2. Trigger (geplant): +30 % Matching aus CharityLock in denselben Vault.
3. Nach Vote & Verifikation Auszahlung an Empfänger – dokumentiert.
4. Optional: Burn gemäß Burn-Policy.
5. Report & Nachweise werden veröffentlicht.

// Pseudocode – Ereignislogik (vereinfacht, Zielarchitektur)
event DonationMatched(address indexed from, uint256 donated, uint256 matched);
event DonationExecuted(address indexed recipient, uint256 amount, bytes32 categoryId);
event TokensBurned(uint256 amount);

function onVaultDonation(uint256 amount) internal {
    uint256 matchAmount = amount * 30 / 100; // 30 % aus CharityLock
    emit DonationMatched(msg.sender, amount, matchAmount);
}

function donateToProject(address recipient, uint256 amount, bytes32 categoryId) onlyMultisig {
    emit DonationExecuted(recipient, amount, categoryId);
}

11) Sicherheitskonzept

• Mehrstufige Freigaben: Multi-Sig für kritische Aktionen.
• Defensive Defaults: Rollen/Rechte-Trennung, Limitierungen, Guard-Mechanismen (wo sinnvoll).
• Monitoring: On-chain Alerts für Transfers, Rollenwechsel und ungewöhnliche Events.
• Bug Bounty: Nach Audit vorgesehen.

12) Rechtliche Hinweise

• Compliance: Schrittweise Anpassung an deutsche & EU-Vorgaben
• Steuern: Abhängig von Rechtsform und Einzelfall
• Haftung: Keine Rendite-Garantien, keine Preisversprechen

13) Roadmap

Zeitpläne sind Zielkorridore und können sich durch externe Faktoren ändern. Änderungen werden dokumentiert.

14) Risikohinweis

15) Smart-Contract-System (architektonischer Überblick)

GFC verfolgt eine modulare Architektur: Token, Vesting/Locks, Presale, Vaults und (später) Matching/Trigger sind klar getrennte Komponenten. Ziel ist Prüfbarkeit und minimale Komplexität pro Modul.

15.1 Architekturprinzipien

• Trennung von Verantwortlichkeiten: einzelne Module statt monolithischer Verträge.
• On-chain Nachvollziehbarkeit: Events und Links als Basis für Reports.
• Nur-Verlängerung: Sperren/Vesting können verlängert, nicht zugunsten des Teams verkürzt werden.
• Vault-First: Mittelverwendung über definierte Strukturen statt private Wallets (Zielbild).
• Defensive Defaults: Multi-Sig, Limitierungen, klare Rollen.

15.2 Verlinkte Contracts auf Base (L2)

Die folgenden Contracts sind auf Base (Chain-ID 8453) deployed, unveränderlich und können über BaseScan geprüft werden. Maßgeblich ist ausschließlich der hier dokumentierte Adressstand.

Presale-Admin (Presale-Wallet): 0x2DF379857C59F01F37830A1Dd19B4dFaf3689a18.
Hinweis: Der Presale-Contract ist bewusst nicht upgradefähig. Änderungen erfolgen ausschließlich über neue Versionen und werden transparent dokumentiert.

15.3 Geplante Komponenten

• Foundation Vault (Multi-Sig): Verwahrung & Freigabelogik.
• Matching-/Trigger-Contract: Automatisches +30 % Matching (Zielarchitektur).
• Staking-Contract: Staking-Pool & Rewards.

15.4 Sicherheit, Upgrades & Audits

• Minimale Upgrade-Komplexität: bevorzugt neue Versionen statt unnötiger Proxy-Komplexität.
• Rollen & Berechtigungen: getrennte Rollen, Übergang zu Multi-Sig.
• Audits: Externe Audits, Veröffentlichung der Berichte.
• Monitoring: Alerts bei großen Abflüssen/Rollenwechseln.
• Bug Bounty: nach Audits vorgesehen.

16) FAQ

Wie wird der EUR-Wert im Presale berechnet?

Der Presale nutzt einen Referenzpreis von 0,05 € pro GFC. Die UI zeigt Umrechnungen zu Informationszwecken. Maßgeblich ist die deterministische On-chain-Logik des Presale-Contracts.

Was passiert mit gespendeten Coins?

Spenden sollen in den Foundation Vault fließen. In der Zielarchitektur löst dies nach Deployment der Trigger-Logik ein +30 % Matching aus. Auszahlungen erfolgen nach Vote & Verifikation, dokumentiert und wo möglich on-chain nachvollziehbar.

Wie wird Missbrauch verhindert?

Durch Multi-Sig/Freigabeprozesse, öffentliche Dokumentation, externe Audits (geplant) und Community-Review.

Wie kann ich heute starten?

Aktuelle Informationen werden auf germanfoundationcoin.org veröffentlicht. Kooperationen sind perspektivisch möglich, jedoch ausschließlich mit Organisationen, die nachweislich transparent arbeiten und dokumentieren.