HOODLER: Global Universal Market Overview

Today, we are unveiling HOODLER, the onchain identity and liquidity layer for crypto — and the HOODLER App, the first native application built on top of it.

Both the network and application are in beta right now, and we would love to build together with fellow blockchain enthusiasts, developers, and users as we work toward the full release.

Crypto has created a world of abundant blockspace: faster VMs, more throughput, more scaling, better execution. But core parts of the blockchain stack that actually touches users - user level management, sequencing, cross chain liquidity - has been handled largely with offchain services.

Therefore, HOODLER is our effort to rethink how these are designed and bring these core primitives onchain with decentralized security.

The HOODLER stack has three main layers:

1. HOODLER Runtime — provides the core security and verification layer through DOVES, Universal Accounts, batch transactions, and eventually APEX.
2. HOODLER Omnichain Ledger — provides a single source of truth for balances, pending actions, in-flight funds, settlement, dynamic finality, and the Unified Dollar Framework across supported chains.
3. HOODLER Core Services — turn that verified state into working operations: intents, account services, liquidity aggregation, routing, deposits, swaps, transfers, and withdrawals — without becoming a separate custody system or independent source of trust.

The HOODLER App is the first user-facing manifestation of this stack. It lets users create a Universal Account, access supported assets across supported chains, use universal crosschain transfers, trade through the Universal Exchange, and track activity through the HOODLER Explorer.

Why HOODLER: Bring core user primitives onchain

For years, crypto has pushed the frontier at the base layer: more scaling, more throughput, more blockspace, better execution. We created a world of abundant blockspace — but the layer above the VM, the layer users actually touch, has barely changed at the primitive level.

This is the layer where users deal with accounts, identity, privacy, sequencing, crosschain security, liquidity access, transfers, and settlement.

Accounts are still mostly wallets and seed phrases, or worse — trusted custodians. Sequencing is centralized through offchain sequencers with no core accountability to users. Most blockchains accept sequencing and MEV as inevitable, without being resistant to it; their economy is focused on the parties that run validators and searchers, not on users.

Bridging is still fragmented across separate validators, oracles, bridge guardians, and operators. Liquidity is still coordinated by centralized venues, market makers, and listing processes. Multichain UX is still stitched together through bridges, wrappers, app balances, and manual routing.

So crypto ended up with a strange contradiction: the underlying chains became more decentralized and more performant, while the actual user experience became increasingly dependent on centralized systems. We decentralized the ledger, but re-centralized the user journey.

HOODLER exists to provide an alternative vision: onchain UX with decentralized security.

Identity, accounts, sequencing, crosschain security, liquidity, transfers, and settlement should become first-class protocol primitives — not centralized services layered on top.

The core purpose of HOODLER is three-fold.

1. To prove there are onchain paths for identity, sequencing, and multichain liquidity that maximize usability. Each is centralized today for a specific, fixable reason — not by law of nature — and we are rebuilding each primitive without the inherited design choice that causes its trade-off.
2. To make the many-chain world usable: each new chain brings new energy and innovation, but a many-chain world only works if someone builds the connective layer for users, liquidity, and applications to move across supported chains.
3. To balance utility and privacy: users should be able to use familiar real-world login methods without exposing their real-world identity onchain, with zero-knowledge proofs used where verification is needed.

HOODLER is our attempt to rebuild these core user primitives from the ground up, so users can finally get simple crypto UX without giving up the security properties that made crypto matter in the first place.

HOODLER Technology Stack

1. HOODLER Runtime: The security and verification layer

Foundation allowing us to bring core user primitives onchain without depending on a separate bridge, oracle, sequencer, or custody backend as the source of truth.

A. DOVES: Decentralized Observation, Validation, and Execution

DOVES are the observation, validation, and execution layer of HOODLER.

The same nodes that run the HOODLER runtime independently watch every connected chain and sign outgoing actions. There is no separate bridge or oracle to trust.

Because validators = bridge signing = identity verification, one account can work across many chains under one security model.

The intended long-term security model is stake-weighted: invalid signing requires control of a supermajority of validator stake.

B. Universal Accounts: Native programmable account system with OpenID-ZK support

Universal Accounts are the native account system of HOODLER.

They support an open-ended set of authentication methods: Ethereum keys, Solana keys, passkeys, and Google/X/Apple through OpenID-ZK, with more to come. The account system is not tied to any one wallet or login provider.

For Ethereum, Solana, and passkey-based accounts, verification happens through signatures: the address is derived from the public key, and no zero-knowledge proof is needed. For OpenID-ZK accounts, users can authenticate with familiar real-world identity methods without putting that identity onchain.

The account layer is designed to support programmable access control, session permissions, delegation, recovery, and onchain 2FA over time. Onchain 2FA and recovery flows are not available yet on current mainnet; they are planned and will be introduced alongside the User Program in the future.

No seed phrase is a side effect. The real point is a programmable account platform that developers can build use cases on top of.

C. Batch Transactions: Performance and cleaner execution

Batch transactions let many transactions lock once and execute together in an app-decided order, instead of forcing many separate lock/execute/release cycles to fight over the same state.

Batch transactions are already implemented in production. They are one of the primitives that make real onchain orderbooks possible: higher throughput, cleaner execution, and less dependence on public-mempool-style ordering games.

D. APEX: Stable-leader sequencing with formal eviction

APEX is our proposed stable-leader sequencing design with our take on how to optimize the most traditionally non-deterministic aspect of blockchains for users.

Leader rotation in the latency-critical path is one of the reasons decentralized systems become slow and jittery. APEX removes leader rotation from the hot path, while keeping the leader accountable through timeout, foul-play detection, and supermajority eviction.

The goal is near-instant, predictable landing without turning ordering into something a validator can simply sell to the highest tipper.

APEX is not integrated in Phase 1, but will be integrated in Phase 2 and beyond.

2. HOODLER Omnichain Ledger

Because DOVES create a single source of truth between what would usually be separate observers, validators, bridge signers, and executors, HOODLER can host an omnichain ledger regardless of how many chains, accounts, or transactions flow through the system.

The HOODLER omnichain ledger is a unified record of what accounts own, what is confirmed, what is pending, and what is in flight across supported chains. This is what makes HOODLER different from a normal bridge or aggregator. HOODLER is not just passing messages between chains; it maintains a signed, unified view of balances, settlement, and crosschain state.

This system allows users and applications to hold funds and transact freely across many chains in a simple way — much like a centralized exchange, but with the objective of being as decentralized as possible. Users should not need to think about where every balance sits, which bridge to use, which deposit address belongs to which chain, or whether an asset needs to be wrapped before it can be used.

One of the core problems in interchain design is the tradeoff between speed and the risk of chain reorgs. Most systems treat finality too statically: either wait too long for everything, or move too fast and take unnecessary risk. But in most cases, HOODLER knows the value of the transaction, the risk profile of the source chain, and how much value is currently in flight versus fully confirmed.

This allows the ledger to support dynamic finality: faster minting and withdrawals for smaller transactions and low-risk scenarios, while demanding higher finality from the DOVES for larger transactions or when there is more value in flight. The goal is simple: make normal usage feel fast, while forcing the system to become more conservative when risk actually increases.

A dollar held on HOODLER should be usable across supported chains without forcing users to think about bridges, deposit addresses, wrapped assets, or which chain their balance currently sits on. Over time, we can extend the HOODLER unified dollars to new chains as well.

3. HOODLER Core Services

The runtime secures and verifies the system. The omnichain ledger records all balances. Core Services turn that verification into working operations, with the objective of making the overall system as decentralized as possible.

Nothing in this layer holds independent trust: every action is an intent settled against the HOODLER ledger and executed through DOVE-signed actions. Services can relay and coordinate actions, but they cannot move user funds on their own. Only users control their funds.

Users sign what they want to do: swap X for Y, withdraw to a chain, or send an asset to another user. The runtime checks the ledger, the DOVES sign the outgoing action, and Core Services relay it to the target chain and settle it back. Users and developers never need to touch bridging mechanics.

Core Services also handle the operational side of universal accounts — sessions, permissions, and access today, with delegation, recovery, and onchain 2FA planned for future account upgrades. These flows run against the runtime's identity layer, rather than becoming a separate custody system or independent source of trust.

Core Services also handle liquidity aggregation and routing. HOODLER routes deposits, swaps, and transfers across chains to the best existing liquidity for each chain. The goal is not to recreate liquidity everywhere; the goal is to connect to the best liquidity where it already exists. We will expand only where liquidity, users, and security assumptions are strong enough.

HOODLER App

The HOODLER App is the first user-facing proof of the HOODLER stack — the place where users create accounts, access liquidity, move assets across chains, and see what happened through one native interface.

1. Universal Account — Log in with Google, X, Apple, passkeys, or crypto keys. No seed phrase by default, no wallet setup, no fragmented accounts across chains. For OpenID-ZK accounts, users can log in with familiar identity methods while keeping that identity offchain.
2. Universal Exchange — Buy, sell, and trade supported assets across supported chains from one app. Once an asset is tradable and reachable through HOODLER's liquidity layer, users should not need to wait for centralized listings or manually bridge funds before accessing it. Spot comes first; orderbook-style perps come from the same runtime primitives: batching gives the orderbook, the liquidity layer gives the assets, and accounts give the access.
3. Universal Omnichain Transfers — Deposit, send, swap, and withdraw across supported chains through one endpoint. One API call returns deposit addresses across supported chains; one plain transfer can arrive on the chain the user chooses. No claiming, no bridging UI, no separate bridge workflow.
4. HOODLER Explorer — View accounts, balances, deposits, transfers, swaps, withdrawals, and intent status across supported chains in one place. Instead of jumping between block explorers, bridge dashboards, and exchange histories, users and developers can see what happened, where it settled, and how it maps back to the HOODLER ledger.

Phase 1: Mainnet Beta

HOODLER is in mainnet beta right now, and the HOODLER App is in private beta — you can create an account and test it today.

Phase 1 is intentionally limited. Supported chains and assets are limited. APEX is not integrated yet. The app will likely not be as mature as what it can become on day one.

In Phase 1, all validators are operated by the team. This is deliberate: the priority is hardening the system's functionality before finalizing the economic model that will let independent third-party validators join. The architecture itself is decentralized by design — validator selection is the only permissioned element, and it is temporary. HOODLER does not depend on a centralized sequencer, bridge operator, or exchange backend; it depends on a validator set whose membership will open as the incentive model matures.

We are launching now because this stack only proves itself end-to-end: accounts, intents, liquidity, transfers, settlement, and real users.

Over the coming weeks, we will publish deeper technical papers and docs on the HOODLER runtime, DOVES, Universal Accounts, APEX, the omnichain ledger, liquidity routing, and our path to progressive decentralization.

In coming phases, we will be completing the rest of the core tech stack.

Pushing the boundaries of onchain UX.

Performance, decentralization, and usability trade off today for specific reasons — not by law of nature. Decentralized systems become slow when leader rotation sits in the critical path. Usability stays broken because identity was never native, so wallets and seed phrases became a key-management layer bolted on top. Multichain became dangerous because bridging was outsourced to separate trusted systems. Sequencing became captured because ordering turned into something validators, searchers, or centralized operators could sell to the highest tipper.

HOODLER does not claim to magically remove every trade-off. But we are rebuilding the primitives that caused those trade-offs in the first place: account management, sequencing, bridge signing, liquidity routing, and crosschain settlement. The bet is that these were not permanent limits of crypto — they were inherited design choices.

We built the runtime, services, and application together because these primitives cannot be proven in isolation. A new account model does not prove itself in a spec. A new sequencing model does not prove itself without real order flow. A new bridging model does not prove itself without real users moving real assets across real chains. The stack only proves itself end-to-end.

The direction is clear: HOODLER is rebuilding the user-facing stack of crypto — accounts, sequencing, liquidity, and crosschain movement — so onchain UX with decentralized security can finally become real.