Skip to main content

Keira

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

Keira — an AI/Agents project on the Base network, token (symbol: KEIRA).

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: an AI agent (claimed) that helps perform typical onchain actions (swaps, NFT operations, in‑game actions).
  • Who it’s for: Web3 users, as well as teams/platforms that want to connect modules (minions) as SaaS features.
  • Why onchain/token: the token is claimed as an instrument of access to features, incentives (staking) and voting; the onchain part is needed for executing transactions and for the token mechanisms.

How it works (very briefly)

  1. The user does: formulates a request (for example, “make a swap”, “help me buy/sell an NFT”).
  2. The system does: interprets the intent and selects a “minion”/tools for the task (claimed).
  3. The user gets: hints/an action plan and (if permitted) execution of the operation via integrations.
  4. Where the blockchain is: execution of onchain operations (swaps/NFTs/transactions) and the onchain logic of the token.
  5. Token role (if any): access to premium features, staking mechanics and governance (claimed in the litepaper).

Quick links: AI thesis fit

Project passport

Field Value
Project name Keira
Also known as (aliases) Keira AI, $KEIRA
Logo (logo) ../assets/657_keira_logo.png
Token symbol (ticker) KEIRA
Category AI/Agents | Consumer
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 0x710eec215b3bb653d42fc6e70e0531ea13f51a7a
Token model (token_type) utility (payments + staking + governance)
Max supply —
Issuance —
Tokenomics (tokenomics, brief) The litepaper claims staking mechanics and a share of revenue allocated to a buyback mechanism.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) LLM task orchestration + minion modules
Use‑case (use_case) on-chain assistant (swaps, NFTs, games)
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 2 / onchain_score 1 / token_score 3 / evidence_score 3
Last verified 2026-02-11

General project overview

In the litepaper, Keira is described as an “onchain AI agent” that acts as a single interface for disparate onchain scenarios: NFT operations, token swaps and in‑game actions. A modular architecture (“Minions Framework”) is also claimed, where specialized modules can be used separately and licensed as vertical SaaS solutions.

Features/modules

  • Keira OS (claimed): LLM core + orchestration layer + minions/tools.
  • Minions Framework (claimed): specialized modules for NFT trading, token trading/DeFi and in‑game scenarios.

Typical scenarios

  • Scenario 1: a user asks to perform an onchain action (a swap/NFT operation) → the agent (claimed) selects the steps and tools.
  • Scenario 2: a user selects a “minion” (for example, NFT‑trader) → gets specialized hints/automation (claimed).
  • Scenario 3: a platform licenses a minion module as SaaS → embeds it into its product (claimed).

Getting started (wallet/network)

  • What you need: a wallet/account and funds for network fees.
  • Network/chain: Base (per the token address in the explorer; see links_*).
  • Fees: network fees for onchain operations.

Architecture/tech (non‑AI)

  • Components (per the litepaper): orchestration layer (context/sessions), minions/tools, integrations with blockchain networks and external APIs.
  • Participant roles: users, developers/integrators, business clients (licensing of minions).
  • Where logic runs: computation/decision‑making — offchain (claimed); onchain — execution of transactions and the token logic.
  • Dependencies: DEX/NFT marketplaces/explorers and other external services (claimed).

Token/economics (expanded, no forecasts)

  • Token utility (per the litepaper): access to premium features/minions, payment of internal fees/features, staking mechanics, governance.
  • Incentive mechanisms (per the litepaper): staking rewards; a buyback mechanism financed from part of the revenue is claimed.
  • Supply/vesting parameters: not found per Tier‑1.

Governance

  • Who makes decisions: the litepaper claims voting by token holders on changes to the ecosystem.
  • How protocol parameters change: not established (details of the process were not found per Tier‑1).

Security and incidents

  • Audits: not found per Tier‑1.
  • Bug bounty: not found per Tier‑1.
  • Incidents: —.
  • Threat model: typical risks for onchain integrations and token contracts; no specifics were found per Tier‑1.

Project status and timeline

  • Current status: mainnet (per the Base network; see links_*).
  • Key releases/milestones: —.
  • Roadmap: not found per Tier‑1.

Ecosystem/integrations

  • Integrations: DEX/NFT marketplaces/explorers and external APIs (claimed).
  • Partners: —.
  • Where it’s actually used: not established; re‑checking against product artifacts/demos is required.

AI component of the project

  • What is real AI here? the litepaper describes an AI agent (Generative AI) and “Keira OS” with an LLM core and orchestration layer (no proof of metrics/demos was found per Tier‑1).
  • What is truly onchain? the token contract on the Base network is confirmed; the rest of the product’s onchain infrastructure/contracts are not established per Tier‑1.
  • Why is a token needed? the litepaper claims the roles: access to features, staking incentives, governance and internal “transaction facilitation”.
  • Red flags (based on the information found): many claims about capabilities without a reproducible demo and metrics; other than the token, there are no addresses of key onchain components; the role of the token requires verification against contracts/facts of use.

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity low 1
Token necessity high 3
Evidence Tier‑1 present 3
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): AI is described as part of the product (agent/OS), not only as an “intent/roadmap”.
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper
  • Why sufficient / why not (one line): We set AI_0 to 0 when Tier‑1 already describes AI as an existing component (this flag is not needed for an intent signal).
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The LLM core (decision-making model) interprets requests and orchestrates “minions/tools” for onchain tasks (claimed).
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper ; https://keira-ai.gitbook.io/keira-litepaper/keira-os
  • Why sufficient / why not (one line): Tier‑1 describes the functional role of the AI part (request understanding, tool selection, multi‑step scenarios).
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): No public reproducible demo/guide on using the product was found per Tier‑1.
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper
  • Why sufficient / why not (one line): AI_2=1 requires a specific “what you can touch” artifact (app/demo/tutorial).
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper
  • Why sufficient / why not (one line): Quantitative quality metrics of the AI/models/agent were not found in Tier‑1.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The Keira OS architecture is described: LLM decision model + orchestration layer + minions/tools (claimed).
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper/keira-os
  • Why sufficient / why not (one line): There is a tech description of the architectural layers and modularity (minions framework), sufficient for AI_4=1.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base
  • Addresses/identifiers: token contract 0x710eec215b3bb653d42fc6e70e0531ea13f51a7a
  • Evidence: Tier‑1 — https://basescan.org/token/0x710eec215b3bb653d42fc6e70e0531ea13f51a7a
  • Why sufficient / why not (one line): There is a verifiable onchain artifact (the token contract) and a network.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: Per Tier‑1, no product addresses/contracts (other than the token) that confirm useful onchain logic were found.
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper
  • Why sufficient / why not (one line): Without addresses/contracts/a specification of onchain logic we set 0 (conservatively).
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: onchain criticality is not established per Tier‑1; the descriptions allow that some functions could work offchain.
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper
  • Why sufficient / why not (one line): OC_3=1 requires the argument “a key property breaks down without the blockchain” + confirmation.
  • 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, $KEIRA.
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper/usdkeira-token
  • Why sufficient / why not (one line): Tier‑1 describes the token utility and tokenomics.
  • 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 litepaper claims the use of the token for paying internal fees/transactions in the ecosystem.
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper/usdkeira-token
  • Why sufficient / why not (one line): “Transaction facilitation / gas fees” are listed as token utility.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): The litepaper claims staking rewards and incentives for holders/stakers.
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper/usdkeira-token
  • Why sufficient / why not (one line): Staking rewards are described as part of the token utility.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): The litepaper claims governance/voting for token holders (propose/vote).
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper/usdkeira-token
  • Why sufficient / why not (one line): Governance & voting are described as token utility.
  • 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.
  • Evidence: Tier‑1 — https://keira-ai.gitbook.io/keira-litepaper/usdkeira-token
  • Why sufficient / why not (one line): TK_4=1 requires a justification that the token’s functions can easily be replaced by an alternative without loss of meaning.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://keira-ai.gitbook.io/keira-litepaper Tier‑1 description of the project as an “onchain AI agent” and of the claimed scenarios.
Tier‑1 https://keira-ai.gitbook.io/keira-litepaper/keira-os Tier‑1 tech description of the Keira OS architecture (LLM + orchestration + minions/tools).
Tier‑1 https://keira-ai.gitbook.io/keira-litepaper/usdkeira-token Tier‑1 description of the token utility (access, staking rewards, governance, transaction facilitation) and the buyback mechanism (claimed).
Tier‑1 https://basescan.org/token/0x710eec215b3bb653d42fc6e70e0531ea13f51a7a Onchain artifact: the token contract on the Base network.

No comments to display

Back to top