Loading market data…
Core pages render independently from optional market-data providers.
Core pages render independently from optional market-data providers.
Fortune is built around three rules: no reward-funded token dumping, holders get paid in the pair asset, and creators can pair launches with an expanding universe of reviewed BNB assets. The interface stays simple while the registry, oracle and graduation checks stay explicit underneath.
A creator chooses a token identity, launch type and pair asset. Fortune validates that configuration against the live registry and oracle policy, deploys a fixed-supply token and opens its curve. When the launch reaches its graduation condition, the standard stack can migrate into Pancake V3 and permanently custody the LP-position NFT in Fortune's locker.
Fortune's production target is Burn + Rewards v2: token-side market fees can only enter an irreversible burn path, while pair-asset fees fund rewards and platform routing directly. Fortune should never need to sell the launch token to pay holders. The older fee-on-transfer stack remains research/testnet evidence and is not being silently shipped as v2.
Burn + Rewards v2 status: research only, disabled for real funds.
Standard graduation uses Fortune's Pancake V3 adapter. The curve preflights the market, transfers the graduation inventory atomically, mints the LP position and deposits the NFT into the permanent Fortune liquidity locker. Failed graduation remains retryable rather than partially completing.
Fortune will expose reward pots, epochs and distribution transactions only when they can be reproduced from chain data. The extended stack already separates holder-dividend accounting from the normal Standard token path; production automation remains a separate review boundary.
Fortune's registry model can represent BNB/majors, stablecoins, BNB-native DeFi assets and compatible tokenized stocks/RWAs. A discovered BSC token is not automatically launchable: an exact contract, compatible transfer behavior, oracle policy and graduation path must all pass.
Fortune can expand toward arbitrary BEP-20 pairs, but BNB tokens can have fees, rebases, blacklists, unusual decimals or thin liquidity. Fortune therefore treats custom pairing as a compatibility pipeline: token behavior, pricing source, liquidity/graduation venue and policy checks must pass before the asset becomes launchable.
The product direction is a short default flow: identity, image, launch type, pair asset and optional creator purchase. Fortune's deeper curve, fee and routing controls remain available for reviewed advanced launch templates rather than overwhelming every creator.
You still trust BNB Smart Chain consensus and the external protocols a launch uses, including WBNB, approved oracle feeds and PancakeSwap. Fortune's own production release additionally depends on independent contract review, contract-based governance, monitored RPC infrastructure and a paused-then-activated deployment ceremony.
Public endpoints cover protocol metadata, assets, pairs, tokenized-stock discovery, launches, readiness, transactions, stats and revenue state. Production contract addresses remain visible through Fortune status pages and BscScan.