$STUB · WHITEPAPER
THE LINEA No-List Fair Mint on BNB Smart Chain
NO LIST. JUST THE LINE.
- Cumulative issuance cap
- 2.1B
- Pool opening threshold
- 100 BNB
- Buy tax / sell tax
- 1% / 2%
- Floor line multiple
- 1.80×
Summary
$STUB is a tiered mint with no allowlist, no presale and no team allocation.
All 2.1 billion tokens come into existence only through public minting: 10,000 stubs before the pool opens, priced across five bands at a fixed 12,600 tokens per stub. When 100 BNB has been raised, the pool opens automatically. Minting then continues through five more bands, each at a higher payment per stub, with the tokens received determined by the market price.
The secondary market carries a 1% buy tax and a 2% sell tax (1% burned, 1% to treasury). The official pair is STUB/BNB, and tokens are non-transferable until the pool opens; transfer is enabled once, at opening. A floor line is checked on every mint: if circulating market value falls below 1.8× cumulative proceeds, tokens are burned from the pool to lift the price.
Every pre-opening payment stays in the mint contract. If the minting period closes below 100 BNB, the contract enters refund mode: minting and opening stop permanently, each wallet can reclaim its full payment, and the corresponding tokens are burned.
There is one rule: your serial number sets your price.
1. Why There Is No List
Every launch asks the same question: who gets in first?
For years the answer has been: whoever is on the list. Allowlists, insider groups, reserved allocations, sniping bots — the ordinary participant is always in the back row.
$STUB tears the list up:
- No allowlist. Any wallet can participate directly.
- No presale. Team, private-sale and free-airdrop allocations are all zero.
- No manual allocation. Every token is minted.
- Project funding comes only from the 20% treasury share of post-opening payments, plus the treasury portion of the secondary-market trading tax (the 1% burned on sells never reaches the treasury).
Price does not depend on who you know. It depends on where you stand in the line. Before the doors open the first band costs 0.008 BNB and the fifth costs 0.012 BNB. After the doors open, each band steps higher again.
Cheapest at the front, dearest at the back. That is the entire rule.
2. The Token
| Item | Value |
|---|---|
| Name / Symbol | Stub / STUB |
| Chain | BNB Smart Chain (BEP-20) |
| Decimals | 18 |
| Hard cap on cumulative issuance | 2,100,000,000 |
| Team / private / airdrop | 0 / 0 / 0 |
| Minting right | Mint contract only, never above the cap |
| Buy tax | 1%, to the project treasury |
| Sell tax | 1% burned + 1% to the project treasury |
| Transfers before the pool opens | Blocked — tokens cannot move |
| Wallet-to-wallet transfer tax after opening | 0% |
Tax rates and recipients are fixed in the contract and cannot be changed. The official pair is STUB/BNB. The full tax rules are in Section 7; the pre-opening transfer ban is in Section 10.
2.1 Supply and Allocation
| Purpose | Amount | Share | Release |
|---|---|---|---|
| Pre-pool user mint | 126,000,000 | 6% | 10,000 stubs, fixed 12,600 tokens each |
| Initial trading pool | 84,000,000 | 4% | Added with 80 BNB when the pool opens |
| Post-pool user mint | 1,050,000,000 | 50% | Calculated from payment and the effective reference price |
| Post-pool paired liquidity | 840,000,000 | 40% | Paired with the 80% BNB share of each payment |
| Total | 2,100,000,000 | 100% | Cumulative cap, including user and pool tokens |
Opening issuance is 210 million tokens, 10% of supply. The remaining 1.89 billion, 90%, is issued afterwards.
2.2 Precedence of the Cap
The 2.1 billion cap is absolute and takes precedence over any band's stub count. If the cap is reached early, later bands do not open. The actual number of stubs in Band X is determined by the market price and the remaining allocation.
Burning does not restore issuance capacity. Tokens burned by the sell tax or the floor line are never re-minted, so final circulating supply may be below 2.1 billion.
2.3 Definitions
Every quantity and market-value figure in this paper uses one set of definitions. The contracts, the interface and llms.txt follow it exclusively.
| Term | Definition | Note |
|---|---|---|
| Total supply | Tokens minted and not yet burned | Includes the pool reserve; equals totalSupply() |
| Circulating supply | Equal to total supply in this design | Pre-opening tokens cannot move, and the pool reserve is tradable after opening, so the reserve is not subtracted |
| Market value | Official pool spot price × total supply | Spot price taken from the STUB/BNB pool |
| Burn | A _burn call that reduces totalSupply() | Not a transfer to a black-hole address, which leaves total supply unchanged and would distort market value |
| Cumulative issuance | Every token ever minted | Monotonic; burning never restores capacity |
"Cumulative proceeds" as used by the floor line means BNB actually paid by users, excluding trading tax and gas.
3. Before the Doors Open: Bands I–V
10,000 stubs in total, 2,000 per band, each stub issuing a fixed 12,600 tokens.
During this phase $STUB is non-transferable: minted tokens can only be held. They cannot be sent out or used to form any pool. Transfer is enabled once, at opening, and can never be disabled again.
| Band | Stub range | Price per stub (BNB) | User tokens this band | Proceeds (BNB) | Cumulative (BNB) |
|---|---|---|---|---|---|
| Band I — The Line | 1 – 2,000 | 0.008 | 25,200,000 | 16 | 16 |
| Band II — Balcony | 2,001 – 4,000 | 0.009 | 25,200,000 | 18 | 34 |
| Band III — Mezzanine | 4,001 – 6,000 | 0.010 | 25,200,000 | 20 | 54 |
| Band IV — Orchestra | 6,001 – 8,000 | 0.011 | 25,200,000 | 22 | 76 |
| Band V — Box | 8,001 – 10,000 | 0.012 | 25,200,000 | 24 | 100 → doors open |
| Total | 10,000 | — | 126,000,000 | 100 | — |
A purchase that crosses a band boundary is priced per band, by the actual number of stubs taken in each.
Every stub before the doors open receives the same 12,600 tokens, whichever band it was bought in. Only the payment differs — which is precisely "your number is your price" in concrete form.
Pre-opening minting is bounded by the minting period: if fewer than 10,000 stubs are sold when it ends, the contract enters refund mode (Section 4.2).
4. Doors Open: Stub 10,000
When stub 10,000 is minted, the pool opens automatically.
| Opening parameter | Value |
|---|---|
| Total raised | 100 BNB |
| BNB added to the pool | 80 BNB |
| Tokens added to the pool | 84,000,000 |
| To the project treasury (after opening) | 20 BNB |
| Implied initial pool price | 1 BNB ≈ 1,050,000 tokens |
| Per stub at the initial pool price | 12,600 tokens ≈ 0.012 BNB |
| Versus Band V | Parity (1×) |
| Versus Band I | 1.5× |
| Token transfers | Enabled at opening, permanent thereafter |
- Parity opening: the pool opens at the Band V price, so the last minters are not immediately underwater.
- The opening transaction does two things: it adds 80 BNB and 84,000,000 tokens to the STUB/BNB pool, and it enables token transfers.
- All LP tokens, initial and subsequent, are burned. Liquidity cannot be withdrawn.
Multiples above compare untaxed initial pool quotes; actual sale prices move with trading.
4.1 Custody Before Opening
All 100 BNB raised before opening stays in the mint contract, both the 80% pool share and the 20% treasury share. Only at the moment the opening transaction succeeds does the contract make two transfers:
| Item | Before opening | Opening succeeds | Opening fails (refund mode) |
|---|---|---|---|
| 80 BNB | Held by the mint contract | Added to the STUB/BNB pool with 84,000,000 tokens | Used for refunds |
| 20 BNB | Held by the mint contract | Sent to the project treasury | Used for refunds |
- Treasury income is zero before opening. The 20 BNB accrued in Bands I–V is credited to the treasury only after a successful opening.
- The contract has no owner withdrawal function. This 100 BNB can only go to the pool or back to the wallets that paid it.
- This is a different rule from the "80 / 20 split on every payment" that applies after opening; do not conflate the two.
4.2 Failure to Raise: Refund Mode
10,000 stubs may take a long time to sell out, so the pre-opening phase has a minting period.
| Rule | Parameter |
|---|---|
| Window ends | 30 days after the last pre-opening mint, or 180 days after deployment, whichever comes first |
| Resulting state | Refund mode: minting stops permanently and the pool never opens |
| Who can claim | Any wallet that paid before opening |
| Amount | 100% of the BNB that wallet paid, including the 20% treasury share |
| Method | The wallet calls refund() itself; no deadline |
| After refund | All of that wallet's pre-opening tokens are burned; its serials and quota are void |
| Unclaimed balance | Stays in the contract indefinitely, claimable only by the wallet that paid it |
- Failure means a full refund: 100% of principal, with no pro-rating, haircut or fee, and no treasury retention. Every BNB the contract received is available for refunds.
- Refund mode is irreversible. Once it starts, no later payment can reopen the pool.
- There is no refund path after opening. Once stub 10,000 is minted, the contract leaves the refundable state permanently and payments are allocated as described in Section 4.1.
- Refunds are per wallet and all-or-nothing; there is no partial refund. The wallet's invitation quota is voided at the same time.
- In refund mode transfers never open. Unclaimed $STUB is permanently non-transferable — claim your principal within the window.
- Refunds bypass the treasury multisig and require no human action: the path is fixed in code. The interface offers one-click refunds, and the contract also exposes refundBatch(address[]) so anyone can trigger refunds on behalf of many wallets; BNB goes directly to each wallet, never to the caller.
5. After the Doors Open: Bands VI–X
Bands VI to X follow, with no additional minting discount (0%).
| Band | Cumulative stub range | Payment per stub (BNB) | Duration rule |
|---|---|---|---|
| Band VI — Encore I | 10,001 – 20,000 | 0.012 | Up to 10,000 stubs |
| Band VII — Encore II | 20,001 – 30,000 | 0.016 | Up to 10,000 stubs |
| Band VIII — Encore III | 30,001 – 40,000 | 0.020 | Up to 10,000 stubs |
| Band IX — Encore IV | 40,001 – 50,000 | 0.024 | Up to 10,000 stubs |
| Band X — Encore V | 50,001 onward | 0.028 | Until the allocation is exhausted |
5.1 Dynamic Issuance
user tokens = BNB paid ÷ effective reference price per token
paired tokens = user tokens × 80%
total new tokens = user tokens × 180%After the doors open, user and paired tokens are issued in a 5 : 4 ratio.
5.2 Modelled Issuance (market price assumed equal to the initial pool price)
| Band | Payment (BNB) | Tokens per stub | User tokens | Paired tokens |
|---|---|---|---|---|
| Band VI | 0.012 | 12,600 | 126M | 100.8M |
| Band VII | 0.016 | 16,800 | 168M | 134.4M |
| Band VIII | 0.020 | 21,000 | 210M | 168.0M |
| Band IX | 0.024 | 25,200 | 252M | 201.6M |
| Band X | 0.028 | 29,400 | 294M | 235.2M |
| Total | — | — | 1.05B | 840M |
This table is a conditional example, not a forecast: it assumes the market price equals the initial pool price and that Bands VI–X each sell 10,000 stubs.
Actual issuance and the number of Band X stubs depend on the reference price and the remaining allocation.
6. Fund Allocation
Every payment is split 80% into the pool and 20% into the treasury. Before the doors open, all payments — including the 20% treasury share — stay in the mint contract and are transferred only on a successful opening (Section 4.1); afterwards they are split per transaction. In refund mode that 20% is used for refunds as well.
| Band | Proceeds (BNB) | To pool | To treasury | Cumulative |
|---|---|---|---|---|
| Band I | 16 | 12.8 | 3.2 | 16 |
| Band II | 18 | 14.4 | 3.6 | 34 |
| Band III | 20 | 16.0 | 4.0 | 54 |
| Band IV | 22 | 17.6 | 4.4 | 76 |
| Band V | 24 | 19.2 | 4.8 | 100 |
| Band VI | 120 | 96 | 24 | 220 |
| Band VII | 160 | 128 | 32 | 380 |
| Band VIII | 200 | 160 | 40 | 580 |
| Band IX | 240 | 192 | 48 | 820 |
| Band X | 280 | 224 | 56 | 1,100 |
| Modelled total | 1,100 | 880 | 220 | — |
- The 100 BNB before opening is a fixed threshold, and treasury income before opening is zero: the "To treasury" column for Bands I–V is credited only after a successful opening.
- The 1,000 BNB after opening is a modelled result under the conditions above; the pool's BNB reserve moves with trading.
- Trading-tax revenue is not included in this table; see Section 7.
7. Trading Tax
7.1 Rates
| Action | Rate | Destination |
|---|---|---|
| Buy through the official pool | 1% | Project treasury |
| Sell through the official pool | 1% burned + 1% | Burn / project treasury |
| Wallet-to-wallet transfer (after opening only) | 0% | — |
| Any transfer before opening | Blocked | No rate applies; the transaction reverts |
| Direct mint | Not taxed | Mint payments are in BNB and do not pass through the pool |
- The official pair is fixed as STUB/BNB; there is no other quote asset.
- Rates and recipients are hard-coded; there is no setter of any kind.
- The burn portion of the sell tax is executed during the transfer and never reaches the treasury.
- Minting incurs no trading tax: the tax applies only to spot trades on the official pair.
- Before opening, the transfer check runs ahead of the tax logic: any outgoing transfer reverts, so there is no "pay the tax and transfer anyway" path.
7.2 Settlement of Tax Revenue
- The treasury portion of both taxes is denominated in $STUB and accumulates in the mint contract.
- Anyone may call swapTax() to convert it to BNB and send it to the treasury, subject to two limits:
- at most once per block;
- at most 0.10% of the pool's $STUB reserve per swap.
- These limits cap the price impact of tax settlement so that it cannot become a dump.
7.3 Pair Restrictions
- The rates above apply only to the official STUB/BNB pair.
- Other pools holding $STUB may be blocked by the treasury multisig; wallets and DEX routers can never be blocked.
- This blocking power lapses permanently after renounce(): no new entries can be added, but existing entries remain blocked forever.
7.4 Permission Inventory
| # | Power | Holder | Can | Cannot | Exit |
|---|---|---|---|---|---|
| 1 | mint() | Any wallet | Mint by paying the band price in force | Exceed 2.1 billion; pause or stop minting (no pause()) | Ends when the allocation is exhausted or refund mode starts |
| 2 | Transfer switch | Contract, automatic | Enable once, in the opening transaction | Be enabled, disabled or re-closed by anyone | Hard-coded once enabled |
| 3 | Tax rates | Hard-coded | — | Be changed | No setter |
| 4 | Floor multiple and per-transaction cap | Hard-coded | — | Be changed | No setter |
| 5 | blacklistPool() | Treasury multisig (3/5) | Block non-official pool contracts holding $STUB | Block wallets, DEX routers or the official STUB/BNB pool | No new entries after renounce() |
| 6 | swapTax() | Anyone | At most once per block and ≤ 0.10% of the pool's $STUB reserve | Exceed either limit | None needed |
| 7 | Treasury funds | Treasury multisig (3/5) | Withdraw BNB and tax revenue credited after opening | Withdraw user principal, LP tokens or refund reserves | Spent per published purpose |
| 8 | Contract upgrade | None | — | Upgrade or replace logic (not a proxy) | Not applicable |
Timeline
- Deployment: the contract is not upgradeable; tax rates, floor parameters and the issuance cap are hard-coded. The treasury multisig is 3-of-5, and its member addresses are published at deployment and in llms.txt.
- 30 days after opening, or 90 days after deployment, whichever is later: the multisig calls renounce() and permanently gives up blacklistPool().
- After renouncement: existing blacklist entries remain in force permanently, but no new ones can be added. Minting, transfers and swapTax() are unaffected.
What is deliberately absent: no pause(), no mint switch, no tax setter, no proxy upgrade, no arbitrary-address transfer blocking. The multisig's only substantive powers are blocking non-official pools and receiving treasury funds.
8. The Floor Line
8.1 Definition
floor line = cumulative BNB paid × 1.80The floor line is a ratchet that rises with cumulative proceeds. It is not a fixed price and not a guarantee of value.
Why 1.80×: at the moment the doors open, circulating market value is exactly 2.0× cumulative proceeds —
pool price = 80 BNB ÷ 84,000,000 = 9.524e-7 BNB per token
circulating = 126M + 84M = 210M tokens
market value = 210M × 9.524e-7 = 200 BNB
market value / proceeds = 200 / 100 = 2.0At 1.80×, the floor line sits at 180 BNB when the doors open — 10% below market value, so it does not trigger at launch.
As post-opening minting proceeds, each payment adds 1.8 × payment to market value (100% user tokens + 80% paired tokens) while cumulative proceeds rise by 1 × payment. The ratio therefore converges from 2.0 toward 1.8, and the distance between market value and the floor narrows. The mechanism stays self-consistent throughout.
8.2 Trigger and Execution
Checked on every mint:
market value (pool price × total supply) < floor line → burn $STUB from the pool and lift the price toward the lineThe burn removes tokens from the pool's reserve; the BNB side is untouched. The pool becomes BNB-heavy and token-light, so the price B/T rises.
Three hard limits:
| Limit | Value | Purpose |
|---|---|---|
| Maximum price lift per transaction | 0.8% | Prevents a single transaction from spiking the price, and prevents farming the line |
| Minimum pool token reserve | 8,400,000 | Prevents the pool from being burned empty and losing the ability to trade |
| Trigger window | Mint only | No timer, no keeper |
The floor line acts only on the pool's token reserve: it adds no BNB, buys nothing back, and does not promise that any wallet can sell at the floor price. It creates no redemption obligation of any kind.
8.3 What It Can and Cannot Do
Can: provide an on-chain anchor for "how much market value should exist given how much money came in", and passively support the price during a sharp decline while minting continues.
Cannot:
- Defend anything without mints — this is not automated market making.
- Guarantee execution — as pool tokens shrink, the sell-side impact actually gets worse.
- Repair quickly — the 0.8% per-transaction cap means closing a 10% gap takes more than a dozen consecutive mints.
- Stop a sustained downtrend — it is a cushion, not a floor.
Because the line moves with cumulative proceeds, the interface must display the live "market value / floor line" ratio and the cumulative burn, or users cannot perceive the mechanism at all.
9. Wallet Quota and Invitations
Any wallet may participate. Purchase quota and invitation quota are recorded per wallet address, shared across both phases, and not reset when the doors open.
| Rule | Parameter |
|---|---|
| Base quota per wallet | 10 stubs |
| Valid invitation | The buyer completes their first successful paid mint with a valid referral code; earlier mints may omit a code |
| Reward per valid invitation | +1 stub for the inviting wallet |
| Maximum invitation bonus | +20 stubs |
| Cumulative cap per wallet | 30 stubs |
| Cap per transaction | 10 stubs |
| Counting an invited wallet | Rewarded once only; changing the referral code later earns no further reward |
| Quota scope | Shared across phases; not reset at opening |
- Invitation stubs are still paid at the band price in force, and funds follow the same 80/20 split.
- Caps apply per wallet address.
- If the inviter has reached the +20 bonus cap, no reward is issued and the buyer's one-time reward eligibility remains unused.
- A zero-address referral or self-invitation does not count.
10. Settlement and Protection Rules
- Cumulative issuance never exceeds 2.1 billion tokens, including user and pool tokens. Burned tokens do not restore issuance capacity.
- Purchases crossing band boundaries are priced per band, by actual stub counts.
- When the remaining allocation cannot fill a whole stub, the final transaction fills partially: it issues the remainder, consumes 1 serial and 1 quota unit, charges pro rata against the tokens actually issued, and refunds the unused BNB.
- All LP tokens, initial and subsequent, are burned.
- Orders set a maximum payment and a minimum tokens received. If a partial fill would deliver fewer tokens than the minimum, the entire transaction reverts: no charge, no serial consumed, no quota consumed.
- Post-opening quotes must pass a price-protection check; the observation window and deviation threshold are to be fixed during contract development.
- All quantity and amount figures exclude transfer tax and on-chain gas.
- The curve controls the payment per stub. After opening, the price per token moves with trading.
- The trading tax applies only to trades on the official STUB/BNB pair; after opening, wallet transfers are untaxed, and the rates cannot be changed.
- The floor line is checked on every mint; the per-transaction lift cap and the minimum pool token reserve are fixed and immutable.
- Before the pool opens, $STUB cannot be transferred at all. The opening transaction enables transfers once; they are never disabled again. Pre-opening tokens can only be held — they cannot be sent out or used in any pool.
- If the minting period closes below 100 BNB, the contract enters refund mode: wallets can reclaim their full payment and the corresponding tokens are burned (Section 4.2).
11. The Queue Stub
The MVP issues no NFT. A stub is the presentation of an on-chain mint record, not a separate asset.
Every mint writes one on-chain record containing:
- Serial number — unique on-chain, and the determinant of price
- Band
- Amount paid
- Wallet address
- Buying N stubs produces N independent records and N serials. A purchase that crosses a band boundary is split by band; serials within a band are still numbered individually.
- Records are never merged, split, or minted as NFTs, and no transferable instrument exists on-chain.
- The interface may render a single record as a 1970s ticket stub — that is only another drawing of the same on-chain data.
- A stub confers no dividend, governance, redemption or any other right, and cannot be transferred or sold on its own. Its purpose is to make "where you stand in the line" visible and shareable.
12. Risks
- Post-opening token amounts are uncertain. Dynamic issuance uses the effective reference price; the modelled table assumes a constant price and actual results may differ materially.
- Bands may not open. The 2.1 billion cap takes precedence; if the allocation is exhausted early, later bands close.
- Funds are custodied before opening. The 80% pool share and the 20% treasury share both sit in the mint contract until the doors open. This is the single custody point in the design and must be audited.
- Locked liquidity is not price protection. Burning LP tokens prevents withdrawal; it does not prevent the price from falling.
- Treasury funds are multisig-controlled. The 20% share of every post-opening payment, and the treasury portion of the trading tax (1% of buys, 1% of sells), go to the project's 3/5 multisig, whose use is decided by that multisig. The burned 1% of the sell tax is destroyed during the transfer and never reaches the treasury.
- The trading tax reduces secondary liquidity. 1% on buys and 2% on sells suppress high-frequency trading and raise the cost of exiting.
- The floor line is not a guarantee. It triggers only on mints, lifts at most 0.8% per transaction, and does nothing when no one is minting.
- Burning thins the pool. The floor line burns pool tokens, so the pool gets shallower and equally sized sells move the price further.
- Parameters are immutable. Tax rates, the floor multiple and the lift cap cannot be adjusted after deployment, even if market conditions change.
- Smart contract risk. Contracts may contain bugs. Read the verified source before participating.
- Tokens cannot be transferred before opening. Until 100 BNB is raised, $STUB cannot be sent, traded or used in any pool. If the minting period closes below the threshold, the contract enters refund mode: minting and opening stop permanently, transfers never open, and unclaimed tokens stay non-transferable. Call refund() to reclaim your principal.
- This document is not investment advice. $STUB is a meme token with no promised utility, yield or value. Its price can fall to zero.
13. Contracts and Verification
- The token and mint contracts should be published and verified so that anyone can check every rule in this paper.
- The mint contract is the only address that accepts payment. Sending BNB or any other token to the token contract does not mint and the funds are lost.
- A plain BNB transfer does not mint. The mint function must be called.
- A machine-readable llms.txt will publish contract addresses, function selectors, live pricing, tax rates, common failure reasons, and the refund() / refundBatch() entry points.
Disclaimer
$STUB is a meme token. It promises no utility, yield or value, and its price may fall to zero.
All figures in this document rest on stated assumptions and are not a promise of future performance.
The trading tax and the floor line are price and liquidity mechanisms. They are not a promise of return and not a guarantee of price.
Crypto assets are highly volatile. Assess the risks yourself and comply with the law of your jurisdiction.
