German Foundation Coin (GFC)

1) Summary

The German Foundation Coin (GFC) is a transparency-oriented ERC-20 token on the Base chain (L2, Chain ID 8453). The goal is to mobilize funding for education, youth and social projects in a verifiable manner – starting in Germany. International funding may be possible in the future, but only via carefully vetted, documented partners and clearly defined approval processes.

Status (document context v1.1): Token, lock and vesting contracts are deployed on Base and linked (see section 15.2). Further components – especially the foundation vault and matching/trigger logic – are described as the target architecture and will be implemented step-by-step, including external reviews (audits). The presale is planned for Feb 2, 2026, 18:00 CET to Mar 16, 2026, 18:00 CET (see section 6).

GFC is deliberately not a meme coin. The objective is a long-term, sustainable funding ecosystem with verifiable documentation, clear rules, and a perspective to extend into platform/app capabilities (project overview, impact display, voting and reporting).

2) Problem & Motivation

Despite large budgets, kindergartens, schools, youth centers and social institutions often report shortages, inefficient processes and low transparency. Donors and supporters frequently cannot independently verify how funds were used and what impact was achieved.

• Information gap: Fragmented pathways, missing or hard-to-access evidence.
• Efficiency problem: High administrative overhead, inconsistent documentation.
• Trust question: Accountability is often hard to compare and not standardized.

Our conviction: a transparent, data-oriented system that prioritizes verifiability can increase trust and effectiveness. GFC is politically neutral: it supports concrete projects, not parties, campaigns or political initiatives.

3) Solution: GFC

GFC combines on-chain verifiability (where sensible) with public documentation (reports, media, proofs) and community participation. Over time, this information is intended to be accessible through a platform/app – with project overviews, an impact view and voting modules.

4) Tokenomics

The “Dev & Development” share includes, among other items, the founder allocation of 500 000 000 GFC (10% of total supply). It is subject to strictly linear vesting over 50 years (600 months). Per month, approx. 0.1667% of the founder tokens are released (≈ 0.01667% of total supply). The vesting contract can only be extended, never shortened in favor of the founder.

For founder and project/marketing vesting, a clear schedule applies: lock until Mar 31, 2026, followed by vesting from Apr 1, 2026. Founder vesting runs until Apr 1, 2076 (50 years), and project/marketing vesting until Apr 1, 2051 (25 years). In both cases, only extensions are possible.

Handling unsold presale tokens

If tokens remain unsold after the presale, they will be assigned once and transparently according to an on-chain fixed logic:

• 50% → Staking pool
• 20% → Charity / Foundation
• 10% → Liquidity
• 10% → Marketing
• 10% → Burn

Tokenomics, distributions and policies are published in versioned form. Changes (if ever required) will only occur in a traceable manner, documented and referenced in the transparency portal.

5) Locks, Vesting & Donation Mechanics

5.1 Charity allocation (lock & target mechanism)

The charity allocation is long-term locked via a CharityLock contract until at least Apr 1, 2051. The lock can only be extended, but not shortened to the benefit of the project/founder. During the lock period, only clearly defined and documented exceptions are intended (e.g., matching transfers per target architecture).

The CharityLock is designed as a multi-asset lock: in addition to GFC, it can also hold assets such as ETH or DAI. While GFC is subject to the long-term lock (exception: defined matching transfers), ETH/DAI may be forwarded under documented rules to designated structures for donation/infrastructure funding.

Note: The target architecture for matching/trigger will be implemented separately, documented and externally reviewed (audit). The current state is transparently verifiable via linked contracts/repos.

Target state (after deployment of the trigger mechanism): A donation into the foundation vault triggers an on-chain event, transferring an additional 30% of the donated amount from the CharityLock into the same vault.

Example (target architecture): donation of 1,000 GFC into the foundation vault ⇒ additional 300 GFC from CharityLock into the vault.

5.2 Foundation vault (multi-sig & approvals)

The foundation vault is a multi-signature structure for secure custody and controlled fund allocation. Payouts are intended to be tied to defined verification and approval processes.

1. Proposal & community decision: projects/categories are submitted, reviewed and voted.
2. Verification: on-site or document verification against a standard – by the GFC team and/or vetted partners.
3. Payout: approvals and payouts are documented; where possible, verifiable on-chain.

5.3 Founder vesting (50 years)

The founder share (500,000,000 GFC) is subject to strictly linear vesting over 50 years. The vesting contract is designed so the period can only be extended, but never shortened in favor of the founder.

5.4 Founder ethics & voluntary contributions (no price promises)

In addition to vesting, GFC follows a founder commitment: at certain value thresholds, the founder may voluntarily use a portion of the monthly vesting (or its value in ETH/USDC) for donations, burns, or reinvestments. Important: this is not a price target, not a return promise and not a forecast – it merely describes a voluntary, transparent principle.

Illustrative orientation (non-binding, to be specified transparently over time):

• from approx. €0.50 per GFC: at least 5% of monthly vesting
• from approx. €1.00 per GFC: at least 10%
• from approx. €2.50 per GFC: at least 20%
• from approx. €5.00 per GFC: 30–50%

The concrete split (e.g., charity, burn, liquidity, treasury) will be documented transparently over time.

6) Presale & Funding

A beginner-friendly overview (how to buy, calculator, safety rules) is additionally available on the presale page.

Discount codes or OTC bookkeeping are optional special cases and exist exclusively to represent clearly labeled exceptions on-chain. There are no hidden team preferential conditions. Relevant deviations will be documented transparently.

7) Treasury & Burn Policy

7.1 Treasury

• Relevant addresses are published and linked.
• Use of funds for the mission, development, audits, infrastructure and resilience (reserves) – documented.
• Regular reports incl. exports (CSV/JSON) as a basis for review/analysis (planned).

7.2 Burn mechanism (policy-based)

Burn is an optional, policy-based instrument for long-term scarcity without compromising the mission. A “Burn Policy v1.0” will be published in a versioned manner; governance can enable later adjustments.

The above values are examples. The authoritative source is the versioned burn policy.

8) Governance, Community & Holder Value

• Right to propose: the community can propose categories/projects (moderated; anti-sybil approach).
• Voting: on-/off-chain votes (e.g., Snapshot) on priorities, policies and parameters.
• Transparency: results are published and linked.

8.1 Concrete value for holders

• Participation: influence funding categories, priorities and policies.
• Alignment with impact: visible projects strengthen trust and reach.
• Programs: staking/community programs to foster long-term engagement (planned).

8.2 Team & background (high-level)

GFC is initiated by a small core team. The goal is a sustainable structure that can be transitioned into a suitable non-profit organization (e.g., gGmbH/foundation). Details on partners/advisors will be published once the legal framework is finalized.

9) Transparency, Reporting & Audit

Price widgets are informational; critical logic does not rely on third-party APIs.

10) Technical Architecture

• Chain: Base (L2, EVM), Chain ID 8453
• Token: ERC-20 (18 decimals)
• dApp/platform (planned): wallet connect, presale/donation modules, reporting dashboards
• Oracles/prices: UI-only (no critical on-chain dependency)
• Multi-sig: governance/treasury control, defined signer policy

Presale deposits remain in the presale contract initially. If the soft cap is not reached, refunds are available. If the soft cap is reached, the admin can withdraw funds according to contract logic – even before the presale ends. Automatic forwarding into vaults is not intended; distribution is performed afterwards with transparent documentation.

The following donation flow describes the target architecture after deployment of lock/vault/trigger components. Interim steps will be documented.

Example: Donation flow (target architecture)

1. Donation into the foundation vault (multi-sig).
2. Trigger (planned): +30% matching from CharityLock into the same vault.
3. After vote & verification, payout to the recipient – documented.
4. Optional: burn per burn policy.
5. Reports & proofs are published.

// Pseudocode – event logic (simplified, target architecture)
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% from CharityLock
    emit DonationMatched(msg.sender, amount, matchAmount);
}

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

11) Security Concept

• Multi-step approvals: multi-sig for critical actions.
• Defensive defaults: separation of roles/rights, limits, guard mechanisms (where sensible).
• Monitoring: on-chain alerts for transfers, role changes and unusual events.
• Bug bounty: planned after audits.

12) Legal Notes

• Compliance: gradual alignment with German & EU requirements
• Taxes: depends on legal form and individual circumstances
• Liability: no return guarantees, no price promises

13) Roadmap

Timelines are target corridors and may change due to external factors. Changes will be documented.

14) Risk Notice

15) Smart Contract System (architectural overview)

GFC follows a modular architecture: token, vesting/locks, presale, vaults and (later) matching/trigger are clearly separated components. The goal is verifiability and minimal complexity per module.

15.1 Architectural principles

• Separation of responsibilities: modules instead of monolithic contracts.
• On-chain traceability: events and links as the basis for reports.
• Extend-only: locks/vesting can be extended, not shortened in favor of the team.
• Vault-first: use funds via defined structures rather than private wallets (target state).
• Defensive defaults: multi-sig, limits, clear roles.

15.2 Linked contracts on Base (L2)

The following contracts are deployed on Base (Chain ID 8453), immutable, and can be verified via BaseScan. The only authoritative source is the address state documented here.

Presale admin (presale wallet): 0x2DF379857C59F01F37830A1Dd19B4dFaf3689a18.
Note: The presale contract is deliberately non-upgradeable. Changes only occur via new versions and will be documented transparently.

15.3 Planned components

• Foundation vault (multi-sig): custody & approval logic.
• Matching/trigger contract: automatic +30% matching (target architecture).
• Staking contract: staking pool & rewards.

15.4 Security, upgrades & audits

• Minimal upgrade complexity: prefer new versions over unnecessary proxy complexity.
• Roles & permissions: separated roles, transition to multi-sig.
• Audits: external audits, publication of reports.
• Monitoring: alerts on large outflows/role changes.
• Bug bounty: planned after audits.

16) FAQ

How is the EUR value calculated in the presale?

The presale uses a reference price of €0.05 per GFC. The UI shows conversions for informational purposes. The authoritative source is the deterministic on-chain logic of the presale contract.

What happens to donated coins?

Donations are intended to flow into the foundation vault. In the target architecture, after deployment of the trigger logic, this triggers a +30% matching. Payouts occur after vote & verification, documented and where possible traceable on-chain.

How is abuse prevented?

Through multi-sig approval processes, public documentation, external audits (planned) and community review.

How can I get started today?

Current information is published at germanfoundationcoin.org. Partnerships may be possible over time, but only with organizations that demonstrably operate transparently and document their work.