Skip to main content

Otto

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

Otto — a project/token on the Base network (EVM). Per Tier‑1 sources, a verifiable description of the AI component could not be established; the flags are set conservatively.

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 token on the Base network (ERC‑20).
  • Who it’s for: users who interact with the token (wallets/DEX/transfers); a description of the product/features is not established per Tier‑1 sources.
  • Why onchain/token: onchain records ownership and transfers of the token; useful onchain logic other than the token is not established per Tier‑1 sources.

How it works (very briefly)

  1. The user does: transfers/receives the token or swaps it on a DEX.
  2. The system does: records transactions and updates balances on the Base network.
  3. The user gets: a confirmed onchain state (balance/transaction history).
  4. Where the blockchain is: the token contract, ownership and transfers (Base).
  5. Token role: the protocol role of the token (payments/incentives/governance) is not confirmed by Tier‑1 sources.

Quick links: AI thesis fit

Project passport

Field Value
Project name Otto
Also known as (aliases) —
Logo (logo) ../assets/602_otto_logo.svg
Token symbol (ticker) OTTO
Category AI/Agents
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 0x62Ff28a01AbD2484aDb18C61f78f30Fb2E4A6fDb
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) Per Tier‑1 sources, no description of the token’s utility/issuance/distribution was found.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) —
Use‑case (use_case) AI agent token
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 0
Last verified 2026-02-11

General project overview

Otto is a project/token on the Base network. Per Tier‑1 sources, a verifiable description of the product (what exactly the AI does, whether there is a demo/code/metrics) is not established. Therefore the card is filled in conservatively: the onchain fact of the token is confirmed, the AI flags are left at 0.

Features/modules

  • ERC‑20 token on Base: the contract and onchain history are available via the explorer.
  • Public channels: website and social channels (see links_*).

Typical scenarios

  • Scenario 1: a user transfers/receives OTTO → the transaction is recorded onchain on Base.
  • Scenario 2: a user checks the contract and transactions in the explorer → verifies the token address and activity.

Getting started (wallet/network)

  • What you need: an EVM wallet with Base support.
  • Network/chain: Base (mainnet).
  • Fees: Base network fees for transactions.

Architecture/tech (non‑AI)

  • Components: the ERC‑20 contract; wallets; network explorers/indexers.
  • Participant roles: token holders; wallet users; validators/sequencer (at the Base network level).
  • Where logic runs: onchain (token accounting and transfers) + offchain (UI of wallets/DEX/explorers).
  • Dependencies: Base RPC/indexers (for displaying data).

Token/economics (expanded, no forecasts)

  • Token utility: not established per Tier‑1 sources.
  • Protocol necessity drivers: not established per Tier‑1 sources.
  • Who pays fees: users of the Base network when making transactions.
  • Where fees go: to network validators/operators (at the Base/Ethereum level).
  • Issuance/burn: not found per Tier‑1 sources.
  • Security/incentive mechanisms: not found per Tier‑1 sources.
  • Distribution and token issuance schedule: not found per Tier‑1 sources.
  • Treasury: not found per Tier‑1 sources.

Governance

  • Who makes decisions: not established per Tier‑1 sources.
  • How protocol parameters change: —.
  • Where decisions are discussed/made: —.
  • Keys/multisig: —.

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: the risks are typical for tokens/wallets (phishing, address substitution, the risk of interacting with unaudited dApps); project‑specific details were not found per Tier‑1 sources.

Project status and timeline

  • Current status: mainnet (the token is deployed on the Base network).
  • Key releases/milestones: —.
  • Roadmap: —.

Ecosystem/integrations

  • Integrations: EVM wallets and explorers (as the network infrastructure layer).
  • Partners: —.
  • Where it’s actually used: onchain activity is available via the explorer (see links_*).

AI component of the project

  • What is real AI here? Per Tier‑1 sources, it was not possible to confirm a description of the AI component (what exactly the AI does and how to verify it).
  • What is truly onchain? The token contract and operations/balances on the Base network.
  • Why is a token needed? The utility of the token (payments/incentives/governance) is not established per Tier‑1 sources.
  • Red flags (based on the information found): the “AI‑agent” label without a Tier‑1 tech description/demo/code/metrics; “onchain” as a synonym for the existence of a token without useful protocol logic; reliance on aggregators instead of primary sources.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality no data 0
Onchain necessity low 1
Token necessity low 0
Evidence Tier‑1 partial 0
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): No Tier‑1 roadmap/declaration of AI intent was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Without a Tier‑1 source we set 0 (conservatively).
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): A description of AI features/model/agent is not confirmed by Tier‑1 sources.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no verifiable description of “what exactly the AI does”.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): No Tier‑1 demo/example of the AI in operation was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no demo surface confirming an AI component.
  • 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): Metrics/benchmarks were not found in Tier‑1 sources.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): No tech description of the AI component/architecture was found in Tier‑1 sources.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Without tech docs/code/architecture we set 0 (conservatively).
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base
  • Addresses/identifiers: ERC‑20: 0x62Ff28a01AbD2484aDb18C61f78f30Fb2E4A6fDb
  • Evidence: Tier‑1 — https://basescan.org/token/0x62Ff28a01AbD2484aDb18C61f78f30Fb2E4A6fDb
  • Why sufficient / why not (one line): The onchain artifact (token contract) is observable via the network explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: Not established (no description of protocol logic other than the token was found per Tier‑1 sources).
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): The existence of a token by itself does not prove useful onchain logic.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: no property of the product that breaks down without the blockchain (other than the existence of the token) was found per Tier‑1 sources.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no proof of “onchain criticality” per Tier‑1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, OTTO (ERC‑20), on the Base network.
  • Evidence: Tier‑1 — https://basescan.org/token/0x62Ff28a01AbD2484aDb18C61f78f30Fb2E4A6fDb
  • Why sufficient / why not (one line): The onchain token 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): No mechanism of payment for the service with the token was found in Tier‑1 sources.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no Tier‑1 description of the “payment for the service” use case.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): No mechanics of token‑based incentives/collateral/penalties were found in Tier‑1 sources.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There are no Tier‑1 artifacts of protocol token mechanics.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): No use of the token for governance was found in Tier‑1 sources.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no Tier‑1 description of onchain governance.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability/irreplaceability of the token is not established per Tier‑1 sources.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Without a description of the protocol role of the token, we draw a conservative conclusion of 0 (not established).
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://basescan.org/token/0x62Ff28a01AbD2484aDb18C61f78f30Fb2E4A6fDb Onchain fact of the existence of the OTTO token on the Base network (contract, transactions, holders).
Tier‑1 https://www.onchainotto.ai/ The project’s official website (a verifiable tech description of the product was not found/not extracted per the available Tier‑1).
Tier‑1 — No Tier‑1 source for claim “the project has a verifiable AI component (what exactly the AI does)” was found.
Tier‑1 — No Tier‑1 source for claim “there is useful onchain logic other than the token” was found.
Tier‑1 — No Tier‑1 source for claim “the token is needed for payments/incentives/governance” was found.
Tier‑2 https://www.coingecko.com/en/coins/otto Reference aggregator card (context; not proof).
Tier‑2 https://coinmarketcap.com/currencies/otto/ Reference aggregator card (context; not proof).

No comments to display

Back to top