The rules,
in view.

Introduction

Build the asset. Define the rules. Show the execution.

Forge is designed as a token launch and economic configuration platform on Solana. Creators deploy supported token configurations without an upfront Forge launch fee, attach economic modules, and publish verifiable launch records. The planned platform collects a default 1% fee shared between creator and platform on bonding curve trades. It combines token creation, fee routing, vesting, and execution reporting in a single workflow.

This document communicates the platform design and development roadmap. It does not guarantee token value, investment returns, product availability, or a launch date.

Executive overview

Make token economics understandable.

A token launch involves more than a name and a supply. Creators must decide how tokens are distributed, how liquidity is established, who controls administrative permissions, and where any collected fees go. When those choices are scattered across interfaces and wallets, participants struggle to understand what they are buying.

Forge’s design unifies these choices in a configuration workflow backed by an on-chain registry. Creators can select supported modules, preview their behavior, authorize deployment, and direct users to a public record of the resulting configuration. The target users are token creators, launch service providers, developers, and participants seeking a clearer view of launch rules.

Deployment lifecycle

Initial product scope

The initial release targets standard token creation, transparent allocation records, creator vesting, and fee routing on a supported venue. Advanced modules follow after integration testing and security review. Forge’s deployment registry is intended to record configuration facts; inclusion is not an endorsement of a token or its creator.

Creators gain a reliable way to deploy understandable token economics without an upfront Forge service charge. The default 1% total curve trading fee comprises 0.375% for creators, 0.375% for Forge, and 0.25% for the protocol. Only Forge’s share is platform revenue. Product performance is measured by completed launches, repeat creator usage, supported curve trading activity, and accurate execution accounting.

Economic modules

Defined behavior. Visible destinations.

Modules define what supported, collectible launch revenue does. A module cannot capture fees from unrelated trading venues merely because the token was created through Forge. Every configuration must identify the fee source, collection authority, and destination addresses.

Configuration and execution policy

Each module records an allocation rule, execution threshold, supported assets, authorized actions, and failure behavior. Splits must sum to 100%. Minimum execution thresholds limit disproportionate transaction overhead.

Launch policies are designed to be fixed by default. If a configuration permits changes, the interface must show who can make them, any delay, and the affected parameters. A fixed configuration does not by itself make an upgradeable program immutable; both policy controls and program upgrade authority must be disclosed.

Planned buyback modules enforce maximum spend per interval, a minimum reserve, quote freshness, and slippage limits. Failed execution must leave funds in the vault for a later attempt; it must not redirect them to an undisclosed recipient.

Liquidity additions do not create a price floor. Token burns reduce supply but do not guarantee demand or appreciation. These modules provide allocation and execution functions; they do not provide insurance or guaranteed yield.

Stock pairing

The curve composer offers SOL and nine tokenized stock quotes: TSLAx, NVDAx, SPYx, AAPLx, MSFTx, AMZNx, GOOGLx, METAx and COINx. TSLAx and NVDAx, the initial stock routes, have passed controlled mainnet launch, trading and migration tests; the other seven remain blueprints until release checks pass. Pairing does not back the new coin with shares or make its price track the underlying stock.

The integration verifies issuer identities, Token-2022 programs, scaled UI amounts, pause flags, pool addresses and migration accounts. The compiled revenue module supports fixed stock mints, platform collection, the exact 60/40 split and FORGE/stock CPMM buybacks with atomic burns. Each stock needs an approved matching pool and budget. Stock-revenue buybacks have not yet been tested live and depend on fee collection being activated. Live actions stay disabled until independent review, issuer access controls and end-to-end wallet acceptance are complete.

The $FORGE token

The token within the Forge ecosystem.

Creators are not required to buy or spend $FORGE to pay a launch service fee. The default 1% total curve trading fee comprises 0.375% for creators, 0.375% for Forge, and 0.25% for the protocol, with a planned buyback budget within the platform share. Planned $FORGE utilities include optional advanced access and later bounded governance; neither is a mandatory launch payment.

Bonding curve trading fees

The planned default Forge trading fee is 1% (100 basis points) total on bonding curve buys and sells: 0.375% to the creator, 0.375% to Forge, and 0.25% to the protocol. This allocation adapts StonkFun’s standard fee model [4]. There is no upfront Forge launch service charge or mandatory $FORGE payment. SOL network costs, account funding, and external venue fees are separate.

Within Forge’s platform share, the planned revenue budget is approximately 60% for buying and burning $FORGE and 40% for the operating treasury, adapting the revenue policy in [5]. On a 1 SOL trade, the default 1% fee is 0.01 SOL: 0.00375 SOL to the creator, 0.00375 SOL to Forge and 0.0025 SOL to the protocol. Forge’s 0.00375 SOL is budgeted as about 0.00225 SOL for buybacks and 0.0015 SOL retained. Buybacks execute separately; this budget is not an immediate burn of each trade’s tokens. Amounts received depend on execution costs and prices.

The Forge fee is not the total cost of a trade. External protocol and pool fees, SOL network costs, slippage, and any transfer tax must be displayed separately. After graduation, trading uses the destination pool’s fee rules; the 1% curve fee is not automatically carried over. The integration must validate creator and platform accounting on both sides of migration before release.

Demand and supply dynamics

Demand for $FORGE depends on the usefulness of its implemented ecosystem utilities. Token creation does not require purchasing $FORGE. Optional locks reduce immediately available supply temporarily; they do not eliminate future selling. Trading volume and platform revenue do not guarantee token demand or appreciation.

Implementation status. Upfront deployment pricing is retired. Bonding curve launches, buys and sells, graduation with 100% LP burning, and post-migration trading have passed controlled mainnet tests, with the 0.375% creator, 0.375% platform and 0.25% protocol fee accrual verified. Scheduled buybacks with acquired-token burns and both Liquidity Builder outcomes passed an isolated mainnet test in October 2026. Fee collection and treasury routing are not yet activated, and public launches remain gated pending independent security review and release checks.

Trading fees and later reward features

StonkFun’s docs describe approximately half of its default tier and three quarters of its higher tier going to creators [4], and separate 1% / 3% reward transfer taxes [6]. Forge’s table specifies intended allocations, not a claim of identical on-chain configuration. The creator share can fund the creator wallet or its explicitly configured economic modules. No transfer tax is added to a standard launch or to $FORGE itself.

Token economics

The preliminary supply and allocation model.

The preliminary token model uses ticker $FORGE and a maximum initial supply of 1,000,000,000 tokens. The intended token standard is SPL, with no transfer tax and no freeze authority. The design requires mint authority revocation after the approved supply is minted. Actual supply and authority state will be disclosed and verifiable before public distribution.

The allocation totals 100%. The preliminary allocation includes no separate private-sale bucket. The distribution method, launch price, circulating supply at launch, market-making arrangements, and wallet addresses are unresolved. Therefore, this paper cannot calculate an initial market capitalization or fully diluted valuation.

Release and treasury discipline

Under the planned schedule, team tokens remain locked during the cliff, then vest evenly over the following 24 months. Treasury and incentive releases will be documented on a public calendar. Unused incentive tokens remain in the disclosed allocation; a scheduled budget is not a requirement to distribute it.

Initial liquidity requires both $FORGE and a quote asset. Reserving 150 million tokens does not itself fund a liquid market. The source of SOL or stablecoin funding and the person controlling liquidity withdrawals must be established before launch.

The operating treasury receives its disclosed vested allocation and the retained portion of Forge’s platform revenue. Creator allocations belong to the creator or the launch’s declared module recipients and must not fund platform expenses. Buyback reserves are tracked separately from operating funds. Treasury receipts are not holder dividends or an entitlement to revenue.

The incentive program targets useful templates, verified bug reports, and completed development work. Eligibility will exclude artificial usage intended solely to farm rewards, with criteria published before any program begins.

PRELIMINARY ALLOCATION · NOT LIVE CHAIN DATA

Architecture & security

A modular deployment architecture.

The architecture defines six components: a web composer; a deployment coordinator; a launch registry; per-launch vaults; approved module programs; and an indexer that presents on-chain history. An execution service can submit eligible module transactions, but funds and permissions remain constrained by program rules.

The coordinator validates a configuration and records deployment state. A launch vault must only move funds through actions explicitly permitted by its module. The registry binds each launch to its configuration hash, module version, mint address, and control authorities. The indexer is a convenience layer; users must be able to verify relevant facts independently.

Integration strategy

The fee-model reference is Raydium LaunchLab with CPMM migration, as described in StonkFun’s developer documentation [4]. Forge must use its own platform configuration and fee recipients; StonkFun’s platform IDs and wallets are not Forge infrastructure. Meteora Dynamic Bonding Curve remains an alternative venue, not an enabled integration or confirmed partnership [1]. Each venue needs independent configuration, migration, and fee verification. The approved Forge launch policy is to permanently burn 100% of the liquidity-provider tokens at CPMM graduation: platform share 0%, creator share 0%, burn share 100%. This does not burn the launch token’s circulating supply. There is no Fee Key allocation under this policy. Venue configuration and deployment must be verified before this becomes active.

Solana Token-2022 transfer hooks can invoke custom logic during token transfers [2]. Integration requires clients to supply the hook accounts; missing accounts can cause transfers to fail [3]. The initial release does not depend on transfer hooks. The 1% bonding curve fee, any external venue fees, and SOL network costs must be explained separately; Forge has no upfront launch service charge.

Required controls before public deployment

Authority management. Publish upgrade, mint, freeze, vault, and treasury authorities. Use a disclosed multisig for administrative powers and a planned 72-hour delay for ordinary program upgrades. Emergency powers, if any, must be narrowly specified and visibly reported.

Validation. Test allocation conservation, vesting boundaries, authorization, failed execution recovery, the 100-basis-point fee on buys and sells, fee rounding and destinations, slippage limits, and repeated calls. Simulate user transactions before requesting signatures.

Independent review. Obtain an external security review covering custom programs and integration assumptions. Publish scope, findings, remediation, and deployed program version. An audit is not a guarantee of safety.

Operational resilience. Plan for RPC outages, stale indexer data, executor downtime, and venue migration failures. Display pending versus confirmed states, avoid success claims before confirmation, and bound value exposed during beta.

What a launch receipt proves

The Forge allocation factory and the bonding-curve composer are separate launch paths. Factory supply starts in a program-controlled escrow and can only be delivered through the approved allocations. The creator still needs to complete setup; an abandoned launch can remain pending. After direct delivery, recipients can transfer or burn their tokens. Factory registration records completed setup, not continuing balances or trading revenue.

A curve launch receipt checks a successful confirmed LaunchLab creation transaction against the mint, creator, platform, pool and original curve parameters. Curve launches do not currently combine custom factory allocations, vesting or TreasuryRouter setup. A failed or unrelated transaction is not accepted as a launch receipt. Mainnet activation still requires independent review and live acceptance.

Governance & roadmap

Development milestones.

Public distribution is contingent on a working launch and bonding curve trading path, documented token economics, security review, and deployment readiness. The 1% trading fee must be tested on buys and sells before activation. The roadmap uses acceptance milestones rather than fixed dates. Verified mint and program addresses will be published when available.

Bounded governance

The initial administration model is a disclosed multisig. Token governance is a later milestone, with scope limited to future template approvals, incentive budgets, and bounded deployment parameters. A draft governance specification covers vote accounting, quorum, delegation, proposal eligibility, and execution delays; it must be finalized, implemented and reviewed before activation.

The intended governance scope does not permit holders to rewrite existing fixed launch rules, seize creator assets, or spend isolated launch vaults. Any upgradeable component must disclose the realistic reach of its authority; interface promises cannot override program privileges.

Public reporting

Reporting is designed to include successful launches, distinct creators, repeat usage, trading volume, creator accruals and payouts, platform receipts, buyback reserves and execution receipts, burned $FORGE, module failures, and operational incidents. Curve and post-migration fee counters must remain distinct. Gross trading volume is not platform revenue.

Forge’s long-term objective is a reusable economic configuration layer for token creators. Expansion depends on demonstrated adoption of the basic deployment product, not on token trading activity. Affordability, transparent permissions, and verifiable execution remain the core design principles.

Disclosures & references

Material risks and primary technical references.

Material risks

Adoption and liquidity. Creators may prefer competing products, and trading fees can affect usage. $FORGE may be illiquid, highly volatile, or lose all market value. Neither a fixed supply nor burning provides a floor.

Programs and dependencies. Bugs, compromised keys, malicious upgrades, unsafe configurations, oracle manipulation, or external venue changes can result in lost funds. Execution services and RPC providers introduce availability dependencies.

Distribution and control. Concentrated ownership, vesting releases, treasury selling, and thin initial liquidity can materially affect the market. A configuration registry improves visibility but cannot certify that a creator is honest or that a launch will succeed.

Public-launch obligations. The operator must obtain jurisdiction-specific advice on token distribution, product fees, marketing, taxes, and any applicable restrictions before release. This document makes no determination about the token’s legal classification.

Launch disclosures

Before public distribution, launch disclosures must identify the operator and contributors, development funding, distribution method, initial circulating supply, liquidity funding and control, the 1% bonding curve fee basis and recipients, any venue or post-migration fees, administrative authorities, review results, and verified mint, program, treasury, and vesting addresses.

Version updates will record material changes to the design parameters and development status. Descriptions of planned features must not be interpreted as evidence of deployed functionality. Final on-chain parameters and published authority disclosures take precedence over preliminary numerical examples in this release.

Primary technical references

[1] Meteora official documentation repository: “What is DBC?” github.com/MeteoraAg/docs — Dynamic Bonding Curve overview

[2] Solana documentation: “How to use the Transfer Hook extension.” solana.com/docs/tokens/extensions/transfer-hook

[3] Solana Foundation documentation source: transfer-hook integration. github.com/solana-foundation/solana-com — integration guide

References reviewed October 6, 2026. They establish available technical building blocks, not a Forge integration, endorsement, or completed implementation.

[4] StonkFun developer documentation: https://www.stonkfun.xyz/developers — standard creator shares, higher fee tier, direct launch path, and LaunchLab migration accounting.

[5] StonkFun revenue policy: https://www.stonkfun.xyz/revenue — approximately 60% of platform revenue allocated to platform-token buybacks and burns.

[6] StonkFun rewards documentation: https://www.stonkfun.xyz/rewards — separate holder reward transfer-tax tiers. These sources inform Forge’s planned model; they do not establish a partnership or working Forge integration.