HOT Protocol primary sources — 2026-05-13

Project status in this pass

• HOT Protocol’s clearest accessible primary materials in this pass were the official HOT Labs site plus the HOT docs for the protocol overview, MPC signing flow, Omni Balance, bridge flow, wallet connector, and authorization flow.
• The official whitepaper PDF was downloadable and saved locally as hot-protocol-whitepaper.pdf, but the strongest directly reviewable signal came from the docs pages rather than from extracted PDF text.
• The main reason HOT matters for the corpus is that it makes a specific chain-abstraction stack legible: identity-bound authorization, MPC signing, a NEAR-centered omni-balance ledger, and validator-backed bridge attestations are all distinct layers.

Primary-source snapshots

1) HOT Labs site

• URL: https://hot-labs.org/
• Key excerpts/signals:
  • Markets HOT as MPC Wallets that make web3 secure.
  • Highlights transferable wallets and two-factor authentication as first-class product properties.
  • Frames HOT around secure signing plus ownership transferability rather than around a governance token or generic wallet UX.
• Why it mattered:
  • It is the clearest concise statement that HOT wants to be understood as MPC-mediated wallet and identity infrastructure, not only as a bridge.

2) Protocol overview docs

• URL: https://docs.hotdao.ai/readme.md
• Key excerpts/signals:
  • Describes HOT Protocol as a combination of smart contracts and off-chain services focused on Chain Abstraction and Identity Management.
  • Says core logic is deployed on NEAR even though the protocol is framed as chain-agnostic.
  • Defines the identity problem as a middle ground between custodial exchange accounts and seed-phrase wallets.
  • Explicitly claims: no external governance or KYC over assets, full user control, flexible identity authorization logic, and transferable identity.
• Why it mattered:
  • This page gives the cleanest high-level statement of HOT’s intended decomposition: chain abstraction plus identity management via MPC.

3) Signature generation via MPC

• URL: https://docs.hotdao.ai/mpc-wallet/signature-generation-via-mpc.md
• Key excerpts/signals:
  • Says the primary use of the MPC network is secure signature generation.
  • Defines identity as wallet_id = hash(uid).
  • Says the MPC network has a master key from which per-identity keys are derived, while no one knows the master or derived secret keys.
  • Describes an authorization flow where the MPC network checks registry-based authorization methods for a given wallet_id before signing.
• Why it mattered:
  • This page is the most important evidence that HOT’s real control surface is identity-bound authorization policy checked by the MPC network, not just an ordinary wallet signature flow.

4) MPC API docs

• URL: https://docs.hotdao.ai/mpc-wallet/signature-generation-via-mpc/mpc-api.md
• Key excerpts/signals:
  • Shows concrete wallet-creation and signing flows.
  • Derives wallet_id and derive from an Ed25519 public key.
  • Uses signed proof messages and auth-account ids to install authorization rules.
  • Documents a /sign path where user_payloads are checked against registered auth methods.
• Why it mattered:
  • This page turns the architectural claims into a protocol/API surface with explicit wallet derivation and proof-of-authorization mechanics.

5) HOT Omni Balance docs

• URL: https://docs.hotdao.ai/hot-omni-balance.md
• Key excerpts/signals:
  • Describes HOT Omni Balance as cross-chain asset representations stored in an on-chain database smart contract on NEAR.
  • Says it is the canonical source of truth for omni-token balances.
  • Defines intents such as transfer, token_diff, and mt_withdraw.
  • Notes that execution can happen via solvers, optional on-chain AMM paths, and experimental intents-based orderbooks.
• Why it mattered:
  • This page shows that HOT’s chain-abstraction stack is not only about bridge attestations. It also has an intent-execution layer and a balance-normalization layer with their own chokepoints.

6) HOT Bridge docs

• URL: https://docs.hotdao.ai/omni-tokens.md
• Key excerpts/signals:
  • Defines the bridge architecture as locker contracts on supported chains, the HOT Omni Balance contract on NEAR, client-side bridge instructions, and HOT Protocol MPC validators.
  • Describes deposit and withdrawal flows where validators check chain state and produce signatures authorizing mint or release operations.
  • Says HOT Omni Balance implements the NEP-254 multitoken standard so bridged assets can be reused by NEAR contracts and intents.
• Why it mattered:
  • This is the clearest primary-source statement that bridge security and liveness depend on a validator-backed signing network rather than on pure light-client verification for these flows.

7) Authorization and wallet-connector docs

• URLs:
  • https://docs.hotdao.ai/hot-kit/authorization-flow.md
  • https://docs.hotdao.ai/hot-kit/manage-connected-wallets.md
• Key excerpts/signals:
  • auth() gets a JWT by signing a nonce-bound commitment rather than a transaction.
  • HotConnector manages connected wallets, balances, and active transactions across chain types.
  • The shared OmniWallet interface exposes transfer, balance, intent-signing, and auth methods across chains.
• Why it mattered:
  • These pages show the developer-facing control plane layered above the protocol: wallet normalization, backend authentication, and intent signing are treated as reusable middleware.

Working conclusion

HOT Protocol is best cataloged as chain-abstraction wallet middleware whose main reusable mechanism is the combination of identity-bound MPC authorization, NEAR-centered omni-balance accounting, validator-backed bridge attestations, and a normalized wallet/intents SDK surface. The decisive signal is not just cross-chain UX, but the way HOT makes identity policy, signing authorization, bridged balance state, and intent execution separate yet coordinated protocol layers.