RSS3
RSS3 — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).
RSS3 — an AI/Data | Infra project that builds a decentralized network for indexing and structuring “Open Information” (social activities, onchain events, RSS/ActivityPub, etc.) and makes this data available via APIs/tools. The network describes a two‑layer architecture: the Data Sublayer (DSL) (indexing/structuring) and the Value Sublayer (VSL) (an L2 layer for staking/rewards/slashing/bridging and for hosting dApps). Token: RSS3 (ERC‑20 on Ethereum; canonical bridged token on VSL).
Disclaimer
Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.
TL;DR (for readers who are not into AI)
- What it is: a “decentralized Google‑like indexer” of open information (social/web/onchain) with an API and a network of nodes.
- Who it’s for: developers of social networks/search/analytics and infrastructure teams that need ready‑made “activity feeds” and open data.
- Why onchain/token: the token is needed to pay for queries to the network and for the participation of nodes/delegators (deposit/staking/rewards/slashing); VSL is the onchain layer of settlement and network rules.
How it works (very briefly)
- The user/developer does: obtains API access and requests “Open Information” (activities/posts/transactions, etc.).
- The network does: RSS3 Nodes index/structure the data (DSL), while Global Indexers coordinate the nodes and provide the DSL API.
- The user gets: structured data for feeds/search/analytics and downstream applications.
- Where the blockchain is: VSL (L2) contains node pools, deposit/staking, rewards distribution and slashing; there is a bridge between Ethereum (L1) and VSL (L2) and a block explorer.
- Token role (if any): per the Tier‑1 tokenomics,
RSS3is used to pay for queries, as a deposit for launching a node, for delegation/entrust and to pay for VSL blockspace.
Quick links: AI thesis fit
Project passport
| Field | Value |
|---|---|
| Project name | RSS3 |
| Also known as (aliases) | RSS3 Network; DSL; VSL; Open Information Layer |
| Logo (logo) | ../assets/136_rss3_logo.svg |
| Token symbol (ticker) | RSS3 |
| Category | AI/Data | Infra |
| Primary chain (chain) | RSS3 VSL |
| Type | EVM |
| Network status | mainnet |
| Consensus (consensus) | L2 (Optimistic Rollup, RSS3 VSL on Ethereum) |
| Launch date (launch_date) | 2022-02-12 (token genesis per the tokenomics) |
| Project status (status) | active |
| Token (standard) | ERC-20 |
| Token contract | 0xc98D64DA73a6616c42117b582e832812e7B8D57F (Ethereum L1) |
| Token model (token_type) | utility (queries + staking + node deposit + slashing) |
| Max supply | 1,000,000,000 RSS3 (max supply) |
| Issuance | year 1 without new issuance; afterwards — 3% annual issuance (Network Rewards) |
| Tokenomics (tokenomics, brief) | payment for queries to the network; deposit ≥ 10,000 RSS3 for a node; staking/rewards + slashing with burn |
| Governance | community governance via the forum + RSS3 Evolution Proposals (REPs) |
| Admins/keys | Safe multisig on VSL (safe.rss3.io is listed in the docs) |
| Audit | — |
| Bug bounty | — |
| Team (team) | — |
| Funding (investors/funding) | — |
| AI component (ai_component) | AgentData (real-time data streams for AI agents) |
| Use‑case (use_case) | indexer/structuring open information |
| DecAI Fit — AI thesis fit | 3/6 — medium alignment with the Decentralized AI thesis |
| DecAI Fit component summary | 1 / 2 / 2 / 3 |
| Last verified | 2026-02-05 |
Links (links_*)
| Type | Link |
|---|---|
| Website | https://rss3.io |
| Docs | https://docs.rss3.io/ |
| GitHub | https://github.com/RSS3-Network |
| Releases / Changelog | https://github.com/RSS3-Network/Node/releases |
| Whitepaper | https://docs.rss3.io/guide/core/whitepaper |
| Roadmap | — |
| Security advisories | https://github.com/RSS3-Network/Whitepaper/security |
| Explorer | https://explorer.rss3.io/ |
| Scan | https://scan.rss3.io/ |
| Contracts | https://docs.rss3.io/guide/vsl/links/contract-addresses |
| Tokenomics | https://rss3.io/mainnet-tokenomics |
| Governance / REP | https://docs.rss3.io/guide/core/governance-and-rep |
| X | https://twitter.com/rss3_ |
| Discord | https://discord.com/invite/rss3-network |
| Telegram | https://t.me/rss3_en |
| Medium | — |
| Audit report(s) | — |
| Bug bounty | — |
| CoinGecko (profile, reference) | https://www.coingecko.com/en/coins/rss3 |
| CoinMarketCap (profile, reference) | https://coinmarketcap.com/currencies/rss3/ |
General project overview
RSS3 positions itself as an Open Information Layer: a decentralized network that indexes and structures open data (including social protocols and onchain activities) and makes it suitable for building applications of the “next Twitter / Google” level, as well as for AI‑oriented scenarios (datasets/AgentData).
In the Tier‑1 documentation, RSS3 Network describes an architecture of two sublayers:
- DSL (Data Sublayer) — nodes index and structure Open Information.
- VSL (Value Sublayer) — an L2 layer (EVM) that contains node/staking pools, rewards distribution rules, slashing, a bridge, and allows the deployment of external dApps.
RSS3 provides developers with the DSL API (via Global Indexers) for retrieving activities/content and the Network Transparency API (NTA) for data on staking/nodes/epochs. For operators there are instructions for deploying and configuring nodes, including an optional AI component that integrates RSS3 AgentData.
Features/modules
- RSS3 Nodes: decentralized nodes that index and structure Open Information (components: decentralized/federated/rss; workers).
- Global Indexers (GI): coordination of nodes + provision of the DSL API and NTA API.
- VSL (L2): staking/deposit/rewards/slashing and a bridge (Explorer + Scan).
- DSL API: endpoints for retrieving activities (by account/network/platform, etc.).
- AgentData + AI component (optional): real‑time data streams for AI agents; integration into an RSS3 Node via the component configuration.
- Open Data datasets: prepared datasets for ML tasks (including a Hugging Face dataset).
Typical scenarios
- Scenario 1 (developer): gets access to the DSL API → pulls activities/content by accounts/networks → builds a feed/search/analytics.
- Scenario 2 (node operator): deploys an RSS3 Node → chooses coverage/workers → receives operation rewards (per the network rewards and request fees model).
- Scenario 3 (delegator): stakes
RSS3in the staking pool of a chosen node or entrusts it to the public good pool → receives rewards/participates in the network economy.
Getting started (wallet/network)
- What you need: for a developer — an HTTP client (cURL/Postman) and access to the DSL API; for an operator — a server/infrastructure for the node; for a delegator — an EVM wallet and
RSS3. - Network/chain: the
RSS3token on Ethereum (L1) and in VSL (L2); node/staking operations are available via the RSS3 Explorer. - Fees: Ethereum/VSL gas for onchain operations (bridge/staking/deposit).
Architecture/tech (non‑AI)
- Components: RSS3 Nodes (DSL), Global Indexers (DSL API/NTA), VSL (L2) contracts (staking/settlement, etc.), Explorer/Scan/Bridge, GitHub repositories (Node/Docs/Whitepaper/REPs).
- Participant roles: node operators, delegators (staking/trust), developers/data consumers, GI as the coordination layer.
- Where logic runs: indexing/structuring — offchain on the nodes; rewards calculations/slashing and pools — onchain on VSL; the token — on Ethereum L1 + bridged to VSL.
- Dependencies: Ethereum L1 (token/bridge contracts), VSL L2, the GI endpoint
gi.rss3.iofor the API, databases (Postgres/Redis) on the node side (per the config).
Token/economics (expanded, no forecasts)
- Token utility: payment for queries to the network; deposit for launching a node (≥ 10,000
RSS3); delegation/entrust; payment for VSL blockspace. - Protocol necessity drivers: the tokenomics describes payment for queries and a mandatory node deposit; the network’s economic model is tied to staking pools/operation pools.
- Who pays fees: applications that make queries to the network, and users/operators for onchain operations (bridge/stake/unstake).
- Where fees go: request fees are distributed into the operation pools of the respective nodes; upon slashing, a share of the tokens is burned (50% of slashed tokens are burned).
- Issuance/burn: max supply 1B; year 1 without new issuance, from year 2 — 3% annual issuance as Network Rewards; slashing leads to the burn of a share of the tokens.
- Security/incentive mechanisms: staking rewards + operation rewards; slashing for poor node performance (demotions/auto‑slashing); redemption takes 30 epochs (~22.5 days).
- Distribution and token issuance schedule: allocation/vesting are described on the mainnet tokenomics page (seed/private/public/team/ecosystem/foundation, etc.).
- Treasury: the allocation includes Foundation/Ecosystem, etc.; details of fund management are not disclosed within this card.
Governance
- Who makes decisions: the community (community‑driven governance) through discussions on the forum and subsequent formalization in REPs.
- How protocol parameters change: changes are proposed on the forum → formalized as RSS3 Evolution Proposals (REPs) → approved by the community.
- Where decisions are discussed/made: https://forum.rss3.io and the REPs repository.
- Keys/multisig: VSL supports Safe multisig; management via
safe.rss3.io(per the docs).
Security and incidents
- Audits: — (no Tier‑1 links to an audit report were found within this card).
- Bug bounty: —.
- Incidents: —.
- Threat model: risks of indexing quality/GI centralization, attacks on incentives/slashing, L2/bridge and VSL smart contract risks.
Project status and timeline
- Current status: mainnet (the Explorer and VSL Scan are available; the mainnet tokenomics is published).
- Key releases/milestones: 2022-02-12 — token genesis (per the tokenomics); current node releases are maintained in GitHub Releases.
- Roadmap: — (a public roadmap document is not recorded in Tier‑1; evolutions proceed via REPs).
Ecosystem/integrations
- Integrations: DSL API (GI endpoint), Explorer/Scan/Bridge, Safe multisig on VSL.
- Partners: — (within this card we record only Tier‑1 integrations/artifacts).
- Where it’s actually used: the public DSL API (docs) and the Explorer/Scan tools demonstrate the availability of the network and its operations.
AI component of the project
- What is real AI here? RSS3 adds an AI‑oriented layer, AgentData (real‑time data streams “tailored for AI agents”), and an optional AI component for the RSS3 Node, but RSS3 Network itself is primarily data/indexing infrastructure (not an “AI model”).
- What is truly onchain? VSL (L2) — staking/pools/bridge/slashing and the Explorer+Scan tools; the contracts are published in the docs.
- Why is a token needed? payment for queries to the network and participation in the node economy (deposit/staking/rewards/slashing).
- Red flags (based on the information found): AI‑washing (medium) (the AI layer = “data for AI” + integrations, without model metrics); onchain‑washing (low‑medium) (there is a full‑fledged L2 layer with rules/slashing); token‑washing (low) (the token is built into query payments and into the node/staking mechanisms).
DecAI Fit component summary
- DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
| Component | Level | Score |
|---|---|---|
| AI reality | low | 1 |
| Onchain necessity | medium | 2 |
| Token necessity | medium | 2 |
| Evidence | Tier‑1 present | 3 |
Details
AI reality
AI_0 — AI intent (Tier‑1 roadmap) (1/0)
- AI_0 (decision): 0
- Claim (one line): RSS3 has AI‑oriented components/integrations (AgentData/AI component), so this is not only an “intent”.
- Evidence: Tier‑1 — https://docs.rss3.io/guide/dsl/agent-data; https://docs.rss3.io/guide/operator/deployment/component/ai
- Why sufficient / why not (one line): Tier‑1 sources describe an existing AI‑oriented layer and the component configuration.
- Conflict note (if any): —
AI_1 — what the AI does (1/0)
- AI_1 (decision): 0
- Claim (one line): in Tier‑1 sources, RSS3 describes “data for AI agents” but does not record its own task/model (inference) as a key component of the protocol.
- Evidence: Tier‑1 — https://docs.rss3.io/guide/dsl/agent-data
- Why sufficient / why not (one line): a data‑stream layer for agents is described, but no specific AI model/function of “what the AI does” inside the network is described → 0.
- Conflict note (if any): —
AI_2 — demos/examples (1/0)
- AI_2 (decision): 0
- Claim (one line): no demonstration of an “RSS3 AI model” specifically as a separate artifact was found; there are examples of AI applications that use RSS3 data.
- Evidence: Tier‑1 — https://docs.rss3.io/guide/ai/chatgpt
- Why sufficient / why not (one line): the GPT page is an example of an application on top of RSS3, not a demo of an AI module of the protocol → 0.
- Conflict note (if any): —
AI_3 — metrics/quality (1/0)
- AI_3 (decision): 0
- Metrics: —
- Context (version/date/how measured): —
- Evidence: Tier‑1 — —
- Why sufficient / why not (one line): there are no Tier‑1 quality metrics for the AI part/models (if any are used).
- Conflict note (if any): —
AI_4 — tech description/architecture/versions (1/0)
- AI_4 (decision): 1
- Claim (one line): the integration of the AI component into the RSS3 Node is described (AgentData endpoint + parameters such as OpenAI/Ollama, etc.), as well as the purpose of AgentData as real‑time streams for AI agents.
- Evidence: Tier‑1 — https://docs.rss3.io/guide/operator/deployment/component/ai; https://docs.rss3.io/guide/dsl/agent-data
- Why sufficient / why not (one line): there is a Tier‑1 technical description of the component and a configuration example.
- Conflict note (if any): —
Onchain necessity
OC_1 — contracts/addresses/chain (1/0)
- OC_1 (decision): 1
- Chain: VSL (L2) + Ethereum (L1, token/bridge contracts)
- Addresses/identifiers:
RSS3ERC‑20 (L1):0xc98D64DA73a6616c42117b582e832812e7B8D57F; bridgedRSS3on VSL:0x4200000000000000000000000000000000000042. - Evidence: Tier‑1 — https://docs.rss3.io/guide/vsl/links/contract-addresses; https://docs.rss3.io/guide/vsl/links/scan
- Why sufficient / why not (one line): the Tier‑1 docs provide contract addresses and official Explorer/Scan links.
- Conflict note (if any): —
OC_2 — onchain beyond just a token (1/0)
- OC_2 (decision): 1
- What useful logic is onchain: staking pools/operation pools, rewards distribution and slashing/settlement on VSL; a bridge between L1 and L2.
- Evidence: Tier‑1 — https://rss3.io/mainnet-tokenomics; https://explorer.rss3.io/; https://docs.rss3.io/guide/vsl/links/contract-addresses
- Why sufficient / why not (one line): the tokenomics and the explorer describe the onchain mechanics of nodes/staking/slashing beyond “just a token”.
- Conflict note (if any): —
OC_3 — onchain is critical (1/0)
- OC_3 (decision): 0
- “Replace the blockchain” test: indexing and the API could work in a centralized way; Tier‑1 evidence of the functional irreplaceability of onchain is not presented.
- Evidence: Tier‑1 — —
- Why sufficient / why not (one line): the criticality of the onchain layer is not proven by a replacement test → 0.
- Conflict note (if any): —
Token necessity
TK_0 — no token (1/0)
- TK_0 (decision): 0
- Claim (one line): the project has a token,
RSS3(ERC‑20 on Ethereum; bridged token on VSL). - Evidence: Tier‑1 — https://docs.rss3.io/guide/vsl/links/contract-addresses
- Why sufficient / why not (one line): the Tier‑1 documentation publishes the token addresses on L1/L2.
- Conflict note (if any): —
TK_1..TK_4 (1/0)
TK_1 — payment for the service (1/0)
- TK_1 (decision): 1
- Claim (one line):
RSS3is used to pay for queries to the network and to pay for VSL blockspace. - Evidence: Tier‑1 — https://rss3.io/mainnet-tokenomics; https://rss3.io/ ($RSS3 section)
- Why sufficient / why not (one line): the tokenomics describes payment for queries with the token and the distribution of request fees.
- Conflict note (if any): —
TK_2 — incentives/collateral/penalties (1/0)
- TK_2 (decision): 1
- Claim (one line): nodes require a deposit (≥ 10,000
RSS3); there are staking rewards and slashing with the burn of a share of the tokens. - Evidence: Tier‑1 — https://rss3.io/mainnet-tokenomics
- Why sufficient / why not (one line): the tokenomics directly describes the node deposit, rewards and the slashing/burn mechanism.
- Conflict note (if any): —
TK_3 — governance (1/0)
- TK_3 (decision): 0
- Claim (one line): the governance structure (forum → REPs) is described, but a direct “token voting” mechanism is not recorded in Tier‑1.
- Evidence: Tier‑1 — https://docs.rss3.io/guide/core/governance-and-rep
- Why sufficient / why not (one line): there is a REPs process, but without an explicit role of
RSS3as a governance token → 0. - Conflict note (if any): —
TK_4 — token is replaceable (1/0)
- TK_4 (decision): 0
- Claim (one line): the Tier‑1 tokenomics establishes
RSS3as the token for paying for queries and as the collateral/staking asset of nodes, to which rewards and slashing are tied. - Evidence: Tier‑1 — https://rss3.io/mainnet-tokenomics
- Why sufficient / why not (one line): if network fees and security/incentives are described specifically through
RSS3, replaceability does not follow from Tier‑1 sources → TK_4 = 0. - Conflict note (if any): —
Evidence (table)
| Tier | Source | What it proves |
|---|---|---|
| Tier‑1 | https://rss3.io/ | Positioning of RSS3 as the Open Information Layer; the role of the token ($RSS3) in queries/node/delegate/blockspace. |
| Tier‑1 | https://rss3.io/what-is-rss3 | Claims about social/search/AI usage contexts and the thesis about open information for AI. |
| Tier‑1 | https://docs.rss3.io/guide/developer/api | Tier‑1 artifact: the DSL API and query examples (gi.rss3.io). |
| Tier‑1 | https://docs.rss3.io/guide/operator | Tier‑1: the structure of an RSS3 Node, components/workers, deployment/management. |
| Tier‑1 | https://explorer.rss3.io/ | Tier‑1 tool: node/epoch/staking operations and a network overview. |
| Tier‑1 | https://docs.rss3.io/guide/vsl/links/scan | Tier‑1: official Explorer/Scan links for VSL (mainnet/testnet). |
| Tier‑1 | https://docs.rss3.io/guide/vsl/links/contract-addresses | Tier‑1: addresses of the token and key contracts on Ethereum (L1) and VSL (L2). |
| Tier‑1 | https://rss3.io/mainnet-tokenomics | Tier‑1: the tokenomics model (queries, node deposit, staking/trust, rewards, slashing/burn, supply/vesting). |
| Tier‑1 | https://docs.rss3.io/guide/core/governance-and-rep | Tier‑1: the governance process (forum → REPs). |
| Tier‑1 | https://docs.rss3.io/guide/dsl/agent-data | Tier‑1: AgentData as real‑time streams for AI agents. |
| Tier‑1 | https://docs.rss3.io/guide/operator/deployment/component/ai | Tier‑1: the AI component and a configuration example of the AgentData integration. |
| Tier‑1 | https://docs.rss3.io/guide/ai/open-data | Tier‑1: open datasets for ML tasks (including an HF dataset, 11M+ posts). |
No comments to display
No comments to display