Trusta.AI

Trusta.AI — 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).

Trusta.AI — an identity / reputation protocol for crypto+AI (POH/anti‑Sybil, attestations), token: TA.

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/service for verifiable identity and reputation in Web3 (attestations, anti‑Sybil scoring).
Who it’s for: projects that need Sybil protection and account assessment; users who receive attestations.
Why onchain/token: attestations are recorded onchain; the token is claimed for payments, role staking and governance.

How it works (very briefly)

The user does: undergoes verification/scoring for a specific scenario (airdrop, access, etc.).
The system does: computes anti‑Sybil/reputation indicators and issues attestations.
The user gets: a confirmation/attestation and score(s) usable by integrators.
Where the blockchain is: attestations are claimed as onchain artifacts.
Token role (if any): $TA is claimed for payments, role staking and governance.

Quick links: AI thesis fit

Project passport

Field	Value
Project name	Trusta.AI
Also known as (aliases)	Trusta Labs; TrustGo; TrustScan; $TA
Logo (logo)	../assets/144_trusta-ai_logo.png
Token symbol (ticker)	TA
Category	AI/Other
Primary chain (chain)	BNB Smart Chain
Type	EVM
Network status	mainnet
Consensus (consensus)	PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date)	—
Project status (status)	active
Token (standard)	BEP-20
Token contract	0x539ae81a166e5e80aed211731563e549c411b140
Token model (token_type)	utility (payments + staking + governance)
Max supply	1,000,000,000 TA (tokenomics; OFT/cross-chain supply may differ across networks)
Issuance	fixed (cap)
Tokenomics (tokenomics, brief)	Total supply capped at 1B; initial circulation 18% (tokenomics).
Governance	DAO (as claimed)
Admins/keys	—
Audit	—
Bug bounty	—
Team (team)	—
Funding (investors/funding)	early backers allocation 13% (tokenomics)
AI component (ai_component)	AI + knowledge graphs for Sybil score/PoH
Use‑case (use_case)	on-chain identity, anti-Sybil + reputation scoring
DecAI Fit — AI thesis fit	3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary	1 / 2 / 3 / 2
Last verified	2026-02-11

Links (links_*)

Type	Link
Website	https://www.trustalabs.ai/
Docs	https://trusta-labs.gitbook.io/trustaai
GitHub	https://github.com/TrustaLabs
Releases / Changelog	—
Whitepaper	https://trusta-labs.gitbook.io/trustaai
Roadmap	—
Security advisories	—
Explorer	https://bscscan.com/token/0x539ae81a166e5e80aed211731563e549c411b140
X	https://twitter.com/TrustaLabs
Discord	https://discord.com/invite/rtwSQxDM6F
Telegram	https://t.me/TrustalabsAnn
Medium	https://medium.com/@trustalabs.ai
Audit report(s)	—
Bug bounty	—
CoinGecko (profile, reference)	https://www.coingecko.com/en/coins/trusta-ai
CoinMarketCap (profile, reference)	https://coinmarketcap.com/currencies/trusta-ai/

General project overview

Trusta.AI is positioned as identity infrastructure for human + AI “intelligences” in the crypto ecosystem: issuance of attestations, anti‑Sybil scoring and reputation/credit assessment.

Features/modules

TrustGo: account assessment (MEDIA score).
TrustScan: Sybil score; AI and a knowledge graph are claimed.
Trusta Attestation Service: issuance/verification of onchain attestations.
Trusta Agent: attestations for POH/POI and AI agents (claimed).

Typical scenarios

Scenario 1: a project filters Sybil accounts in a campaign/airdrop.
Scenario 2: a user receives an attestation and uses it for access/participation.
Scenario 3: a protocol uses the reputation/credit signal in its rules.

Getting started (wallet/network)

What you need: a wallet and participation in a specific scenario/integration.
Network/chain: the token in this card is tied to BNB Smart Chain; other networks are also mentioned in the docs.
Fees: network fees + service fees in the specific product (where applicable).

Architecture/tech (non‑AI)

Components: onchain attestations, SDK/API, offchain computation of scores.
Roles: End Users (provers), issuers/verifiers, AI infrastructure providers (tokenomics).
Where the logic is: attestations — onchain; scoring/graphs — likely offchain (no details in Tier‑1).

Token/economics (expanded, no forecasts)

Token utility (Tier‑1): the tokenomics describes payments, staking (for roles) and governance; a future role as a gas token is also claimed.
Distribution/vesting: the tokenomics contains the distribution by role and the TGE unlock; initial circulation 18%.

Governance

Governance (Tier‑1): the governance role of $TA is described in the tokenomics.

Security and incidents

Audits / bug bounty: Tier‑1 links are not listed in this card.
Risks: scoring errors/false positives; centralization of score computation; key/attestation risks.

Project status and timeline

Current status: active (there are public TrustGo/TrustScan products/pages and documentation).
Key releases/milestones: — (no Tier‑1 release dates/versions recorded).
Roadmap: — (no Tier‑1 roadmap found).

Ecosystem/integrations

Integrations: not established (no Tier‑1 list of integrations/cases found).
Partners: — (no Tier‑1 confirmed list of partners found).
Where it’s actually used: anti‑Sybil/attestations for campaigns and integrators (general scenario); specific public Tier‑1 cases require a separate list.

AI component of the project

What is real AI here? TrustScan claims the use of AI and knowledge graphs for Sybil score/POH.
What is truly onchain? Onchain attestations (POH/identity), which are then used by integrators.
Why is a token needed? $TA is claimed for payments + role staking + governance (and potentially as gas).
Red flags (based on the information found): AI‑washing — medium/high (no technical description/metrics/benchmarks); onchain‑washing — medium (the boundaries between onchain attestations and offchain scoring require an explicit specification); token‑washing — medium (confirmed mechanics of fees/the mandatory nature of the token in the products are needed).

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	2

Details

AI reality

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

AI_0 (decision): 0
Claim (one line): — (there is AI_1 per the Tier‑1 description of functions)
Evidence: Tier‑1 — https://trusta-labs.gitbook.io/trustaai
Why sufficient / why not (one line): AI_0 is set only if AI_1..AI_4 = 0.
Conflict note (if any): —

AI_1 — what the AI does (1/0)

AI_1 (decision): 1
Claim (one line): TrustScan uses AI and knowledge graphs for Sybil score/POH.
Evidence: Tier‑1 — https://trusta-labs.gitbook.io/trustaai
Why sufficient / why not (one line): The Tier‑1 source explicitly describes AI+knowledge graph as part of TrustScan.
Conflict note (if any): —

AI_2 — demos/examples (1/0)

AI_2 (decision): 0
Claim (one line): No public Tier‑1 demo/examples of the scoring in operation were found.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): There is a description, but no reproducible example.
Conflict note (if any): —

AI_3 — metrics/quality (1/0)

AI_3 (decision): 0
Metrics: —
Context (version/date/how measured): —
Evidence: Tier‑1 — —
Why sufficient / why not (one line): The docs used contain no quantitative quality metrics.
Conflict note (if any): —

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

AI_4 (decision): 0
Claim (one line): No technical description of models/versions was found.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): There is a functional description (AI_1), but no architecture/versions.
Conflict note (if any): —

Onchain necessity

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

OC_1 (decision): 1
Chain: BNB Smart Chain
Addresses/identifiers: token: 0x539ae81a166e5e80aed211731563e549c411b140
Evidence: Tier‑1 — https://bscscan.com/token/0x539ae81a166e5e80aed211731563e549c411b140
Why sufficient / why not (one line): The explorer confirms the network and 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: onchain attestations for identity/POH and integrations.
Evidence: Tier‑1 — https://trusta-labs.gitbook.io/trustaai (the volume of “on-chain attestations”)
Why sufficient / why not (one line): The docs contain a direct statement about onchain attestations as a product artifact.
Conflict note (if any): —

OC_3 — onchain is critical (1/0)

OC_3 (decision): 0
“Replace the blockchain” test: No Tier‑1 argument “without the blockchain, X breaks down” was found.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): An explicit “replace the blockchain” test is needed (see the rules).
Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

TK_0 (decision): 0
Claim (one line): The project has a claimed token, $TA.
Evidence: Tier‑1 — https://trusta-labs.gitbook.io/trustaai/tokenomics
Why sufficient / why not (one line): The tokenomics describes the token.
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): $TA is used to pay for identity/attestation services and SDK/API integrations.
Evidence: Tier‑1 — https://trusta-labs.gitbook.io/trustaai/tokenomics
Why sufficient / why not (one line): The tokenomics describes the Payment Utility.
Conflict note (if any): —

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

TK_2 (decision): 1
Claim (one line): staking $TA is mandatory for the issuer/verifier/infra provider roles.
Evidence: Tier‑1 — https://trusta-labs.gitbook.io/trustaai/tokenomics
Why sufficient / why not (one line): The tokenomics describes the Staking Utility as a condition of participation.
Conflict note (if any): —

TK_3 — governance (1/0)

TK_3 (decision): 1
Claim (one line): governance votes on future development/initiatives.
Evidence: Tier‑1 — https://trusta-labs.gitbook.io/trustaai/tokenomics
Why sufficient / why not (one line): The tokenomics describes the governance role of the token.
Conflict note (if any): —

TK_4 — token is replaceable (1/0)

TK_4 (decision): 0
Claim (one line): Replaceability has not been assessed.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): Insufficient data for a conclusion.
Conflict note (if any): —

Evidence (table)

Tier	Source	What it proves
Tier‑1	https://trusta-labs.gitbook.io/trustaai	AI+knowledge graph in TrustScan; the existence of onchain attestations.
Tier‑1	https://trusta-labs.gitbook.io/trustaai/tokenomics	Supply/distribution and token utility (payments/staking/governance).
Tier‑1	https://bscscan.com/token/0x539ae81a166e5e80aed211731563e549c411b140	The token contract on BSC (BEP‑20).