Two markets. One rivalry.

RIVALS launches two rival meme tokens through the configured Pons V2 integration. Each token has its own native-ETH bonding curve. The pair shares one timed battle and one ETH reward pot.

Each side also selects a stock reference. The relative return of those reference feeds decides the battle result. A stock reference is used for scoring only: you buy and sell both meme tokens with ETH.

Each rivalry has one round. A market can continue beyond the round, but that does not open a second reward window.

“Awaiting settlement” means the timed round has ended and its final valid snapshot has not yet been accepted. The reward window remains open until the first successful finalization checkpoint.

The launch builder records both token names, symbols, images and descriptions, optional links, scoring references and round settings. The platform uses the configured Pons launch profile; it does not create a custom stock-token trading pool.

The pair launch fee is unavailable until configuration loads, plus any optional initial buys and network gas. The review step uses the selected network’s configuration. It cannot substitute Preview settings for unavailable chain data.

Start and settlement windows are deployment-specific and shown on each rivalry. The round duration begins at the actual successful start transaction.

Pons pricing uses virtual token and virtual ETH reserves. Buying removes tokens and adds net ETH. Selling adds tokens and removes ETH. Virtual reserves are pricing inputs, not withdrawable balances: a sell also requires enough real ETH in the curve.

Curve progress measures real ETH against the configured graduation target. Once graduated, this interface closes curve trading. A migrated market must be verified before it can be offered as a trading destination.

These values describe the selected launch profile, not a universal Pons fee promise. An early-buy fee, when applicable, is included in the current trade quote. The fee policy does not switch merely because a battle becomes active or its clock expires.

“Minimum received” shows the expected protected output for the quoted fill. Near graduation, a buy may only fill the remaining curve supply and refund unused ETH. In that case, the contract’s submitted price limit is scaled to the full requested input; it is not the same quantity as the expected minimum for the actual fill.

The trade review shows expected spend, estimated refund, price impact, slippage and any early-buy fee. The interface refreshes expired quotes before submission. Once a transaction is signed, the native Pons methods enforce its minimum-price bound but do not provide a transaction-expiry parameter. The output and refund are determined when it executes; changing reserves can cause a revert.

Your tokens stay in your wallet. You can buy, sell or transfer throughout the round. Balances in the last finalized block before the scheduled round end determine eligibility. The block timestamp must be strictly earlier than the deadline; blocks at the exact deadline are excluded. Last-minute purchases count only if included before that cutoff. Later transfers cannot create another entitlement. Local mock mode uses the last mined block before the same strict cutoff.

Of the ETH fees actually received from both markets by finalization, 75% is reserved for token holders and 25% is credited to the pair creator. The winning token’s holders share the holder pool proportionally to their eligible snapshot balances. Curve reserves, liquidity pools and other configured reserve addresses are excluded.

If the vault receives 10 ETH, the creator receives 2.5 ETH and holders share 7.5 ETH. A wallet holding 10% of the eligible winning token supply at the cutoff receives 0.75 ETH, subject to integer rounding.

A draw or a void after a valid start splits the holder pool between sides. Side A receives half rounded down and side B receives the remainder. Each side distributes its budget by its own eligible snapshot supply; the two token quantities never share a denominator.

The configured snapshot publisher reconstructs historical balances and publishes a fixed snapshot root onchain. The full wallet and balance list is public for verification. The contract verifies claim proofs against that root but trusts the publisher to supply correct balances; the published root cannot be replaced.

Holder claims remain unavailable until both the holder snapshot is published and fee collection is finalized, even if the result is already recorded. The interface shows this status explicitly. If a battle never validly starts, there is no eligible round; collected fees are credited to the creator.

Claims pay ETH in individual transactions. Integer-rounding dust remains reserved. If a side has no eligible holder supply, its budget remains reserved rather than being divided by zero. Displayed USD values are estimates.

Anyone can start within the start window after the trading warmup if valid reference price snapshots are available. No holder minimum is required. The contract records both reference prices and starts the round.

The larger product wins; exactly equal products are a draw. This compares relative returns without rounding. Displayed percentages are rounded. A winning relative return can still be negative, and a reference victory says nothing about the meme’s trading profit.

Settlement reads the configured feeds onchain. The backend does not supply the winner. Snapshots check the allowed timestamps, positive values, completeness and configured freshness requirements. The first successful valid read inside the allowed window is used; it is not a guarantee of the price at the exact deadline.

Settlement records the result and attempts reward finalization. The reward pool closes only after the curve, graduated-pool and escrow fee ledgers are fully cleared. If collection is unavailable, the recorded result remains fixed and anyone can retry with “Finalize reward pool” after the Pons operator completes any required conversion. The fee window runs from launch to this first finalization checkpoint, including receipts after the round deadline but before finalization. It is not an exact market-close fee cutoff.

An unavailable upstream harvest cannot invent funds or affect your ability to transfer tokens. Finalization credits 25% of received round fees to the creator and reserves 75% for holder rewards. Later receipts belong entirely to creator credit and cannot increase holder claims. If settlement cannot complete within its window, anyone can void under the lifecycle rules.

There is no free creator token allocation in this integration. A creator can choose paid initial buys, later buy on the market, and sell tokens they hold. Initial buys are ordinary curve trades and may incur the applicable launch-time fee policy.

The eligible Pons creator-fee leg from both tokens is routed to the rivalry vault during the open reward window. Protocol or buyback fee portions are not available to distribute merely because a UI displays them.

At finalization, the creator receives 25% of actual round fee receipts regardless of the winner. The remaining 75% forms the holder reward pool. Later receipts are credited entirely to the creator. The creator collects upstream fees into the vault, then uses “Withdraw creator ETH” to transfer their received credit to their wallet. These are two separate actions. Creator credit is separate from reserved holder rewards. A creator who also holds tokens at the cutoff participates in holder rewards under the same rules.

Current configuration: Loading verification status.

Launching on a verified native Pons deployment may make a token discoverable to terminals that index that deployment. It does not guarantee appearance in GMGN’s newest-token column, simultaneous display of both tokens, or support across every terminal. Preview and local mock launches do not establish public terminal indexing.

Robinhood Mainnet has a separate deployed configuration. The settings above describe the selected mode. RIVALS is an independent project; familiar stock names and token symbols do not establish an official affiliation.

• No guaranteed return. Token prices can fall even when a reference wins.
• No guaranteed fee pot. Volume may be low, fees may remain unharvested, and only actual received ETH can be paid.
• No guaranteed liquidity after graduation. Migration and its trading destination must be verified on the selected deployment.
• No guaranteed oracle availability. Stale feeds, pauses, missed windows or RPC failures can produce a void result.
• No guaranteed terminal placement. Indexers control their supported chains, factories, feeds and filters.
• No independent security audit. Preview and local verification do not establish suitability for real funds.