# Introduction A brief introduction of Heima - the leading Chain Abstraction solution **Heima: The Chain Abstraction Protocol for Cross-Chain DEX Trading** It is purpose-built to eliminate the friction, fragmentation, and complexity of interacting with multichain ecosystems. With one omni account, users can manage assets, interact with dApps, and execute transactions across all supported blockchains — without switching wallets, bridging manually, or worrying about native gas tokens. Heima abstracts the complexity of cross-chain interactions through a four-part architecture: the Heima Layer 1 Network, Account Abstraction, Chain Abstraction, and Agent Hub. These components work together to create a modular, intent-centric automation ecosystem. Whether it’s cross-chain trading, staking, or arbitrage, Heima coordinates the execution logic seamlessly behind the scenes — making interactions feel as seamless as a centralized app, while remaining fully decentralized and non-custodial. Think of Heima as an intelligent coordinator behind the scenes. When a user wants to perform an action (like swapping a token or making a payment), they simply express what they want to do, called an “intent.” Heima then figures out the best way to execute that request, no matter which chains are involved. It even handles gas payments automatically, allowing users to pay fees with any token (like USDT/USDC) — eliminating the need to maintain balances of native gas tokens. This section introduces **Heima** and the **HEI Token**, the native utility token that powers the Heima ecosystem. # Heima High-level overview of Heima **Heima: The Chain Abstraction Protocol for Cross-Chain DEX Trading** Heima is a full-stack coordination protocol that abstracts complexity across accounts, chains, and agents — enabling seamless, verifiable cross-chain execution for users and developers. Managing assets across different networks today requires manual bridging, wallet switching, and constant gas token management — all of which lead to poor user experience, high friction, and security risks. Heima solves this by introducing a unified omni-account system, an intent-centric execution framework powered by the Omni Executor, and a decentralized Agent Hub. With Heima, users interact through a single interface that abstracts away the complexities of underlying blockchains. Behind the scenes, the system computes optimal execution routes, sources liquidity, and fulfills intents through a decentralized execution framework secured by Trusted Execution Environments (TEEs). This architecture allows users to operate across chains without switching wallets, manually bridging assets, or managing native gas tokens — enabling seamless and verifiable automation for cross-chain DeFi workflows. Developers benefit from a programmable automation framework that supports delegated execution and enables custom automation strategies. On EVM chains, Heima offers EOA compatibility via EIP-7702 — allowing seamless integration with existing wallets without infrastructure overhaul. Heima supports both on-chain and omni triggers, enabling a new design space for building cross-chain DeFi protocols, wallets, dApps, and infrastructure primitives. From unified balances and gasless transactions to chain-agnostic smart contract interactions, Heima provides the foundation for building decentralized applications that operate across multiple chains as if they were one unified environment. ### Vision Heima aims to solve these problems by delivering a seamless, cross-chain DeFi experience that rivals CEX usability while maintaining decentralization. ### Architecture Overview Heima is made up of four core module work in unison to deliver seamless coordination, universal access, and programmable automation across multiple blockchain ecosystems. They include: *** **1. Heima Network (Layer 1)** Heima network is a custom Layer 1 blockchain built on Substrate. This network serves as the coordination layer for intents, agents, and cross-chain execution. It anchors all user intents, manages agent registration, governs network parameters, and provides a secure, verifiable ledger of cross-chain activity. Through built-in scheduling, governance, and event systems, the Heima Network ensures high throughput, deterministic execution, and public auditability of all cross-chain workflows. *** **2. Account Abstraction (Omni-account)** Heima eliminates wallet fragmentation by introducing **omni-account,** a new account primitive that unifies Web2 and Web3 identities. Users can authenticate using email, passkeys, or any standard Web3 wallet. Behind the scenes, Heima leverages: * **EIP-7702** for EVM compatibility * **Substrate proxy accounts** for native integration * **TEE-secured accounts** to abstract non-native chains This design enables a seamless login experience and allows users to control assets and activity across chains through a single account interface. *** **3. Chain Abstraction (Omni-Executor)** The **omni-executor** interprets and routes user intents such as swaps, transfers, or staking across any supported chain. It dynamically computes optimal execution paths, handles cross-chain messaging, manages gas abstraction, and ensures final settlement. All execution data is anchored back to the Heima Network for traceability. This layer decouples user experience from the underlying blockchain logic, enabling gasless, unified, and transparent operations. *** **4. Agent Hub** Heima enables decentralized, programmable automation through the **Agent Hub,** a permissionless network of bots and execution agents. These agents monitor conditions (on-chain and omni), fulfill user intents, and execute arbitrage, rebalancing, staking, or complex workflows. Agents are incentivized through built-in reward systems, staking mechanisms, and performance-based rebates. *** #### Open, Extensible, and Composable Heima is built with developers and integrators in mind. The system supports: * custom signers, intent fillers, and execution logic * External routers and automation logic * Rebate and monetization layers for service providers and partners Whether you're building an omni-chain DEX, wallet, GameFi automation, identity protocol, or complex dApp, Heima provides the infrastructure to deploy secure, scalable, and intent-driven applications. > "One Account. All Chains. Any Token." # HEI Token ### **HEI Token: Core Utility and Economic Engine of the Heima Network** **HEI** is the native utility and coordination token of the **Heima Network**, deployed natively across the **Heima Parachain**, **Ethereum**, and **BNB Chain**. It underpins protocol-level operations, facilitates decentralized governance, abstracts gas usage, and anchors cross-chain liquidity provisioning. HEI serves as the foundational value and coordination layer that aligns the interests of **users**, **developers**, **agents**, and **network validators**, while enabling a seamless and composable multi-chain experience. *** #### **Primary Functions of HEI** HEI fulfills three protocol-critical roles: 1. **Governance Primitive** – powering decentralized, on-chain decision-making and upgrade pathways. 2. **Gas Abstraction Settlement** – enabling gasless execution via delegated sponsorship and intent relayers. 3. **Cross-Chain Liquidity Pools** – optimizing routing, bridging, and liquidity discovery across heterogeneous execution environments. *** #### **1. Governance Framework** Inspired by Polkadot's governance model, HEI enables a multi-layered decision-making system starting with Proposals that any token holder can submit by bonding a minimum amount of HEI. These proposals range from runtime upgrades to parameter adjustments. The Heima Council, elected by token holders, evaluates proposals and transforms them into Motions for deliberation. Approved motions advance to Referenda—the final stage where all HEI holders vote. The system employs adaptive quorum biasing where approval thresholds adjust based on voter turnout and the proposal's origin, ensuring sufficient community backing while preventing governance deadlocks. For urgent technical matters, a Technical Committee comprising blockchain experts can fast-track critical proposals like security patches by shortening voting periods. This balanced governance structure allows Heima to evolve with community input while maintaining operational security. *** #### **2. Gasless Transaction Settlement** While HEI serves as the network's gas token, users never need to hold it themselves—one of Heima's most distinctive features. The platform aims to operate invisibly in the background, with the intent filler network sponsoring all gas fees on behalf of users. This gas abstraction layer removes a significant friction point in blockchain interaction. Developers can create seamless user experiences without forcing users to acquire yet another token. The economics balance through an operational reward system where intent fillers, functioning similar to validators, earn compensation for their active participation and resource expenditure. These rewards incentivize intent filler network to cover gas costs and perform essential cross-chain settlement work, representing compensation for computational resources rather than profit-sharing mechanisms. *** #### 3. Cross-Chain Liquidity Pools HEI’s most transformative function is enabling the Heima Chain Liquidity Pool system, where it serves as a mediation asset for exchanging network-native tokens across blockchains, specifically aimed at reducing cross-chain transaction costs. Users of the Heima Network can deploy their own smart contracts using templates provided by the network to create cross-chain liquidity pools. These user-deployed pools aggregate liquidity from supported blockchains. When a user initiates a cross-chain operation, the system can utilize these pools to efficiently acquire necessary native tokens on target chains, significantly reducing slippage and transaction fees compared to traditional bridging mechanisms. Participants who provide liquidity to these pools may earn transaction fees proportional to their contributions. This model creates a positive feedback loop: increased cross-chain activity enhances liquidity depth, which in turn improves execution quality and reduces costs for users. Participation is entirely at users’ discretion, with participants responsible for managing their own risks. By enabling decentralized, user-driven cross-chain liquidity provisioning, Heima offers a more capital-efficient and transparent alternative to conventional bridging infrastructures. *** #### Summary Through governance, gas abstraction, and liquidity coordination, HEI serves as the economic backbone of the Heima protocol that: * Enables gasless cross-chain execution * Powers sustainable incentive mechanisms * Coordinates decentralized decision-making HEI is more than a token—it is the infrastructure layer driving Heima’s chain-agnostic vision for Web3. # Background and Problem Statement This section outlines the core motivations behind the creation of Heima This section outlines the core motivations behind the creation of Heima. It explores the challenges faced by both users and developers operating within today’s fragmented multichain environment, where **cross-chain interactions, pricing inconsistencies, and the lack of automation** create significant friction. You’ll also learn how Heima addresses these issues through a **modular, intent-driven architecture** and how it compares to existing chain abstraction approaches, highlighting where they fall short and why a more comprehensive solution is needed. Summarily, this section will: * Outline the **key problems** users and developers face in the current multichain ecosystem. * Introduce Heima’s approach to solving them through a four-part architecture: Heima Network, Account Abstraction, Chain Abstraction, and a programmable Agent Hub. * Compare existing chain abstraction models and highlight their **limitations** in scalability, security, and UX. By understanding the depth of these issues and the limitations of current solutions, the need for a system like Heima becomes clear: a modular, programmable coordination protocol that enables truly seamless, cross-chain interactions for the next generation of decentralized applications. # Problem This section outlines the identified challenges of the current DeFi ecosystem While the decentralized finance (DeFi) ecosystem continues to expand in functionality, liquidity, and user adoption, user experience is severely lacking as it remains **fragmented, unintuitive, and operationally inefficient** compared to centralized exchange (CEX) platforms. The gap between DeFi and CEX user experience is particularly evident in cross-chain workflows, pricing execution, and trading automation. #### **1. Fragmented Cross-Chain Interactions** The current DeFi infrastructure requires users to **navigate multiple blockchain networks manually**, introducing unnecessary friction at each step of the process. Users are forced to: * Switch between **different wallets** or manage multi-chain wallets with network-specific configurations. * **Manually bridge assets**, exposing themselves to complex routing paths, execution delays, and security risks associated with third-party bridges. * Understand and configure **network-specific gas parameters**, such as gas fees, gas limits, and token approvals, which vary across EVM and non-EVM chains. These requirements introduce a **high technical barrier**, slow down execution, and increase the risk of user errors, resulting in an experience far inferior to the seamless interactions provided by CEXs. *** #### **2. Chain-Specific Pricing Disparities** Token prices across DeFi ecosystems can **vary significantly between chains** due to isolated liquidity pools and arbitrage inefficiencies. Traders are often forced to: * Operate in **chain-siloed environments**, unable to quickly discover or act upon the best prices across networks. * Experience **price slippage** due to delayed bridging or insufficient liquidity in isolated pools. * They also **miss trading opportunities** because of the time and complexity involved in executing arbitrage across multiple chains. This fragmented liquidity leads to **inefficient capital allocation** and deters professional traders from engaging deeply with DeFi markets. *** #### **3. Lack of Native Automation Primitives** Unlike CEXs, DeFi lacks infrastructure for **native automation** of trading, position management, and network-level actions. As a result: * Traders must **manually track market movements**, manage multiple positions, and respond in real-time to volatility. * There is no standard mechanism for **automated order execution**, stop-loss triggers, or rebalancing across chains. * Users must manually handle **transaction nonces**, manage gas optimization strategies, and monitor failed transactions. This absence of programmable execution makes DeFi unsuitable for **high-frequency strategies**, large institutional flows, or casual users seeking a "set-and-forget" experience. The limitations outlined above highlight a critical challenge in DeFi's evolution toward mainstream adoption and institutional-grade usability. Without a unified framework for **abstracting chain complexity**, **aggregating cross-chain liquidity**, and **enabling automated execution**, DeFi users are forced to navigate a fragmented ecosystem that lacks the efficiency and reliability of traditional platforms. # Our Solution This section explains the solution of Heima. **Heima** was created to address this fundamental problem. By abstracting away chain-specific complexity, introducing intent-driven execution, and embedding automation at the protocol level, Heima aims to bring **CEX-level usability** to the decentralized world, without compromising trust, security, or decentralization. ### Heima Solution Overview **Heima** is a full-stack modular, intent-centric coordination layer designed to abstract away the fragmented complexity of today’s multichain DeFi ecosystem. It reimagines how users and developers interact with decentralized infrastructures and replaces brittle workflows involving wallet switching, bridging, and manual gas management with a seamless, programmable infrastructure focused on **automation**, **security**, and **cross-chain simplicity**.
#### **Omni-Account: One Identity Across Chains** At the heart of Heima is a **chain-agnostic omni-account**, which unifies user identity and execution across different DeFi ecosystems. This architecture enables: * **Seamless authentication** using both Web2 (email, passkeys) and Web3 (wallets) * **Delegated execution** via projected accounts, allowing trusted accounts to act and execute transactions on your behalf * **Elimination of wallet switching**, private key sprawl, and inconsistent UX across chains This unified account model drastically simplifies onboarding and ensures consistent UX across chains and interoperability by design. *** #### **Omni-Executor: Intent-Based Chain Abstraction** Heima’s **Omni-Executor** is a TEE-secured execution layer that translates high-level user intents (e.g., swap, stake, bridge) into optimized, multi-step execution paths. It: * Computes the **most efficient route across chains**, factoring in pricing, latency, and liquidity * Handles **gas abstraction**, enabling gasless or meta-transaction-based execution * Relays actions to a **decentralized intent-filler network**, ensuring trust-minimized fulfillment This intent-based approach enables **uniform pricing displays**, **transparent and auditable execution**, and significantly reduces the **cognitive load** for users interacting with multichain DeFi. *** #### **Agent Hub: Permissionless, Programmable Automation** Heima empowers developers to build autonomous agents via the **Agent Hub,** a programmable automation layer secured by TEEs and staking guarantees. It allows agents to: * Monitor on-chain and off-chain conditions in real-time * Execute arbitrage, rebalancing, staking, and other strategies autonomously * Integrate with prebuilt modules or deploy custom logic tailored to specific market conditions This transforms DeFi from a manual, reactive process to a **proactive and intelligent system**, unlocking use cases like 24/7 liquidity management and intent-triggered actions. *** #### **Cross-Chain Payments & Liquidity Abstraction** Heima simplifies multichain payments through: * **Token-agnostic settlement:** Users can pay fees in any token, removing the need to hold native gas assets * **Integrated liquidity routing:** Sourcing from multiple chains to ensure best execution * **Offloading execution to trusted intent fillers:** This helps to guarantee timely and secure completion *** #### **The End of Multichain Friction** By abstracting identities, execution paths, liquidity, and automation into a single programmable layer, Heima delivers **CEX-grade usability** in a **decentralized, permissionless environment**. Developers can finally build applications that feel seamless regardless of how many chains are involved under the hood. It also features a rebate and incentive system that ensures the sustainability of the network while keeping costs low for end users. Heima removes fragmentation at every layer, enabling applications to offer seamless, high-performance cross-chain experiences, without compromising decentralization. # Current Chain Abstraction Systems and How Heima Solves Their Limitations This section explains the limitations of current systems and how Heima solves them Chain abstraction has become a key primitive for reducing UX friction in blockchain interactions and within multichain ecosystems. However, most existing implementations provide only **surface-level unification** and lack the extensibility, universality, performance, and determinism required for building generalized coordination systems across heterogeneous chains. Many approaches focus narrowly on specific application layers, such as wallet-level account abstraction, atomic cross-chain swaps, or isolated relayer networks, without offering a fully composable, modular, and developer-friendly coordination layer. Below, we analyze the technical shortcomings of current models and introduce **Heima’s protocol-native and intent-driven abstraction stack** designed for developers building programmable, cross-chain dApps and infrastructures. *** ### Existing Systems: Fragmented and Rigid 1. **Wallet-Centric Design (e.g., EIP-4337):** Most abstractions are built around **smart contract wallets**, introducing significant operational overhead: * High gas usage due to layer-on-layer verification (paymasters, entry points, validation) * Limited composability with Externally Owned Accounts (EOAs) and legacy DeFi infrastructure * Poor upgradeability and heavy reliance on off-chain bundlers 2. **Atomic Bridging Protocols:** Systems that enforce atomic cross-chain swaps (e.g., Hashed Systems that enforce atomic cross-chain swaps (e.g., HashedTimelock Contracts or token bridges) suffer from: * Coupled execution paths that fail if any leg breaks * No support for asynchronous execution or partial fulfillment * Tight constraints on fallback logic and path optimization 3. **On-Chain Only Execution:** Bridging or coordination logic is often entirely on-chain, making it: * Hard to customize * Expensive to compute across multiple chains * Incapable of integrating off-chain data feeds, triggers, or compute environments 4. **Monolithic Abstraction Stacks:** Existing systems often lack separation of concerns between identity, execution, and coordination. This leads to: * Rigid architectures * Difficult testing and debugging * Low developer extensibility *** ### Heima’s Technical Architecture: Modular, Programmable, and Chain-Agnostic Heima is the chain abstraction protocol built to simplify and unify interactions across multiple blockchains. It ensures performance, auditability, and automation through native scheduling and governance modules, and it introduces a modular coordination framework based on the omni-account and intent-based execution. Heima’s omni-executor is designed to: * Handle intents of arbitrary complexity (e.g., trade, stake, batch actions, timed logic) * Interface with both on-chain and omni services This modular structure expands the design space for decentralized applications beyond what is achievable through rigid, on-chain-only flows, enabling programmable, verifiable cross-chain systems with developer-defined workflows. * **TEE-backed execute** ensures trusted fulfillment without needing a centralized relayer * **All state transitions** can be audited post-factum with proofs * **Modular APIs** enable dApps to integrate only the parts they need Heima is built as a **coordination protocol**, not just a wrapper around user accounts or a relayer layer. Its design addresses limitations at the system architecture level:
ModuleResponsibilityVerifiability
Heima Layer1Omni account management, cross-chain coordinationBlockchain consensus, auditable state proofs
Omni AccountIdentity, signature, multi-chain asset abstractionTEE-backed, upgradable
Omni ExecutorIntent validation and final executionTEE + cryptographic proofs + filler bonds
Agent HubIntent routing, task delegation, agent marketplaceTEE attestation, slashable stake bonded
*** #### Account Abstraction: Protocol-Level Extensibility using **Omni-Accounts (EIP-7702-Compatible, EOA-Native)** Heima introduces **omni-accounts**, a low-level account abstraction built on EIP-7702 that: * Preserves direct compatibility with EOAs, ensuring seamless fallback to existing dApps * Avoids the gas inefficiency of EIP-4337 while enabling full customization of validation logic * Supports both Web2 and Web3 authentication (passkeys, wallets, OAuth) through projected subaccounts * Makes it trivial to delegate execution via deterministic Omni logic (projected keys, TEE-based validators) > 💡 Developers can register validation modules, define hooks, or deploy permissioned sub-accounts with custom policies without sacrificing compatibility. *** #### Chain Abstraction: Intent-Centric Over Atomic Swaps for **Decoupled Execution and Generalized Routing** At the heart of Heima is a **TEE-backed Intent Filter Network** that facilitates chain abstraction. It; * Accepts **intents**: serialized, signed user instructions such as “swap token A for token B with slippage < 1% before time T” * Computes **optimal multi-chain execution paths** based on on-chain state, mempool data, and omni liquidity * Executes actions through the **intent filter network** with attestation and stake guarantees **Features**: * **Decoupled execution:** path resolution happens independently from the user's intent broadcast * **Asynchronous fulfillment:** enables batching, delayed execution, partial fills, and fallback strategies * **Unified gas handling:** pay in any token; execution fills gas requirements from liquidity pools > 🛠 Developers can define arbitrary execution flows and plug in omni routing engines, oracles, or pricing models. *** #### **Agent Hub: for Programmable Automation** Heima’s **Agent Hub** allows permissionless registration of **automation agents** that: * Monitor event triggers (on-chain logs, omni APIs, price feeds) * Respond to defined logic (arbitrage, auto-staking, rebalancing, etc.) * Execute across chains via the intent filter network. Agents are subject to: * **Staking requirements and slashable bonds** for misbehavior * **TEE attestation** to verify logic execution and determinism * **Composable intent scheduling** (recurring jobs, conditional triggers, expiry, etc.) > 🧠 Developers can deploy agents to automate DeFi strategies, execute conditional orders, or run verifiable omni computations without centralized bots. *** Heima abstracts the blockchain's complexity into **developer-definable workflows** that work across environments. **Benefits for developers:** * Write once, deploy anywhere: same logic across chains * Unified UX for users, gasless, and secure * Modular API surface: use accounts, intents, and agents independently > 🔍 If you’re building for the next wave of decentralized coordination, Heima gives you the composability, security, and developer ergonomics that legacy abstractions lack. # Core Concepts Heima is a full-stack coordination protocol designed to abstract complexity across accounts, chains, and agents. It introduces a unified omni-account layer, cross-chain intent routing infrastructure, a permissionless agent hub, and its programmable Layer 1 blockchain — all tied together by auditable execution and verifiable automation.
* **Heima Layer 1 Network**: The coordination and registry layer that ensures all actors and executions are traceable, verifiable, and cross-domain auditable. * **Account Abstraction**: Omni-accounts unify user identity across chains and simplify onboarding with Web2-style authentication. * **Chain Abstraction**: A seamless intent infrastructure removes the need for users to understand or manage different networks. * **Agent Hub**: A permissionless marketplace for agents and bots to offer services ranging from trading to staking, all tied to intent execution. Each of these components is designed to be modular yet tightly integrated, creating a chain-agnostic and intent-centric automation ecosystem. This four-pillar approach creates a comprehensive solution where operations across multiple blockchains become transparent and simple for both users and developers. # Heima Layer 1 Network An explanation of the Heima Layer 1 Network ### Heima Layer 1 Network Heima Layer 1 is a Substrate-based blockchain that serves as the coordination layer for intents, agents, and cross-chain execution. It goes beyond settlement, offering a programmable environment purpose-built for: * High-throughput, low-latency execution (targeting 500ms block time) * A transparent registry of agents and intent fillers * Native cross-chain communication via proxy handlers and prebuilt modules By anchoring every action on-chain, Heima ensures intent execution is fully traceable and verifiable. #### Substrate-Based Flexibility Heima leverages Substrate to provide: * **WASM + EVM compatibility** for flexible execution environments * **Native governance modules** for treasury, staking, Bounty and agent certification * **Runtime upgradeability** without hard forks * **Decentralized schedulers** for intent queueing, retries, and timed execution #### Built for Auditable Automation Transparency and verifiability are core to Heima’s design: * **Unified actor registry** for all agents, fillers, and relayers * **Omni-account anchoring** links executions to cryptographic identities across chains and off-chain environments * **Cross-domain traceability** via attestations and signed logs * **TEE-secured proofs** for off-chain actions involving sensitive data * **Full intent lifecycle visibility** from submission to final state change Heima Layer 1 forms a trust-minimized coordination fabric where all executions are verifiable, composable, and interoperable—supporting secure automation across heterogeneous systems. # Account Abstraction Heima's account abstraction introduces a seamless identity layer centered on the **omni-account,** a unified user ID across all chains. Instead of managing fragmented wallets and credentials, users interact with blockchain applications through a single, cross-chain identity. Key features include: * **Web2 + Web3 login support**: Users can onboard via email, phone, passkeys, or social accounts, powered by partner authentication services. * **Network-aware proxy mapping**: * EVM chains: via EIP-7702 proxy contracts * Substrate chains: native proxy contracts * Non-native environments: TEE-backed secure proxy accounts * **Delegated execution**: Projected accounts can act on behalf of an omni-account with programmable, permissioned control. * **Identity graph**: Heima builds an internal graph to link user personas across apps and contexts, enabling personalization without exposing sensitive data. This model reduces integration complexity for developers, eliminates key fragmentation, and enables secure, user-centric Web3 experiences built on a flexible identity framework. # Chain Abstraction This page explains Heima Chain Abstraction
Heima enables seamless interaction across multiple blockchains through an intent-centric execution model, removing the need for users to manually manage chain-specific operations or gas payments. At the heart of this model is the omni-executor, a TEE-secured execution environment that interprets user intents and fulfills them via optimal cross-chain routes. When a user submits an intent (e.g., “swap token A for token B at the best price”), Heima automatically determines how and where to execute it, abstracting away the underlying blockchain complexities. #### Key Features: * Intent-Based Execution Users express desired outcomes rather than defining transaction steps. The system determines the optimal routing and execution strategy across chains. * Gas Abstraction Users can pay transaction fees with any supported token across any network. Gas management and token conversions are handled automatically behind the scenes. * Modular Architecture Transaction composition, cross-chain routing, and signature validation are decoupled into independent services. This enables flexible implementation strategies, from low-cost off-chain RFQ matching to trust-minimized on-chain DEX fulfillment, depending on user priorities. * Layer 1 Anchoring All execution steps are recorded and validated on Heima Layer 1, ensuring full traceability, verifiability, and auditability. *** Heima’s chain abstraction infrastructure is designed to be production-ready, supporting complex DeFi workflows while preserving a simple and transparent user experience. Through this intent-based system, users simply define what they want to achieve, while Heima coordinates execution securely and efficiently across multiple chains. # Agent Hub This page describes Heima Agent Hub, the native automation layer and it features. The Agent Hub is Heima’s infrastructure layer for registering, deploying, and managing autonomous agents — bots that act on behalf of users or protocols. These agents can be programmed to monitor markets, execute trading strategies, rebalance staking positions, or respond to external signals such as news events or oracle price feeds. Agent developers interact with Heima through a powerful set of APIs and SDKs. Agents register their capabilities and logic, optionally verify their code or operator identity, and begin offering services within the intent execution marketplace. Agents can integrate with the Omni-account system or operate using their own external signing mechanisms. To support real-time operation, Heima provides: * Access to live on-chain data via HTTPS and WebSocket APIs (e.g., token prices, vault positions, arbitrage opportunities). * Integration with off-chain data sources, such as social media crawlers and oracle feeds. * Event-driven triggers through decentralized schedulers and external signals. To incentivize the growth of the agent economy, Heima natively supports: * Rebate and incentive models: Agents earn rewards for successful executions. * Push notification services: Inform users via dApps, email, or external channels when actions are performed. * Staking-based guarantees: Agents stake tokens to back their execution with “skin in the game,” enabling trustless delegation.
Ultimately, the Agent Hub transforms Heima into a marketplace for intelligence, where autonomous agents compete to fulfill intents efficiently, securely, and transparently. This ecosystem shifts DeFi from manual interaction to an automated, intelligence-driven experience, powered by programmable agents with real-time data access and verifiable execution. # Case Study（PumpX） PumpX demonstrates the transformative potential of Heima's omni-chain infrastructure in real-world applications. PumpX started as a single-chain DEX focused on meme tokens within the Solana ecosystem. Despite strong initial traction, user growth was limited by Solana-specific onboarding friction, token support, and gas awareness. By integrating Heima's account, chain, and agent abstraction layers, PumpX was able to seamlessly upgrade its platform without rewriting core logic: * **Onboarding**: Plug in for Web2-style login. Automatically creates Omni-account. * **Key Management**: PumpX continues to use its custodians as the master signer, while Heima's omni-executor requests authorizations from PumpX. * **Execution**: Leverage Heima's cross-chain routing and agent-based automation.
**Before Heima:** * Only supported SOL for purchase * Prices were shown in SOL * No bridging or chain support outside Solana #### After Heima: * **Pay with Any Token**: USDT, BNB, ETH, etc. — from any chain * **Unified Price Display**: All meme tokens are priced in USD regardless of the origin chain * **Zero Gas Management**: User never sees or pays gas directly — it's abstracted by intent and routing layer * **Cross-chain Routing**: Heima routes to the cheapest market across Solana, BNB, Base, etc. * **No Compromise on Speed**: Heima prioritizes the trading speed with specified intent filler. This transformation demonstrates Heima's ability to simplify complex blockchain interactions, abstract away technical barriers, and create seamless, user-friendly DeFi experiences without requiring extensive rebuilding of existing infrastructure. To ensure secure integration and production-grade reliability, PumpX underwent a complete third-party security audit—focusing on modules deployed alongside Heima’s infrastructure. 🔒 Audit Summary Conducted by [SlowMist](https://slowmist.com), the audit covered: * Contract logic and upgradeability * Proxy execution mechanisms * Cross-chain transaction security * Potential exploit vectors in intent-handling and relayer logic 📄 [View Full Audit Report (PDF)](https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/blockchain-application/SlowMist%20Audit%20Report%20-%20PumpX_en-us.pdf) The audit confirmed PumpX’s implementation met key security best practices. Findings were addressed and re-reviewed to meet production-level standards. # Developer Overview This page provides a comprehensive overview of what Heima Network offers developers, why it matters, and how it compares with other solutions in the chain abstraction space. #### Quick Intro *“We provide a full-stack infrastructure service to help Web3 developers build faster, safer, and smarter DEX & dApps — without needing to reinvent complex backend systems.”* #### Core Capabilities * **On-chain Data APIs**: Real-time K-line data, token prices, holder analytics, and liquidity information. * **Secure Execution Environment**: TEE and SMPC-based secure execution infrastructure for signer authorization. * **Trading Infrastructure**: Routing + execution APIs across multi-chain ( Ethereum, BSC, Solana, Base... ) * **Intent-Centric Chain Abstraction**: Simplified cross-chain logic and stablecoin payments with unified UX. * **Push Services**: Websocket and email notifications for alerts and events. *** ### Why Choose HEIMA #### Save Time & Cost * No need to build indexers or coordination logic from scratch. * Use our hosted infra or deploy via Docker. #### Better UX & Security * Cross-chain made invisible to users. * Secure execution with TEE + SMPC. #### Continuous Improvement * Regular updates and early access to new features. * Priority support for ecosystem partners. *** ### Heima’s Competitive Edge #### Lightest Account Abstraction (EIP-7702) * Native upgrade for EOAs without migration. * No relayers, no bundlers, cheaper gas. * Easy to integrate intent signing & login. #### Intent-Based Chain Abstraction * Users express goals, not chain steps. * Omni-executor handles bridging, routing, signing. * Verifiable execution with TEE proofs. #### Omni Liquidity Access * Same-chain + cross-chain + off-chain execution paths. * Unified under a single user intent. #### Summary Comparison
FeatureHeima NetworkERC-4337 PlatformsBridge ProtocolsDEX Aggregators
Account Abstraction✅ Native EOA (7702)❌ Contract migration❌ Not supported❌ Not supported
Cross-Chain Execution✅ Intent-based❌ Requires infra✅ Manual flow❌ Not supported
Gas Abstraction✅ Pay any token✅ Via relayer❌ Requires gas❌ Requires gas
Liquidity Aggregation✅ On + off-chain❌ No routing❌ Asset transfer only✅ Same-chain only
Security Model✅ TEE + SMPC✅/❌ Mixed❌ Risky✅ On-chain only
Integration Cost✅ SDK + native login❌ Complex setup❌ High✅ Easy, limited
*** ### Modular Architecture for Developer Flexibility HEIMA provides six fully decoupled modules that developers can adopt as needed: 1. **Flexible Rebate Module**: Build custom rebate and incentive schemes. 2. **Customizable Authentication Method**: Use web2 social login, email, web3 wallets, passkeys, etc. 3. **Cross-chain Intent Operator**: Define how intents translate into multi-chain execution steps. 4. **External Signer Integration**: Use centralized signers, MPC wallets, or user-controlled wallets. 5. **Cross-chain Router**: Add or replace routing logic and liquidity sources. 6. **WebSocket / REST APIs**: Integrate alerts, updates, and trading signals. Each module is plug-and-play, independently deployable, and supports rapid customization.
### 🌐 Strategic Positioning Heima positions itself as: * The **lightest chain abstraction protocol** for developers and wallets * The **most flexible cross-chain intent network** for DEX and dApps * The **most powerful liquidity router** across multi-chains, protocols, and trusted execution layers No bridges. No chain switching. No gas juggling. Just one account, one intent, and intelligent execution. > HEIMA Network empowers Web3 developers to effortlessly build advanced, secure, and scalable multi-chain applications. # Key Components * **omni-authenticator (same term as in tech dive, equivalent to “account abstraction” service in the first image):** * accepts web2/web3 ways of login * generates omni-account based on it * issues jwt tokens for further communication with omni-executor * **omni-executor**: * accepts user intents, authorized by previous jwt * translates user intent into multi-step blockchain path (txs) * constructs the tx based on user config * executes the tx on the matching chain * records the state onto heima chain * **trade module / heima route**: * flexible trading on single chain by connecting to different DEX pools * **Signer service**: * controls generated EOA accounts used to send tx on chains where user don’t have account, e.g. user logs in with web2 / metamask, but want to send solana tx. * **heima main-net**: * record the intent lifecycle and state update * on-chain trading history: user should be able to reconstruct the trading history just by indexing the heima blockchain data # Integration Guide These components that can be **extensible** and/or **replaceable:** * **extensible**: means the basis of component is provided by heima, but can be extended to have customised features. Analog: browser vs browser extensions. * **replaceable**: means the whole component can be fully replaced/customised on client side, as long as it provides given communication API. **extensible components:** * omni-authenticator: client can add extra user-auth * omni-executor: client can define extra: * conversion logic from intent → blockchain path * cross-chain swap provider * heima main-net: client can add extra logic of lifecycle and data management **replaceable components**: * heima-route: client can provide its own single-chain trading pool * signer service: if client wants to hold the private keys of EOA accounts # Collator ## Functionalities of the Collators To resonate with the collator staking model, we [reworked the tokenomics model](https://heima.subsquare.io/democracy/referenda/37) to allow the collators and their backed users to share the block production rewards. A short summary: * 30% of the network's gas fees will be allocated as rewards for collator staking participants. * This dynamic reward model ensures that rewards scale with network usage, incentivizing active participation and growth. ### Requirements to run a collator #### Hardware requirements Same as the [polkadot validator reference hardware](https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#requirements) #### bonding requirements There's a minimum (self)-bond to join the collator candidate pool and be eligible to get selected to author blocks. Currently it's set to **5000** HEI, you'll have to specify the bond amount when joining the candidate pool via `parachainStaking.joinCandidates` #### **whitelisting** Before we fully activate the DPoS model, the collator set is managed by the whitelist from the Heima team. It means you'll need to get your collator account whitelisted to be able to join the candidate pool. ### How to run a collator ***Currently collator is still the old "Litentry" version. The Heima new version doc update will come very soon.*** #### using docker (preferred) 1\. create a local directory to store the chain database: ```shell mkdir /var/lib/litentry # or use sudo if you don't have permission sudo mkdir /var/lib/litentry ``` 2\. make sure the permission and ownership of the local directory are correctly set: ``` sudo chown -R $(id -u):$(id -g) /var/lib/litentry ``` 3\. run the following docker command, you can replace the `--name="heima-node"` with your own node name: ```shell docker run -d --network=host -v /var/lib/litentry:/data \ -u $(id -u):$(id -g) \ litentry/litentry-collator:v0.9.22-02 \ --base-path=/data \ --chain=litentry \ --name="litentry-collator" \ --collator \ --execution wasm \ --state-cache-size 0 \ -- \ --execution wasm \ --chain polkadot ``` {% hint style="warning" %} `litentry/litentry-collator:v0.9.22-02` is used as an example, please check [github release page](https://github.com/litentry/heima/releases) for the up-to-date releases {% endhint %} The command will run the docker container in the background and the container ID will be printed in the console. With `docker logs -f ` you should be able to see the node starts to sync:

node syncing

{% hint style="info" %} Wait until syncing is done. Depending on the hardware and network status it could take several days to fully sync the parachain and relaychain database. {% endhint %} 4\. generate a session key by sending an RPC call to the http endpoint of the parachain with the `author_rotateKeys` method: ```shell curl http://127.0.0.1:9933 -H \ "Content-Type:application/json;charset=utf-8" -d \ '{ "jsonrpc":"2.0", "id":1, "method":"author_rotateKeys", "params": [] }' ``` An exemplary result: ```json {"jsonrpc":"2.0","result":"0x56066a71efc51e4a6f0f838cac959a08b238e22d478bd5dc0cdc2ac5b40d2e66","id":1} ``` Note down the result, this is your session key. In this case `0x56066a71efc51e4a6f0f838cac959a08b238e22d478bd5dc0cdc2ac5b40d2e66` {% hint style="info" %} Alternatively you could use `author_insertKey` to insert the pre-generated session key. The session key for heima-node is a sr25519 [aura](https://docs.substrate.io/reference/glossary/#authority-round-aura) key. {% endhint %} 5\. bind your collator account to the generated session key, this includes: * prepare a heima-node account. This account will be registered to receive block production rewards. * bind this account to the session key generated in step 4 by submitting extrinsic `session.setKeys`**from the collator account**:

session.setKeys

{% hint style="warning" %} parameters: * keys: the hex string key from step 4 * proof: `0x` {% endhint %} 6\. request to join the collator candidate by submitting extrinsic `parachainStaking.joinCandidates` **from the collator account**:

join the candidate pool

{% hint style="info" %} To be able to successfully join the collator candidates, you have to: * stake the minimum bonds * get added to the candidate whitelist by the admin (whitelisting will be removed once the DPoS is fully activated) {% endhint %} 7\. check your node actually starts to collate Once the extrinsic is sent without errors, wait until the next [round](https://github.com/litentry/litentry-parachain/blob/47386434b0743a6723b29dbd50a45dd86596891d/runtime/litentry/src/lib.rs#L652) begins and you should be able to see your node starting to produce blocks:

new collator produces a block

You should see your node gets chosen from time to time to author blocks according to the emitted events:

the new collator is chosen

{% hint style="warning" %} If the collator doesn't produce blocks after a long time (\~12 hours) while you believe everything is correctly set, please try to restart the node. {% endhint %} {% hint style="success" %} Congratulations! You have managed to run a collator node that starts to produce blocks for the Heima parachain! {% endhint %} #### using binary Running a collator node with the raw binary is very similar to the docker setup above, it only differs a bit in the command line arguments. So instead of steps 1-3 above, run: ``` ./target/release/litentry-collator \ --chain=litentry \ --name="litentry-collator" \ --collator \ --execution wasm \ --state-cache-size 0 \ -- \ --execution wasm \ --chain polkadot ``` By default, the database is stored at `~/.local/share/`, you can override it by using `--base-path=`. {% hint style="warning" %} To get the binary, you could either download it directly from Heima's [Github release page](https://github.com/litentry/heima/releases) (**Linux x86-64** only), or [build](broken://pages/r7BbS90k7gpmTLJqJRMm) it from the source. {% endhint %} The remaining steps to configure the session key and join the collation are the same as the docker method, so it's not repeated here. ### How to update the client Heima constantly works on improving the parachain client and following the upstream changes. Therefore, it's not uncommon to update the client to have the newest features and security patches. Updating the client is simple: **If using docker:** 1. `docker container stop ` 2. run the docker command in step 3 in [#using-docker-preferred](#using-docker-preferred "mention") , with the desired docker image version **If using binary:** 1. stop/kill the `heima-node` process 2. download the desired binary 3. start the new binary using the commands in # using binary # Full Node #### Heima RPC nodes By default, Heima has a few self-hosted, load-balanced RPC nodes that provide public service. Contrary to collators, the RPC nodes don't produce blocks but only sync the chain states and provide RPC/Websocket services to the users. You can find the Heima RPC entrypoint [here](https://polkadot.js.org/apps/?rpc=wss://rpc.litentry-parachain.litentry.io#/explorer) on polkadot-js. With the service, the end-users can query the chain state, inspect the constant and storage, and execute extrinsics. #### Run your full nodes **using docker (preferred)** 1\. Create a local directory to store the chain database: ``` mkdir /var/lib/litentry # or use sudo if you don't have permission sudo mkdir /var/lib/litentry ``` 2\. Make sure the permission and ownership of the local directory are correctly set: ``` sudo chown -R $(id -u):$(id -g) /var/lib/litentry ``` 3\. Run the following Docker command, you can replace the `--name="heima-node"` with your node name: ``` docker run -d --network=host -v /var/lib/litentry:/data \ -u $(id -u):$(id -g) \ litentry/litentry-collator:v0.9.22-02 \ --base-path=/data \ --name="litentry-collator" \ --chain=litentry \ --state-pruning=archive \ --state-cache-size 0 \ --ws-external \ --rpc-external \ --rpc-cors=all \ --execution=wasm \ -- \ --execution=wasm \ --chain kusama ``` `litentry/heima-node:v0.9.22-02` is used as an example, please check [github release page](https://github.com/litentry/heima/releases) for the up-to-date releases The command will run the docker container in the background and the container ID will be printed in the console. With `docker logs -f ` you should be able to see the node starts to sync. Wait until syncing is done, depending on the hardware and network status it could take several days to fully sync the parachain and relaychain database. After it's fully synced, you should be able to access the chain via local ws endpoint in polkadot-js: [https://polkadot.js.org/apps/?rpc=ws://127.0.0.1:9944#/explorer](https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/explorer) **using binary** Running a full node with the raw binary is very similar to the docker setup above, it only differs a bit in the command line arguments. So instead of steps 1-3 above, run: Copy ``` ./target/release/litentry-collator \ --name="litentry-collator" \ --chain=litentry \ --state-pruning=archive \ --state-cache-size 0 \ --ws-external \ --rpc-external \ --rpc-cors=all \ --execution=wasm \ -- \ --execution=wasm \ --chain kusama ``` By default, the database is stored at `~/.local/share/`, you can override it by using `--base-path=`. To get the binary, you could either download it directly from Heima's [Github release page](https://github.com/litentry/heima/releases) (**Linux x86-64** only) or [build](broken://spaces/qZamGXeNdPKNQXKBWxz5) it from the source. # Ecosystem Welcome to the Heima Ecosystem. Explore how different projects and partners are building with Heima across the multichain landscape: * Parachain — Heima’s native Layer 1 network and ecosystem. * Litentry Foundation — Collaborative research and development in decentralized identity and cross-chain technology. * PumpX — A real-world case study of cross-chain DEX trading powered by Heima. # Parachain A basic concept introduction to parachain > A parachain is an application-specific data structure that is globally coherent and validatable by the validators of the Relay Chain. They take their name from the concept of parallelized chains that run parallel to the Relay Chain. Most commonly, a parachain will take the form of a blockchain, but there is no specific need for them to be actual blockchains.

Image from https://wiki.polkadot.network/docs/learn-parachains

Basically, **parachains** are layer-1 blockchains that connect to the **relay chains** (Polkadot, for example), which validate the state transition of connected parachains, providing a shared state across the entire ecosystem. Since the validator set on the relay chains is expected to be secure with a large amount of stake put up to back it, it is desirable for parachains to benefit from this shared security. Moreover, by using heterogeneous sharding, each parachain could be easily tailored through the [substrate](https://substrate.io/) framework, optimizing them for a specific use case and running in parallel rather than the same across all shards. To serve as the backbone platform for various Litentry products and achieve a transparent and decentralized user experience, our parachain was launched with customized features: * [Heima](broken://pages/SegzWaiaEtOxYTEld15m) (Previously known as Litentry) on Polkadot (onboarded on July 4th, 2022) {% hint style="info" %} The source code of our parachain can be found here: [https://github.com/litentry/heima](https://github.com/litentry/litentry-parachain) {% endhint %} ### Heima Network (Polkadot) * Chain ID: **2013** * [Parachain info](https://parachains.info/details/litentry) * [Polkadot-js endpoint](https://polkadot.js.org/apps/?rpc=wss://rpc.litentry-parachain.litentry.io#/explorer) * Blockchain Explorer: [**Statescan**](https://heima.statescan.io/#/) # Litentry Foundation Litentry Foundation Ltd. is the non-profit organization that supports the development of Heima Network.
### **Empowering the Future of Decentralized Identity and Cross-Chain Innovation** #### Litentry Foundation Vision To build a decentralized, privacy-preserving, and interoperable Web3 ecosystem where users have full control over their digital identities and data. The **Litentry Foundation** supports foundational infrastructure projects — including [Heima Network](https://www.heima.network) — that advance this vision. Our work focuses on enabling secure, user-centric identity systems and seamless cross-chain coordination for the next generation of decentralized applications. 🔗 Learn more: [litentry.com](https://www.litentry.com/) # PumpX
## PumpX — Seamless Trading, Powered by Heima **PumpX** is a next-gen omni-chain trading platform that delivers a frictionless trading experience — from token discovery to multi-chain execution — all built on top of the **Heima infrastructure**. By integrating Heima’s **omni-account**, **intent routing**, and **gasless execution**, PumpX allows users to buy and trade tokens across multiple chains with **one account** and **any token**, without worrying about wallets, bridges, or gas fees. > 🎥 [Watch PumpX in Action](https://x.com/pumpx_ai/status/1881679549316137180) *** ### 🚀 Why It Stands Out #### 🧠 Smart Info-to-Execution Flow Combining AI-powered insights with one-click execution, PumpX bridges the gap between meme discovery and on-chain trading, making real-time trends actionable. #### 🔐 Enterprise-Grade Security With support from Heima’s **TEE & SMPC-powered security stack** and a completed **SlowMist audit**, PumpX offers secure intent execution, 2FA protection, and phishing resistance. #### 🌍 Chain-Agnostic by Default Thanks to Heima’s infrastructure, users can trade across multiple chains using **any token as payment**. No native gas required, no wallet switching — just seamless interaction. #### 👥 Community-Centric Built for DeFi-native users and meme traders, PumpX evolves with its community. Feedback loops and fast iteration are core to its product growth. *** ### 🧩 Built with Heima PumpX showcases how external teams can build high-performance, cross-chain applications by integrating Heima’s: * **Omni-account login system** * **TEE-secured omni-executor** * **Unified liquidity access** * **Gasless transaction layer** It’s one example of how the **Heima ecosystem** empowers the next wave of decentralized applications. # Featured DApps Explore decentralized applications built with Heima’s infrastructure. # Web App The Heima WebApp is the official portal for interacting with the Heima Network — providing users with a simple and intuitive interface for cross-chain token transfers and network monitoring. #### 🔧 Key Features * HEI Token Bridge A secure and user-friendly bridge that allows users to transfer $HEI tokens between the Heima Network, Ethereum, and BNB Chain with minimal friction. * Token Conversion The WebApp supports one-way conversion between supported tokens, enabling a smooth transition and unified asset management within the Heima ecosystem. * Network Dashboard View real-time statistics including token supply, staking status, validator activity, and circulation across multiple networks — all in one integrated interface. 🔗 Try It Now：[apps.heima.network](https://apps.heima.network) # IdHub ### What is the IdentityHub (IDHub)? The IdentityHub is the interface to the protocol and front-end product of Heima. It functions as a **decentralized Web3 personal data management tool.** Designed for users to aggregate and manage their data among blockchains and decentralized storage systems and provide data access to 3rd party dApps to maximize personal identity value without compromising privacy & anonymity. \ \ The IdentityHub is the platform where users and projects can discover the value of identity data together. Projects can define their data requirements and attract their perfect user or audience in return for a benefit in the form of product personalization, early access, social impact, or other identity-based incentives. \ \ The IdentityHub is also an experimental playground for new social and economic innovations based on privatized identity data. It functions as a showcase of the Heima Protocol, SDK, and its privacy-preserving identity technology. ### 3 functions of the IdentityHub * **As an interface** to the underlying Heima Protocol, it offers features such as privacy-preserving identity linking, proving account ownership, and issuing privacy-preserving verifiable credentials based on the underlying digital data of the linked accounts. * **As a gateway,** it offers web3 products and services several ways and methods to guide its users in leveraging granular identity details to unlock a better product experience. * **As a platform,** it provides an environment where the web3 entrepreneur and digital identity owner meet to define the value of identity and can exchange data and benefits with one another. ### **The problem the IdentityHub (IDHub) solves** IdentityHub is a solution to the violation of user data rights and privacy breaches. It allows users to control who can access their data without revealing their personally identifiable information or root accounts. When a dApp uses IDHub to access user data, it is following the correct process for protecting user data rights. On the other hand, if users create identities on IDHub, they can be assured of their data rights. The IDHub protects personal data rights and restores an anonymous yet richly identifiable pseudonymous web browsing experience. Here are some of the features of the IDHub. # User Guides # Getting Started with the IDHub The IdentityHub is our interface to the protocol. This is the platform where the user and a project can discover the value of identity data together. To get started with the IDHub, users need to follow the following steps: 1. Visit the IDHub via and click the Start Your Journey button.
2. Upon clicking the button, a Connect Wallet prompt will appear on your screen. Select your desired EVM or Substrate wallet and click connect as shown below: Note: * Only Whitelisted addresses can access the IDHub for now. Click here to get whitelisted * For the purpose of this tutorial, we will be demonstrating using a Polkadot.JS wallet.
{% hint style="info" %} This connected address will be your primary account which you could build your identity around. {% endhint %} 3. Select your desired wallet address from the drop-down options and click the connect button.
4. Once you click the connect button, you’ll be redirected to your dashboard as shown below:
# Setting up a Shielding Key **Set up a Shielding Key** 1. Go to My Identity
2. Click on “Account is not protected by shielding key”
3. Upon clicking it, a dialog pops up to set a password for shielding key {% hint style="info" %} Make sure you set your shielding key with a strong password
{% endhint %}
4. Upon clicking the confirm button, another window will pop up requesting you to sign the message. Enter your wallet password and sign the message and your shielding key is successfully set.
5. Once set, your “My Identity” page will have the “Account is Protected by Shielding Key Banner”
# Linking a Web3 Account The next step in the process is to link your Identity. 1. On your “My Identity” page, Click the “Link Accounts” button:
2. Next, you’ll be redirected to the “Add New Accounts” page where you can link your Web3 (EVM and Substrate account) and Web 2 (Twitter and Discord) accounts.
Select your EVM or Substate account. As earlier mentioned, for the purpose of this tutorial, we will be demonstrating using a substrate-based account (Polkadot.JS wallet). 3. Click the “Link Account” button
4. Next, select your desired Substrate account type and click the “Connect” button.
5. Select the account you’ll like to link and choose the account type from the different available options and click the “Next” button.
6. You’ll be required to sign a proof message with your address. Click the “Sign” button to proceed.
7. Upon clicking the “Sign” button, you’ll be prompted to enter the password of your main account to sign the message.
8. Once entered, wait for a few moments and your account will be connected to the Identity Graph as shown below:

# Linking a Web2 Account - Twitter 1. Click the “Link Account” button to link your Twitter account
2. Enter your Twitter username to verify your Twitter identity and click next to proceed.
3. Upon clicking next, you’ll be required to tweet the content shown on your Twitter account. You can copy and paste it into your Twitter account or use the “Tweet it now” button to proceed accordingly. Upon tweeting the content, click the “I’ve sent it button”.
4. Next, copy and paste the link to the tweet so that it can be verified, and click the “Verify” button.
5. You’ll be required to sign the message as shown below:
6. Once signed, you have successfully linked your Twitter account.

# Linking a Web2 Account - Discord 1. Click the “Link Account” button to link your Discord account
2. Enter your Discord username to verify your identity and click next to proceed.
3. Copy the text shown and send it to the Litentry Discord Verify-Identity channel or use the “Send it now” button. Next, click the I’ve sent it button.
4. Copy the link to the Discord message
5. Then paste it as shown below so that it can be verified and click the “Verify” button.
6. You’ll be required to sign the message as shown below:
7. Once signed, you have successfully linked your Discord account.

# BRC 20 Sign-in ### **1. Preparation** Download the Unisat wallet.\ Link: ### 2. Login Connect your Unisat Wallet to IdentityHub.\ Link: * If you’re a new user, create a new wallet. * If you’re using OKX, Xverse, or MetaMask wallets, import the 12-word mnemonic and private key into Unisat Wallet. ***Note:*** Please log in using the Taproot wallet format (addresses starting with bc1p).
After creating your wallet, go back to IDHub, then refresh this page, and reconnect your wallet to log in to IDHub.
### **3. Set Password** After logging in, click on the bottom left to set your password to protect your data.
Set your password and click the "Confirm" button.
After successfully setting the password, you can enter the BRC20 space to start verifying credentials.
### **4. Generate Your Credential** Click the BRC20 Score profile as shown below:
a. On the BRC20 Score details page, you can see the start and end dates of this campaign. The campaign runs from December 26, 12:00 PM UTC, to January 7, 12:00 PM UTC in 2024.\ b. Your score and leaderboard will be displayed in the top right. Click the Leaderboard button to join.
In this campaign, we have prepared 7 credentials for verification: Ordi, Sats, Rats, MMSS, Long, Cats, and BTCs. Litentry & Ordinals Users are exclusive to the Litentry Discord server.
Taking rats as an example, click on rats to enter the RATS Holding Amount details page. Click “Generate Credential” to create your credential.
Please be patient while the credential is being generated.
When the page shows “Credential Claimed,” your credential claimed is successful.
Back to the details page, your verified RATS Holding Amount credential is successful, and the score is displayed in the top right. Click the Leaderboard button to join, then you can see your score rankings.
### **5. Verify Discord Credential** Join our Discord and, in the “📝︱verify-ordinals” channel, obtain the Ordinals User role. It is crucial to join our Discord as it is closely related to receiving rewards.\ Channel Link: [📝︱verify-ordinals](https://discord.gg/litentry)
# Generating Credentials Verifiable credential (VC) enables individuals to hold and share their digital identities with ease, privacy, and security. Go to the [Credentials page](https://idhub.litentry.io/credentials)
2. Select the credential you want to generate from the different options available on the credential page as shown below:
In this tutorial, we'll demonstrate how to generate a credential for "**Ethereum Account Class of Year**". {% hint style="info" %} **Different credentials have different identity requirements. You may need to link additional identities.** {% endhint %} 3. Choose your Ethereum account and select the account type and hit the "Confirm" button"
4. Next, you'll be required to sign a proof message with your address. Hit the "Sign" button to proceed.
5. Click the "Sign" button on the wallet pop-up and sign the transaction with your main account.
6. Next, click the "Check my Credential" button to generate your credential.
7. With this, you have successfully claimed your credential.
8. You can click the "Check My Credential" button to view your credential
9. To view your generated credentials, check the claim box as shown below:

# How to Stake, Bridge, and Unstake on IdentityHub (deprecated) How to Stake, Bridge, and Unstake on Heima IdentityHub: A Step-by-Step Guide ### 1. Logging into Your EVM Wallet Address To begin, log in using your EVM wallet address. Note that, currently, only EVM wallet addresses are supported on IDHub.
### 2. Access the Staking Interface Once logged in, navigate to the top of the page and click on the “Stake” button to begin the staking process.
## Staking on Heima (deprecated) ### Step 1: Open the Staking Menu Click on the “Stake” button to access the staking options.
### Step 2: Switch to Heima Chain Make sure to switch to the Heima chain before proceeding with the staking process.
### Step 3: Enter Stake Amount Input the amount you wish to stake. The minimum amount required is 5 LIT.
### Step 4: Select a Node Choose a node for staking. Note that the displayed APR reflects the base staking pool APR. The bonus APR from score rewards is unaffected by the node selection.
For more detailed information about nodes, click the “More functions in Cumulon” button.
## Bridging Tokens ### ETH to HEI **Step 1:** Switch to the ETH chain.
**Step 2:** Approve the amount to be bridged.
**Step 3:** Click on “Bridge” after approval. Note that there may be a delay, so please be patient.
### HEI to ETH **Step 1:** Switch to the Heima chain.
**Step 2:** Enter the staking amount. The minimum amount is 16 LIT, and a service fee of 16 LIT applies.
**Step 3:** Click “Bridge” to proceed.
## Claiming Rewards Rewards from the original Heima staking pool will automatically be credited to your wallet. However, bonus rewards must be manually claimed.
Unstaking **Step 1:** Click on “More functions in Cumulon” to navigate to the Cumulon interface.
**Step 2:** Connect your IDHub main account to the corresponding EVM address. Note that currently only IDHub main accounts with a staking score can participate in the bonus pool distribution.
**Step 3:** Select “Heima” as the chain.
**Step 4:** Click on “My Stake.”
**Step 5:** Select “Unstake.”
**Step 6:** After initiating the unstake process, there will be a 7-day cooldown period.
**Step 7:** During the cooldown period, you can cancel the unstake action if needed.
**Step 8:** After the cooldown period, click “Execute” to confirm the unstake (screenshot not available). This guide covers the essential steps for staking, bridging, claiming rewards, and unstaking on Heima. Below are the concluding actions to ensure that the entire process is successfully completed. ## Finalizing the Unstaking Process After the 7-day cooldown period, you will need to finalize the unstaking process: 1. **Execute the Unstake**: Once the cooldown period ends, click on the “Execute” button to confirm and complete the unstake. This action finalizes the process, and your staked LIT will be available in your wallet. 2. Although a screenshot is not available for this step, the process is straightforward and should be completed once the cooldown period concludes. ## Key Reminders * **Minimum Staking Requirements**: Keep in mind the minimum staking amounts for both staking and bridging processes (5 LIT for staking, 16 LIT for bridging). * **Node Selection**: When choosing a node, remember that the displayed APR is based on the original staking pool, and selecting a different node will not impact the bonus APR from score rewards. * **Cooldown Period for Unstaking**: The 7-day cooldown period is mandatory and cannot be skipped. However, if you change your mind, you can cancel the unstake during this period. * **Claiming Rewards**: Always ensure you manually claim your bonus rewards, as they will not be automatically transferred to your wallet like the standard staking rewards. By following these steps carefully, you can effectively manage your staking and bridging activities on Heima, maximize your rewards, and ensure the smooth operation of your assets.
# Direct Invocation Direct Invocation empowers clients to directly request the Enclave Sidechain while ensuring data integrity by posting the results on the Parachain. The IdentityHub has implemented the first version of Direct Invocation. This update enables users to send requests to the TEE enclave directly and reduces waiting time when accessing the IDHub services. This client<>blockchain request forwarding path change redirects service requests from IDHub now to the blockchain. Direct Invocation has streamlined the process for features like setting up a shielding key, linking identities, and generating VCs. Users can now directly send service requests to the TEE sidechain, eliminating the need to go through the Heima Network. Despite this change, the results of these actions will continue to be synchronized and logged on the Heima Network, ensuring data integrity and transparency. Changes in the request workflows: * (Formerly) In Indirect Invocation: IDhub <--> parachain <--> TEE sidechain <--> parachain. * (Currently) In Direct Invocation: IDhub <--> TEE sidechain <--> parachain. See below for the detailed request workflows. ### **Benefits and Tradeoffs** Benefits of this change include: * Increased speed in tasks such as setting up a shielding key, linking identities, and VC generation. * Removal of dependency on gas fees, enabling free services, and unblocking users from obtaining HEI tokens on a substrate wallet. * Maintaining the same level of security: Identity verification, user shielding key synchronization, and VC generation remain secure within the TEE sidechain, while VC issuance transparency remains intact through the Heima Parachain. Are there any trade-offs? * Temporary removal of HEI charges mechanism from VC generation. * Certain transaction logs may become invisible. ### Request Workflows #### Direct Invocation Request Workflows Here is how Direct Invocation changed the request workflow. It enables users to directly send requests such as "set shielding key," "link identity," and "request remove identity" to the TEE Enclave. {% @mermaid/diagram content="sequenceDiagram box Client (IDHub) participant Browser end box Heima Network participant Parachain participant Enclave end ``` %% Setup / Get Enclave's data Enclave->>Parachain: Register ``` Enclave->>Parachain: Get Shard and Enclave Shielding Key Browser->>Parachain: Get Shard and Enclave Shielding Key activate Parachain Parachain->>Browser: Return Shard and Enclave Shielding Key deactivate Parachain %% Client Request Browser->>Enclave: Request set User Shielding Key activate Enclave Note over Browser,Parachain: Wait for UserShieldingKeySet or Error Enclave->>Parachain: Emit UserShieldingKeySet or Error deactivate Enclave activate Parachain Parachain->>Browser: Process UserShieldingKeySet or Error deactivate Parachain Browser-->>Browser: Display result ``` loop [could be multiple identities] Browser->>Enclave: Request Link Identity activate Enclave Note over Browser,Parachain: Wait for IdentityLinked or Error Enclave->>Parachain: Emit IdentityLinked or Error deactivate Enclave activate Parachain Parachain->>Browser: Process IdentityLinked or Error deactivate Parachain Browser-->>Browser: Display result end loop [could remove multiple identities] Browser->>Enclave: Request Remove Identity activate Enclave Note over Browser,Parachain: Wait for IdentityRemoved or Error Enclave->>Parachain: Emit IdentityRemoved or Error deactivate Enclave activate Parachain Parachain->>Browser: Process IdentityRemoved or Error deactivate Parachain Browser-->>Browser: Display result end" %} ``` ### Indirect Invocation Request Workflow In the previous workflow of Indirect Invocation, users were required to send a request to the Parachain initially and wait for block generation before it could reach the TEE Enclave. {% @mermaid/diagram content="sequenceDiagram box Client (IDHub) participant Browser end box Heima Network participant Parachain participant Enclave end ``` %% Setup / Get Enclave's data Enclave->>Parachain: Register ``` Enclave->>Parachain: Get Shard and Enclave Shielding Key Browser->>Parachain: Get Shard and Enclave Shielding Key activate Parachain Parachain->>Browser: Return Shard and Enclave Shielding Key deactivate Parachain %% Client Request Browser->>Parachain: Request set User Shielding Key Note over Browser,Parachain: Wait for UserShieldingKeySet or Error activate Parachain Parachain-->>Enclave: Emit UserShieldingKeyRequested activate Enclave Note over Enclave,Parachain: Enclave: Process Parachain blocks Enclave->>Parachain: Emit UserShieldingKeySet or Error deactivate Enclave Parachain->>Browser: Process UserShieldingKeySet or Error deactivate Parachain Browser-->>Browser: Display result ``` loop [could be multiple identities] Browser->>Parachain: Request Link Identity Note over Browser,Parachain: Wait for IdentityLinked or Error activate Parachain Parachain-->>Enclave: Emit LinkIdentityRequested activate Enclave Note over Enclave,Parachain: Enclave: Process Parachain blocks Enclave->>Parachain: Emit IdentityLinked or Error deactivate Enclave Parachain->>Browser: Process IdentityLinked or Error deactivate Parachain Browser-->>Browser: Display result end loop [could remove multiple identities] Browser->>Parachain: Request Remove Identity Note over Browser,Parachain: Wait for IdentityRemoved or Error activate Parachain Parachain-->>Enclave: Emit RemoveIdentityRequested activate Enclave Note over Enclave,Parachain: Enclave: Process Parachain blocks Enclave->>Parachain: Emit IdentityRemoved or Error deactivate Enclave Parachain->>Browser: Process IdentityRemoved or Error deactivate Parachain Browser-->>Browser: Display result end" %} ``` # EVM Sign-In This feature allow users to interact with the IDHub with their Ethereum Virtual Machine wallet address. To expand the assertion of digital identity securely and privately, HeiHeima has extended its service provision to include Ethereum users with our Ethereum Virtual Machine (EVM) sign-in feature. This novel approach leverages the [Direct Invocation](https://docs.litentry.com/front-end-products/identityhub/product-features/direct-invocation) attribute of the Identity Hub that enables sending direct requests without the need to send extrinsics. With this, the IDHub can accept queries from EVM-based addresses, and users who do not own a parachain/substrate account can create IDGraphs and request VCs with their EVM wallet addresses. This is achieved by mapping the EVM address to the Substrate address space and by supporting the EVM signature scheme.
### Signature verification Currently, the Heima sidechain worker supports two new types of signatures: * `Ethereum` * `EthereumPrettified` They both use ECDSA secp256k1 to verify signature correctness. The difference is that the latter uses "`Heima authorization token:`" prefix to assure users that the transaction payload is generated within Heima context. ### Address mapping All `IdGraphs` are stored inside the substrate's pallet storage and identified by user's `AccountId`. This requires an address mapping from EVM format to Substrate format for all interactions originating from EVM wallets. We use a one-way mapping procedure. The mapping procedure involves: 1. Taking 20 bytes of EVM address 2. Prepending them with `evm:` 3. Computing `Blake2-256` ; and 4. Creating 32 bytes `AccountId` from hash result ### **Ethereum Virtual Machine** The Ethereum Virtual Machine (EVM) is a key component of the Ethereum blockchain. It is a runtime environment that executes smart contracts, which are self-executing contracts with the terms of the agreement directly written into code. It is often described as a sandboxed, isolated environment that ensures the execution of code is consistent across all nodes in the Ethereum network. The EVM operates on a stack-based architecture, where instructions manipulate data on a stack. It is a Turing-complete machine, meaning it can perform any computation that can be expressed algorithmically. This allows for the execution of complex operations and the implementation of decentralized applications (dApps) on the Ethereum network. Overall, the EVM enables the creation of a wide range of blockchain-based services and functionalities. The EVM sign-in feature on the IDHub empowers users to authenticate their identity using their Ethereum addresses. In essence, it’s akin to employing your Ethereum wallet to sign into a myriad of platforms, mirroring the convenience of using Google or Facebook for diverse website logins, with the big difference being that you control your data. ### Primary Identity of IDGraph Upon the launch of IDHub, an IDGraph is created when the shielding key for a Heima Network address is set. Users can link, verify, or remove identities and request VCs by sending extrinsics from that address. Now, the same can be done with an EVM address. This means that: * Each IDGraph has one primary identity, which can be a Heima Network address or an EVM address. * Only the primary identity can modify the IDGraph. * The shielding key is bound to the primary identity. * IDGraphs are not merged automatically. IDGraphs with distinct primary identities are considered different. For example, if substrateA links substrateB, and the user later logs in with substrateB, the IDGraph is empty and they need to link substrateA again if they want to include it in the VC assertion building. {% hint style="info" %} When users log in using an EVM address for the first time, a new account with an empty IDGraph is created. To set up this new IDGraph, users must follow steps including creating a shielding key, requesting a VC, and linking identities. Existing users wanting to log in with an EVM address cannot transfer their IDGraph from their previous substrate address. {% endhint %} It is important to note that the primary identity is the identity that can manage (read and write) the IDGraph. Users can designate at most one web3 address as the primary address with zero restriction on the network type (Heima Network or EVM address). The address that the user uses to log in to the IDHub for the first time becomes the default primary address and it can only be changed by sending a set\_primary request from the old primary address. ### **Implementation of EVM Sign-In** The core scopes of the EVM sign-in feature are: **Ethereum signature verification** - With EVM implementation, users will be able to create identity graphs and request VCs on IdentityHub with their EVM public/private keys, instead of only substrate keys. Users can sign in with their EVM-compatible addresses such as Ethereum and BSC to seamlessly access the IdentityHub services. This integration allows users to link their identity and establish an IDGraph using their EVM-compatible address as the primary account. **EVM IDGraphs** - An identity graph is a data structure that represents the relationships between different identities that belong to the same individual. It represents the relationship between a user’s different accounts and can be used to map out a user’s aggregated identity through his EVM address. **Identity Linking** - User Identity can be linked to only 1 IDGraph. This is because the user [shielding key](https://docs.litentry.com/front-end-products/identityhub/user-guide/set-up-a-shielding-key) is bound to the IDGraph but can only be managed by the primary identity. As a result of this, it is the only entity that can view or update the shielding key which is required to encrypt the user data (e.g. IDgraph, or VC payload). ### **Advantages of EVM Sign-In** * Security: Leverage the built-in security protocols of your Ethereum wallet to interact with the IDHub. * Simplicity: Bypass the hassle of juggling multiple usernames or passwords. Your Ethereum wallet address is the foundation of your web3 identity. * Interoperability: A bridge between Heima Network and Ethereum is been maintained to facilitate token flow and usage in both networks. This allows you to engage effortlessly with an extensive array of applications within the Ethereum ecosystem (now including the IdentityHub). # Verifiable Credentials (VCs) ### Overview Verifiable Credentials (VCs) are JSON files that prove statements of a person, with data as evidence contained, and can be trustlessly verified in its authenticity and timeliness by a third party. It can securely store and transmit information about identity, attributes, or relationships between consenting entities without revealing the individual’s personal information. By analysis of the on-chain history, IDHub is able to add credentials to the aggregated identity of the user. e.g. *The credential 'long term holder' is added or created when on-chain data proofs that the identity owner has held a digital asset over an extensive period of time*. These credentials can unlock custom product experiences, exclusive access, or other benefits. Credentials allow the IdentityHub to offer a tailored experience to the identity owner and show dApp offerings that fit the user's preferences. VCs are stored as clear text JSON files, which use the JavaScript Object Notation (JSON) format for storing and exchanging data. JSON is a text-based format that uses human-readable text to represent data objects consisting of attribute-value pairs and array data types. It is often used for transmitting data over networks or storing data in NoSQL databases because it is lightweight and easy to read and write. In a JSON file, data is organized into key-value pairs, with keys represented by strings enclosed in quotation marks and values represented by strings, numbers, booleans, arrays, or other data types. ### VC Schema To create or generate a VC, it is necessary to have a corresponding VC schema. A VC schema is a data model that defines the information that can be included in a VC and the rules for structuring, formatting, and organizing that information. It typically contains three critical fields: author, id, and content. In the IDHub, the VC schema outlines the types of information that can be included in a VC, the relationships between different data elements, and any requirements that must be fulfilled to validate a VC. To read more, check out our articles on Verifiable Credentials: * [Verifiable Credential I: Data Stardust and Constellations](https://medium.com/litentry/verifiable-credential-i-data-stardust-and-constellations-462846aa9970) * [Verifiable Credential II: Trustless Workflow in Litentry](https://medium.com/litentry/verifiable-credential-ii-trustless-workflow-in-litentry-cff972f79eab) # Identity Score ### Overview A **score** is an identity analysis of a user’s web3 & web2 behaviors. It is also a numerical value representing one or multiple Verifiable Credentials. The IdentityHub uses verifiable credentials to calculate these scores, and uses scores to match DID use cases with their desired audience. Scores provide a more granular assessment, filtering, or segmentation of the user, but are also less exclusive. However, they are more refined and complex than credentials. Every credential on the IDHub has its score and users that match the requirement of the credential can unlock it to rack up their score. Verifiable credentials generated by the Heima Network are attestation for user identification, they’re anonymous yet trustless. ### Scoring dimensions Scoring dimensions play a crucial role in providing a comprehensive and nuanced understanding of the factors that contribute to the overall score of a user within Heima's Identity Hub. These dimensions serve as distinct aspects or characteristics, essentially acting as building blocks for the final score assigned to an individual. They offer a detailed overview of the diverse elements that collectively shape a user's identity and trustworthiness within the Web3 ecosystem. Each credential associated with a user is tagged with a specific identifier or `tag`. These tags act as labels or markers that categorize the credentials based on their nature or the type of information they represent. This categorization is a key organizational mechanism that allows for a more efficient and insightful assessment of a user's score without the need to individually scrutinize every single credential. **Examples of scoring dimensions:** `Web 3` Anything that proves Web3 activity `Web 2` Anything that proves Web2 activity `Humanity` Anything that proves authentic human activity `Activity` Anything that proves activity `Holdings` Anything that focuses on the holdings of assets ### How to Calculate VC value The Heima Identity Hub calculates verifiable credential scores based on the VC format. This means that the calculation format is not fixed. Scores are calculated for VCs that return assertions in `boolean` or `count` * For `boolean`, the weight is put on either True or False, e.g. **y(if(value=T/F))** For example, those from the`oneblock` assertion, points are allocated if the outcome of the claim is positive or truthful. * For `count`, we will put weight directly based on the count, e.g. **x(value)**, or put a threshold on the count and weight on it, e.g. **z(if(value>n))** For instance, holding HEI token for 0 to 1 year might yield 5 points, 1 to 2 years might get 10 points, and so on. ### Score Logic Heima's score logic is a meticulous blend of scoring dimensions, weighted verifiable credentials, assertion description, etc., that underpins Heima's innovative approach to decentralized identity scoring. The IDHub community score is the first and one of the numerous scores of the IdentityHub, by showing the specific score logic components, we provide a detailed understanding of the various VCs, their descriptions, and associated score points. It also shows the issuers and data providers so that users can gain insights into how the scores are calculated.
TypeDescriptionName on the IDHubNetworkScore PointsDimensionIssuerData provider
HEI Holding TimeThe length of time a user continues to hold a particular token (with particular threshold of token amount)HEI Holding TimeEthereum/ HeimaIdentityHub Scoreif credential valid and now - issuance_date <= 100 days： now - from_date is at least 0 years, +5 now - from_date is at least 1 years, +10 now - from_date is at least 2 years, +15 now - from_date is at least 3 years, +25 now - from_date is at least 4 years, +50 now - from_date is at least 5 years, +100 now - from_date is >= 6 years, +200 if credential invalid, +0 If "now - issuance_date > 100 days, +0Holdings Web3HeimaAchainable
DOT Holding TimeThe length of time a user continues to hold a particular token (with particular threshold of token amount)DOT Holding TimePolkadotIdentityHub Scoreif credential valid, "now - issuance_date <= 100 days: now - from_date is at least 0 years, +5 now - from_date is at least 1 years, +10 now - from_date is at least 2 years, +15 now - from_date is at least 3 years, +25 now - from_date is at least 4 years, +50 now - from_date is at least 5 years, +100 now - from_date is >= 6 years, +200 if credential invalid, +0 if "now - issuance_date > 100 days, +0Holdings Web3HeimaAchainable
EVM/Substrate Transaction CountGets the range of number of transactions a user has made for a specific token on all supported networks (invalid transactions are also counted)ETH Transaction CountEthereumIdentityHub Score0 <= X < 1 => 0
1 <= X < 10 => +5
10 <= X < 20 => +10 20 <= X < 50 => +15 50 <= X < 100 => +25 100 <= X < 200 => +50
200 <= X < 300 => +75
300 <= X < 500 => +100
500 <= X < u64::Max => +200		Activity Web3HeimaAchainable
EVM/Substrate Transaction CountGets the range of number of transactions a user has made for a specific token on all supported networks (invalid transactions are also counted)HEI Transaction CountHeima / EthereumIdentityHub Score0 <= X < 1 => 0 1 <= X < 10 => +5 10 <= X < 20 => +10 20 <= X < 50 => +15 50 <= X < 100 => +25 100 <= X < 200 => +50 200 <= X < 300 => +75 300 <= X < 500 => +100 500 <= X < u64::Max => +200Activity Web3HeimaAchainable
WBTC Holding TimeThe length of time a user continues to hold a particular token (with particular threshold of token amount)WBTC Holding TimeEthereumIdentityHub Scoreif credential valid, "now - issuance_date <= 100 days, now - from_date is at least 0 years, +5 now - from_date is at least 1 years, +10 now - from_date is at least 2 years, +15 now - from_date is at least 3 years, +25 now - from_date is at least 4 years, +50 now - from_date is at least 5 years, +100 now - from_date is >= 6 years, +200 if credential invalid, +0Holdings Web3HeimaAchainable
ETH Holding TimeThe length of time a user continues to hold a particular token (with particular threshold of token amount)ETH Holding TimeEthereumIdentityHub Scoreif credential valid, "now - issuance_date <= 100 days, now - from_date is at least 0 years, +5 now - from_date is at least 1 years, +10 now - from_date is at least 2 years, +15 now - from_date is at least 3 years, +25 now - from_date is at least 4 years, +50 now - from_date is at least 5 years, +100 now - from_date is >= 6 years, +200 if credential invalid, +0Holdings Web3HeimaAchainable
Polkadot Governance Participation ProofYou have ever participated in any Polkadot on-chain governance events. This credential is counting: Technical Committee Proposals, Democracy Prososals, Council Proposals, Proposal Seconds, Proposal Votes, Democracy Votes, Council Votes, Treasury Spend Proposals.Polkadot Governance Participation ProofPolkadotIdentityHub ScoreTrue, +25Governance HeimaAchainable
Account Class Of YearThe class of year that the user account was created on a particular network (must have on-chain records)Ethereum Account Class Of YearEthereumIdentityHub Score

2015 +300

2016 +250

2017 +200

2018 +100

2019 +75

2020 +50

2021 +30

2022 +20

2023 +10

Activity Web3HeimaAchainable
Token HolderThe number of a particular token you hold > 0ETH HolderEthereumIdentityHub ScoreTrue, +25Holdings Web3HeimaAchainable
Token HolderThe number of a particular token you hold > 0HEI HolderHeimaIdentityHub ScoreTrue, +50Holdings Web3HeimaAchainable
Token HolderThe number of a particular token you hold > 0DOT HolderPolkadotIdentityHub ScoreTrue, +25Holdings Web3HeimaAchainable
Contract CreatorYou are a deployer of a smart contract on these networks: EthereumEthereum Contract CreatorIdentityHub ScoreTrue, +100Activity Web3HeimaAchainable
IDHub EVM Version Early BirdThe user is an early bird user of the IdentityHub EVM version and has generated at least 1 credential during 2023 Aug 14th ~ Aug 21st.IDHub EVM Version Early BirdEthereumIdentityHub ScoreTrue, +10Activity Web3HeimaHeima Indexer
Completion - OneBlock+ Substrate Blockchain Development CourseYou have completed the course co-created by OneBlock+ and Parity: "Introduction to Substrate Blockchain Development, Phase 12". OneBlock+: “We hope you will keep your enthusiasm and continue to explore on the road ahead.”OneBlock+ Substrate Blockchain Development Course CompletionPolkadot, KusamaIdentityHub ScoreTrue, +10Academy Web2OneBlock+OneBlock+
Outstanding Student - OneBlock+ Substrate Blockchain Development CourseYou were awarded the title "Outstanding Student" in the course "Introduction to Substrate Blockchain Development, Phase 12” co-created by OneBlock+ and Parity.OneBlock+ Substrate Blockchain Development Course Outstanding StudentPolkadot, KusamaIdentityHub ScoreTrue, +15Academy Web2OneBlock+OneBlock+
Participation - OneBlock+ Substrate Blockchain Development CourseYou were a participant to the course co-created by OneBlock+ and Parity: "Introduction to Substrate Blockchain Development, Phase 12".OneBlock+ Substrate Blockchain Development Course ParticipationPolkadot, KusamaIdentityHub ScoreTrue, +5Academy Web2OneBlock+OneBlock+
Uniswap V2/V3 UserYou are a trader or liquidity provider of Uniswap V2 or V3. Uniswap V2 Factory Contract: 0x5c69bee701ef814a2b6a3edd4b1652cb9cc5aa6f. Uniswap V3 Factory Contract: 0x1f98431c8ad98523631ae4a59f267346ea31f984.Uniswap V2/V3 UserEthereumIdentityHub Score

v2 true、v3 false - +50

v2 true、v3 true - +75

v2 false、v3 true - +25

v2 false、v3 false - +0

Activity Web3Heima Achainable
# IdentityHub Client The IDHub client helps users to generate, manage, and interact with their aggregated identities. The client also syncs with the parachain to submit the latest state of the user's ID graph and issue verifiable credentials. When a 3rd party dApp wants to access the user's identity data, it must make a request to the IDHub client and get the user's authorization before it gets the data. The Heima Network will only allow returning identity data to the identity owner, it is up to the user to decide whether to give the data to a 3rd party. The IDHub client allows the user to interact with the IDHub dashboard, IDgraph, VCs, and the Identity score. The client interacts with the parachain & sidechain - where calls made to the parachain are encrypted and opaque to invoke confidentiality. The content of the operation is only visible to the Client and the sidechain TEE (SGX, SGX workers/nodes, and SGX runtime).
Different types of calls can be executed by the client based on the operation destination. They include: * Untrusted Call: The client interacts with the parachain node via untrusted calls, sending transactions or queries. * Trusted call: The client interacts with the TEE enclave directly. * Direct Invocation: Client calls extrinsic in SGX runtime (same as a trusted call). * Indirect invocation: Client encrypts SGX runtime call, sends to Teerex Pallet in parachain. The worker node syncs blocks, identifies call\_work extrinsic, parses call from parachain, and dispatches them to SGX runtime. # Securing Privacy This page discusses how Heima will assure confidential identity data aggregation and computation. The Heima parachain carries the confidential identity data aggregation and generates trusted identity data. The following technologies are put in place to assure the users data privacy. ### Trusted Execution Environment (TEE) The storage of ID graphs and the entire identity data aggregation process will be implemented by the TEE Sidechain of the Heima network. A [Trusted Execution Environment (TEE)](https://en.wikipedia.org/wiki/Trusted_execution_environment) is an environment for executing code, it guarantees code and data loaded inside to be protected for confidentiality and integrity. The TEE is a secure area, also known as an "Enclave," that is isolated from the main operating system (OS). It is designed to protect data and ensure that it is stored, processed, and kept secured by an isolated, cryptographic electronic structure that is resistant to malicious attacks and unauthorized access. The hardware manufacturer guarantees that no one - not even the system administrator or the operating system - has access to the keys or can read the memory stored within the TEE. The Trusted Execution Environments contribute significantly to the security and privacy of IdentityHub by providing a secure enclave for the execution of sensitive operations, isolating critical data, and ensuring the confidentiality and integrity of identity-related processes. ### Confidential storage of ID graphs The IDHub Client will submit ID graphs to the blockchain and the blockchain will verify the ID graphs. Validated ID graphs will be stored in an encrypted on-chain TEE storage. ### Request desensitiser The request desensitiser is executed inside the TEE, it is designed for splitting accounts into separate queries and batching parallel requests belonging to different users aside from adding random addresses when sending it to external data providers. The request desensitiser makes it impossible for data providers to guess a user's ID graph based on the data requests. ### Decentralized data aggregation After sending data requests to data providers, the Heima network will listen to the results from data providers and aggregate the results. The data results will only include the relevant values and are aggregated according to the request ID. The user's address does not appear in the process or is not disclosed in the credential. ### Selective Disclosure A user will have maximal control over the amount of information they want to 'disclose' to a dApp. Heima's verifiable credentials allow the user to only disclose the minimum needed amount of information required for the specific use case. # IDHub FAQs For a complete overview of Heima’s vision, architecture, and key innovations, we recommend reading the full whitepaper. Please also visit more detailed FAQ's for [Heima Protocol](broken://pages/rodPVA8OPaERXe0c5jql) or [Trusted Execution Enclaves](broken://pages/RiWe6SRXBe0yYaQezgrY).
Can Heima see the accounts in my IdentityHub profile? No, the sensitive relationships between the accounts are stored in the [Trusted Execution Environment](broken://pages/RiWe6SRXBe0yYaQezgrY), which is only accessible when the private key of the identity owner is included in the request to open it. Currently, all the SGX nodes are under the control of Heima, which minimizes the risk of attacks by malicious nodes. Heima is actively working towards decentralization, and the eventual decentralization of the nodes is inevitable. [Please also read TEE FAQ](broken://pages/RiWe6SRXBe0yYaQezgrY)
What is a shielding key and how do I set my Shielding Key? A shielding key is a cryptographic key pair that is generated randomly and protected by the user password. Its public key is used by the Heima TEE worker to encrypt user-sensitive information when passing back the data. It is used to encrypt all the data in the communication between the user and the Heima Network. The shielding key is generated in the user’s local environment and used isolate sensitive user data from the IDHub server and all other third parties. Overall, it is an extra layer of security on top of your main account, used exclusively to encrypt your data for transmission and ensure only you or the Enclaves can decrypt it.\ \ **Set shielding key**\ 1\. Sign in with your Substrate or EVM wallet\ 2\. Go to My Identity\ 3\. Click on “Account is not protected by shielding key”\ 4\. Dialog pops up\ 5\. set your shielding key with a strong password
I'm receiving the UserShieldingKeyNotFound error. How do I reset my Shielding Key? You should reset your shielding key if you have been using an older version of the IdentityHub or experience problems linking accounts to your identity. If you get a `UserShieldingKeyNotFound` error, please reset your shielding key. You can reset your shielding key by clicking on 'My Identity' in the lefthand side. -> Afterwards click the 'Account is protected by shielding key' -> Reset Shielding Key. Once successfully done, linking identities and generating credentials should work.
My wallet is not connecting when setting my main identifier, or displays an error. When you are experiencing an error upon wallet selection make sure your wallet isn't rejecting your connection with the IDHub website. You will need to allow the website access manually from the wallet extension. If one doesn’t consent the connection at the start, your wallet extension won’t ask again and deny websites to connect in the future. Adjust this setting and allow connection in the settings of your wallet extension.
Metamask, or another wallet, is installed but i'm unable to connect with the IDHub? The problem you’re experiencing could be due to conflicts between browser extensions like Metamask and other built-in wallets (e.g., Coinbase Wallet). To fix this, disable all wallets except Metamask, restart your browser, and then test Metamask again. Multiple wallets in the same browser can often cause these issues.
What is 'linking an identity' & how do I it? Identity linking refers to the process of linking a Web2.0 or Web3 identity with their Heima Network address. An identity graph records the sensitive relationships between the different accounts of a user. It is used for mapping the user’s aggregated identity through any of the associated crypto addresses. The IDHub aims to provide the tool to generate a trustless identity graph that can be used for generating verifiable identity data for Web3 products and services.\ \ **Link an identity**\ 1\. Set shielding key (See above)\ 2\. Go to My Identity\ 3\. Click on Link accounts\ 4\. For web3 accounts\ 5\. Select substrate or evm account\ 6\. Sign the challenge code with your account-to-be-linked\ 7\. Sign the transaction with your main address\ 8\. Link Discord (If you are unsuccessful during campaign launch, wait until traffic is less)\ 9\. Link Twitter (If you are unsuccessful during campaign launch, wait until traffic is less)
I'm unable to link any web2 accounts to my identity (Discord, Twitter) The linking of your twitter or discord address relies on web2 API connections. There is a limit to the amount of connections we can make with web2 platforms at any given time. During peak traffic of campaign launches we request you to try again later.
I'm failing to link my Discord Identity. Search for you own message on #verify-identity in Heima Discord, click “More”= ‘Copy Link Message :link:’ then paste it as shown in the following tuturial so that it can be verified and click the “Verify” button. \ \ Follow the step by step for discord linking [here](https://docs.litentry.com/front-end-products/identityhub/user-guide/link-identity/link-web2-account#linking-a-discord). \ \ Make sure to provide the exact username that Discord displays; it’s case-sensitive. To find your username, click on your avatar at the bottom left, and hover over your username – you’ll see the option to ‘click’ to copy username.
What are the next chains that you would like to be more present on? Our protocol is designed to be EVM compatible, furthermore Identity Data and the format in which we issue identity data is ‘blockchain agnostic’. A verifiable credential is a human readable text format. See it as an official letter that contains all the necessary information to verify whether the content in the letter is true. Although we are using a parachain as a trust anchor to store our verifiable credential on any other dapp or protocol is able to use these credentials without the need to be present on the polkadot ecosystem. So we can basically integrate any type of data a blockchain data indexer can offer, be it avalanche, solana, or other L2’s.
How does the shielding key protect my data during processing and computation? A shielding key is a 256-bit AES-GCM cryptographic key pair that is generated randomly and protected by the user password. Its public key is used by the Heima TEE worker to encrypt user sensitive information when passing back the data. It is an extra layer of security on top of your Substrate private key (Account) used exclusively to encrypt your data for transmission and ensure only you or the Enclaves can decrypt it.
How do I send my verifiable credential to a dApp or community? Decentralised identity is in it's early stages and we need to see industry wide adoption of it's standards to reach a very user friendly experience. Currently we are exploring different options of transferring a credential or json format to the receiving project, community or verifier of the credential. We are exploring sending the credential from a wallet or offer custom integrations with partners.
Will the IDHub's credentials be used for KYC? Heima is currently not heavily focussed on **Know Your Customer** type of verifiable credentials. Heima supports the development of pseudonymous economies where credential are sufficient to Trust Your Customer. We hope to unlock a greater equality of opportunity for everyone regardless of their personal backgrounds or characteristics.
# Rules of IDHub v0.8 The following are the rules of IDHub v0.8. Users are advised to carefully read and abide by them while interacting with the IDHub. 1. **Season Duration and Scoring** **1.1 Season Duration**: Each season will last approximately one month. To ensure a fair competitive environment, the unified score will be reset at the season's conclusion. **1.2 Exclusive Benefits**: Users can unlock exclusive benefits based on their placement in the unified score rankings (only when their point total is greater than 0). These benefits will be awarded at the conclusion of each season. **1.3 Display of Rankings**: Rankings will be visible on the platform and updated at the close of each season. Users can view their current position and compare it with others on the platform. **1.4 Reset of Rewards and Benefits**: The unified score ranking, along with associated rewards and exclusive benefits, will be reset at the end of each season. New rewards and exclusive benefits will be available for the upcoming season. 2. **Unified Score and Reward System** **2.1 Unified Score**: The unified score aggregates points from each profile, taking into account factors such as user activity, engagement, and reputation. You can generate any credentials to accumulate unified scores. To maintain a fair competitive environment, the unified score will be adjusted downwards based on the user's ranking at the end of each season. **2.2 Rewards**: Rewards may include tokens, access to premium features, NFTs, and more. Rewards are based on the user's unified score and can be claimed once the requisite score threshold is met. However, each reward level is subject to availability and **will be allocated on a first-come, first-served basis**. 3. **General Tasks** **3.1 Account Linking**: You can link a Web3 account across different chains or Web2 accounts to earn scores. Note that scores can be earned only once per type of account linked. **3.2 Referrals**: Invite your friends to join IdentityHub. Once they generate credentials, you will earn scores based on their activities. **3.3 Daily Check-In**: Earn a set amount of scores daily by clicking the “Check-In” button. Check-ins reset at **UTC 0:00** each day, allowing you to earn scores again. Litentry holds the final interpretative authority for this event. # Glossary of Terms
TermDefinition
Auction (Parachain)Parachain auctions are how non-common-good parathreads win a slot to become a parachain
Aggregated IdentityAn identity that consists of multiple data streams from web3 & web2 accounts and platforms.
BountyA mechanism which works in some sense as the reverse of a Treasury Proposal, allowing the Polkadot Council to indicate that there is a need to do some task for the Polkadot network and allowing users to receive DOT in return for working on that task.
Council (Polkadot)An on-chain entity that consists of several on-chain accounts. The Council can act as a representative for "passive" (non-voting) stakeholders.
Decentralised IdentityAn identity that consists of multiple decentralised data points across web3 platforms and blockchains. A D-ID is managed and accessed by decentralised applications.
GovernanceThe process of determining what changes to the network are permissible, such as modifications to code or movement of funds. The governance system in Polkadot is on-chain and revolves around stakeholder voting.
Identity OwnerThe user who has provided access to his various accounts and in this way creates his aggregated identity.
Identity SubjectA label added to the the users aggregated identity determined by their on-chain credentials. e.g. 'Longterm Holder'
NFTA non-fungible token is a unique and non-interchangeable unit of data stored on a blockchain.
ReferendumA vote on whether or not a proposal should be accepted by the network. Referenda may be initiated by the Governance Council, by a member of the public, or as the result of a previous proposal.
Registrar

After a user injects their information on-chain, they can request judgement from a registrar.

Registrars can set a fee for their services and limit their attestation to certain fields.

(to) Second (Polkadot)Agreeing to a proposal by putting up tokens equal to the original bond
TaskFICompleting tasks to earn tokens
Treasury (Polkadot)The Treasury is an account that accumulates funds by inflation as well as by taking a portion of transaction fees and slashes.
# References Source Code Explore our open-source development on GitHub: Official Links Access all Heima resources in one place: # FAQ ### Why did Litentry rebrand to Heima? The rebranding marked Litentry’s evolution and renewed commitment to advancing **chain abstraction** and enabling **seamless interoperability** across diverse blockchain ecosystems. This rebranding was officially approved through Litentry’s decentralized governance process — see **Referendum #38**: . The new name marks a fresh chapter, signifying both technological evolution and community-driven progress. ### **Why choose the name “Heima”?** After much discussion and community input, we’ve chosen to rename Litentry to **Heima Network**. **“Heima”** means *“hometown”* — symbolizing a safe and welcoming place. It reflects our mission to provide users with **a stable, secure, and intuitive home for their digital identities and multi-chain assets**. Heima embodies our philosophy of: * Cross-chain integration * Seamless user experience * One-stop asset and identity management No matter which blockchain users are on, Heima is their **chain-agnostic home**. ### **What happens to the Season Program after rebranding?** The Season Program has been **paused for now**, but don’t worry, we haven’t forgotten the participants. All point collection and participation are **recorded on-chain**, and will be **taken into account** when designing new incentive mechanisms. Stay tuned! ### **When will $HEI staking launch?** **$HEI staking is planned for Q3 2025.** More details will be shared closer to launch. Make sure to follow our official channels for updates. # Support For any issues, questions, comments, feedback or concerns, please join Discord: # Brand Kit Access our official brand assets here: 📁 [Heima Brand Kit – Google Drive](https://drive.google.com/drive/folders/1im39ADF6q5UH4J30aEBLhW-toONq5s87) Please refer to the brand guidelines before using Heima’s identity assets publicly. # Read Online For a complete overview of Heima’s vision, architecture, and key innovations, we recommend reading the full whitepaper. ## Heima Whitepaper ### 1. Introduction #### The Rise of On-chain Activities Decentralized applications (dApps) and decentralized finance (DeFi) are experiencing explosive growth. Users across the globe are actively engaging in on-chain opportunities like: * **Meme Token Trading**: Driven by viral attention and community hype, meme tokens have become the new frontier for retail traders. * **Staking**: Yield-generating mechanisms to earn passive income. * **Arbitrage**: Exploiting price differences across exchanges and chains. However, these activities remain fragmented and technically demanding. #### The Problem Space Despite the growth, the current DeFi user experience is severely lacking in comparison to centralized exchanges (CEXs): 1. **Complex Cross-Chain Interactions** Users must manually switch wallets, bridge assets, and understand gas configurations across different networks. 2. **Chain-Specific Pricing Disparities** Token prices can differ dramatically between chains. Users often suffer slippage and missed opportunities because they can't access the best pricing in time. 3. **Lack of Automation** DeFi lacks automation primitives. Traders must track markets manually, adjust positions frequently, and manage gas and nonce settings themselves. #### Our Vision **Heima** aims to solve these problems by delivering a seamless, cross-chain DeFi experience that rivals CEX usability while maintaining decentralization. We combine: * A Layer 1 blockchain optimized for automation and abstraction. * An intent-based architecture to simplify cross-chain execution. * An agent hub to automate user-defined strategies. Heima bridges the gap between the fractured, manual-first DeFi ecosystem and a unified, frictionless Web3 experience. At the heart of the Heima ecosystem is our native token, HEI, which serves as the foundation for governance, gas fees, and cross-chain liquidity. HEI enables seamless operation across chains while ensuring the long-term sustainability and community-driven development of the platform. In the sections that follow, we outline the current challenges in the DeFi landscape and how Heima addresses these issues with a comprehensive Layer 1 solution designed to unify and simplify cross-chain interactions, creating a chain-agnostic future for DeFi users and developers. ### 2. Architecture Overview: From Abstraction to Coordination
Heima is a full-stack coordination protocol designed to abstract complexity across accounts, chains, and agents. It introduces a unified omni-account layer, cross-chain intent routing infrastructure, a permissionless agent hub, and its programmable Layer 1 blockchain — all tied together by auditable execution and verifiable automation. The system consists of four core components: * **Heima Layer 1 Network**: The coordination and registry layer that ensures all actors and executions are traceable, verifiable, and cross-domain auditable. * **Account Abstraction**: Omni-accounts unify user identity across chains and simplify onboarding with Web2-style authentication. * **Chain Abstraction**: A seamless intent infrastructure removes the need for users to understand or manage different networks. * **Agent Hub**: A permissionless marketplace for agents and bots to offer services ranging from trading to staking, all tied to intent execution. Each of these components is designed to be modular yet tightly integrated, creating a **chain-agnostic and intent-centric automation ecosystem**. This four-pillar approach creates a comprehensive solution where operations across multiple blockchains become transparent and simple for both users and developers. ### 3. Heima Network: A Layer 1 Designed for Interoperability and Automation Heima's Layer 1 blockchain serves as the **coordination layer** for intents, agents, and cross-chain execution. It is not just a settlement layer, but a programmable execution and automation layer — purpose-built for: * High-throughput, low-latency block production, with a goal to reach 500ms block time by the end of 2025. * Transparent registry of agents and intent fillers — enabling auditability across all activity across chains. * Native cross-chain and multi-network communication via prebuilt modules and proxy handlers. By serving as a **shared coordination and registry layer**, Heima ensures that **every task performed by agents is traceable**, and **intent fulfillment is verifiable** by any party, on-chain. #### 3.1 Substrate-based Flexibility Heima is built on **Substrate**, a framework for building custom blockchains. This gives Heima the advantage of: * **WASM + EVM Compatibility**: Developers can choose their preferred execution environment. * **Governance Modules**: Treasury, staking, bounty systems, and agent certification mechanisms are natively on-chain. * **Runtime Upgradeability**: Without hard forks, new features can be added or tuned in real-time. * **Decentralized Scheduler Pallets**: Allow agent tasks and user intents to be queued, re-tried, or timed. #### 3.2 Auditable by Design Heima introduces **transparency and verifiability** as foundational design principles for intent execution — across on-chain, cross-chain, and off-chain contexts. * **Unified Registry of Actors**: All agents, intent fillers, relayers, and execution services are registered on-chain, with traceable identities and verifiable roles. * **Omni Account Anchoring**: Every execution is pegged to an **omni account** — a cryptographically linked identity that spans multiple chains and off-chain environments via secure TEE-based key derivation. * **Cross-Domain Traceability**: Activities carried out on external chains or off-chain (e.g. in trusted enclaves or external APIs) are anchored back to Heima via attestations and signed logs, making them **provably accountable**. * **TEE-Secured Execution Proofs**: Off-chain execution logic that interacts with real-world systems or sensitive data runs in Trusted Execution Environments (TEE), and **emits cryptographic proofs** of integrity and correctness back to Heima. * **Intent Lifecycle Visibility**: From submission to resolution, every stage of an intent is **recorded immutably**, enabling users, auditors, and protocols to inspect the full execution path — including agent selection, condition triggering, and final state change. This system creates a **trust-minimized coordination fabric** where no single actor can alter execution flows undetected, and all participants are publicly accountable — even across heterogeneous systems. As the backbone of the Heima ecosystem, the Layer 1 network provides the necessary infrastructure for verifiable, secure cross-chain operations with high performance and native integration capabilities. ### 4. Account Abstraction: Unified Identity Across Web3 Heima's account abstraction introduces a seamless identity experience through the concept of the **Omni-account**, which acts as a user's unified ID across chains. Instead of managing fragmented wallets and credentials, users interact with all blockchain applications through this single, cohesive identity layer. The Omni-account system simplifies user onboarding by supporting familiar Web2 login methods such as email, phone number, passkeys, and social accounts — integrated through partner authentication services. Behind the scenes, Omni-accounts are represented on-chain via proxy accounts tailored to different network standards: EIP-7702 for EVM chains, native proxy contracts on Substrate-based networks, and TEE-backed secure proxies for environments where native wallet infrastructure is missing. This identity layer not only unifies user experience, but also enables **delegated operation** — projected accounts can act on behalf of the Omni-account with permissioned execution. Developers benefit from this abstraction by reducing the integration complexity required to support multi-chain identity and access logic. Additionally, Heima internally maintains an **identity graph**, linking user personas across applications and contexts, enabling intelligent personalization and interoperability without exposing sensitive metadata. Overall, Heima's account abstraction eliminates redundant key management, enhances security through smart contract and TEE based authorization, and unlocks flexible programmability for user-centric Web3 experiences. This fundamental shift in how users interact with Web3 provides developers with powerful tools for building seamless cross-chain applications with reduced integration complexity. ### 5. Chain Abstraction: Seamless Cross-Chain Execution
Chain abstraction in Heima allows users and developers to operate across multiple blockchains without needing to manage the nuances of each one. At the heart of this model is the **intent-centric execution framework**, where users express desired outcomes, and the system determines how and where to fulfill them. This is made possible through the **omni-executor**, a delegated execution entity that runs within a TEE-powered side-chain. When a user submits an intent (e.g. "swap token A for token B at best price"), the omni-executor consults a **routing engine** to determine the most optimal cross-chain execution path. It can then access liquidity and contracts on other chains by using proxy handlers and relayers, performing the task as if the user interacted directly. Chain abstraction also enables **gas abstraction**, allowing users to pay fees in any supported token across any network. The backend handles the conversions, removing the burden of needing native gas tokens on every chain. The architecture is modular: transaction composition, cross-chain routing, and signature validation are decoupled into independent services. This allows different implementation strategies based on user priorities — for example, cheap off-chain Request for Quotation(RFQ) matching vs. trust-minimized on-chain Decentralized Exchange(DEX) usage. All execution steps are recorded and validated on Heima's Layer 1, ensuring traceability, verifiability, and auditability. This makes Heima's chain abstraction infrastructure production-ready for complex DeFi workflows. Through this intent-based system, Heima transforms how users interact with multiple blockchains. Users simply express what they want to accomplish, and the platform handles the complex routing and execution across chains, maintaining complete transparency while adapting to different user priorities. ### 6. Agent Hub: A Permissionless and Extensible Agent Ecosystem The Agent Hub is Heima's infrastructure layer for registering, deploying, and managing autonomous agents — bots that act on behalf of users or protocols. These agents can be programmed to monitor markets, execute trading strategies, rebalance staking positions, or react to external signals such as news events or price feeds. Agent developers interact with Heima through a set of powerful APIs and SDKs. Agents register their capabilities and logic, optionally verify their code or operator identity, and begin offering services on the intent execution marketplace. Agents can plug into the Omni-account system or use external signing mechanisms to act on users' behalf. To support agents in real-time, Heima offers: * Access to live on-chain data (e.g. token prices, vault positions, arbitrage windows) via HTTPS and WebSocket APIs. * Integration with off-chain data through social media crawlers and oracle feeds. * Event-driven triggers via decentralized schedulers and external signals. To encourage growth of the agent economy, Heima includes native support for: * **Rebate and incentive models**: Agents earn from successful executions. * **Push notification services**: Inform users via dApps or email when actions are taken. * **Staking-based guarantees**: Agents stake tokens to back their actions with skin in the game, enabling trustless delegation. Ultimately, the Agent Hub turns Heima into a marketplace for intelligence — where agents compete to fulfill intents more efficiently, securely, and transparently. This vibrant ecosystem transforms DeFi from a manual process to an automated, intelligence-driven experience where specialized agents can perform a wide range of tasks with security guarantees and real-time data access. ### 7. HEI Token: Core Utility and Economics The Heima ecosystem is powered by its native token, HEI, which serves multiple crucial functions within the platform. HEI is designed to align incentives between users, developers, and the broader Heima community while facilitating seamless cross-chain operations. #### 7.1 Governance Framework Inspired by Polkadot's governance model, HEI enables a multi-layered decision-making system starting with Proposals that any token holder can submit by bonding a minimum amount of HEI. These proposals range from runtime upgrades to parameter adjustments. The Heima Council, elected by token holders, evaluates proposals and transforms them into Motions for deliberation. Approved motions advance to Referenda—the final stage where all HEI holders vote. The system employs adaptive quorum biasing where approval thresholds adjust based on voter turnout and the proposal's origin, ensuring sufficient community backing while preventing governance deadlocks. For urgent technical matters, a Technical Committee comprising blockchain experts can fast-track critical proposals like security patches by shortening voting periods. This balanced governance structure allows Heima to evolve with community input while maintaining operational security. #### 7.2 Gasless User Experience While HEI serves as the network's gas token, users never need to hold it themselves—one of Heima's most distinctive features. The platform aims to operate invisibly in the background, with the intent filler network sponsoring all gas fees on behalf of users. This gas abstraction layer removes a significant friction point in blockchain interaction. Developers can create seamless user experiences without forcing users to acquire yet another token. The economics balance through an operational reward system where intent fillers, functioning similar to validators, earn compensation for their active participation and resource expenditure. These rewards incentivize intent fillers to cover gas costs and perform essential cross-chain settlement work, representing compensation for computational resources rather than profit-sharing mechanisms. #### 7.3 Cross-Chain Liquidity Pools HEI’s most transformative function is enabling the Heima Chain Liquidity Pool system, where it serves as a mediation asset for exchanging network-native tokens across blockchains, specifically aimed at reducing cross-chain transaction costs. Users of the Heima Network may deploy their own smart contracts using templates provided by the network to create these cross-chain liquidity pools. These user-deployed pools aggregate liquidity from various blockchains. When a user initiates a cross-chain operation, the system can utilize these pools to efficiently acquire necessary native tokens on target chains, significantly reducing slippage and fees compared to traditional bridging. Participants in these user-created pools may earn transaction fees proportional to their contributions. This approach creates a mechanism where increased cross-chain activity can improve liquidity and execution quality while reducing costs. Participation is entirely at users’ discretion, with users responsible for understanding and managing any associated risks. The user-driven nature of these pools represents a significant advancement over conventional bridging mechanisms by creating a more decentralized cross-chain liquidity solution. ### 8. Partner Integration: Plug-and-Play Omni-Chain Enablement Heima offers a **comprehensive suite of solutions for business partners** — reducing migration overhead, accelerating go-to-market timelines, and unlocking omni-chain capabilities with minimal architectural disruption. Whether you're a **centralized exchange**, a **multi-chain DEX**, or launching a **new dApp**, Heima provides a seamless pathway into a unified cross-chain ecosystem — without requiring major infrastructure overhauls. #### 8.1 Modular and Flexible Integration Partners have full flexibility in how they integrate with Heima: * **Signer Options**: Heima supports: Self-custodial signers (for user sovereignty), Partner-managed custodians, Or Heima-provided **SMPC-backed** signer modules for secure multi-party control. * Authentication: Heima supports both **Web3 wallet login** and **Web2 login methods** (email, passkey, social account), enabling developers to **fully remove registration flows** and offer instant user onboarding. * **Custom Routing and Intent Handling**: Builders can leverage Heima's existing routing and intent execution network, or **plug in their own intent fillers, cross-chain routers**, or logic layers to fit specific product strategies. * **Customizable Monetization**: The **rebate module** can be tailored to specific business models, allowing partners to define their own revenue-sharing mechanics. #### 8.2 Built for Builders Heima's infrastructure is designed to be **plug-and-play** — offering **account abstraction, intent routing, and authentication layers** out of the box. New projects can focus entirely on product development and user experience, while Heima takes care of the underlying cross-chain and execution complexity. * Developer-friendly APIs and SDKs * Turnkey support for omni-chain workflows * Full interoperability with existing wallets, identity providers, and backend stacks This flexible approach allows developers to focus on user experience and product features, rather than the complexities of cross-chain execution and authentication, minimizing migration overhead while maximizing cross-chain capabilities. ### 9. Case Study: PumpX
PumpX demonstrates the transformative potential of Heima's omni-chain infrastructure in real-world applications. PumpX started as a single-chain DEX focused on meme tokens within the Solana ecosystem. Despite strong initial traction, user growth was limited by Solana-specific onboarding friction, token support, and gas awareness. By integrating Heima's account, chain, and agent abstraction layers, PumpX was able to seamlessly upgrade its platform without rewriting core logic: * **Onboarding**: Plug in for Web2-style login. Automatically creates Omni-account. * **Key Management**: PumpX continues to use its custodians as the master signer, while Heima's omni-executor requests authorizations from PumpX. * **Execution**: Leverage Heima's cross-chain routing and agent-based automation. #### Before Heima: * Only supported SOL for purchase * Prices were shown in SOL * No bridging or chain support outside Solana #### After Heima: * **Pay with Any Token**: USDT, BNB, ETH, etc. — from any chain * **Unified Price Display**: All meme tokens are priced in USD regardless of the origin chain * **Zero Gas Management**: User never sees or pays gas directly — it's abstracted by intent and routing layer * **Cross-chain Routing**: Heima routes to the cheapest market across Solana, BNB, Base, etc. * **No Compromise on Speed**: Heima prioritizes the trading speed with specified intent filler. This transformation demonstrates Heima's ability to simplify complex blockchain interactions, abstract away technical barriers, and create seamless, user-friendly DeFi experiences without requiring extensive rebuilding of existing infrastructure. ### Conclusion Heima represents a paradigm shift in how we think about and interact with blockchain networks. By abstracting away the complexities of accounts, chains, and execution, Heima creates a unified experience that rivals centralized exchanges while preserving the benefits of decentralization. The four pillars of Heima's architecture—Layer 1 Network, Account Abstraction, Chain Abstraction, and Agent Hub—work together to create an ecosystem where users can focus on outcomes rather than technical details. This intent-centric approach, combined with transparent, auditable execution, establishes a new standard for DeFi usability and accessibility. As demonstrated by the PumpX case study, Heima's infrastructure enables existing applications to transform their capabilities without significant redevelopment, accelerating the adoption of cross-chain functionality throughout the ecosystem. Heima envisions a future where blockchain interactions are seamless, automated, and user-centric—a future where DeFi isn't just for the technically savvy but accessible to everyone. By building this comprehensive coordination layer, Heima is taking a significant step toward making the chain agnostic future of finance a reality. # PDF Download You can download the PDF version of our whitepaper here Heima Whitepaper PDF: {% file src="/files/GRFS6lhqEMP02AO6LS3F" %}