Skip to main content

DePHY

DePHY — 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).

DePHY — an Infra project on BNB Smart Chain, token (symbol: PHY).

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: infrastructure/framework for DePIN applications: an off‑chain messaging network + hardware/SDK + oracle/rollup components (per the project’s description).
  • Who it’s for: developers of DePIN applications and projects that need a messaging/verification layer between devices and blockchains.
  • Why onchain/token: onchain is used as a trust/verification layer and for integrating device data with blockchains; the PHY token exists as an onchain artifact and is used in staking/mining mechanics (DePHY Mining).

How it works (very briefly)

  1. The user does: connects a device/node and publishes messages/data.
  2. The system does: synchronizes nodes and relays messages with verifiability mechanisms (DID/SBT and ZK oracle components are claimed).
  3. The user gets: a data stream available for subscription/integration and infrastructure for DePIN applications.
  4. Where the blockchain is: the project describes data integration and a trusted “chip → blockchain” chain, as well as oracle/rollup infrastructure for connecting to blockchains.
  5. Token role (if any): the token is confirmed via the explorer, but the specific utility requires separate verification per Tier‑1.

Quick links: AI thesis fit

Project passport

Field Value
Project name DePHY
Also known as (aliases) DePHY Network
Logo (logo) ../assets/368_dephy-network_logo.svg
Token symbol (ticker) PHY
Category Infra
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 0xD029B392580d555F35CCa1987f27D248cF883716
Token model (token_type) utility (staking + mining)
Max supply 551,676,377.19503 PHY (Max Total Supply, BscScan)
Issuance —
Tokenomics (tokenomics, brief) PHY/stPHY staking and rewards in DePHY Mining; there is a tokenomic paper (Tier‑1)
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) MCP service mesh for LLM clients
Use‑case (use_case) DePIN messaging/oracle infra
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 1 / onchain_score 3 / token_score 1 / evidence_score 3
Last verified 2026-02-11

General project overview

DePHY describes itself as a “framework to build DePIN apps”: open‑source hardware + SDK + tools, and also as a decentralized low‑latency off‑chain network for DePIN messaging with an emphasis on verifiability and composability. The description mentions DID/SBT for devices and the use of ZK technologies in oracle components. The Tier‑1 documentation also has an AI direction at the level of services for LLM clients (MCP service mesh), but this is not proof of the project’s “own ML model/metrics”.

Features/modules

  • Off‑chain messaging network (claimed): low‑latency node synchronization and message exchange.
  • Hardware + SDK (claimed): an open‑source hardware solution and an SDK/tools for DePIN development.
  • Verifiability layer (claimed): DID/SBT for devices and ZK oracle components.
  • Integration with blockchains (claimed): connecting DePIN data to blockchains, including oracle/rollup infrastructure.

Typical scenarios

  • Scenario 1: a developer connects a device/node → publishes data → an application subscribes to the data stream.
  • Scenario 2: a project uses verifiable messages/oracles to record/verify data on the blockchain.
  • Scenario 3: a node operator deploys a node dApp and executes tasks/the scheduler (per the roadmap).

Getting started (wallet/network)

  • What you need: access to the documentation and the application (links_*: docs/app).
  • Network/chain: in this card the token is confirmed on BSC; per the roadmap/website, Solana and BSC are mentioned.
  • Fees: network fees for onchain operations; the product’s fees/tariffs require separate verification.

Architecture/tech (non‑AI)

  • Components: off‑chain messaging network, nodes, devices/identifiers, oracle/rollup layer, web documentation, open‑source repositories.
  • Participant roles: developers of DePIN applications, device users, node operators.
  • Where logic runs: message exchange and part of the computation — offchain; the anchoring of trust/verifiability and integrations — onchain (per the description).
  • Dependencies: supported blockchains and access to them, development tools/hardware.

Token/economics (expanded, no forecasts)

  • Token utility: PHY/stPHY staking for participation in DePHY Mining and receiving rewards (Tier‑1: docs/app).
  • Protocol necessity drivers: the DePHY Mining and delegation mechanics are described in the project’s Tier‑1 documentation.
  • Who pays fees: users/operators during onchain operations (depending on the network).
  • Where fees go: network fees — to the validators of the respective networks.
  • Issuance/burn: not established per Tier‑1.
  • Incentive mechanisms: staking and rewards (Tier‑1: docs/app).
  • Distribution/vesting: not established per Tier‑1.
  • Treasury: not established per Tier‑1.

Governance

  • Who makes decisions: not established per Tier‑1.
  • How protocol parameters change: not established per Tier‑1 (governance processes are not described in the available Tier‑1).
  • Where decisions are discussed/made: the project’s GitHub/social media (links in links_*); a formal forum/DAO process is not confirmed.
  • Keys/multisig: not established per Tier‑1.

Security and incidents

  • Audits: not established per Tier‑1.
  • Bug bounty: not found per Tier‑1.
  • Incidents: no public postmortems were found per Tier‑1.
  • Threat model (what to consider): supply‑chain risks (hardware/SDK), risks of the oracle/rollup layer and of trust in “chip → blockchain”, vulnerabilities in smart contracts/integrations.

Project status and timeline

  • Current status: active (website/repositories available).
  • Key releases/milestones: not established per Tier‑1.
  • Roadmap: https://dephy.io/roadmap

Ecosystem/integrations

  • Integrations: chains/networks mentioned in the project’s materials (Solana, BNB Smart Chain); developer integrations via the SDK/tools (per the description).
  • Partners: not established per Tier‑1.
  • Where it’s actually used: public data on integrations/production cases is not confirmed by Tier‑1 (apart from the descriptions on the website/roadmap).

AI component of the project

  • What is real AI here? The Tier‑1 documentation has an AI direction at the level of services for LLM clients (MCP), but an “AI component” in the sense of the project’s own model/metrics is not confirmed by Tier‑1.
  • What is truly onchain? the token is confirmed as an onchain artifact; the Tier‑1 product description also claims oracle/rollup components and the “chip → blockchain” chain of trust.
  • Why is a token needed? PHY/stPHY staking and participation in the DePHY Mining mechanics (Tier‑1: docs/app), as well as the existence of the token onchain.
  • Red flags (what to double‑check): the contract addresses of the oracle/rollup components; which data are verified by ZK and exactly how; the tokenomics of MCP Mesh (in the roadmap — in the future).

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 1
  • Claim (one line): The Tier‑1 documentation describes AI services (MCP service mesh) as a direction/component for LLM clients.
  • Evidence: Tier‑1 — https://docs.dephy.io/service-mesh/ai-mcp-services/about-mcp
  • Why sufficient / why not (one line): This records AI intent (infrastructure for LLMs/agents), but does not prove an “own model/metrics” (AI_1..AI_4 remain 0).
  • Conflict note: —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): a description of “own AI features” (model/task/outputs) is not established per Tier‑1.
  • Evidence: Tier‑1 — https://docs.dephy.io/
  • Why sufficient / why not (one line): without a description of AI features we set 0.
  • Conflict note: —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a demo/guide confirming an “own AI component” (model/quality) is not established per Tier‑1.
  • Evidence: Tier‑1 — https://docs.dephy.io/
  • Why sufficient / why not (one line): there is an AI direction (MCP for LLM clients), but without a verifiable AI output/metrics.
  • Conflict note: —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://dephy.io
  • Why sufficient / why not (one line): AI metrics were not found in Tier‑1.
  • Conflict note: —

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

  • AI_4 (decision): 0
  • Claim (one line): a tech description of the AI component was not found per Tier‑1.
  • Evidence: Tier‑1 — https://dephy.io
  • Why sufficient / why not (one line): there is no AI part to describe.
  • Conflict note: —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain
  • Addresses/identifiers: BEP‑20 0xD029B392580d555F35CCa1987f27D248cF883716
  • Evidence: Tier‑1 — https://bscscan.com/token/0xD029B392580d555F35CCa1987f27D248cF883716
  • Why sufficient / why not (one line): onchain fact: the token contract in the network explorer.
  • Conflict note: —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: oracle/rollup infrastructure and the “chip → blockchain” chain of trust for verifiable messages/data.
  • Evidence: Tier‑1 — https://dephy.io
  • Why sufficient / why not (one line): the Tier‑1 product description includes oracle/rollup and the transfer of trust to blockchains.
  • Conflict note: —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: the claimed properties of verifiability/trustless data transfer to blockchains lose their meaning when replaced with a centralized operator.
  • Evidence: Tier‑1 — https://dephy.io
  • Why sufficient / why not (one line): Tier‑1 explicitly claims verifiability and a trustless approach for transferring data to blockchains.
  • Conflict note: —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token (the contract is listed in the explorer).
  • Evidence: Tier‑1 — https://bscscan.com/token/0xD029B392580d555F35CCa1987f27D248cF883716
  • Why sufficient / why not (one line): onchain artifact of the token in the network explorer.
  • Conflict note: —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): A Tier‑1 description of payments with the token for the service is not established.
  • Evidence: Tier‑1 — https://dephy.io/roadmap
  • Why sufficient / why not (one line): the roadmap describes stages and tasks, but without token utility.
  • Conflict note: —

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

  • TK_2 (decision): 1
  • Claim (one line): The Tier‑1 documentation describes PHY/stPHY staking and the receipt of rewards (DePHY Mining).
  • Evidence: Tier‑1 — https://docs.dephy.io/dephy-mining/stake-phy-without-a-node ; https://app.dephy.io/
  • Why sufficient / why not (one line): this confirms incentives/rewards via the token (staking/mining mechanics).
  • Conflict note: —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance via the token is not established per Tier‑1.
  • Evidence: Tier‑1 — https://dephy.io/roadmap
  • Why sufficient / why not (one line): there is no description of a governance process.
  • Conflict note: —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of the token is not established per Tier‑1.
  • Evidence: Tier‑1 — https://dephy.io/roadmap
  • Why sufficient / why not (one line): a tokenomics specification is needed.
  • Conflict note: —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.dephy.io/service-mesh/ai-mcp-services/about-mcp AI intent: DePHY Service Mesh (MCP endpoint) for LLMs/agents and integrations with tools.
Tier‑1 https://dephy.io Tier‑1 description of the DePIN infra, verifiability (DID/SBT, ZK in oracles) and integrations with blockchains
Tier‑1 https://docs.dephy.io/other-resources/papers Whitepaper + Tokenomic paper (Tier‑1 documents of the project).
Tier‑1 https://app.dephy.io/ DePHY Mining: the PHY/stPHY staking interface, nodes/delegation/mining (Tier‑1 “what you can touch”).
Tier‑1 https://dephy.io/roadmap Tier‑1 roadmap for network releases/stages (devnet/mainnet‑beta, MCP mesh)
Tier‑1 https://github.com/dephy-io Tier‑1: the existence of the organization’s open‑source repositories
Tier‑1 https://bscscan.com/token/0xD029B392580d555F35CCa1987f27D248cF883716 onchain fact: the token contract
Tier‑2 https://www.coingecko.com/en/coins/dephy-network reference token card (aggregator; not proof of technology)
Tier‑2 https://coinmarketcap.com/currencies/dephy-network/ reference token card (aggregator; not proof of technology)

No comments to display

Back to top