Token Lifecycle · BSC · BigShort Docs

Follow initial minting, curve issuance, and external migration to understand asset ownership, configuration snapshots, and state transitions in a BSC market.

A market proceeds through creation, internal-market trading, atomic migration, external-market trading, and short selling. The economic group and initial supply are fixed at creation. The final curve purchase also funds the external Pair and initializes the Short Engine; routine graduation requires no manual operator action.

1. Initial supply and allocation

Component	Token quantity	Initial holder	Purpose
Internal-market sale inventory	8,000,000,000	Factory	Sold to curve buyers; selling back replenishes available inventory
External-market migration reserve	2,000,000,000	Factory	Join the main Pair at graduation
Separate lending reserves	1,997,367,528	Reserved Short Engine proxy address	Borrow Token to short after graduation
Total initial mint	11,997,367,528	Both address types above	Not all available for sale

S_{\mathrm{curve}}=8{,}000{,}000{,}000+2{,}000{,}000{,}000=10{,}000{,}000{,}000

S_{\mathrm{minted}}=S_{\mathrm{curve}}+1{,}997{,}367{,}528=11{,}997{,}367{,}528

Protocol market cap uses the fixed 10,000,000,000 Token of curve supply rather than initial minted or live circulating supply. The current implementation has no later mint entry point, but burnTaxMode burns Token on taxable external transfers, causing Total supply decreases; the risk model’s curve-supply basis is not reset.

The creator does not automatically receive Token or LP. Lending Token is minted to the reserved Engine address at creation; contract code is deployed there only at migration. Graduation does not mint this inventory again.

2. Creation parameters, identity, and metadata

Configuration	Current constraint
`name`	Nonempty, at most 64 bytes
`symbol`	Nonempty, at most 16 bytes
`uri`	Up to 512 bytes; may be empty

Length is measured in UTF-8 bytes. The creator may be a contract caller but cannot arbitrarily name another identity. taxRecipient and buy recipient may differ without changing creator.

Creation sequence and MarketGroup snapshot

Validate metadata and tax settings, then read defaultMarketGroup confirming the group exists and allows new Token creation.
Derive the deployment salt from Factory, creator, user salt, name/symbol hashes, and creation nonce.
fixed ProtocolDeployer Predict Token, Engine, and optional Processor addresses; Registry records Token and the reserved Engine.
For taxed mode, first deploy and initialize TaxProcessor, then deploy and initialize Token and mint initial supply.
Create or reuse the Token/WBNB Pair; verify venue, address, code, and assets, then bind mainPair.
The Factory stores curve reserves, tax settings, and marketGroupOf[token]enters Bonding and emit the event.

Group Curve, Engine, and Tax economics, Venue, deployer, and Oracle remain snapshotted. A later Factory default-group change does not affect existing Tokens; disabling a group in Registry does not block old Tokens’ trading or migration.

3. State machine and completion conditions

Status	Meaning	User action
`None`	The market does not yet exist in the Factory	Creation
`Bonding`	Curve-sale inventory remains	Buying, selling back, and ordinary wallet transfers
`Complete`	The final purchase has reduced sale inventory to zero	Immediate migration in the same transaction, not an operator waiting stage
`Migrating`	Verify Pair, fund it, and deploy Engine in the same transaction	No separate public migration entry point
`Migrated`	Pair and Engine ready	External trades and eligible position operations; curve trading is closed

None → Bonding → Complete → Migrating → Migrated. The last three stages may all occur in the final purchase transaction; state and logs persist only if the whole transaction succeeds.

Let initial sale inventory be $R_0=8{,}000{,}000{,}000$ Token, with a remaining amount of $R$ :

\mathrm{Progress}=\frac{R_0-R}{R_0}\times100\%

Buying reduces R; selling back increases R. Wallet transfers do not change progress. The sole completion condition is R=0 rather than a fixed BNB fundraising amount or market cap. Selling 4,000,000,000 Token is 50% quantity progress, not 50% of graduation BNB collected.

4. Trading boundaries on the curve

A buy recipient cannot be the main Pair. Refunds go to the transaction caller, not the Token recipient. Holders must approve Factory before selling back.

Before external trading opens, ordinary wallet transfers are allowed, but transfers involving mainPair restricts nonzero transfers; transfers involving Factory are the migration exception. This applies to the bound main Pair, not every third-party market. An existing Pair address does not mean trading is open.

5. Atomic final purchase and migration

The final purchase first settles the curve trade, then wraps all actual curve BNB into WBNB, together with 2,000,000,000 Token Deposit into Pair, deploy and initialize the reserved Engine, verify bindings, and open external trading.

The final purchase consumes more resources than an ordinary purchase; clients should not assume the same fixed gas limit. See funding, donations, LP, and wrapping details in Migration and External AMM.

6. Responsibilities and boundaries after migration

Token manages ERC-20 behavior, main Pair tax, and burn tax; the Pair holds and swaps actual Token/WBNB.
The Engine manages separate lending inventory, BNB positions, Funding, closing, liquidation, and Legacy. The group Oracle maintains observations separately for each Engine.
The Factory retains issuance, migration, and role management. The Quoter provides previews and does not execute trades.
Lending inventory does not enter the AMM. All initial migration LP is held by the zero address, rather than allocated to the creator or final buyer.
Trades and new positions remain subject to risk, inventory, minimum-notional, and pause constraints. Successful migration does not imply unlimited short-selling capacity.