Technical Architecture

The launch flow continues to use a bonding curve model, where token issuance, early price discovery, and initial liquidity formation are handled at the launch layer.

As trading progresses along the curve, liquidity depth is established onchain before routing expands into broader secondary market access.

What has changed is the default pairing path for permissionless launches.

Instead of routing every launch through $EITHER by default, the launchpad now follows the native-chain route. On Solana, that means launches default to SOL pairs. As the launchpad expands across ecosystems, it can also support other native-chain pairs, including Base-native pairs.

The routing layer is being connected to Jupiter legacy API execution paths so launch pairs can become accessible through a wider range of supported interfaces, terminals, and trading bots. As the model expands across ecosystems, routing follows the same principle: native-chain pairing for permissionless launches, with value flowing back into the wider $EITHER economy through launch activity.

To support discoverability and price integrity, Codex / Defined custom metadata indexing is being used to improve pair recognition, metadata consistency, price visibility, and trading support across external terminals and aggregation surfaces.

This is intended to reduce the visibility gap that often affects newly launched pairs in early market environments.

Each permissionless launch also carries a 0.5% residual fee on volume. That residual accrues toward periodic buyback and burn of $EITHER, allowing launch activity across the platform to strengthen the main token without requiring every permissionless launch to be paired directly against it.

That is the technical logic behind the updated model: keep the bonding curve, use native-chain pairs for permissionless launches, expand routing and visibility through supporting infrastructure, and direct part of launch activity back into $EITHER through the residual fee model.