Öffentliche GFC-Nachweisebene

Transparenzportal

Entwicklung / Testnet

Dieses Portal zeigt, was rund um die Entwicklung des GFC Token / Economic Layer derzeit tatsächlich öffentlich nachvollziehbar ist: Projektstatus, veröffentlichte Test-Contracts, Quellcode, On-Chain-Werte, Kontrollstrukturen, zukünftige Produktionsreferenzen und die Grenzen jeder Nachweisart.

Aktuelle Rolle des Portals: Das Transparency Portal ist derzeit eine Read-only-Informations- und Nachweisschicht für die Entwicklung des GFC Token / Economic Layer. Es führt keine Blockchain-Transaktionen aus, verwaltet keine Treasury-Mittel und besitzt keine Governance- oder Kontrollautorität.
Kernprinzip: Eine Behauptung ist kein Nachweis. Stelle bei jeder Referenz drei Fragen: Was ist sichtbar? Was beweist es? Was bleibt unbelegt? Ein sichtbarer Blockchain-Eintrag kann eine technische Ausführung oder einen Contract-Zustand belegen, beweist aber nicht automatisch Sicherheit, wirtschaftlichen Wert, rechtliche Zulässigkeit oder reale gesellschaftliche Wirkung.
Base-Sepolia-Test-Contracts veröffentlicht Kein offizieller Mainnet-Token Kein aktiver öffentlicher Mainnet-Presale Noch kein externer Audit-Bericht
Seiteninhalt zuletzt aktualisiert:

Systemstatus

Aktueller Projektstatus

Zielnetzwerk Base Mainnet Chain ID 8453 • finale Deployments wurden noch nicht veröffentlicht.
Entwicklungsnetzwerk Base Sepolia Chain ID 84532 • veröffentlichte GFC-Test-Deployments mit verifiziertem Quellcode.
Öffentlicher Mainnet-Presale Nicht aktiv Kein offizieller Mainnet-Kaufprozess und keine Einzahlungsadresse.
Audit Kein externer Audit-Bericht veröffentlicht Quellcode-Verifikation ersetzt kein unabhängiges Sicherheitsaudit.
Statusabgrenzung: Testnet-Deployments schaffen Entwicklungsnachweise. Sie sind kein Produktionsprodukt und dürfen nicht mit dem finalen GFC-Token, einem Mainnet-Deployment oder einem aktiven öffentlichen Presale verwechselt werden.

Smart-Contract-Registry

Offizielle Contract-Referenzen

Die nachfolgende Registry wird aus der veröffentlichten Base-Sepolia-Registry-Datei erzeugt. Jedes GFC-Deployment ist mit einem eigenen Manifest, Explorer-Referenzen, dokumentiertem Zweck, Kontrollstruktur, Einschränkungen, Live-Read-Konfiguration und lokalem Solidity-Quellcode verknüpft, dessen SHA-256-Integrität gegen das jeweilige Manifest geprüft wird. Der externe Quellcode-Verifikationsstatus wird separat aus der dokumentierten Explorer-Referenz geführt. Die Contract-Details sollen vier Kontrollfragen direkt beantworten: Was kann dieser Contract? Was kann er nicht? Welche Rollen oder Berechtigungen existieren? Welche Upgrade-, Pause- oder Notfallmechanismen sind offengelegt?

Aktueller Testnet-Umfang: Die Registry führt die aktuell veröffentlichten GFC-Test-Deployments auf Base Sepolia. Jeder Eintrag ist eine technische Testnet-Referenz. Er ist nicht der produktive GFC-Token, besitzt keinen offiziellen Mainnet-Wert und ist weder eine öffentliche Fundraising-Adresse noch ein Nachweis für einen aktiven Mainnet-Presale.

Die interaktive Contract-Registry wird aus der veröffentlichten Base-Sepolia-Registry-Datei aufgebaut.

Registry-Eintrag

Interaktive Contract-Registry

Die zugrunde liegende Registry-Datei ist direkt verfügbar. Die interaktive Darstellung wird nach erfolgreicher JavaScript-Initialisierung geladen.

Verifikationsübersicht

Was ist derzeit verifizierbar?

Jeder Status wird danach eingeordnet, ob er öffentlich verifizierbar, lediglich geplant oder noch nicht verfügbar ist. Testnet, Mainnet, Audit und reale Wirkung werden bewusst getrennt behandelt.

Base-Sepolia-Test-Contracts Veröffentlicht Registry, Adressen, Explorer-Referenzen, Quellcode und ausgewählte Live-On-Chain-Werte sind öffentlich verifizierbar.
GFC-Mainnet-Token Nicht veröffentlicht Es existiert noch keine offizielle Produktionsadresse auf Base Mainnet.
Öffentlicher Mainnet-Presale Nicht aktiv Keine offizielle Mainnet-Verkaufsadresse und kein öffentlicher Mainnet-Kaufprozess.
Produktions-Treasury Nicht veröffentlicht Finale Treasury-, Reserve-, Multisig- und Governance-Referenzen sind noch nicht verfügbar.
Unabhängiges Audit Nicht veröffentlicht Quellcode-Verifikation ist kein Ersatz für ein externes Sicherheitsaudit.
Reale Wirkung Noch keine veröffentlichten Nachweise Das Portal dokumentiert derzeit keine produktiven Charity-Ausschüttungen oder verifizierten realen Ergebnisse.
Finanzielle Ausführung Testnet-Nachweise verfügbar Veröffentlichte Test-Deployments und ausgewählte On-Chain-Aktivitäten können geprüft werden. Derzeit sind keine produktiven Treasury- oder Charity-Flüsse veröffentlicht.
Governance-Nachweise Testnet-Berechtigungen dokumentiert Berechtigungen und Einschränkungen auf Contract-Ebene können für veröffentlichte Testreferenzen geprüft werden. Die finale Produktions-Governance ist noch nicht veröffentlicht.
Wirkungsverifikation Noch nicht anwendbar Derzeit sind keine produktiven Charity-Ausschüttungen oder verifizierten realen Ergebnisse veröffentlicht.
Verifikationsmethode: Was ist sichtbar? Was beweist es? Was bleibt unbelegt? Das aktuelle Portal kann Entwicklungsnachweise vor allem auf Testnet- und Contract-Referenzebene belegen; es macht daraus keine Produktions-, Audit- oder Wirkungsbehauptungen.

Aktueller Nachweisumfang

Nur was belegbar ist, ist verifizierbar

Derzeit öffentlich verifizierbar

  • veröffentlichte Base-Sepolia-Contract-Adressen und Chain ID;
  • zugehörige Explorer- und Quellcode-Referenzen;
  • Deployment- und Verifikationsdaten aus der offiziellen Registry;
  • ausgewählte öffentliche On-Chain-Werte über Read-only-RPC-Abfragen;
  • dokumentierte Testnet-Beziehungen, Abhängigkeiten, Berechtigungen und Einschränkungen.

Schnellverifikation

So verifizierst du eine offizielle Referenz

  1. Beziehe die Contract-Adresse ausschließlich aus der Contract-Registry auf dieser Seite.
  2. Prüfe Netzwerk und Chain ID: Base Sepolia verwendet 84532, Base Mainnet verwendet 8453.
  3. Öffne den zugehörigen BaseScan- oder Blockscout-Link aus demselben Registry-Eintrag.
  4. Vergleiche Adresse, Netzwerk, Contract-Name, Quellcode und angegebenen Verifikationsstatus.
  5. Öffne die Contract-Details und prüfe dokumentierte Berechtigungen, Fähigkeiten, Einschränkungen sowie alle für dieses Deployment offengelegten Upgrade-, Pause- oder Notfallmechanismen.
  6. Prüfe den Audit-Status separat. Verifizierter Quellcode bedeutet nicht, dass der Contract extern auditiert wurde.
  7. Schließe mit den Fragen ab: Was ist sichtbar? Was beweist es? Was bleibt unbelegt?

Systemkontext

Abhängigkeiten und Contract-Beziehungen

Eine verifizierte Contract-Adresse allein erklärt nicht das vollständige System. Dieser Abschnitt zeigt externe Assets, von GFC kontrollierte Test-Contracts, Zahlungswege, Verteilungsbeziehungen und die in der Registry dokumentierte unveränderliche Test-Treasury-Referenz.

Externe Abhängigkeiten

Externe Abhängigkeiten sind in der veröffentlichten Registry dokumentiert; die interaktive Darstellung benötigt JavaScript.

Veröffentlichte Systembeziehungen

Systembeziehungen sind in der veröffentlichten Registry dokumentiert; die interaktive Darstellung benötigt JavaScript.

Der Registry-Hinweis wird nach erfolgreicher JavaScript-Initialisierung aus der veröffentlichten Registry angezeigt.

Governance & Kontrolle

Wer kann tatsächlich was kontrollieren?

Transparenz betrifft nicht nur sichtbaren Code. Entscheidend ist, welche Adresse oder Rolle Parameter ändern, Assets bewegen, Contracts verwalten oder Notfallfunktionen auslösen kann. Bei Test-Contracts werden diese Informationen je Contract in der Registry und den Contract-Details offengelegt.

Testnet-Berechtigungen Je Contract dokumentiert Zulässige Aktionen, nicht verfügbare Aktionen, Fähigkeiten und Einschränkungen werden für jeden Registry-Eintrag angezeigt.
Produktions-Governance Noch nicht veröffentlicht Finale Rollen, Multisig-Struktur, Timelocks und Notfallbefugnisse müssen als separate Produktionsreferenzen veröffentlicht werden. Vor dem Launch sollen relevante Befugnisse offengelegt werden, sodass Autorität sichtbar, begrenzt, regelgebunden und überprüfbar ist.
Treasury-Befugnisse Noch nicht veröffentlicht Derzeit gibt es keine veröffentlichte finale Produktions-Treasury-Struktur.
Impact Vault & Team-Vesting Geplant Die finalen Sperr-, Freigabe- und Kontrollmechanismen wurden noch nicht als Mainnet-Contracts veröffentlicht.
Klassifizierungsregel: Das Portal sollte Begriffe wie „dezentralisiert“, „unveränderlich“ oder „community-kontrolliert“ nicht als pauschale Eigenschaften verwenden. Entscheidend sind konkrete Berechtigungen, Einschränkungen und veröffentlichte Produktionsmechanismen. Ein Multisig kann Freigaben verteilen, beweist für sich allein aber nicht, dass die Signer organisatorisch unabhängig sind. Derselbe Offenlegungsstandard muss letztlich auch für GFC selbst gelten.

Finanzielle Transparenz

Wallets, Reserven und Finanzflüsse

Status: noch nicht anwendbar — keine Produktions-Treasury veröffentlicht. Produktions-Wallets, Treasury-Adressen und Reserve-Adressen wurden noch nicht veröffentlicht. Daher gibt es derzeit keine produktive Treasury- oder Charity-Transaktionshistorie, die dieses Portal als GFC-Mainnet-Nachweis darstellen könnte.

Bewegungen auf Base Sepolia sind ausschließlich Entwicklungs- und Testnachweise. Sie dürfen nicht als produktive Treasury-Aktivität, Charity-Ausschüttungen oder Mainnet-Finanzausführung dargestellt werden.

Sobald Produktionsreferenzen existieren, sollte jede offizielle Finanzadresse mit Zweck, Netzwerk, Kontrollmodell, aktuellem Status und nachvollziehbaren Bewegungen veröffentlicht werden.

Tokenomics

Aktuelle Allokationsstruktur

Status: aktuelles Produktionsmodell, noch nicht technisch auf Mainnet durchgesetzt. Geplant sind 1.000.000.000 GFC Gesamtmenge, keine Inflation bzw. keine freie nachträgliche Mint-Befugnis nach dem finalen Deployment, 0 % Kaufgebühr und 1 % Verkaufsgebühr. Maßgeblich werden diese Regeln technisch erst, wenn der finale Base-Mainnet-Contract veröffentlicht, quellcode-verifiziert und seine tatsächliche Berechtigungsstruktur geprüft ist. Allokation ist zugleich eine Governance-Entscheidung: Prozentwerte allein zeigen nicht, wer die zugewiesenen Wallets kontrolliert, ob Einschränkungen technisch durchsetzbar sind oder ob diese Regeln später geändert werden können.

25%

Impact Vault

250.000.000 GFC • 50-jährige Sperre geplant • für Charity- und Wirkungszwecke gemäß den finalen Vault-Regeln vorgesehen. Die Sperrdauer allein beweist weder Zweckbindung noch Unveränderlichkeit; der technische Mechanismus, die Berechtigungen und Änderungsrechte sind die relevanten Nachweise.

20%

Guardian Growth Fund

200.000.000 GFC • Guardian-Belohnungen, Community-Wachstum, Ambassadors, Governance und Kampagnen.

15%

Presale-Allokation

150.000.000 GFC • geplante Presale-Allokation, derzeit nicht aktiv.

15%

Treasury-Reserve

150.000.000 GFC • Entwicklung, Audits, Infrastruktur, Sicherheit, Partnerschaften und Expansion.

15%

Liquiditätsreserve

150.000.000 GFC • zukünftige Liquiditätsmaßnahmen und Marktzugang.

5%

Ecosystem Growth Fund

50.000.000 GFC • Ökosystementwicklung, Integrationen und Projektentwicklung.

5%

Core-Team-Allokation

50.000.000 GFC • lineares Vesting über 19 Jahre ab einem formal definierten Startdatum. Die Vesting-Dauer allein beweist nicht, dass der Zeitplan unveränderlich ist; der finale Contract und die Kontrollrechte müssen dies festlegen.

Wirkungsverifikation

Eine sichtbare Zahlung ist nur der Anfang

Das langfristige Transparenzmodell soll Finanzbewegungen, Governance-Nachweise und tatsächliche reale Wirkung getrennt offenlegen. Eine Blockchain-Transaktion allein beweist nicht, dass der angegebene gesellschaftliche Zweck erreicht wurde.

Ebene 1 Finanzielle Ausführung Was wurde wann, in welcher Höhe, von welcher offiziellen Adresse an welche Zieladresse übertragen?
Ebene 2 Governance-Nachweise Warum wurde die Zahlung ausgeführt, wer hat sie genehmigt und mit welcher dokumentierten Entscheidung ist sie verknüpft?
Ebene 3 Wirkungsverifikation Welche Dokumentation, Liefer- oder Empfängerbestätigungen, messbaren Meilensteine oder unabhängigen Prüfungen zeigen, dass der reale Zweck tatsächlich erfüllt wurde, und welchen Status haben diese Nachweise: verifiziert, ausstehend, unvollständig oder nicht verifiziert?
Aktueller Status: GFC veröffentlicht derzeit keine produktiven Charity-Ausschüttungen oder verifizierten Datensätze zu realer Wirkung. Dieser Abschnitt beschreibt den vorgesehenen Nachweisstandard, nicht bereits eingetretene Wirkung. Eine sichtbare Transaktion ist der Beginn einer Nachweiskette — nicht ihr Ende.

Verifikationsgrenzen

Was Blockchain beweisen kann

  • dass eine bestimmte Transaktion auf einem bestimmten Netzwerk stattgefunden hat;
  • welche Adressen beteiligt waren und welcher On-Chain-Wert übertragen wurde;
  • welcher Bytecode an einer Contract-Adresse deployed ist;
  • bestimmte öffentlich lesbare Contract-Zustände und technische Regeln.
Verifikationsregel: Sichtbar ≠ verifiziert ≠ vollständig bewiesen. Frage: Was ist sichtbar? Was beweist es? Was bleibt unbelegt? Eine sichtbare Transaktion ist der Beginn einer Nachweiskette — nicht ihr Ende.

Zukünftiger Mainnet-Umfang

Geplante Produktionskomponenten

Status: vorgesehen / geplant. Die folgenden Komponenten bleiben geplant und werden von der aktuellen Base-Sepolia-Test-Registry nicht abgebildet, sofern später kein separates Deployment veröffentlicht wird. Eine Testnet-Referenz wird nicht automatisch zum Produktionsnachweis: Jede Mainnet-Komponente muss mit eigener Adresse, eigenem Netzwerk, Code, Berechtigungen, Kontrollmodell, Verifikationsstatus und geltenden Nachweisgrenzen erneut veröffentlicht werden.

Mainnet-Token Nicht veröffentlicht Die finale GFC-Token-Adresse auf Base Mainnet ist noch nicht verfügbar.
Mainnet-Presale Nicht veröffentlicht Es gibt keinen offiziellen Mainnet-Verkaufscontract und keine Einzahlungsadresse.
Impact Vault Nicht veröffentlicht Die zweckgebundene langfristige Sperrstruktur bleibt geplant.
Core-Team-Vesting Nicht veröffentlicht Der geplante lineare 19-Jahres-Vesting-Contract wurde noch nicht deployed.
Treasury und Reserven Nicht veröffentlicht Die finalen Treasury-, Reserve-, Multisig- und Governance-Kontrollen müssen noch finalisiert und als konkrete Produktionsreferenzen veröffentlicht werden.
Unabhängiges Audit Nicht veröffentlicht Derzeit deckt kein externer Audit-Bericht ein Produktions-Deployment ab.

Audit-Status

Noch kein externer Audit-Bericht

Für keinen der derzeit aufgeführten Base-Sepolia-Test-Contracts wurde bisher ein unabhängiger Audit-Bericht veröffentlicht. Die Quellcode-Verifikation über die im jeweiligen Registry-Eintrag ausgewiesene Explorer-Quelle dokumentiert die Zuordnung des veröffentlichten Quellcodes zum deployten Contract-Code; sie ist kein Sicherheitsnachweis und ersetzt kein unabhängiges Audit.

Ein Audit sollte erst dann als abgeschlossen gelten, wenn der Bericht, die auditierte Code-Version und der Audit-Umfang öffentlich zugeordnet und verifiziert werden können. Quellcode-Verifikation ersetzt kein unabhängiges Sicherheitsaudit.

Presale-Status

Kein aktiver öffentlicher Mainnet-Presale

GFC hat zur technischen Validierung einen Base-Sepolia-Test-Presale-Contract veröffentlicht. Er akzeptiert Base-Sepolia-ETH, von Circle für Base Sepolia gelistetes Test-USDC und GFC Mock DAI und verteilt tGFC unmittelbar nach einer erfolgreichen Testzahlung. Das gelistete Test-USDC wurde nicht von GFC deployed oder kontrolliert und besitzt keinen realen finanziellen Wert.

Dieses Test-Deployment ist weder ein offizieller Mainnet-Presale noch eine öffentliche Fundraising-Adresse oder ein Anlageprodukt. Das konfigurierte Testfenster wird in den Contract-Details direkt aus dem veröffentlichten Test-Contract ausgelesen. Der Test-Contract enthält weder einen Soft Cap noch einen Refund-Mechanismus.

Aktueller Planungsstand: Vorgesehen sind 0,05 € pro GFC, acht Wochen, ein Soft Cap von 250.000 €, maximal 150.000.000 GFC aus der Presale-Allokation und ein Refund bei Nichterreichen des Soft Caps; ein separates monetäres Hard Cap ist derzeit nicht geplant. Diese Parameter sind nicht live, werden derzeit von keinem Mainnet-Verkaufscontract durchgesetzt und es gibt kein öffentlich bestätigtes Startdatum.

Verbindliche Produktionsparameter und die zugehörigen Produktionsreferenzen werden auf der separaten Presale-Seite und hier erst als live bzw. technisch durchgesetzt dargestellt, nachdem die rechtliche, technische, sicherheitsbezogene und operative Freigabe abgeschlossen und die finalen Mainnet-Referenzen veröffentlicht wurden.

Nur Adressen und Links, die auf der offiziellen GFC-Website und in diesem Transparenzportal veröffentlicht sind, sollten als maßgeblich behandelt werden. Testnet-Adressen dürfen niemals als Mainnet-Kauf- oder Einzahlungsadressen behandelt werden.

Risikohinweis

Transparenz reduziert Risiken — sie beseitigt sie nicht

Blockchain-, Token- und Presale-Strukturen bergen erhebliche technische, regulatorische, operative und marktbezogene Risiken.

  • Es gibt keine Gewinnversprechen und keine Garantie für eine Wertsteigerung.
  • Es gibt keine Garantie für Handelbarkeit, Liquidität oder Nachfrage.
  • Verifizierte Contracts sind nicht automatisch extern auditiert.
  • Auch ein Audit kann Fehler oder Sicherheitsrisiken nicht vollständig ausschließen.
  • Rechtliche, technische oder operative Änderungen können die Umsetzung beeinflussen.
  • Diese Website bietet keine individuelle Anlage-, Finanz-, Rechts-, Steuer- oder Kaufberatung.

Dokumentation

Kontext zu den öffentlichen Nachweisen

Das Transparenzportal zeigt Status und Nachweise. Die zugehörigen GFC-Seiten liefern Architektur, Grundlagen, häufig gestellte Fragen und den separaten Presale-Status. Wesentliche Änderungen am Portal werden datiert, damit Statusänderungen, neue Contracts und neue Nachweise von früheren Versionen unterschieden werden können.

Versionierung

Änderungsprotokoll

  • 26. August 2026: Produktrolle des Transparency Portals an den aktuellen GFC-Stand angeglichen: Primärer Fokus bis einschließlich Q1 2027 ist der GFC Token / Economic Layer; das Portal bleibt eine Read-only-Nachweis- und Informationsschicht ohne Ausführungs- oder Kontrollautorität. Base bleibt operativer Blockchain-Fokus; Base Sepolia bleibt die öffentliche Test-/PoC-Referenz, während Mainnet-Token und öffentlicher Presale weiterhin nicht live sind. Verifikations-Freshness, Nachweisgrenzen, Presale-/Token-Planungsstatus, No-JavaScript-Ausgangszustände und mobile Nachweisnavigation wurden präzisiert.
  • 23. August 2026: Portal-Markup für eindeutige Wiederherstellungszustände vorbereitet: separate Retry-Schnittstellen für Contract-Referenz, Live-On-Chain-Werte und Quellcode ergänzt sowie eine zentrale, nicht-visuelle Statusausgabe für zugängliches Interaktionsfeedback vorgesehen. Die englische Portal-Fassung wurde strukturell und inhaltlich auf denselben Stand gespiegelt und die Sicherheitskonfiguration für eine gleichwertige restriktive CSP vorbereitet.
  • 22. August 2026: Deployment-Härtung vorbereitet: Registry-Bootstrap-Watchdog aus dem Inline-Code in eine eigenständige, sofort gestartete Fallback-Datei ausgelagert, damit ein hängendes Deferred-Script den Ausfallschutz nicht verzögert. Canonical-Routen für das Transparency Portal vereinheitlicht und der aktuelle Seitenstand für eine restriktive Content-Security-Policy vorbereitet.
  • 21. August 2026: Nachweiszugriff priorisiert: offizielle Contract-Referenzen nach dem Projektstatus vorgezogen und eine direkte Nachweisnavigation ergänzt. Status- und Aktualitätsangaben semantisch getrennt, Registry-Fehlerdarstellung konsolidiert, Contract-Modal-Ladezustände präzisiert sowie technische Mobile-Typografie und Touch-Targets verbessert. Das Transparency Portal bleibt bewusst Dark-only.
  • 18. August 2026: Footer und Modals statisch in die Portal-Seite integriert; Runtime-Partial-Loader entfernt. Explorer-Links auf die offiziell konfigurierten BaseScan-/Blockscout-Ursprünge begrenzt, Registry- und Manifest-Größenprüfungen auf tatsächlich geladene Bytes gehärtet, Solidity-Quellcode-Integrität und Ladegrenzen verschärft sowie Modal- und No-JavaScript-Zugänglichkeit verbessert.
  • 16. August 2026: Audit-Formulierungen an den seitenübergreifenden Audit-Standard angeglichen. Fehlerbehandlung der Registry mit einem begrenzten Ladezustand, expliziten Nicht-verfügbar-Zuständen, Retry-Unterstützung und Base-Sepolia-Explorer-Fallbacks verstärkt. Seiten-Aktualisierungsdatum und Registry-Aktualisierungsdatum bleiben bewusst getrennt.
  • 13. August 2026: Verifikationssprache des Portals geschärft: aktuelle Nachweisebenen, Testnet-/Mainnet-Trennung, Governance-Offenlegungsprinzipien, Status der finanziellen Transparenz, Verifikationsfragen, Kriterien für den Abschluss eines Audits und Grenzen der Nachweiskette präzisiert.
  • 8. August 2026: Transparenzportal konsequent um Nachweise herum neu strukturiert: Verifikationsübersicht, aktueller Nachweisumfang, Governance- und Kontrollstatus, finanzielle Transparenz, Wirkungsverifikation und explizite Grenzen von Blockchain-Nachweisen ergänzt.
  • 2. August 2026: Zentrale Base-Sepolia-Registry für den GFC Test Token, GFC Mock DAI und GFC Test Presale ergänzt, einschließlich Deployment-Klassifizierungen, Explorer-Referenzen, Abhängigkeiten und Systembeziehungen.
  • 2. August 2026: Dynamische Architektur für Contract-Details vorbereitet, einschließlich Manifest-Daten, direkter JSON-RPC-Abfragen, Berechtigungen, Einschränkungen und vollständigem verifiziertem Solidity-Quellcode.
  • 2. August 2026: Presale-Kommunikation aktualisiert, um den veröffentlichten Base-Sepolia-Test-Presale klar von einem zukünftigen öffentlichen Mainnet-Presale abzugrenzen.
  • 28. Juli 2026: GFC Test Token auf Base Sepolia (0x7262Cca91938ede6bB6560F81104Aa410848e7f3) als erste öffentliche Entwicklungsreferenz ergänzt.
  • 12. Juli 2026: Statuskommunikation für Presale, Mainnet-Contracts, Refunds und Audit standardisiert.
  • 5. Juli 2026: Transparenzseite an den aktuellen GFC-Masterplan angeglichen.

Wesentliche Änderungen werden datiert und sollen später zusätzlich über offizielle Repositories oder Dokumentationskanäle nachvollziehbar sein.

Kontakt

Unstimmigkeit melden

Hast du eine falsche Adresse, einen möglichen Betrugsversuch oder eine widersprüchliche Contract-Referenz gefunden?

info@globalfoundationcoin.org

Bitte füge den Explorer-Link, das Netzwerk, die Chain ID, den Transaktionshash, die URL oder die konkrete Quelle hinzu. Screenshots allein sind kein ausreichender Nachweis.