Whitepaper

Rtp.Fun is built around community-led growth: independent alliance communities create, contribute and use a shared platform. Each alliance is a community base, while RtpFam provides the official discussion channel across the ecosystem. Discovery, launch, trading and review support that model.

This is a product thesis, not a verified growth forecast, a performance benchmark, an equity offer or a promise of investment returns.

1. Community-led growth

The model connects five activities: build a community, create useful work, use the platform, sustain its operations and participate in its direction. An alliance provides continuity beyond an individual token launch. Its members can organise content, calls, projects and voluntary tasks together.

Growth must be assessed through genuine participation and confirmed receipts, not inflated member counts or manufactured trading volume. Community ownership of direction does not itself establish legal ownership of the platform.

2. Creators and alliances

Creator earnings belong to the creator, including when the creator also operates Rtp.Fun. A creator can choose to fund tasks for their own community; each task’s rules decide what work is accepted and what it pays.

The season programme records eligible alliance activity and describes how an unlocked amount would be allocated among contributing members, active members and the owner. An accrual, target or estimate does not establish a funded or paid reward. See Season vault.

3. The RTP token

RTP on Solana is a live test token. The previously announced programme uses a snapshot at 00:00 UTC+8 on October 21, 2026 as an eligibility reference for early access and a possible allocation of the official token. Buying the test token is not a claim receipt, a conversion at equal value, equity or a share of platform income.

As of October 24, 2026, airdrop registration is closed and no fundraising round is open. The planned official-token address is not evidence of an active contract or sale. Final eligibility, allocation, chain, launch terms, liquidity treatment and any refund process require a separate published announcement and an available, verifiable flow. This paper does not offer a sale or promise those outcomes. See RTP ecosystem.

An account, token holding or alliance score does not grant platform-management or treasury-signing permissions.

4. The shared workflow

A participant can encounter a token in one tool, launch or trade it in another, and check its outcome elsewhere. Moving between tools creates opportunities to lose context: the network, the selected Wallet, the amount, the fees and the transaction state.

Rtp.Fun brings those steps into a shared interface. The benefit depends on whether each route works and the information stays consistent; a shared screen alone does not prove either.

5. Discovery, issuance, execution and review

Discovery. Signals, Trackers and Pulse present the data their sources provide. Coverage, latency and call quality must be assessed from recorded data rather than assumed from a label.

Issuance. The launch form selects a platform, network, configuration and pair. Preparation capability is checked for that exact route. Launch platforms describes configured mappings, not universal availability.

Execution. Supported trade, swap and tool actions prepare an unsigned transaction for the browser-held Wallet. Automation requires an open browser session, an unlocked Wallet and a valid execution lease.

Review. Transaction status, position data and creator claims help a user check what happened. Missing position data limits profit-and-loss reporting. A submitted hash does not establish confirmation.

6. Custody

Identity providers establish the RTP session. The embedded Wallet holds execution keys and signs locally in the browser. The server prepares unsigned material and relays freshly signed transactions under authorization and byte-validation checks.

Automation stops renewing its execution lease when the browser closes. The server does not take over as an unattended signer. A transaction already sent to the network still needs to resolve; closing the page does not reverse it.

Self-custody leaves responsibilities on the user: protect the device, check the approved action and preserve recovery material. It does not eliminate malicious approvals, software vulnerabilities or market losses. See Security and custody.

7. Measuring speed

An action’s total time includes information arrival, the user’s decision, transaction preparation and network confirmation. A useful benchmark must record the route, network, test conditions and the start and end of each interval.

This document does not publish a verified latency benchmark. Interface shortcuts or fewer steps should not be read as a guarantee of faster network settlement.

8. Correctness

The execution contract distinguishes PENDING, SUBMITTED, CONFIRMED, UNKNOWN and FAILED. An uncertain result is reconciled against network evidence; it is not treated as permission to send a second transaction.

The review, prepared bytes, Wallet signer and authorization must describe the same action. Rates, amounts and recipients must be checked for the selected route. An unavailable number is not assumed to be zero. See Transaction status and Fees.

9. Limits

Rtp.Fun provides tools, not asset management or investment advice. It promises no returns. Creator earnings depend on trading activity, platform configuration and claim rules. Catalog entries, UI controls and main-branch changes do not by themselves prove a deployed or chain-confirmed flow.

10. Development and change records

The Roadmap lists development directions. The Changelog distinguishes released changes from previews. A release does not establish that every transaction route has been exercised on chain.