The omnichain layer for crypto.

1Executive Summary

OmniHood is building the connective infrastructure crypto has been missing: a single layer where any asset, on any chain, can be swapped, launched, and spent without friction. Since launching on Robinhood Chain in early July 2026, OmniHood has expanded to seven supported chains — Solana, Ethereum, BNB Chain, Base, Robinhood Chain, Stable, and Avalanche — and shipped a functioning cross-chain swap product, a multichain token launchpad, and a spending card, all built and iterated on in public.

This document lays out what OmniHood is today, the technical architecture behind it, the token model for $OMHD, current network metrics pulled live from the protocol ledger, and what remains in development. Consistent with building in public, it separates the live from the in-progress rather than blurring the two.

Crypto today is fragmented by design. A user holding assets on one chain cannot easily:

• Buy a token that only exists natively on a different chain, without first bridging, waiting, and paying multiple sets of fees.
• Launch a new token that is usable across more than one ecosystem from day one.
• Spend crypto directly in the real world without off-ramping through a centralized exchange first.

Existing bridges solve part of this, but usually at the cost of speed (multi-minute settlement), UX complexity (multiple confirmations, manual route selection), or transparency (opaque liquidity mechanisms). Our own technical review of a competing project surfaced a token whose cross-chain price was synchronized without any independently verifiable liquidity behind it on the destination chain — a pattern we explicitly designed against.

3.1 Cross-Chain Swap Live

Swap any supported asset across seven chains in roughly three seconds. Routing is automatic — the user picks source and destination, confirms once, and receives funds without manually choosing a bridge path. Settlement currently runs on Relay (built by the Across Protocol team) for fast cross-chain execution, with Uniswap integration for tokenized-stock and equity-adjacent swaps.

3.2 Multichain Launchpad Live · early

Any existing or new token can become tradable across multiple chains from a single deployment:

• Create a real ERC-20 on Base (or an equivalent home chain), with a real, non-custodial pool via Clanker.
• OmniHood extends it multichain at 1:1 parity, backed by LayerZero OFT (Omnichain Fungible Token standard).
• Or take an existing token already live on one supported chain and make it multichain in one step.

Multiple tokens have been onboarded through the launchpad (including $MENSA, $ANSEM, and others), each with contract addresses published per chain for independent verification.

3.3 OmniHood Card Live · real-world testing

A Visa-based card that lets users spend crypto directly at merchants, demonstrated through real transactions (in-person purchases, a charitable donation). Card spend and cashback are tracked on the public network dashboard (Section 7).

3.4 In Development In progress

• Self-funding cross-chain liquidity layer — buy a token natively from any chain without a prior bridging step (Section 4). Built and tested against a local Base fork; not yet in production.
• Gas sponsorship — removing the need to hold native ETH to pay transaction fees.
• Telegram bot and native iOS/Android apps — announced, not yet shipped.
• Avalanche integration — added to the swap product; launchpad support pending.

This section describes the architecture currently in active development for enabling true native cross-chain purchases, as opposed to bridging.

4.1 Design

Each supported EVM chain runs its own local Uniswap v4 pool, seeded and funded by user liquidity providers through a shared OmniHoodVault. The system keeps every local pool's price aligned to a reference (“home”) price through an automated loop:

4.2 Fee & Liquidity Model

Liquidity providers deposit into the Vault and receive 70% of trading fees generated by their share; OmniHood retains 30% as protocol revenue. A portion of protocol fees is allocated to $OMHD buybacks and burns, tying token value directly to platform usage rather than narrative alone.

4.3 Known Trade-Off: Settlement Latency

Because rebalancing is asynchronous — it depends on LayerZero message delivery, which takes several seconds depending on source-chain finality and the Decentralized Verifier Network used — there is a brief window during which a local pool can be temporarily out of sync with the home price. This is a structural property of any asynchronous cross-chain messaging system, not unique to OmniHood. The mitigation is sufficient local liquidity depth and a well-calibrated drift threshold, both active engineering priorities.

4.4 Current Build Status

Each product is designed to reinforce the others rather than operate as an isolated feature. The intended loop, and the honest caveat about how far it has actually spun:

5.1 Why each link matters

• Chains → Launchpad: every new chain expands the set of tokens that can become multichain and the users who can reach them without bridging manually.
• Launchpad → Swap volume: each token launched multichain is a new source of swap activity, buyable and sellable from any supported chain.
• Swap volume → Fees → Liquidity depth: fees flow 70% to LPs, the direct incentive for liquidity to deepen; deeper liquidity shrinks the practical impact of the latency window in 4.3.
• Protocol revenue → burns + cashback: a share buys back and burns $OMHD (scarcity tied to usage) and funds card cashback (real-world spend tied to the token).
• Card + cashback → real-world utility: the loop's bridge out of pure speculation — a card transaction is useful without a token's price going up.
• Utility + burns → hold/use $OMHD → more launches: as the token accrues scarcity and utility, it becomes a more attractive base asset for new projects — closing the loop.

5.2 What has to be true for the flywheel to actually spin

We think it's more useful to state this plainly than to imply it's already spinning at full speed:

• Liquidity depth has to outpace the settlement-latency arbitrage window (4.3), or fee revenue leaks to short-term arbitrage instead of compounding into LP returns.
• The launchpad needs enough independent projects choosing to launch through it — the flywheel doesn't start turning from OmniHood's own tokens alone.
• The card's regulatory status needs resolving (Section 9); real-world utility only compounds if the product is durable.
• Burns need to stay tied to real fee revenue, not front-loaded or subsidized to fake momentum.

This section matches the official tokenomics published at omnihood.fun/tokenomics. An earlier draft proposed a fixed-supply allocation table (team / community / treasury percentages); that was speculative structure, not the team's actual design, and has been replaced with what is now published. We flag the change rather than silently editing it out.

6.1 Design: usage-driven, not supply-driven

OMHD has no fixed emission schedule and no published total-supply figure. No block rewards, no unlock cliffs, no team / investor allocation table to vest. The token is the settlement asset behind every OmniHood action — swaps, card issuance, token launches — and each action either buys OMHD back from the market or burns it outright. The team's framing: “usage is the only faucet, and most of that faucet points at the fire.”

6.2 The four fee mechanisms

6.3 Supply dynamics

The team states the net pressure across all mechanisms points down — deflationary by design, contingent entirely on usage volume rather than a fixed schedule.

6.4 What's independently verifiable, and what isn't yet

The tokenomics page pulls live figures directly from the protocol ledger (OMHD burned, buyback spent, cashback paid, swap volume), updating roughly every 30 seconds, and links to the contract on the Robinhood Chain explorer — a stronger transparency posture than most early tokens. What this document can't verify on its own: the actual circulating supply at any given time (the team declines to publish a number it says it can't verify on-chain from the page itself), and whether the 80% treasury share of swap fees sits in a transparent, publicly trackable wallet. We'd treat the second point the way we treat the card's regulatory status — worth asking directly rather than assuming either way.

6.5 No on-chain governance yet

OMHD does not currently carry voting rights over protocol parameters. Fee levels, chain integrations, and launchpad rules remain team-decided for now. This is a deliberate sequencing choice, not a permanent one: introducing governance before there's a large enough base of active participants risks “governance theater.” We intend to introduce governance once real usage and distributed holders make it meaningful, and will update this document when a concrete timeline is set.

Burn transactions are independently verifiable on-chain — each is sent to the standard null / burn address with full transaction details (gas, timestamp, contract verification), viewable on the Robinhood Chain explorer.

OmniHood is founded by 0xSebasDev, operating under a public, traceable identity rather than anonymously — a deliberate choice, given how much of the sector runs on unaccountable pseudonyms. Publicly listed prior involvement includes Decentra and TapTapRevolut, along with a background in the Celo ecosystem (six hackathon wins). Some affiliations are self-declared on the founder's public profile; we encourage independent verification rather than taking them at face value, consistent with the transparency standard we hold ourselves to throughout this document.

We'd rather list these plainly than have someone else discover them first:

• No independent smart-contract audit has been completed to date. One is a priority before mainnet deployment of the cross-chain liquidity layer (Section 4).
• Card issuance and compliance framework not yet publicly documented — the single most important transparency gap to close, given the regulatory sensitivity of payment cards.
• The cross-chain liquidity layer (Section 4) is untested in production. Local fork testing is not equivalent to mainnet, adversarial conditions, or high-volatility stress.
• The founder's prior token launches have not, to date, sustained value above their initial peak. Disclosed as track-record context, not a prediction about $OMHD.
• The broader Robinhood Chain ecosystem is new (launched July 1, 2026) and inherently volatile.
• OmniHood is not the first cross-chain infrastructure on Robinhood Chain — Robinhood's own wallet includes a native bridge (via Across), and Uniswap deployed on day one. Our differentiation is depth of tooling (launchpad + card + swap in one place), not first-mover status on bridging.

• 01Independent security audit of the cross-chain liquidity layer, ahead of mainnet deployment
• 02Public disclosure of card issuer and compliance framework
• 03Gas sponsorship (no native ETH required)
• 04Telegram bot and native mobile apps (iOS / Android)
• 05Continued chain expansion beyond the current seven
• 06Public tracking for the treasury wallet receiving the 80% swap-fee share (6.4)
• 07On-chain governance, once network usage and token distribution justify it

This whitepaper reflects where OmniHood actually is, not where we'd like to be perceived to be. Some of what's described is live and independently verifiable today; some is still code running against a local fork. We think that distinction matters more than the pitch, and we intend to keep updating this document as facts on the ground change — not to market ahead of delivery, but as a record we're willing to be held to.

This document is for informational purposes only and does not constitute financial, legal, or investment advice. Digital assets carry risk, including the risk of total loss. Nothing here should be construed as a guarantee of future performance, security, or regulatory compliance of any product described.

OmniHood · Whitepaper v0.1 · living document · figures in Section 7 pulled live from the ledger