Compose
Select metadata, supply, allocations, and compatible modules.
TOKEN CREATION INFRASTRUCTURE / SOLANA
Build the asset. Define the rules. Show the execution. A planned platform for programmable token launches on Solana.
Platform in development/ Whitepaper v1.0
Supply is only the beginning. The rules behind a token deserve the same visibility.
Forge is designed to bring token creation, allocation records, vesting, and fee routing into a single configuration workflow. For creators, it means a clearer deployment path. For participants, a consistent way to inspect the rules.
Explore the planned modules01 / COMPOSE
Compose token metadata, supply, allocation addresses, and supported modules in one planned workflow.
PLANNED PLATFORM WORKFLOWSelect metadata, supply, allocations, and compatible modules.
Inspect permissions, vesting, recipients, and expected costs.
Review a short-lived $FORGE fee quote. SOL and liquidity stay separate.
Review wallet-signed transactions with visible recovery steps.
Inspect the registered mint, configuration, and execution history.
Define what eligible, collectible launch revenue does. Each planned module makes its source, authority, and destination explicit.
Modules apply to supported fee sources and venues. They cannot collect fees from unrelated markets. Later modules depend on integration testing and security review.
Launch with no upfront Forge service fee. The planned total trading fee is 1% on bonding curve buys and sells, including the protocol share. Optional advanced access and later governance are planned $FORGE utilities.
$FORGE · Intended SPL standard
0.375% creator / 0.375% Forge / 0.25% protocol. Planned platform revenue budget: ~60% $FORGE buybacks and burns, 40% retained. No upfront Forge launch fee. SOL network fees, account costs, and liquidity funding are separate.
No separate private-sale bucket in the preliminary model.
Supply, allocations, pricing, and authority policies are preliminary. The distribution method, launch price, initial circulating supply, and official mint address remain unresolved in whitepaper v1.0.
The planned architecture connects each launch to its configuration hash, module versions, and control authorities. The registry records facts; it does not endorse a token or its creator.
Read the architecture & security plan ↗Publish upgrade, mint, freeze, vault, and treasury controls.
External security review, published findings, and documented remediation before public deployment.
Expose on-chain references so users can inspect relevant facts independently of the interface.
Progress is defined by acceptance conditions, not launch dates. These are planned stages; completion is not claimed.
Start with the design. Understand the limitations.
Explore the complete platform design, token model, and development milestones in the official whitepaper.
Read the docs VERSION 1.0 / OCTOBER 6, 2026