Skip to content

GiftoV3 Whitepaper

Version 1.2 — 28 July 2026 (supersedes v1.1, 26 July 2026 and v1.0, 6 July 2026)

Items marked coming soon (contract addresses, audit reports, listings, official links) are published as the relaunch deploys, per the project roadmap. Roadmap features are objectives, not commitments, and are not live until shipped.

??? info "What changed in v1.2 — the migration ratio improved in holders' favour" The migration ratio has changed from 20:1 to 5:1. Every eligible legacy GFT now converts to four times as much GFTW as previously published.

This is an improvement to holders, not a reduction, and we want to be equally clear about what funds it and what it costs. The migration pool grows from 5% of supply (50M GFTW) to **13% (130M GFTW)**, and that 8% comes out of the **Creator Reserve, which falls from 50% to 42%**. No other bucket moves. Insiders remain at 5% and still vest last.

**The launch price is unchanged at $0.20, and so is the $200M fully diluted valuation.** The ratio changed; the price did not.

One figure does move as a consequence. Migration carries no lockup, so a larger migration pool means more supply is liquid on day one: **opening float rises from ~7% to ~15%, and expected initial market cap from ~$14M to ~$30M.** That is not a change of plan or valuation, it is arithmetic — more tokens in holders' hands at launch, at the same price per token. §9.6 has been recalculated accordingly.

We are stating it rather than leaving it to be discovered, because a higher opening float is the honest cost of a better ratio and you should be able to see both sides of the trade.

Migration eligibility is unchanged: the November 2024 minted tokens remain excluded by the snapshot cutoff, and prior-operator wallets remain excluded (§7.2). Exchange-held balances are included.

??? info "What changed in v1.1 — and why we are telling you" Version 1.0 was written before the contracts were built. Building them settled several questions that v1.0 had answered provisionally, and in four places v1.0 no longer described reality. Rather than quietly edit, we are listing every change. A whitepaper that changes silently is how a project starts lying to you slowly.

- **§7.2 — the snapshot.** v1.0 said a snapshot had "already been taken." It had not. Eligibility has now been rebuilt directly from the public chain record at a published cutoff block, and the dataset plus the script that produces it are published so anyone can reproduce it. This is a stronger position than v1.0 claimed, but the v1.0 claim was not accurate and should not have been made.
- **§7.2 — registration is now required.** Migration is **not automatic**. Holders must register a receipt wallet within a published window or they do not receive GFTW. v1.0 described claiming with no such precondition. This is the single most important change in this revision.
- **§7.3 / §9.5 — the anti-dump fee.** v1.0 said the fee "cannot be bypassed" because GFTW would not be transferable until listing. We have since decided **not** to put any transfer lock or fee logic in the token, because both would hand the operators a lever over your funds. The fee is therefore a platform policy that applies to in-platform sales only, and we say so plainly rather than overstating its reach.
- **§9.6 — staking after Year 3.** v1.0 implied rewards would continue automatically from fee revenue. On-chain emissions are finite and end at month 36. Anything beyond that is a platform-funded policy decision, not a protocol guarantee.
- **§9.1, §11** — added the token contract's capability table (what it can and cannot do) and stated the audit sequencing openly.

Mechanics that did **not** change in v1.1: the fixed 1B cap with no mint function, vesting schedules, and the no-lockup commitment on migrated tokens. *(The ratio and allocation table subsequently changed in v1.2 — see above.)*

Disclaimer (Read First)

This whitepaper is provided for informational purposes only and is not an offer or solicitation to buy, sell, or hold any token or financial instrument, nor investment, financial, legal, or tax advice. Nothing here is a promise of future performance, value, or return.

Self-custody notice. GiftoV3 is non-custodial. You hold, and are solely responsible for, your own keys and recovery phrase. GiftoV3 never takes custody of your funds, cannot move them, and cannot recover a lost key or recovery phrase.

Regulatory notice. GFTW's classification (utility vs. security) and the availability of GiftoV3 services depend on jurisdiction and remain subject to regulation. Features, wallet model, and distribution may be restricted, modified, or delayed to meet legal and compliance requirements. Restricted jurisdictions are set out in the Terms of Service.

Forward-looking statements. This document contains forward-looking statements about roadmap, features, partnerships, and timelines. These are subject to change and are not guarantees. Roadmap items are objectives, not commitments, and may not ship as described or at all.

Third-party services. References to third-party providers (payment processors, exchanges, bridges, compliance vendors, card networks) describe intended or in-progress integrations and do not imply endorsement, partnership permanence, or availability.

By reading or relying on this document, you acknowledge that you understand these risks and accept that GiftoV3 and its contributors disclaim liability to the maximum extent permitted by law.


0. Glossary

  • GiftoV3 — the relaunched Gifto project: a self-custodial creator wallet with built-in migration, swap, and payments.
  • GFTW (Giftworld) — the new GiftoV3 token. Fixed supply of 1,000,000,000 (1B), never minted beyond the cap. The token legacy holders migrate to and the unit of utility across the ecosystem.
  • GFT — the legacy Gifto token (~1B supply). The token holders migrate from.
  • GFTPay — GiftoV3's payments product (virtual/physical cards, tap-to-pay, local-currency conversion). Rolling out — not yet live.
  • Migration — the one-directional swap of eligible legacy GFT into GFTW at a fixed 5:1 ratio, following registration of a receipt wallet (§7.2).
  • Registration — the step in which an eligible legacy holder designates the wallet that will receive their GFTW, proving control of the wallet that held their GFT. Migration is not automatic; holders who do not register do not receive GFTW.
  • Self-custodial — users hold their own keys; GiftoV3 never takes custody of funds and cannot move them.
  • Anti-dump fee — a tapering early-sell fee applied by the platform to in-platform sales of migrated tokens, directed to the liquidity pool and stakers, that decays to zero over time. It is a platform policy, not a property of the token (§7.3).
  • TGE — Token Generation Event: the relaunch moment when GFTW becomes claimable, liquidity is seeded, and staking/emissions begin.
  • Multisig treasury — the project treasury, controlled by multiple signers rather than a single founder.
  • Creator Reserve — a fixed, pre-allocated pool of GFTW (50% of supply) distributed to creators over time as the creator economy grows. Metered distribution from a capped reserve — not new minting; the 1B cap is never exceeded.

1. Executive Summary

GiftoV3 is the relaunch of Gifto as a self-custodial creator wallet and payments platform. It gives people a straightforward way to migrate legacy GFT into the new GFTW token, hold and swap assets they fully control, and — through GFTPay — spend their balance in the real world.

GiftoV3 is deliberately self-custodial: users hold their own keys, and the platform never takes control of their funds. We focus on making self-custody as approachable as we can, while being plain about the responsibility it carries: only you can access your wallet, and only you can recover it.

The native token, GFTW, is a fixed-supply utility token. It is the destination for legacy migration, the asset staked for rewards, the basis for light governance, and — as features ship — the medium of exchange and fee token inside GFTPay.

Key parameters:

  • Total supply: 1,000,000,000 GFTW (fixed cap — no inflation, no minting)
  • Launch price: $0.20/GFTW → FDV $200M, ~$30M initial market cap at TGE (the price at which liquidity is seeded, not a prediction of where GFTW trades)
  • Creator Reserve: 42% of supply (420M GFTW) distributed to creators as the ecosystem grows — from a fixed pool, never minted
  • Migration: eligible legacy GFT converts at 5 GFT → 1 GFTW (130M GFTW pool = 13% of supply), with no lockup. Registration is required (§7.2)
  • Insiders: 5% (team + investors + advisors), vest last — far below V1's ~40%
  • Treasury: multisig-controlled
  • Staking rewards: funded by a pre-allocated community bucket of 180M GFTW over 36 months — no new issuance

The GiftoV3 thesis: legacy holders deserve a safe, honest path forward, and creators deserve the simplest possible way to own and spend their value. GiftoV3 corrects the structural mistakes of prior versions — insider-heavy allocation, opacity, and complexity — with a community-weighted token, a transparent migration, and an approachable self-custodial experience built for everyday users.


2. The Gifto Story

A relaunch only earns trust by being honest about the past. So before anything else: GiftoV3 is operated by a new, independent entity that acquired the Gifto brand and rebuilt the project under a new, more secure framework. The team behind GiftoV3 was not responsible for the prior token contract or the late-2024 events described below. We inherited a name with a history — and with it, an obligation to do right by the people that history left behind.

2.1 Origin: a landmark launch

Gifto launched in 2017 as a universal gifting protocol for content creators, tied to the Uplive live-streaming platform. It was the first project ever to launch on Binance Launchpad (December 14, 2017): it raised its $30M target within minutes, was oversubscribed roughly 1,066×, and traded up about 10× on its first day. For a time, the token (then GTO) was one of crypto's most visible community success stories.

2.2 What went wrong

The promise didn't hold.

  • A long decline. Through the 2018 bear market and the years after, development and usage faded; by around 2021 the project was widely regarded as inactive.
  • Transition and loss. The token was swapped GTO → GFT (BNB Chain, 1:1) in January 2023. Founder Andy Tian passed away in February 2023, days before the GFT launch — a genuine loss that also left the project without its original leadership.
  • The November 2024 collapse. On November 26, 2024, Binance announced it would delist GFT, citing a potential smart-contract security issue and declining activity. Within roughly two days, ~1.2 billion new GFT were minted on-chain — more than doubling the supply — and distributed across multiple exchanges. The price fell sharply, and Binance accelerated the delisting to December 3, 2024, reportedly the first time it removed a project early for manipulation of circulating supply. Those operating the project at the time described it as a "security incident," then went largely silent.

We do not restate intent we cannot prove. But the on-chain facts are not in dispute: supply was doubled into a delisting, holders absorbed the loss, and the silence that followed compounded it.

For the community, the damage was not only financial. A global holder base — many holding since 2017, spread across dozens of countries and languages — watched the supply double, the price collapse, and the project's channels go quiet, then found themselves stranded as exchanges removed GFT one by one. Notably, the holders who understood the chain pointed to the precise mechanisms that made it possible: an active mint function and unlocked liquidity. GiftoV3 is built to answer them directly — not with reassurance, but with structure.

2.3 New stewardship, a new framework

GiftoV3 exists to give this community something the last chapter did not: a project that cannot repeat those failures by design. The changes are structural, not cosmetic — and each one answers a specific, documented failure:

What went wrong What GiftoV3 changed
1.2B tokens minted unilaterally Fixed 1B supply cap, no minting — every allocation, creator rewards included, comes from fixed pre-minted pools; the cap is never exceeded
Concentrated, opaque insider control Multisig treasury; insiders just 5% (was ~40%) and vest last
Minting / dumping onto holders Anti-dump fee on in-platform sales (temporary, disclosed, §7.3) + community-weighted supply
Silence during the crisis Transparency commitments — public migration ledger, treasury attestations, audits, reporting
Team could move or freeze user funds Non-custodial — GiftoV3 never holds your keys or funds, so it cannot freeze, seize, or dump them
Legacy holders stranded Eligible legacy GFT migrates (130M GFTW pool at 5:1) after registration, no lockup. Prior-operator wallets are excluded (§7.2)
"Dead / inactive," missed milestones Utility marketed only when it ships; roadmap items are objectives, not promises

The rest of this document details each of these mechanisms.


3. Why GiftoV3 Exists

Creators and legacy holders face problems that polished UX alone cannot solve. GiftoV3 is built around three of them.

3.1 Legacy holders need a safe path forward

Across prior versions, holders were left with stranded value and broken trust. A relaunch that ignores them repeats the mistake. GiftoV3 migrates eligible legacy GFT at a fixed 5:1 ratio with no migration lockup — returning holders are made whole and not trapped a second time — while weighting the broader supply toward community and creators, not insiders. Eligibility is fixed by a reproducible on-chain snapshot that excludes the prior operators' own wallets, and holders register a receipt wallet to claim (§7.2). Anti-dump protection is handled by a temporary, transparent fee on in-platform sales (§7.3), not by freezing balances or restricting the token.

3.2 Crypto is too hard for everyday creators

Wallets, private keys, gas, and bridges exclude the very people the creator economy depends on. GiftoV3 keeps users in full control of their own keys while smoothing the experience around it — guided setup, a clean interface, and clear prompts — so self-custody is as approachable as we can make it. We are explicit about the trade-off: holding your own keys means you are responsible for keeping your recovery phrase safe.

3.3 Creators lose too much to platforms

Creators routinely surrender 10–30%+ of revenue to intermediaries, wait on delayed payouts, and are geographically gated. GiftoV3's roadmap pairs the wallet with GFTPay (§8) and creator tools to enable direct, low-fee, cross-border monetization and spending — turning held value into usable value.


4. What We're Building

GiftoV3 exists to make owning, moving, and spending digital value as simple as using a banking app — without gatekeepers or crypto barriers. The platform provides:

  • legacy migration of GFT → GFTW at a fixed ratio
  • multi-asset hold & swap between supported tokens
  • GFTPay — real-world spend via cards and tap-to-pay (rolling out)
  • creator monetization — in-stream tipping, stablecoin payouts, and token gifting (roadmap)

GiftoV3's role is to be the most approachable self-custodial home for a creator's value: bring legacy holders across safely, smooth the friction that keeps mainstream users out of crypto, and connect holdings to everyday spending and earning. Each capability is labeled by maturity — live, rolling out, or roadmap — throughout this document.


5. System Overview

5.1 Core Components

Wallet (self-custodial)

  • email-based accounts, no seed phrases
  • multi-asset balances, send/receive, in-app swap
  • KYC / compliance gating where required

Migration

  • GFT → GFTW conversion at a fixed 5:1 ratio
  • snapshot of eligible legacy holders + claim flow
  • unclaimed allocation returns to treasury after the window

GFTPay (rolling out)

  • virtual/physical card issuance
  • tap-to-pay and local-currency conversion at the point of spend

Self-custody & Compliance

  • users hold their own keys; GiftoV3 never takes custody of funds and cannot move them
  • KYC/AML at the platform / onboarding layer
  • policy: GiftoV3 never asks you to share your seed or recovery phrase

Integrations (in progress; subject to final agreements & usage rights)

  • payment, on/off-ramp, and compliance providers
  • card-network and bridging partners

5.2 Self-Custody Model (stated honestly)

GiftoV3 is non-custodial: users hold their own keys, and GiftoV3 never controls, holds, or can move user funds. The trade-off is responsibility — if you lose your key or recovery phrase, GiftoV3 cannot restore it. We treat this honestly, because it is also the point: GiftoV3 literally cannot do what the prior version did — freeze, seize, or dump user funds — because it never holds them. Our obligations are to make self-custody approachable, to secure the platform and contracts (§11), and to be transparent about exactly what we do and do not control.


6. The Wallet

6.1 What it is

The GiftoV3 wallet is a self-custodial, multi-asset wallet whose keys are held by the user. It is the home base for migrating, holding, swapping, and (as it ships) spending GFTW and supported assets. (Live.)

6.2 Onboarding & Keys

  • You hold your keys. Setup is guided, and your wallet is yours alone; GiftoV3 never holds it.
  • Back up your recovery phrase. Only you can restore your wallet — keep your recovery phrase safe and private.
  • Compliance-gated actions. Certain platform actions (e.g., higher-value flows) are gated behind KYC.

6.3 Assets & Swap

  • Hold supported assets in one balance.
  • Swap between supported assets in-app.
  • Send/receive to and from other accounts.

Self-custody: because you hold your keys, only you can access your funds — and only you are responsible for keeping your recovery phrase safe. GiftoV3 cannot access, freeze, or recover them.


7. Migration: GFT → GFTW

Migration is the heart of the relaunch: it brings legacy holders forward fairly and seeds the GFTW holder base.

7.1 Why Migrate

Legacy GFT carries the project's history and its holders. Rather than abandon them, GiftoV3 converts eligible GFT into GFTW so that legacy value is honored in the new economy. Migration covers the genuine legacy holder base (a 130M GFTW pool at 5:1) and seeds the new holder community.

Two categories are deliberately outside it: tokens created in the November 2024 mint, which the snapshot cutoff excludes entirely, and wallets belonging to the prior operators, including the address holding the original deployment mint. Migrating those would mean handing the people responsible for the collapse a stake in the recovery from it, funded out of the pool meant for the holders they harmed. We are not doing that.

7.2 Mechanics

  • Conversion ratio: 5 GFT → 1 GFTW (locked). Eligible legacy holdings map into the 130,000,000 GFTW migration pool (= 13% of the 1B total).
  • The ratio was improved in holders' favour. Earlier drafts of this document published 20:1. We revised it to 5:1, quadrupling what every eligible holder receives, and funded it by reducing the Creator Reserve from 50% to 42% rather than by minting anything. We are stating the change plainly rather than quietly restating the number, because a ratio that moves without explanation is exactly the kind of thing this project exists to stop doing.
  • Snapshot: rebuilt from the public chain record, and independently reproducible. Eligibility is fixed at BSC block 44,384,350 — the last block before the first of the November 2024 mint transactions — so the 1.2B tokens minted during the collapse confer no claim. The snapshot was produced by replaying every GFT transfer event from the token's creation block, and the full dataset, the script that generates it, and the supply-integrity check are published so that anyone can reproduce it independently rather than take our word for it.
  • Exclusions. Wallets belonging to the prior operators are excluded — including the address that received the original deployment mint. Balances held on exchange, bridge, and liquidity-pool addresses are custodial: crediting them would send holders' GFTW to the custodian rather than to the holder, so they are handled by published manual review, not blanket crediting. The exclusion list is published with the snapshot bundle.
  • Registration is required. Migration is not automatic. Eligible holders must actively register a receipt wallet during the registration window, proving control of the wallet that held their GFT. This is what lets self-custodial holders receive GFTW at an address they control today, rather than one they may no longer have keys for.
  • The registration window is 30 days and cannot be extended. Both the opening and closing timestamps are written into the MigrationRegistry contract at deployment as immutable values, and the contract has no owner and no administrative function. No party — the team, the treasury signers, or anyone else — is able to extend, reopen, or grant an exception to this deadline. This is deliberate: a deadline that can be moved is a deadline that can be moved against holders. The trade-off is equally deliberate and holders should understand it plainly — missing the window is unrecoverable, and the value returns to treasury.
  • Claim flow: after registration closes, the claim tree is built over registered receipt wallets and published. Registered holders then claim GFTW in-wallet during the claim window.
  • ⚠️ Unregistered value returns to treasury. Holders who do not register during the registration window do not receive GFTW. Unclaimed GFTW after the claim window closes likewise returns to treasury (claim rates are never 100%). Both windows and their deadlines are published in the project roadmap and announced across every official channel, with repeated reminders before each closes.

7.3 Anti-Dump Fee (no lockup)

Migrated tokens are fully liquid at claim — there is no migration lockup. Holders who were burned before are not frozen again. Instead, early dumping is discouraged by a tapering early-sell fee that decays to zero:

Period after claim Early-sell fee
0–7 days 10%
8–30 days 5%
31–60 days 2%
60+ days 0%
  • Where the fee goes: fees collected by the platform are directed ~50% to the liquidity pool / ~50% to stakers — LP for depth and price stability, stakers as a loyalty reward.
  • Scope — stated plainly. The fee applies to sales made inside the GiftoV3 platform during the early window. It is a platform policy, not a property of the token.

    The GFTW token contract contains no fee logic and no transfer restrictions. There is no launch lock, no tax on transfers, and no mechanism that can prevent you moving your own tokens. You can withdraw GFTW to a wallet you control at any time, and a sale made outside the platform is not subject to this fee.

    We could have enforced the fee at the token level. We chose not to, for two reasons. A token that can tax or block transfers is a token whose operators hold a lever over your funds, and this community has already seen what happens when operators hold levers. It also breaks the self-custody commitment in §5.2, which we are not willing to qualify. We would rather have a weaker fee and a token that cannot be used against you. - Disclosure: documented here and shown at the point of sale (the sell/withdraw confirmation) plus Terms — not surfaced on marketing pages. A fee not shown when it is charged is a hidden fee; we disclose at point of sale. - Temporary by design: the fee tapers to 0 — it is not a permanent tax.

7.4 Transparency

GiftoV3 will publish a public ledger of burned (GFT) vs. issued (GFTW) so the migration can be independently verified on-chain (BscScan).

Migration eligibility is verifiable end to end. We publish the snapshot dataset, the script that rebuilds it from public chain logs, the cutoff block, the exclusion list with reasons, and the Merkle root of the claim tree. Anyone can re-run the rebuild against BSC and confirm they get the same result, then verify their own claim against the published root. Eligibility does not depend on trusting a list we assert; it depends on a computation you can repeat yourself.

Scope note: the rebuilt snapshot covers GFT on BNB Smart Chain. Holders of the original Ethereum-era token who never migrated to BSC GFT are not captured by it; how that group is treated is addressed with the migration launch.


8. GFTPay

8.1 What it is

GFTPay is GiftoV3's payments layer: a way to turn held balances into real-world spending through virtual and physical cards, tap-to-pay, and local-currency conversion at the point of purchase.

Status: rolling out — GFTPay is not yet live.

It is described here as a roadmap product. Utility that depends on GFTPay is intentionally phased (§9.2) and is not marketed as available until it ships.

8.2 How it Works (intended design)

  1. A user funds their GiftoV3 balance (migration, swap, or on-ramp).
  2. GFTPay issues a virtual/physical card linked to that balance.
  3. At checkout, the spend is converted to local currency and settled.
  4. Fees and conversion terms are disclosed at the point of spend; the full schedule is published when GFTPay launches.

8.3 Rollout & Honesty

Card issuance, settlement, and conversion rails depend on third-party providers and regulatory clearance per market. GFTPay will be launched market by market, clearly labeled live vs. coming, and only marketed where it is actually available.


9. Token Economics (GFTW)

9.1 Token Properties

  • Name / symbol: Giftworld / GFTW
  • Total supply: 1,000,000,000 GFTW — fixed cap (no inflation, no minting beyond the cap)
  • Decimals: 18
  • Standard / chain: BEP-20 on BNB Smart Chain (BSC)
  • Role: migration target, staking asset, governance unit, and (as features ship) GFTPay medium of exchange and fee token

What the contract can and cannot do — verify this yourself.

The GFTW token contract is deliberately minimal. The entire supply is created once, in the constructor, and the contract holds no powers over it afterwards:

Capability Present?
Mint new tokens No — no mint function exists in the deployed bytecode
Owner, admin, or privileged role No — the contract is ownerless
Pause, freeze, or blacklist No
Fee or tax on transfers No
Transfer restrictions or launch lock No
Upgradeable / proxy No — immutable once deployed

This is the direct structural answer to November 2024. The mint function that doubled GFT's supply is not disabled or owner-gated here; it does not exist. Neither does any address with authority to alter balances or block transfers.

None of this asks for trust. The source is verified on BscScan and the supporting contracts (migration, staking, vesting) are equally ownerless. Read them, or have someone read them for you, before you migrate.

9.2 Core Uses of GFTW (phased)

Utility is usage-driven and phased so that day-one value rests on real, available functions — not unshipped promises.

  • Phase 0 — at launch: migration target (GFT → GFTW); staking (rewards + reduced sell pressure); light governance; in-wallet hold / transfer / swap.
  • Phase 1 — GFTPay live: medium of exchange for spend/payments; fee token & fee discounts.
  • Phase 2 — creator tools live: in-stream tipping settled in GFTW; access to creator features; creator allocations distributed from the Creator Reserve (§9.3) as the creator economy grows.

Each utility is marketed only once it ships. This phasing also strengthens the utility-vs-security position; counsel has reviewed and treats GFTW as a utility token in target markets (§13).

9.3 Token Allocation

Locked principles, explicitly correcting V1 (which placed ~40% with insiders):

  • supply weighted to creators + community + returning holders, not insiders
  • a large Creator Reserve (42%) distributed to creators over time — from a fixed pool, never minted
  • insiders held to just 5%, with cliffs + linear vesting, unlocking last
  • multisig treasury — controlled, but not solely by founders
  • public sale comes later, tied to a future exchange listing/re-listing
Bucket % GFTW Notes
Creator Reserve 42% 420,000,000 distributed to creators as the ecosystem grows; metered, from a fixed pool (no minting)
Community & ecosystem rewards 18% 180,000,000 airdrops, staking, referrals; funds the staking contract's fixed 180M emission schedule (§9.6)
Migration (legacy GFT → GFTW @ 5:1) 13% 130,000,000 pool for eligible, registered legacy holders (§7); unregistered and unclaimed value returns to treasury
Treasury (multisig) 12% 120,000,000 ops, dev, runway
Insiders (team + investors + advisors) 5% 50,000,000 team ~3% / investors+advisors ~2%; vest last
Public sale (later, at listing) 5% 50,000,000 sold at a future listing
Liquidity 5% 50,000,000 DEX/CEX, locked LP
Total 100% 1,000,000,000

9.4 Vesting & Lockups

  • Creator Reserve (42%): released gradually over a multi-year horizon, gated to creator-tool launch and real adoption (governance-overseen). Minimal at TGE; it is the long-term distribution engine, not an upfront unlock.
  • Migration (13%): no lockup — fully liquid at claim. Anti-dump handled by fee (§7.3), not a lock. This is now the largest unlocked bucket at TGE and the main driver of opening float (§9.6).
  • Community / rewards (18%): emitted as earned over ~36 months (§9.6).
  • Treasury (12%): linear / governance-gated over ~36 months.
  • Team (~3%): 12-month cliff → linear over 24 months.
  • Investors / advisors (~2%): 6-month cliff → linear over 18 months.
  • Public sale (5%): terms set at listing (e.g., partial unlock + linear).
  • Liquidity (5%): unlocked at listing; LP locked.

Insiders deliberately vest last — team tokens are not fully unlocked until month 36, and insiders are only 5% of supply.

9.5 Anti-Dump Fee

See §7.3 for the full schedule and scope. In tokenomics terms: the fee is a temporary, tapering, transparent fee on in-platform sales of migrated tokens, decaying to 0% after 60 days, with collected fees directed to the liquidity pool and stakers. It transfers value from early in-platform sellers to long-term holders and to pool depth — without minting new tokens and without locking anyone's balance.

This is a platform revenue policy, not a protocol mechanism. It is applied by the GiftoV3 platform to sales made inside it, and the resulting allocation to LP and stakers is a commitment we make and report on, not a flow enforced by the token contract. The token contract has no fee logic in it at all (§7.3). Because the fee does not reach sales made outside the platform, the revenue it generates is smaller than a token-level tax would produce, and we plan accordingly rather than overstating it.

9.6 Emissions & Release Schedule

Emissions / inflation: none. Fixed cap of 1,000,000,000 GFTW; no minting. (V1 ran ~2%/yr inflation — removed.) Every token, including creator rewards, is distributed from a fixed, pre-minted pool. The cap is never exceeded.

Creator Reserve (42% / 420M). The Creator Reserve is the project's long-term distribution engine: as creator tools ship (Phase 2) and creators onboard and earn, GFTW is released to them from this fixed pool, metered and governance-overseen. It is adoption-gated — it does not unlock on a fixed calendar, and it cannot create new supply. What looks like "minting" to a creator receiving tokens is distribution from the reserve, within the 1B cap.

Staking-reward emission curve (the 180M community bucket, decaying):

Period Monthly Period total Cumulative
Year 1 7.5M/mo 90M 90M
Year 2 4.5M/mo 54M 144M
Year 3 3.0M/mo 36M 180M
Year 4+ 0 — bucket exhausted 180M

After Year 3 the community bucket is spent and on-chain staking emissions end. The staking contract's reward schedule is hardcoded and finite: it pays out exactly 180M GFTW across 36 months and then stops. Nothing continues automatically after that, by design — the alternative would be a contract that can keep issuing rewards, and no such mechanism exists.

Any continuation of staking rewards beyond month 36 would be funded by the platform from the staker share of collected fees (§9.5), as a policy decision at that time. We are stating that as an intention, not a guarantee: it depends on platform fee revenue that does not yet exist, and we would rather set that expectation honestly now than have it read as a protocol commitment it is not.

Circulating supply over time (illustrative, % of 1B). Token counts only; at the $0.20 launch price they convert to USD as noted below. Migration-claim pace and creator-adoption pace are assumptions.

Milestone Approx. circulating Drivers
TGE (Month 0) ~15% (~150M) migration claims (13%) + seeded liquidity
Year 1 ~26% community emissions, migration complete, early treasury/investor unlocks, creator pilot
Year 2 ~38% more community + staking, insiders vesting, Creator Reserve ramping
Year 3 ~50% community bucket done, insiders fully vested, Creator Reserve scaling
Year 4+ (long run) toward ~100% the Creator Reserve distributes over the long term, gated to adoption

Takeaways: opening float is ~15% of 1B, the great majority of it migrated tokens held by returning holders; insiders are tiny (5%) and vest last; the Creator Reserve (42%) is a slow, adoption-gated long tail, not an upfront unlock. The cap is fixed and nothing is ever minted beyond it. At the launch price of $0.20/GFTW: FDV = $200,000,000, and initial market cap ≈ $30,000,000 (~150M TGE float).

Stated plainly, because it is the number most likely to be misread. Moving the migration ratio to 5:1 tripled the migration pool, and migration carries no lockup, so roughly 13% of total supply becomes freely transferable as soon as claiming opens. Opening float is therefore about double what earlier drafts described, and most of it sits with holders who have been waiting since 2024.

The price and the fully diluted valuation did not change: $0.20 and $200M, exactly as first published. Initial market cap rose from ~$14M to ~$30M for one reason only — more tokens are in holders' hands at launch, at the same price each. We improved the ratio and left the price alone.

The $0.20 figure is the price at which liquidity is seeded. It is not a forecast, not a floor, and not a promise. Where GFTW actually trades will be decided by the market, and it may trade below it.


10. Governance

Governance covers protocol/fee parameters (including the anti-dump split), treasury policy, staking & rewards policy, ecosystem grants, and migration/listing milestones. GFTW carries light governance from Phase 0, expanding as the ecosystem matures. The treasury is multisig — signers are not solely the original founders. Because the GiftoV3 platform operates within regulatory constraints, the operating entity may decline or delay governance outcomes that would be illegal or harmful to the ecosystem as a whole — stated openly rather than implied. Mechanism, thresholds, and voting weight are published as governance rolls out (see roadmap).


11. Security & Compliance

GiftoV3 treats security and compliance as product, not paperwork:

Current build state. All five contracts — token, migration registry, migration claim, staking and vesting — are written and tested, with an automated test suite passing and full coverage on the critical paths. Nothing is deployed to any public network yet. Every one of them is ownerless and immutable by design, with no admin key, no upgrade path, and no mint function. Deployment and audit sequencing are set out below, and timing is in the project roadmap.

  • Independent audits — smart-contract (token, migration, staking, vesting) and platform security. Reports published in full when complete, findings included (coming soon).

    Sequencing, stated openly: the contracts are deployed and verified on BscScan before the external audit begins, so that the auditor reviews the exact bytecode that is live rather than a candidate version. The deployed commit is tagged and the auditor verifies the on-chain bytecode against it.

    Because these contracts are immutable and ownerless, there is no patch path — so deployment alone is deliberately made harmless: the token pools stay unfunded and the registration and claim windows stay closed until the audit is in and all critical and high findings are cleared. An unfunded contract with no open windows holds nothing and can do nothing. Funding is the real point of no return, and it does not happen until the audit clears. If the audit finds something serious, the remedy is to redeploy before funding, at no cost to holders. - Non-custodial by design — GiftoV3 holds no user funds, so there are no user balances to misappropriate. Project treasury/reserve holdings are attested on-chain (BscScan); attestation links are published at launch. - KYC / AML program and jurisdictional coverage. - Staged rollouts with caps/limits on new modules (e.g., GFTPay markets). - Monitoring & incident response playbooks. - Transparency reporting — migration ledger, treasury reporting, governance reporting. - Seed-phrase policy — GiftoV3 never requests seed or recovery phrases.


12. Roadmap

Phased and dependency-ordered. Timing is published in the project roadmap; items are objectives, not commitments.

  • Phase 1 — Relaunch & Migration: wallet live · contracts deployed and verified · registration window opens, then closes · claim tree published · GFT → GFTW claims open · liquidity seeded · staking + light governance live.
  • Phase 2 — Trust & Transparency: independent audit published in full · treasury attestation · public migration ledger published.
  • Phase 3 — GFTPay Rollout: card/payments launched market by market, clearly labeled per region.
  • Phase 4 — Creator Tools: streaming SDK with in-stream tipping · stablecoin creator payouts · token gifting.
  • Phase 5 — Listing & Expansion: public sale + exchange listing on target venues (subject to each exchange's approval; timing TBD): Binance, KuCoin, MEXC, Gate.io · broader governance.

Accountability model. GiftoV3 grounds accountability in structure rather than personalities. The prior collapse was enabled by concentrated, unaccountable control; GiftoV3 answers that not by asking holders to trust named individuals, but by making misconduct structurally hard and externally verifiable — don't trust, verify. Accountability rests on three pillars:

  • a registered legal entity that operates GiftoV3 and bears legal responsibility;
  • a multisig treasury that prevents any single party from acting unilaterally;
  • independent audits, on-chain treasury attestations, and transparency reporting (§11) that let anyone verify claims without trusting a person; and a non-custodial design, so GiftoV3 never holds user funds in the first place.

Individual team identities are not published at launch. (A named, credentialed team is a stronger signal and may be disclosed as the project matures; entity-level accountability is the baseline commitment.)

Legal entity. GiftoV3 is operated by GIFT FOUNDATION.

GFTW classification. Counsel has reviewed GFTW and treats it as a utility token in target markets. Classification can still vary by jurisdiction and remains subject to regulation; see the risk factors (§14).

Treasury. The treasury is held in a multisig wallet, configured as 2-of-3: three signers, any two of whom must approve a transaction.

No single party holds more than one key. That is the part that matters. It means no individual can move treasury funds alone, and every transaction requires two independent parties to agree. A multisig where one party quietly holds the majority of keys is a single signer wearing a costume; this one is not that, and the published signer set will let you check.

The full signer set, the independence of each signer, and the treasury address are published before anything is funded, together with reserve attestations and a reporting cadence. Treasury addresses appear in §15.

The multisig address is already established and can be independently verified against its published construction parameters once deployed. Its owners and threshold can be changed later through the Safe itself, and any such change is announced.

The honest v1/v2 post-mortem lives in §2, where a relaunch's history belongs.


14. Risks & Disclaimers

Note

These risk factors are not exhaustive and may be supplemented per jurisdiction. Nothing here is legal, financial, or investment advice.

Holding, acquiring, or using GFTW and GiftoV3 involves significant risk. Prospective and existing holders should weigh at least the following.

  • Market & price risk. GFTW's price may be volatile and may fall to zero. Past performance of GFT or any asset does not indicate future results. Nothing here promises value, return, or liquidity.
  • Regulatory & classification risk. The legal treatment of GFTW (utility vs. security) and of GiftoV3's services varies by jurisdiction and may change. Regulation, licensing, or enforcement could restrict, suspend, or end features, migration, or the token in some or all markets.
  • Self-custody risk. Users hold their own keys. If you lose your key or recovery phrase, your funds are permanently inaccessible and GiftoV3 cannot recover them. You are solely responsible for securing your keys and verifying transactions; transactions you authorize may be irreversible.
  • Migration risk — action is required on your part, within a deadline nobody can extend. Migration is not automatic. It depends on a snapshot, eligibility rules, a 30-day registration window, and a claim window. If you do not register a receipt wallet before the registration window closes, you do not receive GFTW, and that value returns to treasury. Because the window is immutable and the contract is ownerless, there is no appeal, no exception process, and no second round — not on grounds of illness, connectivity, travel, lost access, or not having heard about it in time. The same applies if you register but do not claim before the claim window closes. Eligibility disputes, exclusions (§7.2), loss of access to the wallet that held your GFT, and technical failures may also cause loss of the claim right. Deadlines are published and reminded, but the responsibility to act within them is yours.
  • Snapshot and exclusion risk. Eligibility is fixed at a published cutoff block and excludes prior-operator wallets; balances held on exchange, bridge, or liquidity-pool addresses are custodial and are handled by manual review rather than automatic crediting. If your GFT was held on an exchange at the cutoff, your eligibility depends on that review and is not guaranteed. The snapshot covers BSC GFT only.
  • Anti-dump fee. A temporary, tapering early-sell fee applies to in-platform sales of migrated tokens (§7.3). It is disclosed at the point of sale, but it reduces proceeds for holders who sell early inside the platform. Note that this is a platform policy rather than a token property: it does not apply to sales made elsewhere, and the revenue it generates — and therefore the LP and staker allocations funded from it (§9.5) — is correspondingly smaller and not guaranteed.
  • GFTPay & third-party risk. GFTPay is not live and depends on third-party processors, card networks, banking partners, and per-market regulatory clearance. It may launch late, in limited markets, or not at all; integrations may change or be withdrawn.
  • Smart-contract & technical risk. Token, migration, and related contracts may contain vulnerabilities despite audits. Infrastructure and dependencies may fail or be exploited.
  • Liquidity & listing risk. There is no guarantee of exchange listing or re-listing. Liquidity may be thin; large transactions may move the price; a public sale or listing may be delayed or may not occur.
  • Legacy-association & reputational risk. GiftoV3 builds on a brand with a troubled history (§2). Negative association, ongoing disputes, or actions by parties connected to prior versions could affect GiftoV3 regardless of its independence.
  • Execution risk. Roadmap items (§12) are objectives, not commitments, and may not ship as described or on any timeline.
  • Tax risk. Migration, swaps, staking rewards, and spending may carry tax consequences that vary by jurisdiction. Holders are responsible for their own tax compliance.
  • No advice; your responsibility. Nothing here is financial, investment, legal, or tax advice. Do your own research, consult professionals, and do not transact with funds you cannot afford to lose.

Additional jurisdiction-specific terms are set out in the Terms of Service.


15. References & Appendix

Addresses and links below are published as the relaunch deploys — marked coming soon until live.

On-chain

  • GFTW token contract: coming soon (published at deployment on BscScan)
  • Migration registry + claim contracts: coming soon (published at deployment on BscScan)
  • Staking + vesting contracts: coming soon (published at deployment on BscScan)
  • Treasury (multisig) address(es), signers and threshold: coming soon (published before launch)
  • Migration snapshot bundle — dataset, rebuild script, cutoff block, exclusion list, Merkle root: coming soon (published so eligibility can be independently reproduced, §7.4)
  • Public migration ledger (burned GFT vs. issued GFTW): coming soon (on-chain, BscScan)

Audits & reserves

  • Smart-contract audit report(s): coming soon
  • Proof-of-reserves / treasury attestation: coming soon

Official channelsbeware impersonators: only links published here and on the official site are genuine.


GiftoV3 — Bring your value forward. Spend it anywhere.