Skip to main content

XO Protocol

XO Protocol — 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).

XO Protocol — a project on the Cyber L2 network, token (symbol: XOXO).

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: an AI‑powered social protocol / application (matching + chat AI tools), with onchain components on the Cyber L2 network (see whitepaper).
  • Who it’s for: application users; also dApps/partners who want to use anti‑fraud/verification and the social layer (as claimed in the whitepaper).
  • Why onchain/token: the Tier‑1 whitepaper specifies onchain activities and contract addresses on Cyber L2; in Tier‑1 sources, the $XOXO token is mentioned as rewards/payment for individual actions inside the product (see <details>).
  • What you can actually touch (Tier‑1): download/open the application (see App / Demo in links_*).

How it works (very briefly)

  1. The user does: uses the product/scenario described in the project documentation (whitepaper).
  2. The system does: executes the project logic; some artifacts are associated with the Cyber L2 network (see whitepaper).
  3. The user gets: a result in terms of the product (not detailed in this card without extracting specific quotes from Tier‑1).
  4. Where the blockchain is: onchain activities and contracts on the Cyber L2 network (see Explorer / whitepaper).
  5. Token role (if any): the token exists; the necessity is not established (conservatively).

Quick links: AI thesis fit

Project passport

Field Value
Project name XO Protocol
Also known as (aliases) XO
Logo (logo) ../assets/472_xo-protocol_logo.png
Token symbol (ticker) XOXO
Category AI/Other | Infra
Primary chain (chain) Cyber L2
Type EVM
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) —
Token contract —
Token model (token_type) utility (payments + rewards)
Max supply —
Issuance —
Tokenomics (tokenomics, brief) In Tier‑1 sources, the $XOXO token is mentioned as rewards/payments in the product; issuance/model parameters are not confirmed by Tier‑1 in this card.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI matchmaking + AI chat assistance (agents)
Use‑case (use_case) social/dating (matching + chat)
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 2 / token_score 2 / evidence_score 3
Last verified 2026-02-11

General project overview

In Tier‑1 sources (official website + whitepaper), XO Protocol is positioned as an AI‑powered matchmaking social protocol/application that combines AI assistants (including AI agents for chat) and Web3 components for verification/anti‑fraud and “tokenized incentives”. The whitepaper also lists onchain activities and contract addresses on the Cyber L2 network.

Features/modules

  • Documentation/whitepaper (Tier‑1): a link to the project whitepaper (see links_*).
  • Onchain artifacts (Tier‑1): the addresses of the XO protocol contract and XOUL (SBT) on the Cyber L2 network (see whitepaper/Explorer).
  • Social channels (Tier‑1/2): X/Telegram/Discord for communication and updates (as context; claims require Tier‑1).

Typical scenarios

  • Scenario 1: a user reads the whitepaper → understands the purpose of the project and its user flow.
  • Scenario 2: checking the onchain part: viewing onchain activities and contracts in CyberScan (see links_*).
  • Scenario 3: monitoring project updates via the official channels (X/Telegram/Medium).

Getting started (wallet/network)

  • What you need: you can start with the website/whitepaper (see links_*); for onchain operations — an EVM wallet.
  • Network/chain: Cyber L2.
  • Fees: network fees apply to onchain operations (if you perform them).

Architecture/tech (non‑AI)

  • Components: the application + onchain activities/contracts on Cyber L2 (the addresses are given in the whitepaper).
  • Participant roles: users/integrators and the project team/contributors.
  • Where logic runs: the onchain part — Cyber L2 (see the addresses/activities in the whitepaper); the AI/chat logic is generally offchain.
  • Dependencies: Cyber L2 infrastructure (explorer) and the application infrastructure.

Token/economics (expanded, no forecasts)

  • Token utility: per Tier‑1 sources, $XOXO is used as rewards and as the unit of payment for individual actions/features (example: Paid DM in the UI on the website).
  • Protocol necessity drivers: Tier‑1 describes tokenized incentives and the use of $XOXO in the product; at the same time, issuance/model parameters and “why it cannot work without the token” are not recorded in this card without a separate Tier‑1 text.
  • Who pays fees: if onchain transactions are performed — the transaction initiator pays the fees (general principle).
  • Where fees go: network fees belong to the network; separate protocol fees are not established per Tier‑1.
  • Issuance/burn: not established per Tier‑1.
  • Security/incentive mechanisms: not established per Tier‑1 (in this card, apart from the general mention of incentives).
  • Distribution and token issuance schedule: not established per Tier‑1.
  • Treasury: not established per Tier‑1.

Governance

  • Who makes decisions: not established (in this card there is no Tier‑1 description of a formal governance model).
  • How protocol parameters change: not established.
  • Where decisions are discussed/made: public channels — X/Telegram/Discord (see links_*).
  • Keys/multisig: not established.

Security and incidents

  • Audits: not established (there is no link to a report in links_*).
  • Bug bounty: not established.
  • Incidents: not established.
  • Threat model: typical risks include smart contract risks and a mismatch between claims and verifiable artifacts; separate verification is required.

Project status and timeline

  • Current status: active (there is a website/whitepaper/social channels; without claims about activity metrics).
  • Key releases/milestones: not established.
  • Roadmap: published in the project documentation (see links_*).

Ecosystem/integrations

  • Integrations: not established (in this card).
  • Partners: not established (in this card).
  • Where it’s actually used: the application is publicly available (see App / Demo); other cases are not listed in this card.

AI component of the project

  • What is real AI here? Tier‑1 sources describe AI‑powered matchmaking and AI assistants (AI agents) in the product.
  • What is truly onchain? the Tier‑1 whitepaper lists onchain activities and addresses on the Cyber L2 network (including the XO protocol contract and XOUL SBT).
  • Why is a token needed? Tier‑1 sources mention $XOXO as rewards/payments in the product; the “protocol inevitability” of the token (why it cannot be done otherwise) is not proven in this card.
  • Red flags (based on the information found): substitution of product metrics (downloads/tx) for AI quality metrics (AI_3=0); the absence of a Tier‑1 specification of tokenomics/issuance in one place.

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
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): AI is described in Tier‑1 as part of a working product (not only as a “plan without implementation”).
  • Evidence: Tier‑1 — https://docs.xoapp.co/xo-whitepaper ; https://www.xoapp.co/
  • Why sufficient / why not (one line): AI_0 records intent without proof; here there is a Tier‑1 description of specific AI features.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The project describes AI‑powered matchmaking and AI‑assist/agents for chat (for example, AI bartender / wingmen).
  • Evidence: Tier‑1 — https://docs.xoapp.co/xo-whitepaper ; https://www.xoapp.co/
  • Why sufficient / why not (one line): Tier‑1 sources directly describe what the AI part of the product does.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): There is a publicly available entry point for installing/using the application (download link).
  • Evidence: Tier‑1 — https://page.rooit.net/link/xoappwebsite ; https://www.xoapp.co/
  • Why sufficient / why not (one line): This is a reproducible demo surface and it is synchronized with links_*/Evidence/TL;DR.
  • 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): Tier‑1 sources contain product metrics (downloads/tx), but no reproducible quality metrics of the AI models/agents.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): The whitepaper has an architecture section (AI + Web3 components; onchain activities and addresses).
  • Evidence: Tier‑1 — https://docs.xoapp.co/xo-whitepaper/architecture
  • Why sufficient / why not (one line): The architecture section provides sufficient tech context at the level of components/network/addresses.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Cyber L2
  • Addresses/identifiers: XO protocol contract: 0x84583e7d2d92d87d5b3bac850ab4bad37ae568e8; XOUL (SBT): 0x85eee73d0ebf017f445eb3fb0c5438d8fb47315d
  • Evidence: Tier‑1 — https://docs.xoapp.co/xo-whitepaper/architecture ; https://cyberscan.co/address/0x84583e7d2d92d87d5b3bac850ab4bad37ae568e8
  • Why sufficient / why not (one line): The Tier‑1 whitepaper publishes the network and the addresses; the explorer allows verifying the onchain activities.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: decentralized verification / onchain activities (including XOUL SBT) as part of the anti‑fraud and social layer.
  • Evidence: Tier‑1 — https://docs.xoapp.co/xo-whitepaper/architecture
  • Why sufficient / why not (one line): The whitepaper describes the onchain usage not just as “token issuance” but as a functional layer (verification/activities).
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: not established.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): OC_3=1 requires an explicit argument and a source.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): Tier‑1 sources mention the $XOXO token (rewards/payments), so “no token” is incorrect.
  • Evidence: Tier‑1 — https://www.xoapp.co/ ; https://docs.xoapp.co/xo-whitepaper
  • Why sufficient / why not (one line): Official sources directly mention $XOXO as the product token.
  • 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): The product describes paid actions/features denominated in $XOXO (for example, Paid DM).
  • Evidence: Tier‑1 — https://www.xoapp.co/
  • Why sufficient / why not (one line): Tier‑1 shows the payment/cost of features in the token, which corresponds to a pay‑for‑service signal.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): The official website describes tokenized incentives: earn $XOXO rewards via matching/chatting/companionship.
  • Evidence: Tier‑1 — https://www.xoapp.co/
  • Why sufficient / why not (one line): This is a direct Tier‑1 description of incentives/rewards in the token.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): In this card, no Tier‑1 governance mechanism was found where $XOXO is a mandatory key of governance.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): 1 requires an explicit voting/governance mechanism via the token and a Tier‑1 source.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability of the token is not established (no Tier‑1 argument “it can be replaced without loss of meaning”).
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): 1 requires a specific conclusion and a source.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.xoapp.co/xo-whitepaper Tier‑1 description of the product and the AI/Web3 intent.
Tier‑1 https://docs.xoapp.co/xo-whitepaper/architecture Tier‑1: onchain activities and contract addresses (Cyber L2), as well as the AI+Web3 linkage.
Tier‑1 https://www.xoapp.co/ Tier‑1: AI‑powered matchmaking; earn $XOXO rewards; examples of pay‑in‑token (Paid DM).
Tier‑1 https://page.rooit.net/link/xoappwebsite What you can touch: download/entry point of the application (AI_2 sync).
Tier‑1 https://cyberscan.co/address/0x84583e7d2d92d87d5b3bac850ab4bad37ae568e8 Onchain fact: the address of the XO protocol contract on Cyber L2 (OC_1).
Tier‑2 https://www.coingecko.com/en/coins/xo-protocol Reference profile of the token/project (context).
Tier‑2 https://coinmarketcap.com/currencies/xo-protocol/ Reference profile of the token/project (context).

No comments to display

Back to top