Skip to main content

375ai

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

375ai — a DePIN and AI/Data project on Solana: a decentralized edge network for collecting and processing multimodal data (375edge devices + the 375go mobile app) with AI summarization/insights at the “edge” and the 375 token for incentives/staking/buy‑and‑burn.

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 network of devices and apps that collects data “in the field” and turns it into useful insights on the spot (edge AI), and then provides them to buyers.
  • Who it’s for: enterprises/data buyers + network participants (app users and device deployers).
  • Why onchain/token: the 375 token — incentives for quality data and a buy‑and‑burn mechanism when data is purchased via data credits (per the whitepaper).

How it works (very briefly)

  1. The user does: participates as 375go (a mobile app — passive/active data collection) or as 375edge (deploying an edge node).
  2. The system does: 375edge collects multimodal data (cameras/sensors) and, using a GPU (NVIDIA), locally transforms it into “summarized and queried insights”; 375go supplements/validates the data and participates in “Proof of Data” (per the whitepaper).
  3. The user gets: rewards in 375 tokens (epoch‑based), depending on data quality and compliance with the rules (penalties/reduced rewards are described in the whitepaper).
  4. Where the blockchain is: onchain — the 375 token on Solana and its economic operations (reward/distribution, buy‑and‑burn via data credits).
  5. Token role (if any): 375 is used for rewards, staking/validation (Proof of Data) and governance; data consumption leads to a buy‑and‑burn of the token (per the whitepaper).

Quick links: AI thesis fit

Project passport

Field Value
Project name 375ai
Also known as (aliases) 375
Logo (logo) ../assets/170_375ai_logo.webp
Token symbol (ticker) 375
Category AI/Data | DePIN
Primary chain (chain) Solana
Type non-EVM
Network status mainnet
Consensus (consensus) PoS (Solana)
Launch date (launch_date) —
Project status (status) active
Token (standard) SPL
Token contract 375aiUqZERLrB9sHtsArKr4nuWCgBrtqibUDBMGeLvZC
Token model (token_type) utility (staking + incentives + buy-and-burn)
Max supply 1,000,000,000 375
Issuance fixed supply; bootstrap rewards → then revenue‑based incentives + burn (per the whitepaper)
Tokenomics (tokenomics, brief) data credits (fiat) → buy‑and‑burn 375; epoch‑based rewards with penalties for low quality/uptime
Governance governance via staked 375 (per the whitepaper; the framework is high‑level)
Admins/keys — (details of admin keys/program upgrades are not disclosed in the whitepaper)
Audit yes (Hacken “375ai audits” page)
Bug bounty —
Team (team) co‑founders are listed in the whitepaper
Funding (investors/funding) —
AI component (ai_component) edge AI (sensor data summarization/insights)
Use‑case (use_case) collection + sale of privacy-preserving edge data
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 1 / 3 / 2
Last verified 2026-02-11

General project overview

375ai describes itself as a DePIN network — a “decentralized edge data intelligence network” — that makes data collection and insight extraction at the edge more efficient. The whitepaper emphasizes a shift from the traditional “capture & compress → transfer → decompress & analyze” model to “capture & summarize → transfer → prompt”, where LLM‑like models yield gains in transfer efficiency and require compute at the edge.

The project consists of two key products:

  • 375edge: stationary enterprise nodes with cameras/sensors and a GPU for local processing (NVIDIA GPUs are mentioned in the whitepaper).
  • 375go: a mobile app for consumers (passive and “gamified” active data collection), with a premium mode for claiming rewards and participating in PoD validation (per the whitepaper).

Features/modules

  • Edge AI processing: local summarization/insights from multimodal data on 375edge.
  • Proof of Data (PoD): the claimed mechanism of data validation between 375edge and 375go (per the whitepaper).
  • Epoch‑rewards + penalties: rewards decrease upon quality/uptime violations; penalties and slashing of the stake for spam are possible (per the whitepaper).
  • Data marketplace / data buyers: data buyers pay via “data credits” (fiat), which are used for the token buy‑and‑burn (per the whitepaper).

Typical scenarios

  • Scenario 1 (375go user): installs the app → collects signals/data → receives rewards if the rules are followed.
  • Scenario 2 (375edge deployer): installs a node at a location → the device collects and processes data → the deployer receives rewards per epoch.
  • Scenario 3 (data buyer): buys data credits → a buy‑and‑burn of 375 takes place → the buyer gets access to data/insights.

Getting started (wallet/network)

  • What you need: to participate in the token economy — a Solana wallet; for 375go — the mobile app; for 375edge — onboarding/vetting (per the whitepaper).
  • Network/chain: Solana.
  • Fees: Solana fees for operations; also, the premium version of 375go requires a payment to claim rewards (per the whitepaper).

Architecture/tech (non‑AI)

  • Components: 375edge hardware (cameras/sensors/GPU) + the 375go app + backends/data marketplace + the 375 token on Solana.
  • Participant roles: app users (375go), device deployers (375edge), data buyers, governance/validators (via the staking model).
  • Where logic runs: AI processing — at the edge (offchain, on devices); reward accounting/token operations and buy‑and‑burn — onchain.
  • Dependencies: Solana; location providers (the whitepaper mentions access to 40k locations via a partnership).

Token/economics (expanded, no forecasts)

  • Token utility: rewards to network participants; staking for PoD validation/anti‑spam; governance; deflation mechanics via buy‑and‑burn when data is purchased (per the whitepaper).
  • Protocol necessity drivers: without the token, the incentives model for data providers and the burn link to data consumption break down.
  • Who pays fees: data buyers pay in fiat for data credits; participants pay onchain Solana fees.
  • Where fees go: buy‑and‑burn: fiat/USDC → purchase of 375 on the market → burn (per the whitepaper).
  • Issuance/burn: total supply 1,000,000,000; bootstrap rewards inflation, then a transition to revenue‑based incentives; tokens from data sales are largely burned (per the whitepaper).
  • Security/incentive mechanisms: penalties for offline/incomplete data; slashing of the stake and a ban are possible for prolonged spam/violations (per the whitepaper).
  • Distribution and token issuance schedule: the whitepaper contains a table: investors 15% (1Y cliff + 24m linear), listings 5% unlocked, liquidity 2.5% unlocked, treasury 5% unlocked, partnerships/marketing 5% unlocked, community incentives 42.5% (distributed over ~8 years), team 25% (1Y cliff + 24m linear).
  • Treasury: 5% of the supply is allocated to the treasury (per the whitepaper); further policy — via governance.

Governance

  • Who makes decisions: governance via staked 375 (described in the whitepaper); the practical governance model (forum/snapshot/threshold) is not disclosed in the whitepaper.
  • How protocol parameters change: via the governance process described in the whitepaper, and via updates of the offchain infrastructure (edge devices/app).
  • Where decisions are discussed/made: the project’s public channels (see links_*: X/Discord) + publications/updates (blog/roadmap).
  • Keys/multisig: not disclosed in Tier‑1 sources (the whitepaper does not list onchain program addresses/admin structures).

Security and incidents

  • Audits: yes (Hacken, see links_* → Audit report(s)).
  • Bug bounty: —.
  • Incidents: — (no public postmortems/incidents were found in the reviewed sources).
  • Threat model: data spoofing/low data quality (Sybil/spam), privacy risks and compromise of edge devices/the mobile app, as well as the risk that the onchain part (PoD/marketplace programs) is not sufficiently publicly specified with addresses.

Project status and timeline

  • Current status: active (the 375 token on Solana mainnet; the product architecture is described in the whitepaper; see links_*).
  • Key releases/milestones: —.
  • Roadmap: https://www.375.ai/blog/road-to-mainnet

Ecosystem/integrations

  • Integrations: Solana (token), 375edge hardware (GPU/sensors), the 375go mobile app, data marketplace/data credits (per the whitepaper).
  • Partners: there are public Tier‑1 partnership announcements and a partners page (e.g.: Outfront Media; Akave; AYDO — see Evidence).
  • Where it’s actually used: collection of edge data and provision of insights to data buyers (see Whitepaper/Website in links_*).

AI component of the project

  • What is real AI here? edge AI (GPU) is used on 375edge nodes for the local transformation of sensor data into “summarized and queried insights” (per the whitepaper).
  • What is truly onchain? the 375 token on Solana and its economic model (rewards, staking, buy‑and‑burn).
  • Why is a token needed? rewards/incentives and anti‑spam via staking + a deflationary link to data purchases (buy‑and‑burn) and governance.
  • Red flags (based on the information found): onchain‑washing — medium risk (most of the “AI” and the data collection are offchain); double‑check the actual Solana contracts/programs once they are publicly documented with addresses.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): AI functions are described as current components (edge AI and products), so the intent flag is not used.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): the whitepaper describes working elements of 375edge/375go and their AI role.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): 375edge locally transforms multimodal data into summarized/queryable insights (edge AI).
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): the whitepaper describes the data, sensors and computation at the edge with a GPU.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): public demo links/screencasts of the models in operation are not presented in the Tier‑1 whitepaper.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): there is a product description, but no demonstration/reproducible examples.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): model quality metrics/benchmarks are not provided.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): the components of the edge node (cameras/sensors/GPU) are described, as well as the fact that processing/summarization is done locally on the device.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): there is a technical description of the edge component architecture (albeit without specific models/versions).
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Solana
  • Addresses/identifiers: SPL mint: 375aiUqZERLrB9sHtsArKr4nuWCgBrtqibUDBMGeLvZC
  • Evidence: Tier‑1 — https://solscan.io/token/375aiUqZERLrB9sHtsArKr4nuWCgBrtqibUDBMGeLvZC
  • Why sufficient / why not (one line): the token identifier is specified; reading the parameters may require JS rendering of the explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: the Tier‑1 whitepaper does not provide program/contract addresses (other than the token) for PoD/the marketplace.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): the mechanics are described, but without onchain artifacts/addresses.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: data collection and AI processing are possible without a blockchain; onchain is chosen as the mechanism for accounting incentives and the burn link to data consumption.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): most of the logic is offchain/edge; onchain is the accounting and incentives layer.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, 375, on Solana.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf ; https://solscan.io/token/375aiUqZERLrB9sHtsArKr4nuWCgBrtqibUDBMGeLvZC
  • Why sufficient / why not (one line): the tokenomics and supply are described in the whitepaper; the mint is listed in the project’s links.
  • 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): purchasing data via data credits leads to a buy‑and‑burn of the 375 token, linking service consumption to the token.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): the whitepaper directly describes data credits → buy‑and‑burn.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): rewards to network participants; staking for PoD validation; penalties and slashing for low quality/spam.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): reward epochs, penalties, slashing/bans are described.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): governance is described as a function of staked 375 (especially for the 375go service).
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): there is a separate Governance section in the whitepaper.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the token is built into the core economy of the network (rewards + burn from data consumption), so by design it is not “optional”.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf
  • Why sufficient / why not (one line): buy‑and‑burn and staking anti‑spam are tightly tied to the token.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://cdn.prod.website-files.com/667a49b0c9134fc9329e183b/668da6a6f0bc27c3138337b9_375ai%20Whitepaper.pdf Architecture of 375edge/375go, edge AI, Proof of Data, tokenomics (1B supply, allocations, buy‑and‑burn), governance
Tier‑1 https://hacken.io/audits/375ai/ The existence of an audit (vendor page; report details require opening the specific artifact)
Tier‑1 https://solscan.io/token/375aiUqZERLrB9sHtsArKr4nuWCgBrtqibUDBMGeLvZC The identifier of the 375 SPL token on Solana
Tier‑1 https://www.375.ai/partners The public partners/ecosystem page (Tier‑1 navigation of partnerships)
Tier‑1 https://www.375.ai/blog/375ai-akave-partner-to-build-verifiable-edge-intelligence An example of a Tier‑1 partnership announcement (Akave)

No comments to display

Back to top