This Stellar migration runs on the Stellar testnet stack of 29 September 2026. Mainnet contracts are not deployed; mainnet addresses must be published and pinned before any mainnet use. Where something is a judgement call or an open risk, it says so.
One transaction deploys your token, creates a Sushi V3 pool paired to USDC, seeds 30% of the supply into the knockout vault and up to 70% into that pool as single-sided liquidity, and locks the position permanently.
| Supply | 1,000,000 | Fixed. No mint function exists. |
|---|---|---|
| Owner | none | The token has no admin after deploy. |
| Transfer tax | 0% | No tax code path exists. |
| Pool | Configured tier | Sushi V3, paired to Circle USDC on Stellar. |
| Opening price | Pinned terms | Read from the launch configuration before signing. |
| Address | C… | Stellar contract address, deterministically derived from the launch request. |
| Launch fee | Pinned limit | USDC launch fee plus Stellar network fees in XLM. |
Ordinary receipts are blocked in the launch ledger, except the atomic opening buy. During the explicitly configured number of ledgers, cumulative receipts and wallet balances are capped using the initial supply. Transfers cannot reset the cumulative counter.
Every parameter is checked before the token contract is created, so a rejected launch costs you the gas of a cheap revert rather than a full deployment. The page also re-reads the live launch terms and refuses to send if they differ from what it was built against; the contract re-checks the same hash when the transaction executes, so nothing can change between the two.
A trader pays exactly one fee: the configured Sushi V3 pool fee. Nothing is added on top by us at swap time.
Sushi pays that fee out in both assets of the pair, and each side is treated differently.
Sushi may deduct its own protocol share first. The following split applies to the USDC fees actually received by the Dotcom locker; it is not a split of gross trading volume.
Rounding remainders always go to the creator. Integer division leaves at most a couple of raw USDC units per collection; it lands on the creator's side, never ours.
The protocol never holds or sells a token launched here. Its share of the token-denominated fees goes through the token’s burn function in full, which means every fee collection also shrinks that token's supply. Creators are paid in USDC only, deliberately: a payout in your own thin-liquidity token is not really a payout.
constant in the deployed contract, not settings.
There is no setter. No admin key, including ours, can retune them. Changing them would require
deploying a different contract, which existing pools would not use.
33% of the USDC side of the 1% pool fee, forever, on every trade of the token you launched. In round numbers: $1,000 of volume produces $10 of pool fees, of which about $3.30 is yours.
Fees accrue in the locked position and are paid out when collectFees is called for your
token. Anyone can trigger it; the recipients are fixed on chain, so an open call cannot misdirect
anything. You may also point your share at a different wallet.
The buyback share accumulates as USDC in a vault. On a schedule, a keeper spends it on DOTCOM, the protocol token, and the purchased tokens go straight to the burn address inside the swap itself. They never rest in the vault.
A knockout position is time-boxed exposure: you pick a token, a USDC amount and a duration, pay the duration's price up front, and the token amount is fixed at entry. Survive to expiry and the tokens are delivered to your wallet. Touch the barrier first and the position ends, costing you what you paid. In traditional markets this instrument is called a knockout certificate.
| Duration | You pay (of exposure) | Knocks out if it falls |
|---|---|---|
| 6 hours | 73.93% | ~19% |
| 12 hours | 70.20% | ~23% |
| 24 hours | 65.60% | ~28% |
| 7 days | 50.47% | ~44% |
| 15 days | 44% | ~52% |
| 30 days | 37% | ~59% |
The barrier is exact: a position knocks out when its value falls to 110% of what you paid. While your tokens are worth more than 110% of your payment, you cannot be knocked out. After expiry, no knockout is possible at any price; delivery is a right.
Circle CCTP V2 connects Stellar with seven peer networks: Solana, Unichain, X Layer, Base, Arbitrum, Ethereum and OP Mainnet, in both directions (14 routes, always Stellar on one side; never peer to peer). Pick the network in the bridge panel, then the direction. Connect Freighter on the Stellar side and an EVM wallet (Rabby, MetaMask) or a Solana wallet (Phantom, Solflare or any Wallet Standard wallet) on the other side. The destination address is shown in full before burning; Solana funds arrive in the connected wallet’s USDC token account.
Transfers into Stellar use Circle Fast only and pay a 3% service fee; Standard is no longer offered for them. A burn that starts on Stellar uses Circle’s standard attestation, which is already fast on Stellar (Circle offers no Fast tier from Stellar), and pays 2%. There is no speed choice. Circle’s separate fee is quoted live and capped at 1% of the net burn by the collectors. A quote that exceeds the cap, or that does not match the selected network and direction, is refused; the app never falls back to Standard.
The source transaction takes the service fee and burns the remainder atomically: an EVM collector contract per EVM network, one Stellar collector for all seven destinations, and on Solana a fee transfer and the Circle burn inside one signed transaction (all or nothing, but not enforced by a program). Peer-to-Stellar funds mint through Circle’s forwarder directly to your G account. Stellar-to-EVM funds mint to your explicit EVM address; Stellar-to-Solana funds mint to your USDC token account. After attestation, claim on the destination network. You need destination gas (XLM, ETH, OKB on X Layer, or SOL) and a USDC trustline on Stellar.
Share your link. When someone who arrived through it trades, you earn 20% of the protocol's revenue from their activity, paid in USDC.
Rewards use actual collected USDC protocol revenue, weighted by qualifying referred trading volume after referral binding. Sushi’s protocol share and token-denominated fees are not counted as received USDC. Displayed claimable amounts come from the funded vault.
These are properties of the code, not promises:
| Liquidity | The locker contract has no function that withdraws, decreases or transfers a position. There is no path to remove launch liquidity, for anyone. |
|---|---|
| Fee split | Compile-time constants. No setter exists. |
| Buyback target | Set once, then permanently rejected. |
| Factory binding | The locker binds to one factory once and refuses to be repointed. |
| Referral claims | Cannot be paused. A pause switch over withdrawals is a rug vector and is deliberately absent. |
| Ownership | renounceOwnership is disabled, so the protocol cannot be
accidentally bricked into an unmanageable state. |
Verify everything above yourself. Nothing here asks for trust that the chain cannot confirm.
This page is updated with the live addresses the moment the contracts are deployed and verified on the Stellar explorer.
Stellar transactions use Freighter and the selected network’s passphrase. G accounts are supported; muxed addresses and contract wallets need a separate integration. EVM and Solana wallets are used only for the CCTP bridge, on the network you selected; the app switches or adds the chain from its verified registry and refuses to sign on any other chain or cluster.
The app simulates each Stellar transaction, checks the connected account and network again before signing, and verifies the wallet returned the same transaction. EVM bridge approvals cover only the requested amount; Solana needs no approval because the fee and burn are one transaction.
Referral binding uses a separate, expiring Stellar signed message. It contains the site domain, network, wallet, referrer and single-use nonce; it does not transfer funds.
No third-party audit. The contracts have a test suite covering the fee split, the burn path, the buyback guards and the anti-snipe rules. A test suite is not an audit. One is worth commissioning before the value at stake exceeds what an audit costs, and that has not happened yet.
Sushi is an external dependency. Its verified Stellar mainnet factory has administrative upgrade and pause capabilities. Dotcom’s immutable locker does not remove those Sushi-level powers.
Thin pools move on small trades. New launches begin with single-sided token liquidity. Swaps require an exact-input quote, minimum output, explicit price limit and deadline; partial fills are refused. These checks cannot eliminate market risk.
Nothing here is advice. This site publishes data and executes transactions you sign. It does not tell you what to buy, and it never will.
Something broke, a number looks wrong, a transaction did not do what the page said it would? Write to support@dotcombubble.fun. Include the wallet address, the transaction hash if there is one, and what you expected to happen. Both inboxes are read by a person.
| Support | support@dotcombubble.fun for bugs, stuck transactions, wrong data and questions about how something works. |
|---|---|
| Security | security@dotcombubble.fun for anything that could lose somebody money: a contract flaw, a way around a guard, a frontend that can be made to sign the wrong thing. Please write here first, before posting it anywhere public, so it can be fixed while nobody is exposed. There is no paid bounty programme yet. |
| X | @dotcombubblefun for announcements. Direct messages there are not a support channel. |