Doc.com
Doc.com — 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).
Doc.com — a consumer/app project with claimed use of AI in the product; an ERC‑20 token/contract on the Ethereum network is also recorded.
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 telemedicine application/platform (consultation marketplace) with claimed AI support for triage and symptom collection.
- Who it’s for: users who need online consultations with licensed specialists.
- Why onchain/token: the claim “secured by blockchain” is recorded per Tier‑1, but specific onchain logic and the role of the token in the product are not established; only the fact of the ERC‑20 contract’s existence is confirmed.
How it works (very briefly)
- The user does: selects a consultation type and describes the request/symptoms.
- The system does: collects input and, per the project’s claim, generates clarifying questions via AI models (triage).
- The user gets: a consultation/answer/next steps.
- Where the blockchain is: the use of blockchain for “security” is claimed, but specific onchain mechanisms are not established.
- Token role (if any): the role of the token in the product is not established; only the ERC‑20 contract is confirmed.
Quick links: AI thesis fit
Project passport
| Field | Value |
|---|---|
| Project name | Doc.com |
| Also known as (aliases) | Docademic |
| Logo (logo) | ../assets/693_doc-com_logo.svg |
| Token symbol (ticker) | MTC |
| Category | AI/Other | Consumer |
| Primary chain (chain) | Ethereum |
| Type | EVM |
| Network status | mainnet |
| Consensus (consensus) | PoS (Ethereum) |
| Launch date (launch_date) | — |
| Project status (status) | active |
| Token (standard) | ERC-20 |
| Token contract | 0x905E337c6c8645263D3521205Aa37bf4d034e745 |
| Token model (token_type) | — |
| Max supply | — |
| Issuance | — |
| Tokenomics (tokenomics, brief) | Not established per Tier‑1 as of the verification date. |
| Governance | — |
| Admins/keys | — |
| Audit | — |
| Bug bounty | — |
| Team (team) | — |
| Funding (investors/funding) | — |
| AI component (ai_component) | AI triage + symptom Q&A |
| Use‑case (use_case) | telemedicine + online consultations |
| DecAI Fit — AI thesis fit | 3/6 — medium alignment with the Decentralized AI thesis |
| DecAI Fit component summary | ai_score 1 / onchain_score 1 / token_score 0 / evidence_score 3 |
| Last verified | 2026-02-11 |
Links (links_*)
| Type | Link |
|---|---|
| Website | https://doc.com/ |
| Docs | https://cdn.docademic.com/documents/Docademic+ICO+White+Paper.pdf |
| GitHub | https://github.com/Docademic/ |
| Releases / Changelog | https://github.com/Docademic/MTC/commits |
| Whitepaper | https://cdn.docademic.com/documents/Docademic+ICO+White+Paper.pdf |
| Roadmap | — |
| Security advisories | — |
| Explorer | https://etherscan.io/token/0x905E337c6c8645263D3521205Aa37bf4d034e745 |
| X | https://twitter.com/doc_comofficial |
| Discord | — |
| Telegram | https://t.me/docToken |
| Medium | — |
| Audit report(s) | — |
| Bug bounty | — |
| CoinGecko (profile, reference) | — |
| CoinMarketCap (profile, reference) | https://coinmarketcap.com/currencies/doc-com/ |
General project overview
Doc.com describes itself as a digital health company that connects users with licensed medical specialists via an application/platform. The project’s public materials claim the use of AI technologies to support the medical team (for example, triage and clarifying questions about symptoms).
Separately, an ERC‑20 contract (Ethereum) is recorded in the card links. Per Tier‑1 as of the verification date, it is not established how exactly the blockchain and token are built into the product mechanics, other than general claims on the website.
Features/modules
- Consultation marketplace (selecting a consultation type, submitting a request).
- Claimed AI component for triage/clarifying questions.
- The claim “secured by blockchain” without disclosure of onchain mechanics details as of the verification date.
Typical scenarios
- Scenario 1: a user selects a consultation and describes symptoms → receives a consultation/doctor’s recommendations.
- Scenario 2: a user uploads documents/data → receives a more contextual analysis during the consultation.
Getting started (wallet/network)
- What you need: access to the project’s application/website.
- Network/chain: onchain actions for using the application are not established; the Ethereum network is recorded for the token.
- Fees: Ethereum network fees are possible only for operations with the token; service/consultation payment terms are not detailed per Tier‑1 as of the verification date.
Architecture/tech (non‑AI)
- Components: web/mobile application, service backend; the onchain part is not disclosed as of the verification date, other than the ERC‑20 contract.
- Participant roles: users and licensed specialists.
- Where logic runs: service logic in the application/backend; ERC‑20 operations — on the Ethereum network.
- Dependencies: —.
Token/economics (expanded, no forecasts)
- Token utility: not established per Tier‑1 as of the verification date.
- Protocol necessity drivers: not established per Tier‑1 as of the verification date.
- Who pays fees: token users for ERC‑20 operations on Ethereum.
- Where fees go: to Ethereum validators (network fees).
- Issuance/burn: not established per Tier‑1 as of the verification date.
- Security/incentive mechanisms: not established per Tier‑1 as of the verification date.
- Distribution and token issuance schedule: not established per Tier‑1 as of the verification date.
- Treasury: —.
Governance
- Who makes decisions: not established per Tier‑1 as of the verification date.
- How protocol parameters change: not established per Tier‑1 as of the verification date.
Security and incidents
- Audits: —.
- Bug bounty: —.
- Incidents: —.
- Threat model: service risks depend on the application implementation; there is no Tier‑1 data on the onchain part other than the ERC‑20 contract.
Project status and timeline
- Current status: active (based on the presence of a working website and public materials).
- Key releases/milestones: not established per Tier‑1 as of the verification date.
- Roadmap: not found per Tier‑1 as of the verification date.
Ecosystem/integrations
- Integrations: —.
- Partners: —.
- Where it’s actually used: the product part — in the application/platform; onchain use is not established.
AI component of the project
- What is real AI here? Per the project’s claim, AI models are used for triage (generating clarifying questions about symptoms and supporting the consultation process).
- What is truly onchain? An ERC‑20 contract on Ethereum is confirmed; the rest of the onchain logic is not established per Tier‑1 as of the verification date.
- Why is a token needed? Not established per Tier‑1 as of the verification date.
- Red flags (based on the information found): claims of “secured by blockchain” without disclosure of what exactly is done onchain; no Tier‑1 description of the role of the token in the product.
DecAI Fit component summary
- DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
| Component | Level | Score |
|---|---|---|
| AI reality | low | 1 |
| Onchain necessity | low | 1 |
| Token necessity | low | 0 |
| Evidence | Tier‑1 present (partially) | 3 |
Details
AI reality
AI_0 — AI intent (Tier‑1 roadmap) (1/0)
- AI_0 (decision): 0
- Claim (one line): AI is described as a part of the product that is in use (not only intent/roadmap).
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): When there is a description of actual AI use, this “intent” flag adds no signal.
- Conflict note (if any): —
AI_1 — what the AI does (1/0)
- AI_1 (decision): 1
- Claim (one line): AI‑driven symptom assessment and real‑time generation of clarifying questions (triage) based on the entered data are claimed.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): The official website describes how AI works in the product at the user flow level.
- Conflict note (if any): —
AI_2 — demos/examples (1/0)
- AI_2 (decision): 0
- Claim (one line): No Tier‑1 demo/public test surface was found that can unambiguously be “touched” as an AI feature of the project.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): There is a description and links to download the application, but 1 requires a reproducible demo artifact/guide.
- Conflict note (if any): —
AI_3 — metrics/quality (1/0)
- AI_3 (decision): 0
- Metrics: —.
- Context (version/date/how measured): —.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): No Tier‑1 reproducible benchmark/quality metrics of the AI subsystem were found.
- Conflict note (if any): —
AI_4 — tech description/architecture/versions (1/0)
- AI_4 (decision): 0
- Claim (one line): A technical description of the AI architecture/model versions was not found per Tier‑1 as of the verification date.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): 1 requires a document/repository/description of the AI component’s architecture, which was not found as of the verification date.
- Conflict note (if any): —
Onchain necessity
OC_1 — contracts/addresses/chain (1/0)
- OC_1 (decision): 1
- Chain: Ethereum
- Addresses/identifiers: 0x905E337c6c8645263D3521205Aa37bf4d034e745 (ERC‑20 contract)
- Evidence: Tier‑1 — https://etherscan.io/token/0x905E337c6c8645263D3521205Aa37bf4d034e745
- Why sufficient / why not (one line): There is an onchain artifact: an observable ERC‑20 contract on Ethereum.
- Conflict note (if any): —
OC_2 — onchain beyond just a token (1/0)
- OC_2 (decision): 0
- What useful logic is onchain: Not established per Tier‑1 as of the verification date (other than the fact of the token/contract).
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): The website has a general statement about blockchain security, but without specific onchain logic/addresses/mechanics.
- Conflict note (if any): —
OC_3 — onchain is critical (1/0)
- OC_3 (decision): 0
- “Replace the blockchain” test: it is not established that a key property of the product breaks down without onchain.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): No Tier‑1 justification of onchain criticality was found.
- Conflict note (if any): —
Token necessity
TK_0 — no token (1/0)
- TK_0 (decision): 0
- Claim (one line): An ERC‑20 contract is recorded in links_*, so the token exists.
- Evidence: Tier‑1 — https://etherscan.io/token/0x905E337c6c8645263D3521205Aa37bf4d034e745
- Why sufficient / why not (one line): The onchain contract page confirms the existence of the token.
- 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): No Tier‑1 confirmation of payment for the service with the token was found as of the verification date.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): 1 requires an explicit Tier‑1 artifact describing the token’s pay mechanics.
- Conflict note (if any): —
TK_2 — incentives/collateral/penalties (1/0)
- TK_2 (decision): 0
- Claim (one line): Mechanics of token‑based incentives/collateral/penalties are not established per Tier‑1 as of the verification date.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): There is no description of the token’s onchain economy.
- Conflict note (if any): —
TK_3 — governance (1/0)
- TK_3 (decision): 0
- Claim (one line): The use of the token for governance is not established per Tier‑1 as of the verification date.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): 1 requires an explicit Tier‑1 document/voting rules.
- 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 established per Tier‑1 as of the verification date.
- Evidence: Tier‑1 — https://doc.com/
- Why sufficient / why not (one line): 1 requires an understanding of the role of the token; it is not established.
- Conflict note (if any): —
Evidence (table)
| Tier | Source | What it proves |
|---|---|---|
| Tier‑1 | https://doc.com/ | The project’s claims about the presence of AI support (triage) and use of blockchain (in general terms, without mechanics). |
| Tier‑1 | https://etherscan.io/token/0x905E337c6c8645263D3521205Aa37bf4d034e745 | The existence of an ERC‑20 token/contract on the Ethereum network. |
| Tier‑1 | https://github.com/Docademic/MTC | Official ICO contracts for MTC token (context: the MTC ticker and the project’s connection to the token). |
No comments to display
No comments to display