Official technical and economic project document
LIGONE (LIG1)
Whitepaper - Base V2
LIG1 is the digital asset at the center of the LIGONE ecosystem. The current system is deployed on Base and combines a capped supply, wallet concentration limits, time-based sell fees, system liquidity, optional private liquidity and controlled reward minting. This document describes what the system is intended to achieve, how the currently reviewed LIG1Core works, which parts belong to connected modules, and which risks remain.
Contents
01
Abstract
LIGONE is an ecosystem project built around the idea that digital systems should be understandable, transparent and usable by ordinary people. LIG1 is its blockchain-based digital asset. The current LIG1 deployment runs on Base and uses USDC as the principal counter-asset for the initial market.
The token design does not attempt to guarantee price stability. Instead, it introduces explicit on-chain rules intended to limit wallet concentration, distinguish short-term selling from longer holding, route token fees into a dedicated liquidity architecture, and constrain how future LIG1 can be created through rewards.
LIG1 is intended to develop alongside a wider LIGONE ecosystem of community functions, information, regional services, participation mechanisms and future applications. The economic value of LIG1 ultimately depends on real demand, real liquidity and real use; none of these can be guaranteed by code alone.
02
Purpose and Design Principles
Transparency
Rules should be inspectable in deployed code and observable on-chain wherever technically possible.
Distributed participation
The system aims to limit excessive concentration and create room for many smaller participants.
Understandability
Technical rules are accompanied by plain-language explanations instead of requiring blind trust.
Utility before hype
LIGONE seeks to build applications and services around LIG1 rather than presenting price appreciation as the product.
03
Token Overview
| Property | Current LIG1 |
|---|---|
| Name | LIGONE |
| Symbol | LIG1 |
| Network | Base |
| Decimals | 18 |
| Maximum supply | 1,000,000,000 LIG1 |
| Initial system liquidity allocation | 20,000,000 LIG1 |
| Maximum reward-mintable amount | 980,000,000 LIG1 |
| Normal-wallet maximum | 2,000,000 LIG1 (0.2% of max supply) |
| Primary counter-asset | USDC on Base |
LIG1Core
USDC used by LIG1Core
The contract address is the authoritative identifier of the current Base token. Older Polygon-era LIG1 contracts and their historical balances, liquidity and security classifications must not be treated as properties of this deployment.
04
System Architecture
The current design separates responsibilities instead of placing every function inside one contract. The reviewed LIG1Core contains the token transfer logic and references dedicated modules for liquidity and rewards.
LIG1Core
ERC-20 token core, MaxWallet checks, pool-aware transfer routing, FIFO tranches, fee calculation and reward execution checks.
LiquidityVault
Referenced by LIG1Core as the recipient/processor for LIG1 fees and as an authorized system-liquidity actor.
RewardController
Referenced by LIG1Core to confirm approved rewards and mark an approved reward as executed.
Private LP Manager / System LP Vault
Separate roles used by the core for private-liquidity deposit/withdrawal flows and custody of initial system LP tokens.
LIG1Core is constructed with immutable references to the liquidity vault, reward controller, initializer and USDC. The reviewed source also contains one-time initialization functions for the Private LP Manager, System LP Vault and the initial LIG1/USDC pool.
Ownable
pattern, but it does contain an initializer role for one-time setup. For that reason this whitepaper documents the actual
initialization paths rather than relying on a broad marketing phrase such as "no administrative logic".
05
Supply Model
The maximum token supply is fixed in LIG1Core at 1,000,000,000 LIG1. The initial system liquidity allocation is 20,000,000 LIG1. The remaining 980,000,000 LIG1 represents the maximum amount that can be created through the reward path defined by the core.
Absolute maximum LIG1 supply
Initial system-LP allocation
Maximum reward-mintable remainder
Max supply is not the same as circulating supply. Tokens that have not yet been minted do not exist in wallets or in the market. For market-cap calculations, current supply and market price must therefore be distinguished from fully diluted valuation (FDV).
06
MaxWallet - Concentration Limit
The reviewed LIG1Core sets MAX_WALLET = 2,000,000 LIG1, equal to 0.2% of the maximum supply. Incoming transfers to normal wallets are checked against this ceiling.
The core exempts specific system addresses and registered pools from the normal-wallet check. This is necessary because liquidity pools and system modules must be able to hold balances larger than an ordinary user wallet.
07
Fee Model
| Transaction | Core rule | Purpose / effect |
|---|---|---|
| Buy from active pool | 0.1% | Low fixed buy fee; fee is routed into the configured liquidity architecture. |
| Sell before 100 days | 1.0% | Higher fee applies to the portion of sold LIG1 whose FIFO tranche is younger than 100 days. |
| Sell after 100 days | 0.1% | Lower fee applies to the portion of sold LIG1 whose tranche has reached the holding period. |
| Ordinary wallet transfer | No buy/sell fee | The recipient receives a new tranche timestamp under the reviewed transfer logic. |
Fees are denominated in LIG1. A fee collected in LIG1 does not itself create USDC. This distinction is fundamental: token fees and the counter-asset side of liquidity are economically different resources.
08
100-Day Tranche Model
The 100-day rule is implemented per tranche, not as one timer for the whole wallet. LIG1Core stores an amount and a timestamp for token tranches and consumes them using FIFO (first in, first out) when a sale is processed.
When calculating the sell fee, each portion of the sale is tested against its tranche timestamp:
- younger than 100 days: the 1% sell fee applies to that portion;
- 100 days or older: the 0.1% sell fee applies to that portion.
This means a wallet may simultaneously contain older and younger LIG1 subject to different sell-fee rates.
09
Transfer Engine
LIG1Core distinguishes transfers involving registered active pools from ordinary wallet-to-wallet transfers and from special liquidity-module flows.
Buy
A transfer from an active pool to a normal wallet is treated as a buy and is subject to the buy rule and MaxWallet checks.
Sell
A transfer from a normal wallet to an active pool is treated as a sell. The FIFO tranche model is used to calculate the applicable fee.
Wallet transfer
For an ordinary wallet-to-wallet transfer, the reviewed code consumes the sender's FIFO tranches and appends a new tranche for the recipient using the current block timestamp. In practical terms, the recipient's transferred LIG1 begins a new holding period under this logic.
LP-specific paths
The core includes explicit temporary states for Private LP deposits, Private LP withdrawals and System LP deposits so those module-driven transfers can be distinguished from ordinary market buys/sells.
10
Liquidity Model
The initial market is designed around a LIG1/USDC liquidity pool on Base. A liquidity pool contains both sides of the market. Buyers add USDC and remove LIG1; sellers add LIG1 and remove USDC.
Because price is formed by the relationship between reserves, liquidity depth matters. A small pool can move significantly after relatively small swaps; a deeper pool normally requires more volume for the same percentage price move.
Liquidity is not demand
Adding liquidity can deepen a market, but it does not create buyers or guarantee price appreciation.
Fees are not USDC creation
LIG1 fees can support system liquidity processes, but a LIG1-denominated fee does not mint or manufacture USDC.
11
System LP
During initial pool setup, LIG1Core mints the initial 20,000,000 LIG1 directly into the verified LIG1/USDC pair, transfers the supplied USDC amount into that pair, and mints the resulting LP tokens to the configured System LP Vault.
The core also allows the LiquidityVault to enter a dedicated system-LP deposit state. This lets system-liquidity transfers be handled separately from normal market sells.
12
Private LP
Private LP is intended to allow users to provide their own LIG1 plus the corresponding counter-asset amount as liquidity.
LIG1Core includes a dedicated privateLPManager role and deposit/withdrawal states for this purpose.
The core also maintains hasPurchasedLIG1, allowing connected liquidity logic to distinguish wallets that have
previously purchased LIG1 from wallets that only received tokens by transfer.
A private liquidity position is not the same as simply holding LIG1. The composition of an LP position can change as traders interact with the pool, and liquidity providers are exposed to price divergence and impermanent-loss risk.
13
Reward Minting
Future LIG1 supply can be created through the reward execution path. In the reviewed LIG1Core, an approved reward is read from the external RewardController, and the receiving wallet must execute the reward itself.
The core currently enforces several reward constraints:
- total reward minting cannot exceed 980,000,000 LIG1;
- total supply cannot exceed 1,000,000,000 LIG1;
- a wallet cannot exceed the core's reward-per-wallet cap;
- the wallet must remain within MaxWallet after the reward;
- the reward must be approved and not previously executed;
- the core contains time-window limits for reward frequency and aggregate reward issuance.
A newly minted reward creates LIG1, not USDC. If a recipient later sells rewarded LIG1 into the LIG1/USDC pool, that sale removes USDC from the pool and adds LIG1, just like any other market sale.
14
Market Mechanics, Market Cap and FDV
LIG1 has no contract-level mechanism that guarantees a particular market price. Price is formed through trading and liquidity conditions.
| Metric | Meaning |
|---|---|
| Token price | The current market price at which LIG1 is exchanged against its counter-asset. |
| Current supply | The amount of LIG1 that has actually been minted at that time. |
| Market capitalization | Current price multiplied by current supply. This is a market metric, not cash held by the project. |
| FDV | Current price multiplied by the maximum supply of 1,000,000,000 LIG1. |
| Liquidity | The assets available in the pool for swaps. Liquidity is not the same as market cap. |
LIGONE's public Market-Cap Challenge is intended as a transparent measurement exercise: it documents how the actual market develops without presenting milestones as forecasts or guaranteed targets.
15
The LIGONE Ecosystem
LIG1 is intended to connect a broader LIGONE ecosystem rather than remain only a tradable token. Current and developing concepts include educational content, user accounts, community participation, regional marketplace functions, sharing and invitation tools, rewards, service-provider participation and additional utility-oriented web applications.
Understand
Plain-language education and transparent explanations of rules, liquidity and risk.
Participate
Community contributions, missions, invitations and other forms of involvement as these features become available.
Use
Long-term value depends on whether LIG1 becomes useful within real services and applications.
Planned functionality is not represented as already available. LIGONE intends to distinguish clearly between live features, features under construction and longer-term ideas.
16
Security, Verification and External Review
A project's own description is not a security proof. Technical confidence should come from verifiable source code, deployed bytecode, contract addresses, concrete tests, on-chain behavior and independent review.
What has been reviewed for this document
The current LIG1Core source used for this revision contains the constants and mechanisms described above, including max supply, initial system liquidity, reward-supply ceiling, MaxWallet, buy/sell fees, the 100-day FIFO tranche model, reward execution checks and module-specific LP transfer states.
What this document does not claim
- It does not claim that an independent third-party audit has already proven the complete system safe.
- It does not claim that connected module contracts are risk-free merely because LIG1Core references them.
- It does not claim that warnings from external security providers are automatically incorrect.
- It does not claim that smart contracts can guarantee price, liquidity or adoption.
17
Technical Verification Status
| Item | Status in this whitepaper | Basis |
|---|---|---|
| Base network / LIG1Core address | Verified reference | Current deployed Base LIG1Core address. |
| Max supply, initial system LP, reward cap | Verified in reviewed LIG1Core source | Core constants. |
| MaxWallet | Verified in reviewed LIG1Core source | 2,000,000 LIG1 normal-wallet limit. |
| Buy and sell fee constants | Verified in reviewed LIG1Core source | 0.1% buy; 1% / 0.1% sell. |
| 100-day FIFO tranche model | Verified in reviewed LIG1Core source | HOLD_PERIOD plus tranche calculation/consumption logic. |
| Reward execution controls | Verified in reviewed LIG1Core source | RewardController approval + core caps and timing limits. |
| Private LP economics | Connected-module behavior | Must be assessed together with the deployed Private LP module. |
| System LP custody / withdrawal restrictions | Connected-module behavior | Must be assessed from the deployed System LP Vault. |
| Independent third-party audit conclusion | Separate review required | Not replaced by this whitepaper. |
18
Risk Factors
Market risk
LIG1 can rise or fall sharply in price. The token can lose part or all of its market value.
Liquidity risk
A small or imbalanced pool can produce high price impact, slippage and difficult exits.
Smart-contract risk
Software can contain design flaws, implementation bugs or unexpected interactions even after testing.
Module and integration risk
The complete system depends on multiple contracts, token interfaces, pool contracts, front ends and external infrastructure.
Reward-supply risk
New reward-minted LIG1 increases supply. If substantial rewarded tokens are sold without sufficient counter-demand, market price can decline.
LP risk
Liquidity providers can experience impermanent loss and may withdraw a different asset composition than they originally deposited.
External-service risk
Wallets, explorers, RPC providers, security scanners, DEX interfaces and data providers can be unavailable or classify assets differently.
Regulatory and tax risk
Legal, regulatory and tax treatment varies by jurisdiction and can change. Users are responsible for obtaining appropriate advice.
Adoption risk
There is no guarantee that LIGONE applications will achieve meaningful usage or that LIG1 will develop sustained demand.
19
Development Direction
The current priority is not to maximize the number of promises, but to make the live Base system understandable, verifiable and usable. Development is intended to proceed in visible stages.
- Technical stabilization: verify contracts, liquidity paths, rewards and public data.
- Security documentation: maintain scope, findings and evidence suitable for external review.
- User clarity: keep the 14-part LIG1 explanation series and transaction guidance current.
- Community accounts: expand participation, missions, invitations and reward-related user workflows.
- Ecosystem utility: connect LIG1 to useful LIGONE services where a real function exists.
- Measured growth: observe market cap, liquidity, holders and usage without presenting milestones as guaranteed outcomes.
20
Official References
- LIGONE official website
- LIG1 - understandable explanation series
- LIG1Core on BaseScan
- LIG1/USDC market on GeckoTerminal
- Buying and selling LIG1
- LIG1 Market-Cap Challenge
LIG1Core:
Current Base LIG1/USDC pool reference:
21
Disclaimer
This whitepaper is an informational description of the LIGONE / LIG1 project and the technical design reviewed for this revision. It is not investment advice, a prospectus, an offer of securities, a promise of returns or a guarantee of future functionality.
Users must make their own decisions and should independently verify contract addresses, transaction details, liquidity, market conditions and applicable legal or tax requirements. Cryptocurrency and decentralized-finance activity can result in substantial or total loss.
If a conflict exists between descriptive text and deployed smart-contract behavior, the deployed contract and verifiable on-chain state are technically authoritative for blockchain execution.