The Architecture Behind GFC

1. Executive Summary

Global Foundation Coin (GFC) is currently developing the GFC Token / Economic Layer on Base. Through Q1 2027, operational work is focused on robust presale and mainnet readiness of this product. Transparency, Governance, Verification, Testing, Security, Smart Contracts, Legal, Website, Marketing, Partnerships and Funding support that focus. From Q2 2027, development is intended to expand progressively toward the broader GFC system and, over the longer term, Accountability Infrastructure around the token and potentially beyond it. This longer-term direction is a roadmap, not a representation of currently active functionality.

The objective is not to replace trust with marketing, but to make as many verifiable elements as possible publicly accessible: technical rules, contract versions, wallet roles, governance decisions, financial movements and – where realistic – supporting evidence of real-world impact.

2. The Problem

In charity, impact and publicly communicated funding projects, information is often distributed across separate systems, documents and channels. As a result, it may be visible that money was moved without it being equally clear why a decision was made, who authorized it and which evidence is later available for the result.

3. The GFC Approach

GFC separates four layers that are intended to create a more traceable public overall picture when combined.

4. What Blockchain Can Verify – and What It Cannot

5. Current Development Status

GFC consistently distinguishes between specified, in development, testnet/pilot, planned and production active.

Through Q1 2027, the GFC Token / Economic Layer is the primary product. The operational focus is robust presale and mainnet readiness; supporting system areas are presented as current only where they are actually published, specified or available in test/pilot form.

Swipe or scroll horizontally on smaller screens to view all columns.

The public Base Sepolia PoC creates development evidence. Testnet deployments are not production products, not purchase addresses and not the production GFC token. The Transparency Portal is authoritative for current production status, official addresses and versioned references.

6. GFC Token / Economic Layer and Utility

The GFC Token / Economic Layer is currently GFC’s primary product. Technically, GFC is planned as an ERC-20 token on Base Mainnet; “coin” is the project and brand term and does not refer to a separate native blockchain. Through Q1 2027, the operational focus is robust presale/mainnet readiness. A function should only be described as implemented utility when its mechanism, eligibility, timing, limits, change authority and production status are publicly defined and verifiable.

Swipe or scroll horizontally on smaller screens to view all columns.

7. Tokenomics and Allocations

The planned fixed total supply is 1,000,000,000 GFC. Allocation is a governance decision, not merely a percentage chart: it distributes access, liquidity, incentives and potential influence. Each allocation therefore needs purpose, control, restrictions and time logic.

Swipe or scroll horizontally on smaller screens to view all columns.

8. Locking and Vesting

To Be Disclosed Before Production Activation

• start event and exact time logic;
• release intervals and maximum releases;
• whether a protection period can only be extended — and cannot be shortened — where extension-only protection is part of the final design;
• beneficiaries and controlling roles;
• amendment, extension and emergency rights;
• treatment of unused or unvested tokens;
• public contract and wallet references.
• all production locking and vesting rules must be publicly mapped to the deployed contract version and controlling roles before activation.

9. Governance and Distribution of Power

At GFC, governance initially does not mean “every token is one vote,” but the precise definition of technical and organizational decision-making authority.

Swipe or scroll horizontally on smaller screens to view all columns.

10. Governance Constraints

Principle: Relevant authority should be visible, limited, rule-bound and reviewable. The same standard must ultimately apply to GFC itself.

11. Transparency Architecture

The whitepaper describes how transparency is intended to work. The transparency portal shows which specific data, contracts, status information and evidence are currently available.

12. Technical Architecture

GFC is initially planned as Ethereum-compatible infrastructure on Base. A proprietary blockchain is not part of the launch model.

13. Smart Contract Principles

Smart contracts do not automatically solve governance. Their value lies in making certain rules technically enforceable and more clearly limiting the remaining scope for human discretion.

• fixed or clearly limited token rules instead of hidden special rights;
• public source-code verification of production contracts;
• explicit roles and permissions;
• audit report, audit scope, exact reviewed code version/commit and the associated production address must be publicly and unambiguously matchable;
• critical exceptions and pause functions must be documented;
• production addresses are published exclusively through official references.

14. Presale Architecture

The planned presale is a funding mechanism within the GFC Token / Economic Layer, currently GFC’s primary product. It is not active. Through Q1 2027, the operational focus is robust presale and mainnet readiness. Operational participation, binding terms, official production references and any later purchase guide belong on the separate Presale page and Transparency Portal.

Swipe or scroll horizontally on smaller screens to view all columns.

Required Before Activation

1. binding refund and unwind logic for GFC already allocated immediately;
2. final technical and legal terms;
3. frozen production contract version for review;
4. independent review of critical production contracts;
5. remediation or disclosure of relevant findings;
6. publication of report, address and source-code reference;
7. public activation only afterward.

15. Staking

A hybrid, non-inflationary staking model is planned as part of the long-term token architecture, but it is currently not active. There is no guaranteed return and no final published APY.

• the reward source must be fully disclosed before activation;
• rewards must not require additional token inflation;
• lock periods and payout rules must be technically defined;
• governance or community benefits must be described concretely rather than rhetorically;
• smart contract, liquidity and market-price risks remain;
• slashing is currently not a confirmed component of the model.

16. Expansion from Q2 2027: Protocol and Impact Layer

From Q2 2027, GFC is intended to expand progressively into the broader system around the token. This includes more deeply integrated transparency, governance, verification and impact structures. Over the longer term, the development direction is Accountability Infrastructure around the token and potentially beyond it. This expansion is not a launch promise and does not represent currently active functionality.

Criteria, review scope, conflicts of interest, evidence classes, verification status, revocation, updates and validity period must be fully published before any public use of such a status. A “GFC Verified” label would not be government approval and would not guarantee integrity, security, impact or economic success.

17. Security

• internal testing before production deployment;
• an audit should only be treated as publicly and unambiguously mapped when the audit report, audit scope, exact reviewed code version/commit and the associated production address can be publicly matched to one another;
• independent review of final critical production contracts;
• public source-code verification;
• separation of critical operational roles;
• multi-party approval where appropriate;
• documented emergency and recovery procedures;
• clear rules for official links, wallets and contract addresses;
• responsible disclosure process for security reports.

18. Risks and Non-Goals

19. Development Roadmap

The roadmap describes technical maturity stages rather than speculative market targets.

20. Documentation Hierarchy and Changelog

Not every piece of information belongs at the same level. GFC deliberately distinguishes between accessible overall documentation, normative specifications, technical implementation and current verification data.

Normative Documents

• specs/README.md — specification index, status model and release rules
• specs/glossary.md — shared terminology
• specs/non-goals.md — intentional exclusions and unsupported interpretations
• specs/architecture.md — high-level architecture and constraints
• specs/governance-constraints.md — governance and authority constraints
• specs/transparency-model.md — evidence, verification and disclosure requirements
• specs/presale.md — presale rules and participant protections
• specs/token.md — token model, fixed-supply logic and technical token requirements
• specs/allocations.md — allocations, purpose restrictions, constraints and time logic

Repository-Level Documents

• SECURITY.md — security reporting guidance
• CHANGELOG.md — repository-level change history

The file names below describe the project’s current internal specification set. They are not currently linked on this website as public versioned repository references. Only a published, unambiguous release or commit reference makes a specification a publicly canonical technical source. Potential future specifications — including dedicated treasury, vesting, staking or impact-methodology specifications — must not be presented as existing until they have been created and versioned.