RTP ecosystem

RTP connects alliance communities, creator activity and platform revenue. Build your community, contribute useful work and understand which records affect your participation. Solana holder revenue participation belongs to the first phase; it is not reserved for a future EVM token.

Phases

Phase 1 · Solana

Build and participate

Alliances, creators and holders co-build the platform. Holder participation uses platform revenue as its basis; the percentage, qualification thresholds and weight coefficients remain to be defined.

Phase 2 · EVM

Govern the next economy

A different economic direction with its own funding and participation rules. Community governance decides the relationship with the first phase.

1. Build an allianceCreate a community, share calls and develop projects. Recorded activity feeds the alliance's ranking and season records.
2. Participate as a holderSustained holding and verified contribution inform the qualification direction. Balance alone does not establish a high participation tier.
3. Create and support tasksCreator earnings belong to the creator. Voluntary task funding is a separate contribution governed within the community.

Explore the contribution weights, your season estimate or future governance. The App separates Overview, Vault, My rights, Governance and Community.

Overview

Your alliance is your community base. An account may create one ordinary alliance and belong to two ordinary alliances in total, including its own. RtpFam is the official discussion channel and is exempt from that quota and ordinary competition.

The ecosystem flywheel

1. Build togetherAlliances, calls, projects and shared knowledge bring people together.
2. Use the platformEligible real activity produces recorded fees and contribution data.
3. Confirm receiptsConfirmed eligible platform receipts establish the funding basis.
4. Fund the ecosystemOperations, reserves, alliance programs and holder participation have distinct roles.
5. Recognize contributionRanking measures alliance performance; program rules determine funded allocations.
6. Build furtherCommunity support and useful projects encourage renewed participation.

Creator-funded tasks enter this loop separately: creator earnings → funded tasks → verified contribution. Creator receipts are not automatically platform income. Growth is the objective; real activity, costs and receipts determine its results.

Read the displayed records correctly

• Public competition alliances counts listed, active, non-private ordinary alliances and excludes RtpFam.
• RtpFam public members describes membership, not verified contribution.
• Recorded alliance Vault balances are accounting records, not total platform revenue, available cash or payout receipts.
• The overview’s 24h chart connects actual 15-minute observations; other ranges identify their own intervals. Connecting observations does not create missing prices or transactions. Unavailable reads are not shown as zero.

Posts and external token-market volume are not platform receipts. This surface does not publish a total platform-revenue figure.

Vault

Platform revenue and creator earnings are separate. DEV receipts belong to the creator, including when that creator operates RTP. Voluntary creator tasks use their own funding record.

Alliance programs

Eligible fee activity

Confirmed fees and published season rules support alliance accounting and member estimates.

Solana holder participation

Platform revenue

The selected basis is revenue, not profit remaining after costs. The allocation rate and qualification formula are not yet fixed.

Platform sustainability

Operations and reserves

Infrastructure, the technical team and reserve needs belong in the same economic model.

These are parallel uses, not a cost-first waterfall. For a hypothetical budget, A = F × a / 100, H = R × h / 100, and retained revenue is R − A − H − C − M. Here F is the eligible fee basis contained in platform revenue R; C and M are operations and reserves. These symbols do not approve rates or publicly set future expenditure.

An estimate, an unlocked ledger amount and a confirmed payment are different states. A program is shown as open only after funding is confirmed, distribution is reproducible and a recipient receipt exists. A date or target alone does not prove payment. Published timestamps use UTC.

Rights

Solana holders and contributors are part of the first-phase participation model. The direction combines sustained holding + verified contribution, rather than assigning high weight from token balance alone. Exact coefficients, thresholds, settlement coverage and anti-abuse criteria require a published approved policy.

Holder qualification, staking, holder distributions and formal voting remain preparing on this surface. Account connection does not establish qualification; missing qualification records do not establish ineligibility. Participation rights do not grant corporate equity, management or treasury-signing authority.

Weights

There are three distinct systems: alliance ranking, alliance season allocation, and holder qualification. A score is not a payout percentage.

1. Alliance ranking

Recorded input	Ranking weight
Trading profit	30%
RTP volume over the last 7 days	25%
Members who traded during the week	20%
Call quality, from at least 5 calls	15%
Alliance-room launches, plus twice the graduations	10%

Ranking scales qualifying values against the leading alliance. A member’s profit and volume score inputs are capped at 30% of the corresponding uncapped total. These weights decide the leaderboard, not each person’s reward. See the ranking rules.

2. Alliance season allocation

Fee contribution

70%

Split in proportion to each member's eligible fees relative to the alliance's eligible member-fee total.

Active members

20%

Split equally among members who satisfy the season's active-volume requirement.

Alliance owner

10%

Assigned to the owner. An admin role does not receive the owner allocation.

These are the current public reference parameters, not a newly approved policy. The current active-volume reference is $10,000 per member during the season, with at least 5 active members for the alliance payout eligibility check. Follow the rules published for the applicable season if parameters change. Weekly activity used for ranking is different from this season-volume test.

A person can qualify for more than one component: fee share, active-member share and, if the person is the owner, the owner share add together. An admin can earn fee and active-member shares but does not become the owner merely by managing.

3. Holder qualification

The holder direction is sustained holding plus verified contribution. Its exact coefficients and thresholds remain undecided; the 70/20/10 alliance split and the 30/25/20/15/10 ranking weights must not be reused as holder weights.

Calculator

See how your actions affect an alliance estimate

Assume a $2,000 alliance Vault balance, your eligible fees of $1,000 out of $10,000 in eligible member fees, and 10 active members. Assume your season volume is $10,000, meeting the current active-volume reference. These are hypothetical inputs for explaining the published allocation components, not your live ledger. The Vault amount is an illustrative season allocation balance, not total platform revenue.

1. $140 · fee contribution$2,000 × 70% × ($1,000 ÷ $10,000). Your share of eligible fees determines this component.
2. $40 · active membership$2,000 × 20% ÷ 10. This applies because your season volume meets the active-member requirement.
3. $200 · owner component$2,000 × 10%. Add this only if you are the alliance owner, not an admin.

Contributing active member or admin

$180

$140 fee share + $40 active-member share.

Owner with the same contribution and active status

$380

$140 fee share + $40 active-member share + $200 owner share.

Only qualifying recorded activity counts. Before competition opening, earlier fees do not enter the campaign. A personal estimate is not a claim or payment; season eligibility, ledger unlocks and confirmed recipient receipts still apply. See Season vault.

Separate holder and creator-task scenarios

The advanced holder example is independent of the alliance calculation: hypothetical platform revenue $17,940.62 × 5% = $897.031 in holder funding. An invented eligible weight of 5/100 gives $44.85155. This is arithmetic only; 5% and 5/100 are not the RTP holder policy or a qualification result.

A separate voluntary creator-task budget of $3,000, with an illustrative weight of 10/40, gives $750. Its creator and community govern its rules. It does not reduce platform revenue or its retained-budget calculation.

These independent examples must not be added together as total personal earnings. Advanced scenario calculations use decimal-string arithmetic, truncate shares to nine decimal places and reject invalid weights, rates or overspent budgets. They do not claim rewards or submit transactions.

Governance

Phase two develops an EVM economy with its own economic direction. It does not automatically extend Solana percentages or delay first-phase holder participation until EVM exists. Community governance must decide the next phase’s funding, revenue coverage and participation rules.

The published planned EVM reference is 0x00000244a78ADaB235b08c54171ABDFbd49F0000. Its presence in the App is not proof of deployment or tradability. Bridges, supply, migration or conversion, liquidity funding and cross-chain eligibility remain separate governance decisions. A matching address does not unify supply, liquidity, authority or economics. Possible L2/L3 directions remain later options, not automatic entitlements.

Only explicitly authorized accounts may manage settings. Treasury execution retains independent signing and verification controls. Later governance must respect rights earned under an approved published period.

Community

RtpFam is the official discussion channel for the team, builders, holders and contributors. It uses the alliance format without competing in ordinary rankings. Its entry opens the existing alliance page, posts and replies; the preview uses real public cover, avatar and member records.

After deployment, new verified registrations join by default. Existing accounts are not bulk-enrolled. Members may mute or leave; later logins do not silently rejoin exited or removed members. Account-persisted channel mute is separate from device notification-category settings.

Alerts cover newly authorized top-level pins and another author’s reply to your post. Ordinary posts and repeated pins do not create alerts; unmuting does not replay old ones. Community preferences do not hide or acknowledge transaction outcomes requiring review.

Related: Alliances · Fees · Security and custody · Roadmap

Historical market-scale reference for advanced scenarios

For 2025-07-02 UTC, DefiLlama’s Axiom series reports $2,635,681 in user-paid fees and $1,794,062 in retained protocol revenue, after accounting for referrals and cashback. The approximately $1.8M is before operating expenses, not net profit. It is one historical day, not an RTP forecast. The advanced $17,940.62 revenue input is 1% of that scale, not a market-share assumption.

Sources, retrieved 2026-10-10 UTC: Axiom fee terms, DefiLlama Axiom methodology, daily fees series, daily revenue series. Both series use UTC-day timestamp 1751414400.