FOURLABPairing is part of the product.
FOURLAB starts from a different assumption than a fixed-pair launcher: the quote asset can be part of the narrative itself. The interface therefore treats pairAsset as a first-class launch parameter alongside the token name, ticker, image and description.
tokenIdentity,
pairAsset,
narrative,
profile,
wallet
}
From idea to transaction.
The intended production flow is deliberately short. The creator defines the token, selects a pair asset, reviews the full configuration, connects an EVM wallet, and signs the verified Four.Meme launch transaction. The interface should never silently replace the selected pair or request a signature before the configuration is visible.
02 PAIR CONTRACT
03 PAIR VALIDATION
04 LAUNCH PROFILE
05 USER REVIEW
06 WALLET SIGNATURE
07 FOUR.MEME ROUTER
08 REGISTRY OUTPUT
Address-first, validation-second.
The prototype accepts an EVM token address as the pair target. The Pair Inspector can query public DEX information to help the user inspect that address, but public market data is not the same as launch eligibility. A production FOURLAB integration should validate the asset against whatever pair rules the verified Four.Meme router enforces.
What should be validated
Contract address, chain, token metadata, supported-asset status, router compatibility and the exact transaction parameters returned by the official launch path.
User-controlled execution.
FOURLAB connects to an injected EVM wallet and requests BNB Smart Chain when the user chooses to connect. The front end should never ask for a private key or seed phrase. In the current build, connecting a wallet is functional, but preparing a launch only creates a local draft.
chainId: 0x38
custody: none
privateKey: never requested
Every launch should remain explainable.
A production registry should preserve the experiment ID, token address, selected pair, launch profile, transaction hash, timestamp and deployment status. This allows the Explore/Experiments interface to show real launches without fabricating numbers or activity.
The current version stores prepared experiments in localStorage on the user's device and labels them Local draft.
The router is the boundary.
The browser UI should not be treated as the source of truth for launch eligibility. Pair validation, supported launch modes and token-creation rules should be enforced by the verified router or contracts. The interface should display the transaction being signed and avoid arbitrary factory calls.
What works in this build.
The delivered website includes a multi-page FOURLAB interface, responsive Four.Meme-inspired branding, injected-wallet connection, BNB Chain switching, local experiment drafts, a public BSC pair inspector, page transitions and the complete documentation surface.
The site does not claim that the Four.Meme launch router is integrated. To turn the composer into a real deployment interface, the verified router address, ABI, allowed pair rules and launch parameters still need to be supplied.