Skip to main content

Dtec

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

Dtec — an AI/Assistants / DePIN project about a “smart assistant for transport/IoT” (Dtec Assistant, Dtec Brain, DtecGPT), where the DTEC token is used as the ecosystem’s utility token (payments/rewards for data sharing per the whitepaper). The DTEC token is deployed on the Polygon network (EVM).

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 “car/IoT assistant” product/ecosystem + the DTEC token.
  • Who it’s for: drivers/users of the assistant; an ecosystem of partners/integrators (claimed).
  • Why onchain/token: the token is needed as a means of payment/rewards (including for consenting to share data under the project’s model).

How it works (very briefly)

  1. The user does: uses the assistant (voice commands/interaction, per the whitepaper).
  2. The system does: processes speech/context (STT/NLP/TTS), controls functions and connected IoT devices (as claimed in the whitepaper).
  3. The user gets: a voice interface for control/information and “personalized assistance” (claimed).
  4. Where the blockchain is: the DTEC token on the Polygon network is confirmed onchain; the materials also claim a reward mechanism for data sharing (details of smart contracts other than the token are not disclosed in the extracted Tier‑1).
  5. Token role (if any): DTEC is described as the ecosystem’s payment token and as a reward/incentive.

Quick links: AI thesis fit

Project passport

Field Value
Project name Dtec
Also known as (aliases) DTEC, Dtec World, Dtec Assistant (DtecA), Dtec Brain (DtecB), DtecGPT
Logo (logo) ../assets/264_dtec-token_logo.svg
Token symbol (ticker) DTEC
Category AI/Assistants | DePIN
Primary chain (chain) Polygon
Type EVM
Network status mainnet
Consensus (consensus) PoS (Polygon)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0xd87aF7B418d64FF2cdE48d890285bA64fc6E115F
Token model (token_type) utility (governance)
Max supply CONFLICT: 450,000,000 (whitepaper) / 900,000,000 (GitHub README)
Issuance capped; burn (in the ecosystem’s smart contracts, per the GitHub README)
Tokenomics (tokenomics, brief) reward for data sharing; payments/transactions in the token (per the whitepaper)
Governance company
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) voice NLP assistant + DtecGPT
Use‑case (use_case) in-car assistant + IoT control
DecAI Fit — AI thesis fit 4/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 1 / 1 / 3
Last verified 2026-02-11

General project overview

Dtec describes an ecosystem of several components: Dtec Assistant (DtecA) as a software assistant (e.g., for a car/smart platform), Dtec Brain (DtecB) as the AI technology/“brain”, DtecGPT as a chat module, as well as the DTEC token as the onchain component for rewards and payments. The whitepaper claims the tasks of voice control, IoT integration and “personalization” via training on user data (with consent).

Features/modules

  • DtecA: a voice assistant, control of functions/devices, IoT integration (claimed).
  • DtecB: data processing (voice/visual/IoT), training and “emotional” personalization (claimed).
  • DtecGPT: the assistant’s chat module (claimed).
  • DTEC token: reward for data sharing + token payments/transfers (whitepaper).
  • NFT plans: customization of the assistant via NFTs (whitepaper, as a plan).

Typical scenarios

  • Scenario 1: a driver gives a voice command → the assistant performs an action/gives an answer (whitepaper).
  • Scenario 2: a user controls home/office IoT devices from the assistant → a single point of control (whitepaper).
  • Scenario 3: a user consents to data sharing → receives periodic DTEC rewards (whitepaper).

Getting started (wallet/network)

  • What you need: an EVM wallet (e.g., MetaMask) to work with the DTEC token.
  • Network/chain: Polygon mainnet.
  • Fees: Polygon network fees in POL for onchain transactions (transfer/approve, etc.).

Architecture/tech (non‑AI)

  • Components: a client application/software assistant (DtecA) + an AI service/subsystem (DtecB) + the DTEC token (ERC‑20 on Polygon).
  • Participant roles: users of the assistant; token holders/users.
  • Where logic runs: the AI logic is described as offchain; the DTEC token is confirmed onchain.
  • Dependencies: Polygon (EVM); external IoT/internet data sources (per the whitepaper).

Token/economics (expanded, no forecasts)

  • Token utility: DTEC is described as the ecosystem’s “local payment token” and as a reward for data sharing.
  • Protocol necessity drivers: the reward mechanism (incentive) and payments within the ecosystem are claimed as the basis for the token.
  • Who pays fees: onchain Polygon fees (gas) are paid by users for token transactions.
  • Where fees go: to the Polygon network validators (gas); the business mechanics of DTEC distribution are described in the whitepaper at the tokenomics level, without onchain contracts in the extracted sources.
  • Issuance/burn: a capped model is claimed; the GitHub README mentions burn functionality and a capped supply (see the max supply conflict).
  • Security/incentive mechanisms: incentivization via data‑sharing rewards (whitepaper); as for slashing/staking — not found in the extracted Tier‑1.
  • Distribution and token issuance schedule: the whitepaper describes distribution categories and vesting; the exact onchain wallets/vesting contracts are not confirmed in the extracted Tier‑1.
  • Treasury: — (the extracted Tier‑1 contains no specific treasury address/multisig).

Governance

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

Security and incidents

  • Audits: — (there are no public audit reports in links_*).
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: claims about “emotional AI/autonomous learning” are not accompanied by public metrics; in addition, apart from the token, onchain artifacts are not confirmed in this card.

Project status and timeline

  • Current status: the DTEC token exists on Polygon; the product is claimed to be under development (there is a roadmap on the website).
  • Key releases/milestones: —.
  • Roadmap: https://dtec.space/roadmap

Ecosystem/integrations

  • Integrations: EVM wallets; Polygon.
  • Partners: —.
  • Where it’s actually used: — (the extracted Tier‑1 contains no verifiable cases/integrations “in production”).

AI component of the project

  • What is real AI here? the whitepaper describes AI/ML modules (STT/NLP/TTS, noise cancellation, wake word) and “DtecGPT” as a chat module; this looks like an applied AI assistant, but without public quality benchmarks.
  • What is truly onchain? the DTEC token (ERC‑20) on Polygon is confirmed; other onchain contracts/addresses for data‑sharing rewards were not found in the extracted Tier‑1.
  • Why is a token needed? as the ecosystem’s payment token and as a reward for data sharing (whitepaper).
  • Red flags (based on the information found): the max supply conflict (whitepaper vs GitHub README); no public audit; few verifiable onchain mechanics other than the token; no reproducible AI quality metrics.

DecAI Fit component summary

  • DecAI Fit: 4/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity low 1
Token necessity low 1
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: AI is described not only as an “intent”, there is a description of functions/modules (AI_1/AI_4).
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): AI_0 is used when there is no proof of AI_1..AI_4; here it exists.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the assistant recognizes speech/intents (STT + intent classification/slot filling), generates voice responses (TTS) and controls devices/functions via voice commands (whitepaper).
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): there is a specific description of the AI tasks and modules in the whitepaper.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a public reproducible demo of the assistant (video/repo/public build) was not found / not confirmed by Tier‑1.
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): the whitepaper describes, but does not provide a demo artifact/public example that can be verified.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: — (the extracted Tier‑1 contains no public quality numbers/benchmarks with context; there is only a “99% accuracy” plan without a methodology/version).
  • Context (version/date/how measured): —.
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): verifiable metrics with context and artifacts are absent.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): the whitepaper describes the set of AI/ML modules (STT, wake word, noise cancellation, NLP, TTS) and the general pipeline for processing a voice command.
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): there is a structured technical description of the modules/pipeline (albeit without code).
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Polygon
  • Addresses/identifiers: DTEC token contract: 0xd87aF7B418d64FF2cdE48d890285bA64fc6E115F
  • Evidence: Tier‑1 — https://polygonscan.com/address/0xd87af7b418d64ff2cde48d890285ba64fc6e115f ; https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): the token address and network are confirmed by the explorer; the whitepaper states that the token is on Polygon.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: the extracted Tier‑1 contains no addresses/contracts that implement data‑sharing rewards or other business logic (other than the token).
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): without specific addresses/contracts, the onchain logic is not verifiable.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the assistant’s core functions (STT/NLP/TTS/IoT control) remain if the blockchain is replaced with an ordinary server; without onchain, only the token layer of rewards/payments is lost.
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): onchain is not shown to be critical; the onchain component looks auxiliary.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, DTEC.
  • Evidence: Tier‑1 — https://polygonscan.com/address/0xd87af7b418d64ff2cde48d890285ba64fc6e115f
  • 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): 1
  • Claim (one line): DTEC is described as the ecosystem’s “local payment token” (whitepaper).
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): the “token payments” utility is claimed in the official whitepaper.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): DtecA users who consent to data sharing receive DTEC rewards according to the tokenomics schedule (whitepaper).
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): the tokenomics describes the reward mechanics (incentive) for users.
  • 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://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): the whitepaper contains no explicit description of onchain governance via DTEC.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): the payment/bonus part can also be implemented via other assets/accounting (e.g., a stablecoin/points) without changing the AI product.
  • Evidence: Tier‑1 — https://dtec.space/documents/WhitepaperEN.pdf
  • Why sufficient / why not (one line): the assistant’s AI functions do not depend on the token; the token serves the economy and therefore looks replaceable.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://dtec.space/documents/WhitepaperEN.pdf description of the AI modules (STT/NLP/TTS), the role of DTEC in rewards/payments, tokenomics categories and vesting
Tier‑1 https://polygonscan.com/address/0xd87af7b418d64ff2cde48d890285ba64fc6e115f confirms the onchain existence of the DTEC token contract on the Polygon network
Tier‑1 https://raw.githubusercontent.com/DtecSpace/dtec-contracts/master/README.md description of the ecosystem contracts (sale/vesting/locking) and the claim about capped supply/burn (records the max supply conflict)

No comments to display

Back to top