TRND.fun DocsProduct overview
VIRAL INTELLIGENCE PROTOCOL

Internet attention,
mapped to markets.

TRND.fun detects what the internet is beginning to care about, scores the event, matches its narrative to relevant real-world assets and opens a path to launch that moment as an onchain market on Robinhood Chain.

Current product status

TRND.fun is a Robinhood Chain testnet beta. Public signals, confirmed launches, trades, candles and holder counts come from backend or chain data. Documentation examples are illustrative and never enter operational feeds.

01

How it works

TRND.fun combines a scanner, an intelligence layer and a launch engine in one continuous workflow.

SCAN

Monitor X, TikTok, Instagram, YouTube and news for emerging or high-authority events.

SCORE

Measure velocity, acceleration, anomaly, reach, authority, novelty and spread.

MATCH

Rank four currently enabled RWA pair assets with independent relevance scores.

LAUNCH

Configure a token, sign with a wallet and permanently connect the market to its origin.

INTERNET → VIRAL EVENT → SCORE → RWA MATCH → LAUNCH → MARKET
02

Core concepts

The system is organized around concrete source events rather than generic token ideas.

Viral EventOne specific source item—a tweet, TikTok, Instagram post, YouTube video or news object—with a stable internal identity.
NarrativeThe concise cultural or financial story that explains what the event means and why it may matter.
Pair AssetThe actual asset against which the launched token trades—not a decorative category label.
ProvenanceThe permanent relationship between the original source, detection data, score at launch, selected pair and resulting token market.
03

The Viral Engine

The engine looks for two different kinds of opportunity. Both can produce valid signals.

TYPE A

Emerging momentum

Content is accelerating abnormally relative to its recent history or the source account’s baseline—even before it reaches mainstream scale.

TYPE B

High-signal source

A major creator, CEO, celebrity, institution or public figure posts something new. Source authority can make the event important before conventional virality appears.

Detection principles

Exact duplicates use a normalized platform + source_post_id identity.
Cross-platform confirmation increases confidence but is not required.
Related posts may remain separate events while being linked under one narrative.
Production scores come from repeated metric snapshots, not a single static view count.
04

Viral Score

Every accepted event receives a 0–100 score designed to be understandable at a glance and explainable in detail.

Component
VelocityHow quickly views, mentions and interactions are growing.
AccelerationWhether the rate of growth is itself increasing.
Engagement anomalyPerformance versus the source account’s normal baseline.
ReachCurrent and estimated audience exposure.
Source authorityThe influence, history and relevance of the source.
Cross-platformEvidence that the narrative is spreading elsewhere.
Novelty & persistenceHow new the event is and how likely it is to endure.
Explainable, not absolute

The score is a ranked intelligence signal—not a guarantee of future attention, token performance or financial return. Model and feature versions should be stored with every published score.

05

AI RWA matching

TRND.fun asks which real-world asset the narrative belongs with, then ranks only pair assets that are currently enabled by launch infrastructure.

Example · NVIDIA event
NV
NVDA
NVIDIA
91%
AM
AMD
Advanced Micro Devices
74%
QQ
QQQ
Nasdaq-100 ETF
58%
MS
MSFT
Microsoft
41%

Independent scores

Scores do not form a portfolio and never need to total 100%.

Browse all active pairs →
Named companies and products receive direct relevance.
Peers, sectors and broad-market assets can receive secondary relevance.
The user may ignore all four recommendations and browse the current pair universe.
The application must never fabricate a symbol or permanently hardcode a pair count.
06

Canonical launch path

Every launch begins with stored source provenance and ends with a wallet-confirmed market.

LIVE SOURCE

Launch from a signal

Open an available Viral Event, review its intelligence, choose an enabled pair, configure the token and sign the launch.

ADMIN SOURCE

Add then launch

An operator can add a source post manually in Admin. Once stored and scored, that post follows the same canonical launch path as provider-ingested content.

07

Launch lifecycle

One exact Viral Event can be launched once. A temporary reservation prevents two wallets from winning the same event simultaneously.

01
AVAILABLE

The event can enter Launch Studio.

02
RESERVED

A short launch lock belongs to one wallet.

03
LAUNCHED

Confirmed onchain and permanently linked.

If the wallet rejects, the transaction fails or the reservation expires, the event returns to available. The permanent lock happens only after confirmed transaction state—not when a frontend button is pressed.

08

Market provenance

Markets launched from signals retain a verifiable record of where the idea came from and what the system knew at launch time.

Viral Event ID
Platform + source post ID
Original source URL
Source account
Detected timestamp
Viral Score at launch
Selected RWA pair
AI match score
Launcher wallet
Token address + transaction hash
09

Trading fee & distribution

Every token market created through TRND.fun uses a 1% base trading fee. That fee is split across creators, recurring creator incentives, operations and the TRND token economy.

50%
Creator

Paid to the creator associated with the market.

20%
Daily creator rewards

Funds the daily reward pool for top-performing creators.

10%
API, team & infrastructure

Supports data providers, AI calls, engineering and operations.

20%
TRND buyback

Reserved for manual, multisig-controlled TRND token buybacks according to protocol policy.

1% TRADE FEE × 100% = 50% + 20% + 10% + 20%
Example

If a trade generates $1.00 in base trading fees, $0.50 goes to the creator, $0.20 to daily creator rewards, $0.10 to operations and $0.20 to the manual TRND buyback treasury.

10

Creator rewards

Creators participate in two distinct incentive lanes: direct market fees and a competitive daily reward pool.

Direct creator share50% of the trading fee generated by markets connected to that creator.
Daily rewards pool20% of the trading fee funds rewards for the top five creators under the active ranking policy.
Creator profileA transparent view of launches, volume, fees earned, reach, performance and the markets connected to the creator.
Ranking policy

Exact ranking weights, eligibility, anti-manipulation rules, claim windows and payout timing must be published before rewards become live. Prototype leaderboard values are simulated.

11

TRND buyback

Twenty percent of base-fee revenue is reserved for manual, multisig-controlled TRND token buybacks, connecting market activity to the platform token economy.

Production documentation must identify the buyback wallet or contract, execution cadence, eligible venues, slippage controls, transaction records and whether purchased tokens are burned, held or distributed. Until those rules and contracts are finalized, the interface should describe this allocation as a protocol policy—not claim completed onchain execution.

12

Event states

Status communicates where an event sits in both the attention lifecycle and launch lifecycle.

NEWEARLYHEATINGBREAKINGVIRALCOOLINGLAUNCH PENDINGLAUNCHED

Launched events are never removed from the timeline. Their primary action changes from launch to view market, preserving historical context.

13

Infrastructure

The consumer experience belongs to TRND.fun; launch preparation and onchain execution sit beneath it.

01TRND.fun interface
02TRND.fun backend
03Launch infrastructure
04Connected wallet
05Robinhood Chain
Pair assets and launch configuration are synchronized dynamically.
Prepared transaction data is passed to the user’s wallet for approval.
Confirmation from chain/API state—not optimistic UI—finalizes a launch.
14

Security principles

Wallet custody, API secrecy and authoritative launch state are non-negotiable boundaries.

Never request or store a private key.
Keep launch-provider keys server-side.
Validate event and reservation ownership.
Validate pairs against current configuration.
Use idempotency for launch preparation.
Confirm transaction state before LAUNCHED.
15

Frequently asked questions

READY TO EXPLORE?

Watch culture move in real time.

Open Live