Summary: Heima is best understood as a full-stack coordination protocol that bundles omni-account identity, cross-chain intent routing, agent execution, and a dedicated Layer 1 registry into one system. Its reusable mechanism is not just “better UX for multichain DeFi”; it is the attempt to move trust and coordination above individual wallets and bridges into a protocol-owned orchestration layer where omni-accounts, routing engines, registered fillers, and TEE-backed agents share one auditable control plane. Analytically, that makes Heima a useful comparison class for Epoch-style intent orchestration, Valence-style execution environments, and account-abstraction stacks that stop at the wallet layer.
What it does:
Gives users an omni-account that acts as a unified identity across chains and login methods
Maps that omni-account into different execution environments using EIP-7702 proxies on EVM chains, native proxy contracts on Substrate networks, and TEE-backed secure proxies where native wallet infrastructure is missing
Lets users express intents such as swap, stake, bridge, or automate, then routes them across chains through an omni-executor and routing engine
Adds gas abstraction so users can pay fees in supported tokens instead of maintaining native gas balances everywhere
Runs an Agent Hub where autonomous agents can register, advertise capabilities, and execute strategies or conditional tasks on behalf of users or protocols
Anchors identities, agents, fillers, attestations, and execution traces to a dedicated Heima Layer 1 so the system can claim auditable, cross-domain accountability
Key claims:
The official docs repeatedly describe Heima as a four-part architecture composed of a Layer 1 network, account abstraction, chain abstraction, and Agent Hub, which is why it is more useful to model as a coordination stack than as a single-purpose bridge or wallet product
The account-abstraction docs say the omni-account supports Web2 and Web3 login methods and maps into EVM, Substrate, and TEE-backed environments, showing that Heima is trying to own the identity layer above per-chain wallet conventions
The same docs say projected accounts can act on behalf of the omni-account with programmable permissions and that Heima maintains an internal identity graph, which means authority can accumulate in delegation rules and graph-linked identity context rather than only in signatures
The solution and whitepaper pages say an omni-executor inside a TEE-secured environment consults a routing engine to find efficient cross-chain paths and relays actions to a decentralized intent-filler network, placing practical control in execution orchestration rather than only in user wallets
The whitepaper frames Heima’s Layer 1 not merely as settlement but as a coordination and registry layer where agents, fillers, relayers, and off-chain execution services are registered and execution lifecycles are auditable, which is the clearest sign that Heima wants to be a trust-minimized control plane for cross-chain automation
The public GitHub repo says Heima evolved from Litentry and still includes runtime logic around enclave management, DID, an identity-worker sidechain, and omni-executor / TEE-worker components, reinforcing that secure enclave infrastructure is a core design dependency rather than a minor implementation detail
Because the stack combines EIP-7702-style account projection, intent routing, TEE execution, and agent registration, the main analytical question is where real authority ends up: in the wallet surface, the routing engine, the agent marketplace, the attestation layer, or the Layer 1 registry that certifies who is allowed to act
Whitepaper: The docs include a readable Heima whitepaper section rather than a standalone PDF. The strongest primary materials were the official docs introduction, core-concepts pages, solution page, whitepaper read-online page, and the public code repository; see ../whitepapers/heima-primary-sources-2026-05-09.md.