Guanciale

Guanciale — 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).

Guanciale — a project on the Base network, token (symbol: —).

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 project/token on the Base network; links_* contains the website/social channels and the onchain token contract.
Who it’s for: users/integrators (the specific scenario is not established per the available sources).
Why onchain/token: the token contract is verifiable; the necessity of the token and any AI claims are not confirmed by Tier‑1 per the available sources (see <details>).

How it works (very briefly)

The user does: uses the product/scenario claimed by the project (not detailed).
The system does: executes the project logic; the onchain artifact includes a token on the Base network.
The user gets: a result in terms of the product (not detailed).
Where the blockchain is: the token and transactions/events are onchain on Base (see Explorer).
Token role (if any): the token exists; the necessity per the TK flags is below.

Quick links: AI thesis fit

Project passport

Field	Value
Project name	Guanciale
Also known as (aliases)	—
Logo (logo)	../assets/474_guanciale_logo.png
Token symbol (ticker)	—
Category	AI/Other \| Infra
Primary chain (chain)	Base
Type	EVM
Network status	mainnet
Consensus (consensus)	PoS (Base; Ethereum L2)
Launch date (launch_date)	—
Project status (status)	active
Token (standard)	ERC-20
Token contract	0xcc0adB6C436eB1f65B2f27733Bf926691b94c5f1
Token model (token_type)	—
Max supply	—
Issuance	—
Tokenomics (tokenomics, brief)	per the available sources, issuance/model parameters were not extracted; the existence of the token is confirmed by the onchain contract.
Governance	—
Admins/keys	—
Audit	—
Bug bounty	—
Team (team)	—
Funding (investors/funding)	—
AI component (ai_component)	—
Use‑case (use_case)	—
DecAI Fit — AI thesis fit	0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary	ai_score 0 / onchain_score 1 / token_score 0 / evidence_score 1
Last verified	2026-02-11

Links (links_*)

Type	Link
Website	https://guanciale.ai
Docs	—
GitHub	—
Releases / Changelog	—
Whitepaper	—
Roadmap	—
Security advisories	—
Explorer	https://basescan.org/token/0xcc0adB6C436eB1f65B2f27733Bf926691b94c5f1
App / Demo	—
X	https://twitter.com/GuancialeAI
Discord	—
Telegram	https://t.me/guancialeai
Medium	—
Audit report(s)	—
Bug bounty	—
CoinGecko (profile, reference)	https://www.coingecko.com/en/coins/guanciale
CoinMarketCap (profile, reference)	https://coinmarketcap.com/currencies/guanciale/

General project overview

Guanciale is a project for which links_* specifies the website/social channels and an onchain artifact (the token contract on the Base network). Within DecAIHub, this allows verifying the minimum: the existence of the token and its onchain anchoring. Claims about an AI component and the necessity of the token are not confirmed by Tier‑1 per the available sources, so the decisions are set conservatively.

Features/modules

Onchain artifact (Tier‑1): the token contract on the Base network (see Explorer).
Public channels: X/Telegram and the project website (context; claims require Tier‑1 confirmation).

Typical scenarios

Scenario 1: token check: viewing the contract in BaseScan → basic parameters/transaction history.
Scenario 2: reviewing the project’s public materials → forming a list of what needs to be double‑checked with Tier‑1.

Getting started (wallet/network)

What you need: for onchain checks — an EVM wallet/tools (optional); for reading — the project’s public links (see links_*).
Network/chain: Base.
Fees: Base network fees apply to onchain operations (if you perform them).

Architecture/tech (non‑AI)

Components: at minimum — the token contract on Base; other product components are not established per the available sources.
Participant roles: users/integrators and the project team (without details).
Where logic runs: the token — onchain (Base); the remaining logic, if any, is probably offchain (not established).
Dependencies: Base/Ethereum infrastructure (RPC/explorer) and the project’s infrastructure (not established per the available sources).

Token/economics (expanded, no forecasts)

Token utility: not established per the available sources (there is no extracted Tier‑1 description of “what is paid for/what is received”).
Protocol necessity drivers: No Tier‑1 source for “why the key function does not work without the token” was found per the available sources.
Who pays fees: if transactions are performed on Base — the initiator pays the fees.
Where fees go: Base network fees belong to the network; separate protocol fees are not established per the available sources.
Issuance/burn: not established per the available sources.
Security/incentive mechanisms: not established per the available sources.
Distribution and token issuance schedule: not established per the available sources.
Treasury: not established per the available sources.

Governance

Who makes decisions: not established per the available sources.
How protocol parameters change: not established per the available sources.
Where decisions are discussed/made: not established per the available sources; public channels — X/Telegram (see links_*).
Keys/multisig: not established per the available sources.

Security and incidents

Audits: not established per the available sources.
Bug bounty: not established per the available sources.
Incidents: not established per the available sources.
Threat model: typical risks include smart contract risks and a mismatch between claims and verifiable artifacts; separate verification is required.

Project status and timeline

Current status: active (there are public channels/pages; without claims about activity metrics).
Key releases/milestones: not established per the available sources.
Roadmap: not found/not established per the available sources.

Ecosystem/integrations

Integrations: not established per the available sources.
Partners: not established per the available sources.
Where it’s actually used: not established per the available sources.

AI component of the project

What is real AI here? per the available sources, no Tier‑1 confirmation of an AI component was found (what the AI does/how quality is measured).
What is truly onchain? a token on the Base network (the contract is verifiable in BaseScan).
Why is a token needed? per the available sources, no Tier‑1 source was found that unambiguously records the necessity of the token per TK_1..TK_3.
Red flags (based on the information found): AI‑washing and token‑washing; what to double‑check: official docs/repositories (if they appear) for AI/onchain logic and token utility.

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	1
Token necessity	low	0
Evidence	Tier‑1 present	1

Details

AI reality

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

AI_0 (decision): 0
Claim (one line): A Tier‑1 claim about AI intent/applicability was not extracted per the available sources.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): Without an explicit Tier‑1 mention of AI as intent we set 0 (conservatively).
Conflict note (if any): —

AI_1 — what the AI does (1/0)

AI_1 (decision): 0
Claim (one line): Not established: what exactly the AI does as a component of the product.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): There is no extracted Tier‑1 description of an AI feature.
Conflict note (if any): —

AI_2 — demos/examples (1/0)

AI_2 (decision): 0
Claim (one line): No Tier‑1 App/Demo URL as “what you can touch” was found per the available sources.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): 1 requires an explicit demo surface + synchronization (links_*/Evidence/TL;DR).
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): AI metrics/benchmarks were not extracted per the available sources.
Conflict note (if any): —

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

AI_4 (decision): 0
Claim (one line): AI architecture/versions as a separate component were not extracted per the available sources.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): 1 requires a specific tech context of the AI part.
Conflict note (if any): —

Onchain necessity

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

OC_1 (decision): 1
Chain: Base
Addresses/identifiers: token contract: 0xcc0adB6C436eB1f65B2f27733Bf926691b94c5f1
Evidence: Tier‑1 — https://basescan.org/token/0xcc0adB6C436eB1f65B2f27733Bf926691b94c5f1
Why sufficient / why not (one line): The existence of the onchain artifact is verifiable via BaseScan.
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 the available sources.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): 1 requires a specific Tier‑1 artifact/description.
Conflict note (if any): —

OC_3 — onchain is critical (1/0)

OC_3 (decision): 0
“Replace the blockchain” test: not established per the available sources.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): OC_3=1 requires an explicit argument and a source.
Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

TK_0 (decision): 0
Claim (one line): The token exists (there is a token contract on Base).
Evidence: Tier‑1 — https://basescan.org/token/0xcc0adB6C436eB1f65B2f27733Bf926691b94c5f1
Why sufficient / why not (one line): The onchain contract 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): Not established: mandatory payment for the service with the token.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): There is no extracted Tier‑1 pay‑for‑service mechanism.
Conflict note (if any): —

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

TK_2 (decision): 0
Claim (one line): Not established: incentives/collateral/penalty as a mandatory mechanism.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): There is no extracted Tier‑1 description of the mechanism.
Conflict note (if any): —

TK_3 — governance (1/0)

TK_3 (decision): 0
Claim (one line): Not established: a governance mechanism where the token is mandatory.
Evidence: Tier‑1 — —
Why sufficient / why not (one line): There is no extracted Tier‑1 governance description.
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 (no Tier‑1 argument per the available sources).
Evidence: Tier‑1 — —
Why sufficient / why not (one line): 1 requires a specific conclusion and a source.
Conflict note (if any): —

Evidence (table)

Tier	Source	What it proves
Tier‑1	https://basescan.org/token/0xcc0adB6C436eB1f65B2f27733Bf926691b94c5f1	Onchain fact: the token contract on the Base network (OC_1/TK_0).
Tier‑1	—	No Tier‑1 source for claim “what is real AI here” was found per the available sources.
Tier‑1	—	No Tier‑1 source for claim “why is a token needed (pay‑for‑service / collateral / governance)” was found per the available sources.
Tier‑2	https://www.coingecko.com/en/coins/guanciale	Reference profile of the token/project (context).
Tier‑2	https://coinmarketcap.com/currencies/guanciale/	Reference profile of the token/project (context).