Skip to main content

PINGPONG

PINGPONG (PINGPONG) — 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).

PINGPONG — a DePIN/Compute / Infra project: in the docs it is positioned as a “DePIN liquidity & service aggregator” with the products Multi‑Mining App and Compute Resource Exchange; the Compute Resource Exchange documentation describes onchain forwards and a “trustless on‑chain clearing protocol”. Token: PINGPONG (BEP‑20 on BNB Smart Chain).

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 app/platform for aggregating DePIN mining and a marketplace/protocol for trading “compute derivatives” (onchain forwards).
  • Who it’s for: users who provide compute (multi‑mining); users/investors who buy forwards; developers (a DePIN SDK is claimed as “soon”).
  • Why onchain/token: per the docs, onchain is needed for trustless settlement/clearing of forwards; the PINGPONG token is confirmed onchain, but its utility is not disclosed in the extracted Tier‑1.
  • What you can actually touch (Tier‑1): the PINGPONG App (multi‑mining dashboard) + installation/launch guides in the docs.

How it works (very briefly)

  1. The user does: launches the Multi‑Mining App and connects the available DePIN networks/mining strategies (per the docs).
  2. The system does: helps aggregate/switch mining and track statuses; in parallel, there is the Compute Resource Exchange for onchain instruments (per the docs).
  3. The user gets: “higher efficiency/convenience” for participating in DePIN; or access to products such as onchain forwards.
  4. Where the blockchain is: for forwards, onchain clearing is claimed (smart contracts, locking of funds, default penalties) (docs); the PINGPONG token is confirmed on BSC.
  5. Token role (if any): within the extracted Tier‑1, there are no specifics about the utility of the PINGPONG token.

Quick links: AI thesis fit

Project passport

Field Value
Project name PINGPONG
Also known as (aliases) pingpong.build, PINGPONG App
Logo (logo) —
Token symbol (ticker) PINGPONG
Category Infra | DePIN/Compute
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) —
Project status (status) active
Token (standard) BEP-20
Token contract 0x3ecb529752dec6c6ab08fd83e425497874e21d49
Token model (token_type) unknown
Max supply 1,000,000,000 PINGPONG (BscScan)
Issuance fixed (minted at deploy, per the contract)
Tokenomics (tokenomics, brief) —
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) offline on-device LLM chat
Use‑case (use_case) DePIN compute aggregator + forwards
DecAI Fit — AI thesis fit 4/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 3 / 0 / 3
Last verified 2026-02-11

General project overview

In its documentation, PINGPONG describes itself as a “DePIN liquidity & service aggregator” and tries to lower the barriers to entry into DePIN (mining aggregation) and improve the demand side (a unified dev experience). A separate product, Compute Resource Exchange, describes onchain financial instruments (“yield‑enhanced mining‑backed on‑chain forwards”) with trustless settlement/clearing.

Features/modules

  • Multi‑Mining App: “one‑click” launch/management of several DePIN networks + a changelog of updates (docs).
  • Compute Resource Exchange: onchain forwards with locking of funds and default penalties via smart contracts (docs).
  • AI element: the changelog mentions an offline LLM chat (qwen3/llama3/deepseek) and an “edge AI network” (docs).

Typical scenarios

  • Scenario 1: a user launches the Multi‑Mining App → aggregates participation in DePIN networks and tracks statuses (docs).
  • Scenario 2: a buyer purchases an onchain forward → receives delivery of the asset/compensation per the smart contract rules (docs).
  • Scenario 3: a user uses the offline LLM chat → a private chat locally on the device (docs changelog).

Getting started (wallet/network)

  • What you need: an app/account (for mining/products); for the token — an EVM wallet.
  • Network/chain: the PINGPONG token — BNB Smart Chain.
  • Fees: BSC gas for token operations; fees of the forwards products — per the protocol rules (no specific figures in the docs in the extracted fragment).

Architecture/tech (non‑AI)

  • Components: a desktop app (multi‑mining) + web products; a smart‑contract “clearing protocol” for forwards (docs).
  • Participant roles: miners/issuers (sell forwards), buyers, the platform‑protocol (PINGPONG) (docs).
  • Where logic runs: mining/DePIN operations — offchain; settlement of forwards — onchain via smart contracts.
  • Dependencies: BNB Smart Chain (token); DePIN networks (the list changes with releases).

Token/economics (expanded, no forecasts)

  • Token utility: — (no Tier‑1 description of the PINGPONG token utility was found in the extracted sources).
  • Protocol necessity drivers: —.
  • Who pays fees: users pay BSC gas during onchain operations.
  • Where fees go: to BSC validators (gas).
  • Issuance/burn: the token contract on BSC mints 1B tokens in the constructor (per the code on BscScan).
  • Security/incentive mechanisms: the forwards product describes sellers’ collateral/deposits and default penalties via smart contracts (this is product logic, not token logic).
  • Distribution and token issuance schedule: —.
  • Treasury: —.

Governance

  • Who makes decisions: — (no description of governance/DAO was found in the extracted Tier‑1).
  • How protocol parameters change: —.
  • Where decisions are discussed/made: —.
  • Keys/multisig: —.

Security and incidents

  • Audits: — (no audit report(s) on the protocol/contracts were found in the extracted Tier‑1).
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: counterparty risks for issuers/buyers; the risk of the absence of public addresses of onchain contracts in the extracted fragments of the docs; the utility of the PINGPONG token is also not confirmed.

Project status and timeline

  • Current status: the products are described as working (there are docs and a changelog of the Multi‑Mining App).
  • Key releases/milestones: key changes are recorded in the Multi‑Mining App changelog.
  • Roadmap: https://github.com/users/dev-ping-pong/projects/2

Ecosystem/integrations

  • Integrations: the list of integrated/supported networks and modules changes with Multi‑Mining App releases (see the changelog).
  • Partners: —.
  • Where it’s actually used: — (there is no list of production integrations/clients in the extracted Tier‑1).

AI component of the project

  • What is real AI here? the Multi‑Mining App changelog claims an offline chat with local LLMs (qwen3/llama3/deepseek) and an “edge AI network”/AI agents (as product features).
  • What is truly onchain? the Compute Resource Exchange docs describe a trustless onchain clearing protocol for forwards (smart contracts, locking of funds, automatic execution/default).
  • Why is a token needed? the utility of the PINGPONG token is not confirmed in the extracted Tier‑1 (apart from the fact that the token exists).
  • Red flags (based on the information found): token‑washing risk (no Tier‑1 token utility); AI features are described at the “feature list” level without architecture/metrics; onchain contracts are mentioned without addresses.

DecAI Fit component summary

  • DecAI Fit: 4/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity high 3
Token necessity low 0
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): not applicable: there is a description of AI features in the changelog (AI_1) and a working product (AI_2).
  • Evidence: Tier‑1 — https://docs.pingpong.build/multi-mining-app/change-log
  • Why sufficient / why not (one line): AI_0 is set when AI_1..AI_4 = 0; this is not the case here.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the Multi‑Mining App claims a “fully offline chat” with local LLMs (qwen3/llama3/deepseek) directly on the device.
  • Evidence: Tier‑1 — https://docs.pingpong.build/multi-mining-app/change-log
  • Why sufficient / why not (one line): there is a specific description of an AI function (a local LLM chat) in the Tier‑1 changelog.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): public product documentation (including download/updates) and the app website.
  • Evidence: Tier‑1 — https://docs.pingpong.build/ ; https://www.pingpong.build/
  • Why sufficient / why not (one line): there is a public product and its docs, as well as described features/updates.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: — (there are no benchmarks/quality metrics for the AI functions in the extracted Tier‑1).
  • Context (version/date/how measured): —.
  • Evidence: Tier‑1 — https://docs.pingpong.build/multi-mining-app/change-log
  • Why sufficient / why not (one line): there is a description of features, but without measurable metrics.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): there is no technical description in the extracted Tier‑1 (architecture, model versions/configs, methodology for running local LLMs).
  • Evidence: Tier‑1 — https://docs.pingpong.build/multi-mining-app/change-log
  • Why sufficient / why not (one line): the changelog describes “what was added”, but does not disclose the architecture/model versions.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain
  • Addresses/identifiers: PINGPONG token: 0x3ecb529752dec6c6ab08fd83e425497874e21d49
  • Evidence: Tier‑1 — https://bscscan.com/token/0x3ecb529752dec6c6ab08fd83e425497874e21d49
  • Why sufficient / why not (one line): the address and network are confirmed by the explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: the Compute Resource Exchange describes onchain forwards with settlement via smart contracts and a “ClearingHouseFactory on‑chain contract”.
  • Evidence: Tier‑1 — https://docs.pingpong.build/compute-resource-exchange/yield-enhanced-mining-backed-on-chain-forwards
  • Why sufficient / why not (one line): Tier‑1 explicitly describes the logic of locking funds/execution via a smart contract, not just a token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without the blockchain, trustless settlement/penalties for forwards disappear (locking of funds, automatic delivery/default compensation).
  • Evidence: Tier‑1 — https://docs.pingpong.build/compute-resource-exchange/yield-enhanced-mining-backed-on-chain-forwards
  • Why sufficient / why not (one line): the docs directly describe that settlement and default logic are implemented via the onchain clearing protocol.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, PINGPONG.
  • Evidence: Tier‑1 — https://bscscan.com/token/0x3ecb529752dec6c6ab08fd83e425497874e21d49
  • Why sufficient / why not (one line): the token exists onchain.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): token‑payment utility is not confirmed in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://docs.pingpong.build/
  • Why sufficient / why not (one line): the extracted documentation contains no description of “payment with the PINGPONG token”.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): incentives/collateral specifically via the PINGPONG token are not confirmed in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://docs.pingpong.build/
  • Why sufficient / why not (one line): the docs describe collateral of forwards sellers, but it is not tied to the PINGPONG token in the extracted fragment.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): the governance utility of the token is not confirmed in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://docs.pingpong.build/
  • Why sufficient / why not (one line): there is no Tier‑1 description of governance via the token.
  • 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 assessed without a Tier‑1 description of its function (TK_1..TK_3).
  • Evidence: Tier‑1 — https://docs.pingpong.build/
  • Why sufficient / why not (one line): a confirmed token utility is needed first.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.pingpong.build/ the project’s positioning and products
Tier‑1 https://docs.pingpong.build/compute-resource-exchange/yield-enhanced-mining-backed-on-chain-forwards onchain clearing/settlement logic for forwards (not just a token)
Tier‑1 https://docs.pingpong.build/multi-mining-app/change-log AI features (offline chat with LLMs), the product release history
Tier‑1 https://bscscan.com/token/0x3ecb529752dec6c6ab08fd83e425497874e21d49 the onchain PINGPONG token and the max total supply of 1B

No comments to display

Back to top