Skip to main content

Datagram

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

Datagram — a DePIN/Infra / Networking / AI project: a “Global Hyper Fabric Network” for real‑time connectivity and the deployment/scaling of DePIN networks. The documentation describes architectural layers (Node Network, DCS, Hyper Network Layer) and reward mechanics; token: DGRAM (the token contract is confirmed on BNB Smart Chain; the whitepaper also describes DGRAM as an ARC‑20 on Avalanche and tokenomics with a max supply of 10B).

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 infrastructure network/platform for connectivity, data transmission and the provision of resources (bandwidth/compute/storage) for applications and DePIN.
  • Who it’s for: Web2/Web3 businesses, DePIN projects (existing and new), node operators/resource providers.
  • Why onchain/token: onchain is used for the incentive model and for the automation of rules/payouts; DGRAM is described as a utility token for payments and governance, as well as the unit into which reward points are converted (per the whitepaper).

How it works (very briefly)

  1. The user does: connects Datagram via API/SDK or deploys/runs a node as an operator.
  2. The system does: routes traffic and allocates resources via nodes (Node Network) and the DCS layer; the Hyper Network Layer is claimed to be AI‑driven coordination for load balancing/traffic routing.
  3. The user gets: connectivity/resources for real‑time applications and DePIN networks; the operator receives a reward that depends on uptime/latency/usage.
  4. Where the blockchain is: in the whitepaper, the blockchain is used for onchain incentives and smart‑contract automation; the DGRAM token exists onchain (the contract is confirmed on BscScan).
  5. Token role (if any): DGRAM is described as a payment+governance token; reward points ($UDP/$TCP/$AI) are converted into DGRAM within the emissions model (per the whitepaper/Rewards docs).

Quick links: AI thesis fit

Project passport

Field Value
Project name Datagram
Also known as (aliases) Datagram Network, DGRAM
Logo (logo) ../assets/262_datagram-network_logo.svg
Token symbol (ticker) DGRAM
Category DePIN/Infra | Networking | AI
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) — (not found in the extracted Tier‑1)
Project status (status) active
Token (standard) BEP-20
Token contract 0x49c6c91ec839a581de2b882e868494215250ee59
Token model (token_type) utility (governance)
Max supply max supply 10,000,000,000 DGRAM (per the whitepaper); the onchain max total supply on BscScan is shown as 2,381,739,902.618031 DGRAM (a version/network difference is possible)
Issuance issuance per the whitepaper: max supply 10B; daily emissions depend on the latent supply (Latent Supply × 0.125%)
Tokenomics (tokenomics, brief) distribution per the whitepaper: 50% Full Core Operators; TGE total supply 5.75B; the emissions formula and checkpoints are described in the whitepaper.
Governance governance is described in the whitepaper (section 7), implementation details/addresses are not established per Tier‑1
Admins/keys the token contract uses AccessControl (DEFAULT_ADMIN_ROLE, MINTER_ROLE, BURNER_ROLE) and an optional supplyCap
Audit — (no public audit was found in the extracted Tier‑1)
Bug bounty — (not found in the extracted Tier‑1)
Team (team) — (no Tier‑1 confirmation found)
Funding (investors/funding) — (not found in the extracted Tier‑1)
AI component (ai_component) AI-driven traffic routing + load balancing
Use‑case (use_case) DePIN connectivity + bandwidth/compute/storage
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 2 / 3 / 3
Last verified 2026-02-11

General project overview

Datagram describes itself as a “DePIN baselayer” and a “Global Hyper Fabric Network” that pools idle bandwidth/compute/storage into a global decentralized network for modern real‑time applications (video communication, games, AI/ML, CDN, etc.). The documentation identifies groups of clients: existing DePIN networks, new DePIN projects and Web2/Web3 businesses, which are offered integration via API/SDK with a “Web2‑like experience”.

Internally, Datagram describes an architecture of several layers: Node Network, Fabric Networks, Core Substrate (DCS) and Hyper Network Layer, where the latter is claimed to be AI‑driven coordination for routing/load balancing/resource allocation.

Features/modules

  • Hyper Network Layer: AI‑driven coordination for traffic routing, load balancing and resource allocation.
  • Datagram Core Substrate (DCS): a connectivity layer for integrating DePIN networks and coordinating resources; integration with the NOC for monitoring and reward distribution.
  • Node Network / Cores: distributed nodes (Datagram Cores) that participate in routing/validation/data transmission.
  • Rewards: phased rewards: points (Alpha Testnet) → token rewards $DGRAM (Mainnet), with checkpoints (uptime/latency/usage).

Typical scenarios

  • Scenario 1: a business integrates Datagram via API/SDK → uses decentralized connectivity/resources without the need to “deploy its own blockchain”.
  • Scenario 2: an operator deploys a node (Full Core) → maintains uptime/latency → receives reward points and/or DGRAM rewards per the emissions model.
  • Scenario 3: a DePIN project connects via DCS → gets access to bandwidth/compute/storage and AI optimization of routing.

Getting started (wallet/network)

  • What you need: for a node operator — an account/access to the dashboard and infrastructure (hardware+internet); for onchain actions with the token — an EVM wallet.
  • Network/chain: the DGRAM token is confirmed on BNB Smart Chain; in the whitepaper, DGRAM is described as an ARC‑20 on Avalanche.
  • Fees: BNB Chain gas for transfers/interactions with the DGRAM contract; the rewards model also mentions fees for custodial wallets (in the whitepaper).

Architecture/tech (non‑AI)

  • Components: Node Network (cores), DCS, NOC (monitoring/rewards), Hyper Network Layer; integration via API/SDK.
  • Participant roles: business clients, DePIN projects, node operators (Full Core / Partner Core), testnet participants, referrers.
  • Where logic runs: the routing/resource network — offchain node infrastructure; token/reward accounting and the points→DGRAM conversion — described as onchain mechanics in the whitepaper.
  • Dependencies: blockchain infrastructure (described as blockchain‑agnostic), plus an oracle for the 7‑day average price (the whitepaper mentions a “CoinGecko Oracle” for the DATA mechanics).

Token/economics (expanded, no forecasts)

  • Token utility: in the whitepaper, DGRAM is described as the primary utility token for payments and governance; reward points ($UDP/$TCP/$AI) are converted into DGRAM at the daily settlement.
  • Protocol necessity drivers: DGRAM is embedded in the incentives model (operators receive points and convert them into DGRAM), as well as in the payments model (via DATA, which is generated by burning DGRAM).
  • Who pays fees: network gas (e.g., BNB Chain for BEP‑20) for token transfers; the whitepaper also mentions fees for custodial wallets for transfers/processing.
  • Where fees go: network gas — to the BNB Chain validators; an internal custodial wallet fee is mentioned, but its distribution is not disclosed in the extracted fragments.
  • Issuance/burn: whitepaper: DGRAM max supply 10B; initial total supply at TGE 5.75B. Emissions: Daily Emissions = (Maximum Supply − Current Total Supply) × 0.125%. In the tri‑token model, DGRAM is burned to generate DATA (a burnable non‑transferable service token).
  • Security/incentive mechanisms: incentives are tied to checkpoints (uptime/availability, latency/response times, usage). Rewards in the testnet phase — points, in mainnet — DGRAM daily emissions.
  • Distribution and token issuance schedule: whitepaper distribution: Full Core Operators 50% (15% minted at TGE; then daily vesting 12m), Airdrop 5% (capsules unlock 10% at TGE; then daily vesting 12m), Ecosystem 16% (100% TGE), MMs/Exchanges/LPs 5% (100% TGE), Investors 10% (vesting 36m), Team 10% (6m cliff + 36m daily vesting), Advisors 2.5% (6m cliff + 36m daily vesting), KOLs 1.5% (vesting 12m).
  • Treasury: the extracted Tier‑1 contains no separate description of a treasury; there are categories Ecosystem/LPs, etc., as allocation directions.

Governance

  • Who makes decisions: governance is described in the whitepaper (section 7), but the details of the participants/governance bodies are not established per Tier‑1.
  • How protocol parameters change: votes/processes are claimed (section 7 of the whitepaper), implementation details not extracted.
  • Where decisions are discussed/made: — (not found in the extracted Tier‑1).
  • Keys/multisig: the token contract (on BSC) uses AccessControl roles; specific admin/multisig addresses are not given in the extracted Tier‑1.

Security and incidents

  • Audits: — (not found in the extracted Tier‑1).
  • Bug bounty: — (not found in the extracted Tier‑1).
  • Incidents: — (not found in the extracted Tier‑1).
  • Threat model: risks of centralized roles in the token contract (MINTER/BURNER/ADMIN), risks of the “BSC token vs Avalanche ARC‑20” inconsistency in the documentation, risks of claims about AI optimization without metrics.

Project status and timeline

  • Current status: active documentation; Alpha Testnet (points) and Mainnet (token rewards) are described as rewards phases.
  • Key releases/milestones: the transition points→token rewards and checkpoints (described in the Rewards docs/whitepaper).
  • Roadmap: — (no roadmap is listed in links_*; no separate roadmap page was found in the extracted Tier‑1).

Ecosystem/integrations

  • Integrations: API/SDK, CLI, desktop application guide, dashboard; the whitepaper mentions interoperability with Ethereum/Avalanche/Solana/Base, etc., as “blockchain‑agnostic”.
  • Partners: — (not found in the extracted Tier‑1).
  • Where it’s actually used: the website/whitepaper claim “200+ enterprises” and “1M+ users”, but specific verifiable cases/metrics are not given in the extracted Tier‑1.

AI component of the project

  • What is real AI here? the Hyper Network Layer is described as AI‑driven coordination: it analyzes network conditions, predicts traffic patterns, optimizes routing/load balancing/resource allocation.
  • What is truly onchain? the DGRAM token exists as a BEP‑20 contract on BSC (verified code); the whitepaper describes onchain incentives and smart contract automation (payouts/distribution/rules), but without addresses in the extracted fragments.
  • Why is a token needed? DGRAM is described as a payment+governance token and as an incentives tool (conversion of reward points → DGRAM; emissions model).
  • Red flags (based on the information found): AI‑washing — the extracted Tier‑1 contains no metrics/technical details of the “AI‑driven coordination”; onchain‑washing — part of the onchain logic is described conceptually without addresses; a conflict/inconsistency — in the docs, DGRAM is described as an ARC‑20 on Avalanche, but links_* lists a BEP‑20 contract on BSC.

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 high 3
Evidence Tier‑1 present 3
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): the AI component is described as a functional part of the architecture (Hyper Network Layer), so “intent only” does not apply.
  • Evidence: Tier‑1 — https://doc.datagram.network/introduction/what-is-datagram ; https://doc.datagram.network/datagram-architecture/datagram-architecture-overview
  • Why sufficient / why not (one line): AI_0 is used when AI_1..AI_4 = 0; here AI_1 = 1.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the Hyper Network Layer is claimed to be AI‑driven coordination for routing/load balancing/resource allocation and congestion prevention.
  • Evidence: Tier‑1 — https://doc.datagram.network/introduction/what-is-datagram ; https://doc.datagram.network/datagram-architecture/datagram-architecture-overview ; https://datagram.network/
  • Why sufficient / why not (one line): Tier‑1 sources describe the functions of the AI layer at the level of tasks/purpose.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): the extracted Tier‑1 contains no reproducible demo/methodology for verifying the “AI‑driven coordination” (metrics/comparison of routing/latency).
  • Evidence: Tier‑1 — https://doc.datagram.network/introduction/what-is-datagram ; https://datagram.network/ ; https://doc.datagram.network/documentation/whitepaper
  • Why sufficient / why not (one line): there is a description, but no demonstration artifacts/guides for verification.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: — (not found)
  • Context (version/date/how measured): — (not found)
  • Evidence: Tier‑1 — https://doc.datagram.network/documentation/whitepaper ; https://datagram.network/
  • Why sufficient / why not (one line): the extracted Tier‑1 contains marketing numbers (e.g., 90% lower costs, 1M+ users), but no quality metrics for the AI coordination.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): the architecture is described at the component level (Hyper Network Layer), but there is no specification of models/versions/data/algorithms for the AI part.
  • Evidence: Tier‑1 — https://doc.datagram.network/datagram-architecture/datagram-architecture-overview ; https://doc.datagram.network/introduction/what-is-datagram
  • Why sufficient / why not (one line): insufficient technical details for AI_4.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain
  • Addresses/identifiers: DGRAM token 0x49c6c91ec839a581de2b882e868494215250ee59
  • Evidence: Tier‑1 — https://bscscan.com/token/0x49c6c91ec839a581de2b882e868494215250ee59
  • Why sufficient / why not (one line): BscScan confirms the contract, max total supply, verified source code.
  • Conflict note (if any): the whitepaper describes DGRAM as an ARC‑20 on Avalanche; a specific ARC‑20 contract is not listed in the extracted Tier‑1.

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

  • OC_2 (decision): 0
  • What useful logic is onchain: the whitepaper describes smart contract automation (payments/resource allocation/rewards), the tri‑token model and governance, but without extracted addresses/contracts other than the token on BSC.
  • Evidence: Tier‑1 — https://doc.datagram.network/documentation/whitepaper/2.-why-blockchain ; https://doc.datagram.network/documentation/whitepaper/5.-tokenomics/5.1.-tri-token-model ; https://doc.datagram.network/documentation/whitepaper/6.-datagram-rewards-and-emissions-model/6.1.-checkpoints
  • Why sufficient / why not (one line): descriptions exist, but verifiable onchain artifacts “other than the token” were not found / not confirmed by Tier‑1 — conservatively 0.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: replacing the blockchain with a centralized server loses the key properties that Datagram calls its advantages: decentralized fault tolerance, onchain incentives and smart‑contract rule automation (payments/resource allocation/rewards), as well as “censorship‑resistant infrastructure” and user control over data.
  • Evidence: Tier‑1 — https://doc.datagram.network/documentation/whitepaper/2.-why-blockchain
  • Why sufficient / why not (one line): the “Why Blockchain” section directly justifies that the blockchain is needed for the properties that constitute the meaning of the product.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, DGRAM (contract on BSC), and the DGRAM tokenomics is described in the whitepaper.
  • Evidence: Tier‑1 — https://bscscan.com/token/0x49c6c91ec839a581de2b882e868494215250ee59 ; https://doc.datagram.network/documentation/whitepaper/5.-tokenomics/5.2.-supply-and-distribution
  • Why sufficient / why not (one line): the existence of the token is confirmed by the explorer and the documentation.
  • 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): in the tri‑token model, DGRAM is described as the primary utility token for payments in the ecosystem; DGRAM is burned to generate DATA, which is used for service payments.
  • Evidence: Tier‑1 — https://doc.datagram.network/documentation/whitepaper/5.-tokenomics/5.1.-tri-token-model
  • Why sufficient / why not (one line): this is a direct description of the payment utility in the whitepaper.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): node operators are rewarded with reward points ($UDP/$TCP/$AI), which are converted daily into DGRAM; emissions and checkpoints (uptime/latency/usage) are described in the whitepaper.
  • Evidence: Tier‑1 — https://doc.datagram.network/documentation/whitepaper/6.-datagram-rewards-and-emissions-model/6.1.-checkpoints ; https://doc.datagram.network/documentation/whitepaper/6.-datagram-rewards-and-emissions-model/6.2.-emissions-formula ; https://doc.datagram.network/documentation/whitepaper/5.-tokenomics/5.1.-tri-token-model
  • Why sufficient / why not (one line): Tier‑1 describes the incentive model and the link between rewards and the token.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): the whitepaper, in the tri‑token model, calls DGRAM a governance token.
  • Evidence: Tier‑1 — https://doc.datagram.network/documentation/whitepaper/5.-tokenomics/5.1.-tri-token-model ; https://doc.datagram.network/documentation/whitepaper/7.-datagram-governance
  • Why sufficient / why not (one line): Tier‑1 explicitly claims governance utility, although the implementation (onchain/offchain) was not extracted.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): DGRAM is embedded in the incentives/payments/governance model (points→DGRAM, DGRAM→DATA), which makes the token functionally the core of the economy.
  • Evidence: Tier‑1 — https://doc.datagram.network/documentation/whitepaper/5.-tokenomics/5.1.-tri-token-model ; https://doc.datagram.network/documentation/whitepaper/6.-datagram-rewards-and-emissions-model/6.2.-emissions-formula
  • Why sufficient / why not (one line): replacing the token breaks the described tokenomics logic (burn/conversion/emissions), so conservatively 0.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://doc.datagram.network/introduction/what-is-datagram description of the components (Hyper Network Layer, DCS) and AI‑powered optimization.
Tier‑1 https://doc.datagram.network/datagram-architecture/datagram-architecture-overview architecture: Node Network, Fabric Networks, DCS, Hyper Network Layer (AI‑driven coordination).
Tier‑1 https://doc.datagram.network/documentation/whitepaper/2.-why-blockchain justification of the need for a blockchain (fault tolerance, onchain incentives, smart contracts).
Tier‑1 https://doc.datagram.network/documentation/whitepaper/5.-tokenomics/5.1.-tri-token-model the tri‑token model: DGRAM (payments+governance), DATA (burnable service token), reward points ($UDP/$TCP/$AI) and the conversion.
Tier‑1 https://doc.datagram.network/documentation/whitepaper/5.-tokenomics/5.2.-supply-and-distribution max supply 10B, TGE supply 5.75B, allocations and vesting.
Tier‑1 https://doc.datagram.network/documentation/whitepaper/6.-datagram-rewards-and-emissions-model/6.2.-emissions-formula the emissions formula: Daily Emissions = Latent Supply × 0.125%.
Tier‑1 https://bscscan.com/token/0x49c6c91ec839a581de2b882e868494215250ee59 the onchain fact of the DGRAM token on BSC: contract, max total supply, verified source (AccessControl, mint/burn roles, supplyCap).

No comments to display

Back to top