Scry.info

Scry.info — 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).

Scry.info — a project/ecosystem that, per Tier‑1 sources, includes “Scry Data Protocol”; token (symbol: DDD).

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 protocol/SDK for data sharing with a blockchain layer (encryption/signatures, data storage/search, smart contracts, events) — “Scry Data Protocol”.
• Who it’s for: for data providers (data providers), data consumers (data demanders), verifiers (verifiers) and dApp/integration developers (per the protocol README).
• Why onchain/token: the ERC‑20 token DDD on Ethereum is confirmed; in the Tier‑1 protocol description, the token/“digital currency” is used to pay for data access and for verifier/arbitration collateral (pledge) (see Evidence).

How it works (very briefly)

1. The developer does: uses the components/data protocol (integration details depend on the specific implementation).
2. The system does: implements “Scry Data Protocol” and related components (per the repository descriptions).
3. The developer receives: data protocol infrastructure/primitives.
4. Where the blockchain is: the token on Ethereum is confirmed; the Tier‑1 protocol description includes smart contracts that record transactions/scores and select verifiers.
5. Token role: payment for data access; pledge (collateral) for the verifier role; smart-contract verification/arbitration (per the Tier‑1 protocol description).

Quick links: AI thesis fit

Project passport

Field	Value
Project name	Scry.info
Also known as (aliases)	SCRYINFO
Logo (logo)	../assets/687_scryinfo_logo.svg
Token symbol (ticker)	DDD
Category	Infra
Primary chain (chain)	Ethereum
Type	EVM
Network status	mainnet
Consensus (consensus)	PoS (Ethereum)
Launch date (launch_date)	—
Project status (status)	—
Token (standard)	ERC-20
Token contract	0x9F5F3CFD7a32700C93F971637407ff17b91c7342
Token model (token_type)	—
Max supply	—
Issuance	—
Tokenomics (tokenomics, brief)	The protocol describes “digital currency” payments for data access and pledge (collateral) for verifiers; issuance/distribution parameters are not confirmed by Tier‑1 in this card.
Governance	—
Admins/keys	—
Audit	—
Bug bounty	—
Team (team)	—
Funding (investors/funding)	—
AI component (ai_component)	—
Use‑case (use_case)	data protocol (Scry Data Protocol)
DecAI Fit — AI thesis fit	0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary	0 / 2 / 2 / 1
Last verified	2026-02-11

Links (links_*)

Type	Link
Website	https://home.scry.info/
Docs	https://github.com/scryInfo/dp
GitHub	https://github.com/scryInfo
Releases / Changelog	—
Whitepaper	—
Roadmap	—
Security advisories	—
Explorer	https://etherscan.io/token/0x9F5F3CFD7a32700C93F971637407ff17b91c7342
X	https://twitter.com/scryinfo
Discord	—
Telegram	https://t.me/scryinfo1
Medium	https://medium.com/@scryscry8
Audit report(s)	—
Bug bounty	—
CoinGecko (profile, reference)	—
CoinMarketCap (profile, reference)	https://coinmarketcap.com/currencies/scryinfo/

General project overview

Per a Tier‑1 source (the dp repository), the protocol describes an SDK and a data-sharing process with a blockchain layer: encryption/decryption, signatures, smart contracts, events, APIs for data storage/search, as well as digital payments for data access. The participant roles described are data provider, data demander and verifier; a verifier “qualifies” through a pledge (collateral) into a smart contract.

Features/modules

• dp — “Scry Data Protocol” (per the repository description).
• dot — “componentized development framework” (per the repository description).

Typical scenarios

• Scenario 1: a data provider publishes data/metadata via the SDK → a data consumer searches for and receives data after paying “digital currency” (per the protocol description).
• Scenario 2: a data consumer initiates a compensated verification/arbitration request → a verifier is selected by the smart contract (per the protocol description).

Getting started (wallet/network)

• What you need: the dp repositories/documentation; Tier‑1 instructions mention ipfs client and geth client for a local/private network (dev environment).
• Network/chain: Ethereum (per the token contract).
• Fees: standard Ethereum network fees for operations with the token; protocol fees/payments are described as “digital currency payment” (without details on the DDD token in this card).

Architecture/tech (non‑AI)

• Components: repositories of the data protocol and components (per GitHub).
• Participant roles: data provider, data demander, verifier (per the protocol description).
• Where logic runs: encryption/signatures — via the SDK; exchange/verification/arbitration — via a smart contract (per the protocol description).
• Dependencies: dev instructions mention ipfs client and geth client.

Token/economics (expanded, no forecasts)

• Token utility: the Tier‑1 protocol description includes “digital currency” payments for data access and verifier pledge (collateral).
• Protocol necessity drivers: mechanics of payment for data access and verifier qualification through pledge are described.
• Who pays fees: the data consumer pays “digital currency” to obtain data (per the protocol description); Ethereum gas is paid by the transaction sender.
• Where fees go: not confirmed by Tier‑1 in this card.
• Issuance/burn: not confirmed by Tier‑1 in this card.
• Security/incentive mechanisms: verifier pledge; compensated verification requests; reputation/score records in a smart contract (per the protocol description).
• Distribution and token issuance schedule: not confirmed by Tier‑1 in this card.
• Treasury: not confirmed by Tier‑1 in this card.

Governance

• Who makes decisions: not confirmed by Tier‑1.
• How protocol parameters change: not confirmed by Tier‑1.
• Where decisions are discussed/made: not confirmed by Tier‑1.
• Keys/multisig: not confirmed by Tier‑1.

Security and incidents

• Audits: not confirmed by Tier‑1.
• Bug bounty: not confirmed by Tier‑1.
• Incidents: not confirmed by Tier‑1.
• Threat model: partially follows from the protocol model (data encryption, arbitration/verification via a smart contract), but a formal threat model is not confirmed by Tier‑1.

Project status and timeline

• Current status: not confirmed by Tier‑1.
• Key releases/milestones: not confirmed by Tier‑1.
• Roadmap: No Tier‑1 roadmap found.

Ecosystem/integrations

• Integrations: not confirmed by Tier‑1.
• Partners: not confirmed by Tier‑1.
• Where it’s actually used: not confirmed by Tier‑1.

AI component of the project

• What is real AI here? Per Tier‑1 sources, no confirmation of an AI component or an AI roadmap was found.
• What is truly onchain? The DDD token contract on Ethereum is confirmed; the Tier‑1 protocol description claims smart contracts that record transactions/scores and select verifiers.
• Why is a token needed? The Tier‑1 protocol description includes “digital currency” payments and verifier pledge; the connection specifically to the ERC‑20 token DDD requires separate Tier‑1 confirmation.
• Red flags (based on the information found): the absence of a Tier‑1 description of the token role and the protocol’s onchain logic; double‑check against the documentation/contracts.

DecAI Fit component summary

• DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)

Component	Level	Score
AI reality	low	0
Onchain necessity	low	2
Token necessity	low	2
Evidence	Tier‑1 partial	1

Details

AI reality

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

• AI_0 (decision): 0
• Claim (one line): No Tier‑1 AI intent was found.
• Evidence: Tier‑1 — https://github.com/scryInfo
• Why sufficient / why not (one line): per the Tier‑1 repository descriptions — data protocol/infra without AI‑intent.
• Conflict note (if any): —

AI_1 — what the AI does (1/0)

• AI_1 (decision): 0
• Claim (one line): No Tier‑1 confirmation of AI features was found.
• Evidence: Tier‑1 — https://github.com/scryInfo
• Why sufficient / why not (one line): An AI component is not established.
• Conflict note (if any): —

AI_2 — demos/examples (1/0)

• AI_2 (decision): 0
• Claim (one line): No demo of an AI component was found (an AI component is not established).
• Evidence: Tier‑1 — https://github.com/scryInfo
• Why sufficient / why not (one line): there is no subject of AI verification.
• Conflict note (if any): —

AI_3 — metrics/quality (1/0)

• AI_3 (decision): 0
• Metrics: not found (an AI component is not established).
• Context (version/date/how measured): —
• Evidence: Tier‑1 — https://github.com/scryInfo
• Why sufficient / why not (one line): AI metrics are absent.
• Conflict note (if any): —

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

• AI_4 (decision): 0
• Claim (one line): No Tier‑1 tech description of an AI component was found (the AI component is not established).
• Evidence: Tier‑1 — https://github.com/scryInfo/dp
• Why sufficient / why not (one line): AI architecture/model versions are absent.
• Conflict note (if any): —

Onchain necessity

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

• OC_1 (decision): 1
• Chain: Ethereum
• Addresses/identifiers: ERC‑20 token: 0x9F5F3CFD7a32700C93F971637407ff17b91c7342
• Evidence: Tier‑1 — https://etherscan.io/token/0x9F5F3CFD7a32700C93F971637407ff17b91c7342
• Why sufficient / why not (one line): there is a Tier‑1 onchain artifact (the token contract).
• Conflict note (if any): —

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

• OC_2 (decision): 1
• What useful logic is onchain: in the Tier‑1 protocol description, the smart contract records transactions and participant scores and participates in verifier selection/arbitration.
• Evidence: Tier‑1 — https://raw.githubusercontent.com/scryInfo/dp/master/README.md
• Why sufficient / why not (one line): protocol onchain logic is described as part of the process (not just the existence of the token).
• Conflict note (if any): —

OC_3 — onchain is critical (1/0)

• OC_3 (decision): 0
• “Replace the blockchain” test: not confirmed by Tier‑1.
• Evidence: Tier‑1 — https://github.com/scryInfo/dp
• Why sufficient / why not (one line): onchain criticality is not proven.
• Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

• TK_0 (decision): 0
• Claim (one line): No Tier‑1 confirmation that the project has no token was found.
• Evidence: Tier‑1 — https://etherscan.io/token/0x9F5F3CFD7a32700C93F971637407ff17b91c7342
• Why sufficient / why not (one line): the absence of a token is not proven.
• 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): The protocol describes payment of “digital currency” to obtain data via the SDK.
• Evidence: Tier‑1 — https://raw.githubusercontent.com/scryInfo/dp/master/README.md
• Why sufficient / why not (one line): The Tier‑1 process description includes payment for data access; the link specifically to ERC‑20 DDD requires separate confirmation.
• Conflict note (if any): —

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

• TK_2 (decision): 1
• Claim (one line): A verifier qualifies through a pledge (collateral) of a certain amount of “digital currency” into a smart contract.
• Evidence: Tier‑1 — https://raw.githubusercontent.com/scryInfo/dp/master/README.md
• Why sufficient / why not (one line): The Tier‑1 description includes pledge for the verifier role.
• Conflict note (if any): —

TK_3 — governance (1/0)

• TK_3 (decision): 0
• Claim (one line): No Tier‑1 confirmation of the governance role of the token was found.
• Evidence: Tier‑1 — https://github.com/scryInfo
• Why sufficient / why not (one line): insufficient data.
• 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 confirmed by Tier‑1.
• Evidence: Tier‑1 — https://github.com/scryInfo
• Why sufficient / why not (one line): insufficient data.
• Conflict note (if any): —

Evidence (table)

Tier	Source	What it proves
Tier‑1	https://github.com/scryInfo/dp	Repository description: “Scry Data Protocol”.
Tier‑1	https://github.com/scryInfo/dot	Repository description: “Componentized development framework”.
Tier‑1	https://raw.githubusercontent.com/scryInfo/dp/master/README.md	Process description: encryption/signatures, payment for data access, verifier pledge, arbitration/recording of scores in a smart contract.
Tier‑1	https://etherscan.io/token/0x9F5F3CFD7a32700C93F971637407ff17b91c7342	Onchain artifact: ERC‑20 token DDD contract; a list of official links (website/github/social).
Tier‑1	—	No Tier‑1 source for claim “there is an AI component/AI intent” was found.
Tier‑1	—	No Tier‑1 source for claim “the role of the DDD token in the protocol (E_TK_T1)” was found.