Token Lifecycle

Follow fixed-supply creation, curve issuance, and external migration to understand permissions, asset ownership, and state transitions at each stage.

BigShortProtocol-EVM divides a Token's lifecycle into creation, internal-market trading, atomic migration, external-market trading, and short selling. Supply and issuance configuration are fixed at creation; the final internal-market buy also establishes the external pool and initializes the Short Engine. The normal flow has no manual graduation step performed by an operator.

1. Fixed Supply and Initial Allocation

Each Token mints its entire supply once during construction; curve inventory and lending reserves serve distinct purposes.

The curve supply basis is:

Total supply is:

The market-cap model uses the curve supply basis of 1,000,000,000 Token, not the ERC-20 total supply of 1,199,861,071. This is a protocol valuation convention and must not be confused with circulating market cap or valuation based on the full total supply.

Initiating creation does not automatically give the creator a Token allocation. A creator who wants sale inventory must acquire it through trading. Nor is the lending reserve minted at migration: the Token is already transferred to the predicted Engine address at creation, before the Engine contract code has been deployed at that address.

2. Business Configuration Determined at Creation

These limits count UTF-8 bytes, not Chinese characters. Data such as name and symbol participate in deterministic deployment address derivation; different initiators and creation sequence numbers have distinct deployment namespaces.

Creation Execution Order

1. Validate metadata, creator, and tax configuration.
2. Read the current default Launch Profile and lock the four versions for Token, curve, Engine, and trading venue.
3. Calculate the predicted Token and independent Short Engine addresses.
4. Deploy the Token and mint curve supply and lending reserves once. If taxed mode is selected, also deploy that Token's dedicated Tax Processor.
5. Create or reuse the designated Token/USDC Pair, validate its identity and code, and bind it as mainPair.
6. Set the curve to Bonding, record initial reserves, metadata, tax rates, and the configuration snapshot, and emit the creation event.

Each Token retains its own Launch Profile. Selecting a new default Profile later does not automatically switch existing Token to a new curve or venue; Factory proxy upgrade authority is separate from this configuration snapshot mechanism, as explained in the permissions chapter.

3. State Machine and Available User Actions

The stage transitions in a normal successful transaction are:

None → Bonding → Complete → Migrating → Migrated

The last three stages may all occur during execution of the same final buy transaction. New on-chain state and logs are retained only if the entire transaction succeeds.

The Sole Quantity-Based Completion Condition

Let initial sale inventory be $R_0$ and current sale inventory be $R$. Progress based on net quantity sold is:

Here, $R_0=\mathrm{793,100,000}$ Token. Buys reduce $R$, sales back increase $R$, and wallet-to-wallet transfers do not affect progress. This percentage is useful for display, but is not a separate state field maintained by the contract.

Completion requires $R=0$, not a fixed amount of USDC raised or a fixed market cap. For example, if exactly 396,550,000 Token have been sold net, 396,550,000 remain and progress is 50%; this does not mean 50% of the final USDC has been received, because the curve price changes as trades execute.

4. Trading Boundaries during the Internal Market

The internal market quotes using virtual reserves recorded by the Factory and settles using actual reserves. Its three entry points serve different needs:

Buyers may specify a Token recipient, but cannot use the main Pair as recipient; refunds always go to the transaction initiator, not the Token recipient. Sellers must first approve the Factory to spend their Token.

Before the Main Pair Opens

• Ordinary holders can transfer between wallets.
• Before external trading opens, nonzero Token transfers involving mainPair are restricted; the Factory is the controller exception reserved for migration.
• An internal-market buy cannot send Token directly to the Pair.
• The Pair address may already exist, but creating a Pair does not mean that external trading has opened.

This restriction applies to the protocol-bound mainPair; it must not be presented as a global block on every third-party address or independently created market.

5. Atomicity of the Final Buy and Migration

The final buy settles under internal-market rules, then funds the external pool, deploys and initializes the Engine, and opens external trading. If any required step fails,the entire final buy reverts: Token transfers, curve-reserve updates, refunds, and logs in this transaction are reverted. Earlier completed transactions are unaffected.

The final buy requires more execution resources than an ordinary buy; clients should not reuse a fixed gas limit for ordinary buys. See Migration and External AMM.

6. Module Responsibilities after Migration

Migration does not add lending reserves to the AMM or allocate initial LP to the creator or final buyer. Trading prices are determined by the migrated Pair's actual reserves; short selling must still satisfy risk-capacity, lending-inventory, and margin requirements together.