# $FULBO Tokenomics ### Overview The $FULBO token is the core currency of the Fulbo ecosystem. Its design is focused on: * Utility-driven demand * Controlled supply * Long-term sustainability The system operates as a **closed-loop economy**, where tokens are: * Used through gameplay * Redistributed through rewards * Partially removed from circulation *** ### Total Supply * Total Supply: **1,000,000,000 $FULBO** *** ### Token Allocation | Category | Allocation | | -------------------- | ---------- | | 🚀 Pre-sale | 30% | | 🎮 Ecosystem Rewards | 20% | | 📢 Marketing | 20% | | 🔧 Development | 5% | | 👥 Team | 15% | | 🌊 Liquidity (Total) | 10% | *** ### Token Utility The $FULBO token is used for: * Competition entry * Marketplace transactions * Buying players and scouts *** ### Token Flow Players earn tokens\ ↓\ Spend tokens on assets and entries\ ↓\ Compete again\ ↓\ Repeat *** ## Pre-Sale Phase ### Overview The pre-sale is a **stage-based token sale** where users purchase $FULBO using SOL. * Tokens are allocated instantly * Locked until TGE * Subject to stage-based vesting *** ### Payment * Currency: **SOL** * Conversion: **SOL → USD via oracle** * All stage targets are defined in USD *** ### Stage System Each stage includes: * Funding target * Token price * Allocation * Vesting conditions Stages progress automatically once targets are reached. *** ### Vesting (Pre-Sale) * Vesting begins at **TGE** * Unlock depends on stage * Remaining tokens unlock at **5% every 30 days** #### Stage-Based Vesting * **Stages 1–4** * 50% unlocked at TGE * 50% unlocked linearly at **5% every 30 days** * **Stages 5–8** * 65% unlocked at TGE * 35% unlocked linearly at **5% every 30 days** * **Stages 9–11** * 80% unlocked at TGE * 20% unlocked linearly at **5% every 30 days** *** ### Launch Conditions TGE occurs when: * All stages are completed, or * A launch date is defined with **30-day notice** At TGE: * Pre-sale closes * Liquidity is deployed * Vesting begins *** ### Unsold Tokens Unsold tokens are not left idle: * **60% → Burned 🔥** * **40% → Reallocated to Rewards Pool** *** ## Pre-Sale Funds (SOL Treasury) ### Overview All pre-sale funds are stored in a **smart contract treasury**. Funds are distributed periodically using a transparent and predefined system. *** ### Distribution Logic * Funds are accumulated over time * Allocations are executed **every 30 days.**\ Only predefined public wallets can claim funds *** ### Treasury Wallets #### Team Wallet * Receives allocated funds * Fully transparent * Distributed **every 30 days.** *** #### Marketing Wallet * Public wallet * All transactions visible * Distributed **every 30 days.** *** #### Development Wallet * Public wallet * Used for product development * Distributed **every 90 days.** *** #### Liquidity Pool Wallet * Used for DEX liquidity provisioning * Deployed **at the end of the pre-sale.** *** ### Fund Allocation (SOL) * 20% → Team * 25% → Marketing * 35% → Development * 20% → Liquidity *** ## Liquidity Strategy ### Initial Liquidity (TGE) * \~1% of total token supply * \~20% of raised funds * Used to create the initial DEX liquidity pool *** ### Reserved Liquidity (9%) Allocated for: * Liquidity expansion * Market stabilization * CEX listings *** ## Token Vesting Structure ### Marketing (20%) * **20% unlocked at TGE** * Remaining tokens unlock at **5% every 30 days** *** ### Development (5%) + Team (15%) * **5% unlocked at TGE** * Remaining tokens unlock at **5% every 30 days** * Team tokens follow stricter internal controls *** ### Liquidity (10%) * 1% deployed at TGE * 9% reserved for future use *** ## Reward System (Token Pool) ### Allocation Sources The rewards pool is funded by: * 20% initial token allocation * 40% of unallocated tokens * 1% marketplace fees * 80% competition entry fees *** ### Structure * 50% → Weekly League * 50% → Weekend Cup *** ### Distribution Model Rewards are: * Activity-based * Dynamically adjusted * Not fixed or inflationary *** ## Post Pre-Sale Token Lifecycle ### In-Game Token Flows #### Competition Entry Fees * 80% → Rewards Pool * 40% Weekly * 40% Weekend * 20% → Team * Subject to **50% vesting, and then 5% every 30 days.** *** #### Marketplace Fees (5%) * 1% → Burn 🔥 * 1% → Rewards Pool * 3% → Team * Subject to **50% vesting, and then 5% every 30 days.** *** ### Token Sinks The system removes tokens through: * Marketplace burn * Player and scout expiration * Controlled supply mechanisms *** ### Asset Model (Important) * Players and scouts have **fixed attributes** * They **do not improve or degrade** * They have a **limited lifespan** This creates: * Continuous demand * Constant market turnover * No inflation through upgrades *** ### Unallocated Tokens Applies to: * Pre-sale leftovers * Unused marketing allocation * Unused team/development tokens #### Distribution * 60% → Burn 🔥 * 40% → Rewards Pool *** ### Economic Loop Players earn tokens\ ↓\ Spend tokens on gameplay and assets\ ↓\ Tokens are redistributed, partially burned\ ↓\ New activity is generated *** ## Sustainability Model The system avoids: * Passive emissions * Fixed reward schedules * Infinite inflation Instead, it relies on: * Activity-driven demand * Controlled supply * Continuous asset turnover *** ## Core Principles * No unused tokens remain idle * No arbitrary token releases * Full transparency across funds and flows * All value is driven by activity *** ## Final Vision $FULBO operates as a system where: * Gameplay drives demand * Assets circulate continuously * Tokens are reused or removed * Supply remains controlled Creating a sustainable, long-term ecosystem. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://fulbo.gitbook.io/fulbo-docs/usdfulbo-tokenomics.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.