Skip to main content

HeyElsa

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

HeyElsa (Elsa) — an AI/Agents | DeFi project: an AI copilot for performing onchain actions (swap/bridge/stake etc.) through dialogue and multi‑agent orchestration; the ELSA token is declared as utility for execution/inference/access.

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 copilot application: the user formulates an “intent”, and the system plans and performs actions in web3 scenarios.
  • Who it’s for: users who need an “intent → action” interface for DeFi actions, and partners/developers who embed the widget/SDK.
  • Why onchain/token: onchain is where the target actions are executed (transactions/positions); the ELSA token is described as utility for execution/inference/feature access (exact terms — in the litepaper).
  • What you can actually touch (Tier‑1): https://app.heyelsa.ai/ (web‑app).

How it works (very briefly)

  1. The user does: formulates a task in chat (swap/bridge/strategy/automation) or launches the widget in a partner application.
  2. The system does: turns intent into a plan, orchestrates specialist agents, and checks constraints/security (simulation/guardrails).
  3. The user gets: the completed operation(s) and/or a report/receipts on transactions.
  4. Where the blockchain is: final execution consists of onchain transactions on supported networks/protocols; the onchain artifact of the token is the ELSA contract on the Base network.
  5. Token role (if any): ELSA is claimed as a utility token (execution/inference/access; fee discounts, feature access, gas abstraction).

Quick links: AI thesis fit

Project passport

Field Value
Project name HeyElsa
Also known as (aliases) Elsa, ELSA
Logo (logo) ../assets/902_heyelsa_logo.svg
Token symbol (ticker) ELSA
Category AI/Agents | DeFi
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 0x29cc30f9d113b356ce408667aa6433589cecbdca
Token model (token_type) utility (payments + staking + governance)
Max supply 1 000 000 000 ELSA
Issuance —
Tokenomics (tokenomics, brief) Total supply: 1,000,000,000; utility: execution/inference/access (as claimed).
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) multi-agent orchestration (intent → action)
Use‑case (use_case) DeFi execution copilot + widget/SDK
DecAI Fit — AI thesis fit 4/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 1 / token_score 0 / evidence_score 3
Last verified 2026-02-11

General project overview

Per Tier‑1 sources, HeyElsa (Elsa) is an AI copilot and “crypto agent layer” that translates user intent into a plan and performs web3 actions. The litepaper describes the stack as a multi‑agent system: from intent parsing and orchestration to the execution layer (simulation, guardrails, routing, receipts).

The product is described through 3 surfaces:

  • Copilot (B2C): a chat interface for actions (swap/bridge/stake etc.).
  • Widget & SDK (B2B): embedding “trade with AI” into wallets/dApps/content applications.
  • AgentOS: an environment for creating/hosting specialized agents and coordinating them.

Features/modules

  • Intent → plan → execute: converting a request into a plan and executing transactions.
  • Multi-agent system: a set of “specialists” (swap/bridge/yield/risk etc.) and coordination via A2A.
  • Execution & safety: simulations, policy/guardrails, “receipts” for execution results (claimed).
  • Partner integrations: widget/SDK and callbacks (claimed).

Typical scenarios

  • Scenario 1: a user writes “do X” → the system prepares steps/transactions → the user confirms execution.
  • Scenario 2: a partner embeds the widget → the user launches a scenario from a third-party interface → receives receipts.
  • Scenario 3: a builder publishes an agent/integration → the agent participates in planning/execution.

Getting started (wallet/network)

  • What you need: web access to the Elsa application.
  • Network/chain: depends on the action and supported networks; the ELSA token is deployed on the Base network (onchain artifact — the token contract).
  • Fees: depend on the onchain operations performed (gas/fees); the litepaper claims fee discounts/gas abstraction mechanics for ELSA.

Architecture/tech (non‑AI)

  • Components: intent layer + orchestration + A2A coordination + execution layer + safety/policy + observability (described in the litepaper).
  • Participant roles: users; partners (widget/SDK); agent builders (AgentOS).
  • Where logic runs: planning/validation — offchain; final execution — onchain transactions.

Token/economics (expanded, no forecasts)

  • Token parameters (Tier‑1): total supply 1,000,000,000; Base network; decimals 18.
  • Token utility (Tier‑1): execution/inference/feature access; fee discounts; gas abstraction (claimed).

Governance

  • Not established per Tier‑1: a unified, described governance process (DAO/voting/parameters).

Security and incidents

  • Audits/bug bounty: not established per Tier‑1.
  • Safety claims: described as part of the architecture (simulation/guardrails), require further verification via public artifacts (code/audits).

Project status and timeline

  • Current status: the product is available as a web application; the roadmap is described in the litepaper and documentation.

AI component of the project

  • What is real AI here? a multi‑agent system that plans/validates and performs actions (intent → action) and uses multi‑LLM routing (described in the litepaper/docs).
  • What is truly onchain? final execution — onchain transactions; the onchain artifact of the token is the ELSA contract on the Base network.
  • Why is a token needed? in Tier‑1 sources, ELSA is described as utility for execution/inference/access (fee discounts, feature access, gas abstraction).
  • Red flags (based on the information found): much of “safety/guardrails” is described as design; public artifacts (code/audits/security programs) are not confirmed per Tier‑1.

DecAI Fit component summary

  • DecAI Fit: 4/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity low 1
Token necessity low 0
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 a working component of the product (agent layer), not just an “intention”.
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/ ; https://docs.heyelsa.ai/
  • Why sufficient / why not (one line): the intent flag adds no signal when Tier‑1 already describes AI mechanics in the product.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The AI layer translates intent into a plan and coordinates specialized agents for execution (intent → action).
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/ ; https://docs.heyelsa.ai/
  • Why sufficient / why not (one line): Tier‑1 sources explicitly describe a multi‑agent system, orchestration, and execution.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): The Elsa web application is available (an intent → action demo surface).
  • Evidence: Tier‑1 — https://app.heyelsa.ai/ ; https://www.heyelsa.ai/
  • Why sufficient / why not (one line): there is an accessible product through which scenarios can be executed.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.heyelsa.ai/
  • Why sufficient / why not (one line): Quality metrics are not recorded per Tier‑1.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The litepaper describes a layered architecture (intent/orchestration/A2A/agents/execution/safety).
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/
  • Why sufficient / why not (one line): The Tier‑1 document contains a coherent tech description of components and flows.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base
  • Addresses/identifiers: ELSA token (ERC‑20): 0x29cc30f9d113b356ce408667aa6433589cecbdca
  • Evidence: Tier‑1 — https://basescan.org/token/0x29cc30f9d113b356ce408667aa6433589cecbdca
  • Why sufficient / why not (one line): the token contract address on a public network is a verifiable onchain fact.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: —
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/
  • Why sufficient / why not (one line): Without a Tier‑1 description of protocol logic, OC_2 cannot be confirmed.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: —
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/
  • Why sufficient / why not (one line): Onchain criticality requires formal justification and sources.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, ELSA.
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/ ; https://basescan.org/token/0x29cc30f9d113b356ce408667aa6433589cecbdca
  • Why sufficient / why not (one line): Tier‑1 sources describe the token and confirm the onchain contract.
  • 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): ELSA is described as utility for execution/inference and B2B use (fees/fees/access).
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/
  • Why sufficient / why not (one line): The Tier‑1 document lists token use cases (execution/inference/access).
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): The litepaper mentions staking, but the mechanics of incentives/collateral/penalties as a mandatory onchain mechanism are not recorded.
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/
  • Why sufficient / why not (one line): “1” requires a described protocol mechanism (terms/contracts/parameters).
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): The use of the token for governance is not established per Tier‑1.
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/
  • Why sufficient / why not (one line): “1” requires a described governance process; the litepaper does not establish it as a mechanism.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): The role of the token appears “optional/add-on” (access/discounts/gas abstraction), rather than a fundamental onchain necessity.
  • Evidence: Tier‑1 — https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/
  • Why sufficient / why not (one line): Tier‑1 describes utility as access/fees/inference; without a proven protocol “must-have”, we allow for replaceability.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://www.heyelsa.ai/ Product positioning as an AI crypto copilot and access to the application.
Tier‑1 https://docs.heyelsa.ai/ Product/architecture documentation (overview).
Tier‑1 https://blog.heyelsa.ai/heyelsa-the-crypto-agent-layer-litepaper/ Multi‑agent “intent → action” architecture, safety/execution layer, and token parameters/utility.
Tier‑1 https://app.heyelsa.ai/ An accessible web application (demo surface).
Tier‑1 https://basescan.org/token/0x29cc30f9d113b356ce408667aa6433589cecbdca Onchain fact: the ELSA token contract on Base; max total supply 1B.
Tier‑2 https://coinmarketcap.com/currencies/heyelsa/ Aggregator profile (context).
Tier‑2 https://www.coingecko.com/en/coins/elsa Aggregator profile (context).

No comments to display

Back to top