HeyElsa (ELSA) Price

HeyElsa is a crypto agent layer that turns a user's natural-language goal into an onchain execution plan: a user can request a swap, cross-chain transfer, staking, or automation, and the system then attempts to break the request down and execute it. It is not a token network that takes custody of users' assets; its focus is to consolidate operational entry points that were previously distributed across wallets, chains, and protocols into an execution service for users or partners. Its process begins at the intent layer. This layer organizes text or voice into a structured intent, which may include the action, asset, amount, chain, time limit, and constraints such as maximum slippage; when information is missing, an asset or chain is ambiguous, or confidence is low, the design requires the user to clarify. The orchestration layer then generates a plan with step dependencies, success conditions, and fallback paths according to task complexity, latency, risk, required wallet authorizations, and available chains/protocols, and assigns subtasks to the relevant agents. Before execution, the execution layer can use pre-audited scripts, transaction simulations, route selection, and policy limits to check the plan; after submission, it collects transaction IDs, status, actual slippage, fees, and receipts. Therefore, “entering one sentence” does not mean every request will be filled directly: when a plan is infeasible, alternatives may be returned, and policies may restrict operations because of allowlists, amount or risk limits, geographic restrictions, or KYC conditions.

ELSA is HeyElsa's utility token on the Base network, with a fixed total supply of 1 billion tokens and 18 decimal places. The official Litepaper positions it as a token supporting execution, reasoning, and access; it does not state that it represents company equity, ownership of underlying assets, or an inherent governance right. The 1 billion figure refers to total supply, not the number that can be traded or is circulating at a given time. Tokens are first allocated across categories such as community, foundation, investors, team, and liquidity, and are then released gradually under their respective TGE releases, cliff periods, and linear-unlock schedules; determining the amount available at a given time requires examining both the specific category and its release progress.

The official Litepaper lists four ELSA use cases: providing an economic layer for AI-model inference and onchain agent execution; use cases such as B2B SDKs and Widgets; execution-fee discounts for holders and stakers; and unlocking advanced agent features such as copy trading, sniping, and cognitive caching. These describe intended uses within the platform; they do not mean holding ELSA automatically grants every service or removes every cost. Fee discounts require that a user qualify as a holder or staker as described by the official materials; the precise eligibility, discount level, and settlement rules must be determined by the applicable product rules, and the Litepaper gives no uniform percentage. The list of advanced features likewise shows that access depends on product support and account or policy conditions; one cannot infer from “the token has utility” that every feature is available to every user. The Litepaper also proposes ELSA-based Gas abstraction or a “Gas-free” experience for supported in-Elsa scenarios. This means the platform may abstract the process through which a user pays network fees; it does not mean the Base network no longer charges native transaction Gas, nor does it establish that every transaction is necessarily free. Applicability depends on whether the scenario is supported and on the product rules at that time.

ELSA's total supply of 1 billion tokens is allocated across six categories: community 40% (400 million tokens), foundation 34.49% (344.9 million tokens), seed round 9.11% (91.1 million tokens), liquidity 8% (80 million tokens), team 7% (70 million tokens), and pre-seed round 1.4% (14 million tokens). These percentages total 100%. Release rules differ by category. The liquidity portion is fully released at TGE. The community portion releases 20% at TGE, or 80 million tokens; the remaining 80%, or 320 million tokens, unlocks linearly over 48 months. The foundation portion releases 20% at TGE, or 68.98 million tokens; it then has a 10-month cliff, after which the remainder unlocks linearly over 24 months. The team, pre-seed, and seed-round allocations all unlock linearly over 24 months after a 12-month cliff: no tokens are released under that linear schedule during the cliff, and periodic releases begin only after it ends. Therefore, neither the “1 billion total supply” nor allocation percentages alone can determine the number of tokens available to the market at any point; it is also necessary to distinguish categories released immediately at TGE, still in a cliff, and already in linear release.

HeyElsa has three types of user interface: Copilot for individuals, Widgets and SDKs that wallets and applications can embed, and AgentOS for developers to build or host specialized agents. The three reuse the same intent, orchestration, agent-coordination, and execution capabilities rather than being separate blockchains. Copilot brings chat-style goals into the execution process; Widgets and SDKs allow partners to embed that process in their own wallets, dApps, or content applications, together with their own context; and AgentOS enables specialized agents to collaborate through a shared agent-to-agent communication layer. Agents can declare the chains, actions, amount limits, and expected latency they support, and the orchestration layer assigns work based on those capabilities and task requirements. Official materials list swaps, cross-chain transfers, staking, lending, yield optimization, and automation among the operations that can be handled, but whether a particular request can be executed still depends on supported chains and protocols, wallet authorizations, liquidity, policy constraints, and simulation results. A product page's list of features should not be understood as an unconditional availability commitment for any asset, chain, or request.

HeyElsa's key distinction is that it plans and validates before execution, rather than treating a model response as a trading instruction directly. The orchestration layer sets step dependencies, service objectives, and fallback paths for a plan; multiple specialized agents can collaborate on the same subtask based on price, latency, and reputation. The execution stage can first simulate transactions to check parameter boundaries, failure reasons, and routes; it then submits them using DEX or cross-chain routing, transaction batching, or MEV protection, and produces receipts containing transaction IDs, status, actual slippage, and fees. A successful simulation is not a guarantee of the final execution price or cross-chain completion time, because onchain state, liquidity, and network conditions may still change after submission. The security layer applies data-freshness and anomaly checks, protocol allowlists, risk and notional-value limits, and applicable geographic/KYC rules throughout the process. For a request without a feasible plan, the intended handling is to return possible alternatives rather than continue to execute a plan that will fail.

The official Litepaper's roadmap timing needs to be understood separately. It lists items completed “as of Q2 2025,” including the public beta launch, the release of the core DeFi Copilot, commercialization enablement, and reported daily trading-volume, monthly-active-user, and registration data at that time. That section reviews the status up to that point. The same document places perpetual-contract integration with Hyperliquid, copy-trading and sniping agents, yield vaults and automation, mobile, multi-agent orchestration, ELSA's TGE, and token-utility activation in “Q3–Q4 2025”; it places fully automated portfolio management, tokenized crypto indices, the Agent Builder SDK, a strategy marketplace, and a cross-chain execution suite in “2026.” These are roadmap items and cannot be considered completed, implemented on mainnet, or actually adopted by users merely because they appear in the Litepaper. This distinction affects how ELSA utility is understood: for example, an advanced agent or Gas-abstraction design use becomes a feature that can actually be used only when the corresponding product functionality has been enabled and the user meets the applicable conditions.