Launch Twins coordinates one project across Flap.sh and Four.meme without pretending the two markets are the same. One identity enters, two native launches come out, and both can be linked under one verifiable Twin Pair.
Flap and Four grew into separate launch cultures on BNB. That competition is useful, but it forces creators to split distribution at the exact moment attention matters most. Launch Twins turns the rivalry into a routing layer: prepare both sides from one interface and preserve each venue as its own native market.
Same project identity. Different contracts. Different markets. One verified relationship.
Name, ticker, image, description and project links are entered once.
Platform-specific adapters map the shared project into each verified launch interface.
The wallet submits two native launches as closely together as supported by the underlying systems.
Both returned contract addresses can be bound into one public Twin Pair.
Translates approved creator settings into the supported Flap launch call and reads the resulting native contract.
VERIFIED INTERFACE REQUIREDOne creator session, one wallet, shared metadata, platform-aware review.
FRONTEND READY
Builds the supported Four payload while preserving the Four-side market and lifecycle as native state.
VERIFIED INTERFACE REQUIREDCanonical mapping between creator, Flap contract, Four contract and shared metadata hash.
CONTRACT / TBA> project_input ├─ flap_adapter → native_flap_token └─ four_adapter → native_four_token > returned_contracts └─ twin_registry → pair_id > market_rule └─ two_markets / no synthetic merged price_
Future modules stay visibly separate from the live launcher until their mechanics are defined and shipped.
Open the launch console and prepare the Flap and Four twins from one workspace.
Launch Twins does not wrap the two sides into one token. Each deployment remains native to its platform.
The two transactions are coordinated in one creator flow, but each platform still confirms independently.
Once both contract addresses are confirmed, the pair can be registered under one Twin ID.
One page for every verified pair. Two markets stay separate; the pair identity stays shared.
This area activates after the Twin Registry and platform indexers are configured. It will not display invented launches or fabricated market metrics.
Name, ticker, creator, shared metadata hash and permanent Twin ID.
Native Flap contract, market state, activity and lifecycle status.
Native Four contract, market state, activity and lifecycle status.
Registry verification plus side-by-side state. No synthetic combined price.
The registry is the public mapping that says which two contracts actually belong together.
// twinRegistry is not configured // lookup remains read-only until a verified address + ABI are added
Creator + both contract addresses + metadata hash + creation timestamp.
Shared token identity is locked for the session.
Flap-side contract address is returned.
Four-side contract address is returned.
Both addresses are committed as one Twin Pair.
The public Twin ID becomes queryable.
Pair registration must be attributable to the configured creator or authorized launcher flow.
A contract should not silently appear inside multiple unrelated Twin IDs.
The shared identity can be hashed so later UI changes cannot rewrite the original pairing claim.
How the coordination layer is intended to work, what is already functional, and what remains locked.
Launch Twins is designed as a coordination interface for launching one project through two existing BNB launch ecosystems. It does not merge Flap and Four into one exchange and it does not invent a synthetic shared market.
The intended output is two native launches linked by one verifiable pair identity. Each twin can develop its own holders, price, liquidity and lifecycle while remaining visibly connected to its sibling.
Collects shared metadata, wallet state and platform-specific configuration.
Maps approved UI inputs into the verified Flap launch interface.
Maps approved UI inputs into the verified Four launch interface.
Stores or exposes the canonical relationship between both deployed contracts.
Reads public events and market state for the post-launch Twin dashboard.
The frontend intentionally does not guess unknown contract calls. Adapter execution remains locked until verified contract addresses, ABI definitions and supported creation methods are supplied.
Request the browser EVM wallet and switch to BNB Chain.
Enter project image, token name, ticker, description and links once.
Build both platform payloads and show the creator exactly what differs.
Submit the verified Flap and Four creation calls through the connected wallet.
Read the resulting contract addresses from confirmed transactions/events.
Bind both addresses to the original shared metadata and creator.
A Twin ID exists to solve a simple problem: two independent contracts need one public source of truth declaring that they were intentionally launched as a pair.
Launch Twins should distinguish underlying platform fees from any creator-directed or beneficiary revenue supported by the native launch configuration.
If a future Twin Treasury is enabled, the dashboard should preserve source attribution instead of presenting all inflows as if Launch Twins owns platform revenue.
The Connect Wallet button uses the injected EIP-1193 provider exposed by MetaMask-compatible browsers. The frontend requests accounts, then requests BNB Smart Chain mainnet (chain ID 56). If the chain is missing, it can request that the wallet add it.
Before production deployment, verified contract allowlists, transaction simulation/review, error decoding and testnet/mainnet validation should be added.
The launch button remains intentionally non-transactional until the underlying platform interfaces are verified. This is safer than presenting guessed calls as a live launchpad.