Papers
Topics
Authors
Recent
2000 character limit reached

HOT Protocol (2512.02287v1)

Published 1 Dec 2025 in cs.CR

Abstract: HOT Protocol provides the infrastructure that allows smart contracts to securely own and manage private keys. The Multi-Party Computation (MPC) Network manages signing keys. By running an MPC node inside a Trusted Execution Environment (TEE), the protocol achieves stronger security guarantees while lowering economic requirements for participants. The NEAR Protocol provides a decentralized and efficient state layer. Key management can be integrated with any smart contract across Stellar, TON, Solana, and EVM-compatible networks.

Summary

  • The paper introduces a comprehensive framework where threshold MPC in TEEs secures smart contract key operations.
  • It details integration of cryptographic schemes, hierarchical key derivation, and on-chain governance mechanisms using gTOKEN.
  • Robust security measures including DoS mitigation, confidentiality enforcement, and signature indistinguishability support cross-chain interoperability.

Summary of HOT Protocol

HOT Protocol constitutes a generalized infrastructure enabling smart contracts to securely manage and utilize private keys via threshold Multi-Party Computation (MPC) within Trusted Execution Environments (TEE), complemented by robust on-chain governance mechanisms. By decoupling cryptographic key operations from specific blockchain constraints and leveraging distributed, hardware-secured computation, this protocol addresses inherent limitations in traditional smart contract architectures, such as secure key custody and cross-chain interoperability.

Technical Architecture

MPC Network and TEE Integration

The heart of HOT Protocol is an MPC network where private key material is generated and operated on in a decentralized, threshold manner. The protocol employs cryptographic schemes such as ECDSA and EdDSA for signing operations—using protocols including those in [gennaro-dkg], [fast-ecdsa], and [frost]—ensuring that individual nodes never possess complete key material, thus providing strong guarantees against key exfiltration and single-point compromise.

MPC nodes execute within TEEs—such as Intel TDX or AMD SEV—which enforce code integrity and data confidentiality at the hardware level. Remote attestation is periodically performed and verified on-chain to maintain integrity of the trusted regions. The nodes collaborate to sign messages once contractual authorization is fulfilled, with signature outputs indistinguishable from signatures produced by a single master key, rather than classical multisig outputs.

Contractual Key Ownership and Authorization

Key management is abstracted such that a smart contract can own multiple private keys, identified by key_id and mapped in an on-chain Key Registry. Signature requests are processed in a pull-based fashion: third parties trigger signing flows, which are subject to granular contract-based authorization that uses a read-only hot_verify method. This method specifies the conditions under which a message may be signed, allowing contracts to encode sophisticated policies—e.g., multi-factor, time-based, or identity-based checks—without re-deployment.

Key derivation leverages ideas from BIP32, supporting scalable hierarchical key generation without repeated DKG or resharing, enabling efficient support for applications demanding large, dynamically defined keyspaces.

Access Control and Load Management

A Gatekeeper Network intermediates between third-party requesters and MPC nodes, mitigating DDoS, spam, and abuse, and implementing rate limits and economic separation. Gatekeepers do not interact with private key material and are fully customizable, accommodating varied commercial and usage models.

On-chain Governance and Incentive Model

Governance is anchored by the gTOKEN, a native asset on NEAR Protocol driving staking, collateralization, and reward distribution. Roles encompass DAO members for policy and oversight, MPC node providers for computational integrity, Gatekeepers for capacity management, and Fishermen for open, incentivized monitoring. Economic mechanisms—staking, rewards, slashing—align incentives for honest participation and network liveness. Notably, TEE-signed logs are used as authoritative evidence in governance processes, including dispute resolution and penalization.

Security Model

HOT Protocol’s security design assumes an honest majority among MPC nodes and validated TEE integrity. Protocol-level mitigations include:

  • Denial of Service: Responsive node selection, key resharing, node blacklisting, and on-chain governance to exclude misbehaving participants.
  • Confidentiality: TEE enclaves isolate critical computations and key shares; periodic attestation and log-based monitoring mitigate mimicry and persistent attacks.
  • Access Layer Abuse: Gatekeeper quotas and log-based detection of abuse, with slashing mechanisms enforced by the DAO using TEE-signed evidence.
  • Smart Contract Registry Hardening: Authorization mappings and controller contract employ keyless operations, neutralizing unilateral takeover scenarios.

These measures ensure that compromise of individual nodes, gatekeepers, or governance actors does not subvert the threshold or economic security guarantees.

Numerical Results and Claims

The paper asserts the following strong security and performance claims:

  • Signature indistinguishability: MPC-generated signatures are byte-wise identical to standard ECDSA/EdDSA outputs, not multisig artifacts.
  • Hardware-enforced confidentiality/integrity: TEE isolation is proven via periodic attestation and is used as the basis for on-chain slashing.
  • Threshold resilience: No key material is reconstructible by fewer than the threshold number of nodes.
  • Scalability: Key derivation enables scalable management of large sets of keys without DKG bottlenecks.
  • Interoperability: Cross-chain key management is realized, with Bitcoin, EVM, Solana, NEAR, Stellar, and TON supported.

Implications and Future Developments

Practically, HOT Protocol enables:

  • Chain-Abstracted Assets: Smart contracts autonomously manage assets across heterogeneous blockchains.
  • Advanced Wallet/Policy Management: E.g., Bitcoin-style multisig wallets, passkey wallets, 2FA, seed rotation, recovery flows, and custom dApps not feasible via legacy smart contract patterns.
  • Programmable Cryptographic Governance: Composable, self-enforcing policies with transparent economic accountability.

Theoretically, this protocol advances the conception of trust-minimized computation for key management in adversarial settings, integrating cryptographic, hardware, and economic trust layers in a unified design. Open questions remain regarding further reducing trust in TEE manufacturers, optimizing MPC for lower latency, and provisioning formal guarantees in permissionless environments. Continued evolution may focus on zero-knowledge integration, post-quantum key schemes, and automated cross-chain dApp deployment.

Conclusion

HOT Protocol presents a comprehensive architecture for decentralized key custody and usage, leveraging MPC, TEEs, and tokenized governance to overcome secure smart contract limitations and enable chain-abstracted, cryptographically verifiable actions. Its security, scalability, and economic model position it as an enabling infrastructure for next-generation decentralized applications requiring cryptographic orchestration beyond any single blockchain domain.

File Document Download Save Streamline Icon: https://streamlinehq.com PDF File Document Download Save Streamline Icon: https://streamlinehq.com Markdown

Whiteboard

Explain it Like I'm 14

Overview

This paper introduces HOT Protocol, a system that lets smart contracts safely “own” and use cryptographic keys to sign messages and transactions across many blockchains. It does this by splitting the key across many computers (so no single computer ever has the full secret) and by running sensitive parts inside secure hardware. It also adds a fair, on-chain governance and rewards system so the network stays honest and reliable.

Key Objectives and Questions

The paper focuses on solving two main problems:

  • How can a smart contract sign things outside its own blockchain when it can only react to incoming transactions?
  • How can a smart contract control a private key if its state is public and anyone can read it?

In simple terms: the goal is to let smart contracts safely and automatically “approve and sign” actions in other places, without revealing private keys and without trusting any single machine.

Methods and Approach

The protocol combines several ideas. Here’s how they work in everyday language:

  • Smart contracts and authorization:
    • Each contract that wants a key defines a read-only permission check called hot_verify. Think of this like a teacher checking a permission slip. If hot_verify says “yes,” then the message can be signed.
    • Each contract can have multiple keys, identified by a key_id. A shared “Key Registry” remembers which contract controls which key_id.
  • Multi-Party Computation (MPC):
    • Instead of one computer holding the whole private key, the key is split into pieces called “shares,” and spread across many nodes. Imagine a treasure map torn into parts—no one can find the treasure unless enough people join their pieces.
    • A threshold (for example, “at least 3 of 5 nodes”) must cooperate to produce a valid signature. No single node can misuse or reveal the full key.
    • Key creation uses Distributed Key Generation (DKG), a method where nodes create and share key pieces securely from the start.
    • Keys can be “reshared” if the group changes (new nodes join, or the threshold is updated), without changing the actual key.
    • The network supports common signature types: ECDSA (used by Bitcoin and Ethereum-like chains) and EdDSA (used by Solana, NEAR, Stellar, TON).
  • Trusted Execution Environments (TEE):
    • Sensitive code runs inside a secured “room” inside the CPU that outside software cannot peek into or tamper with. This adds confidentiality, integrity, and attestation (proof that the right code is running).
    • Examples include Intel TDX and AMD SEV.
    • Nodes provide cryptographic attestation to a Controller contract so others can verify they are running trusted code.
  • Gatekeeper network:
    • Gatekeepers are like receptionists that organize incoming signing requests. They prevent overload, filter bad requests, and choose which MPC nodes will participate.
    • Gatekeepers never touch the private key shares. They simply manage traffic and capacity.
  • NEAR Protocol as the state layer:
    • NEAR stores the Controller contract and the Key Registry because it’s efficient and decentralized.
    • The Controller contract tracks node details (like IPs and public keys), manages network configuration, and coordinates resharing when group settings change.
  • Key derivation and scalability:
    • Instead of running expensive key-generation for every new configuration, the network creates one “root key” and derives child keys deterministically using tweaks (like BIP32 for wallets). The tweak is the key_id.
  • Full signing flow (simplified):

    1. A user asks for a signature via a Gatekeeper and provides the message plus any extra info the contract needs to check permissions.
    2. The Gatekeeper selects a threshold set of MPC nodes to handle the request.
    3. The MPC nodes check the Key Registry to find the contract for that key_id, call the contract’s hot_verify, and if it returns “true,” they jointly produce a valid signature.

  • Governance and incentives:

    • A governance token (gTOKEN on NEAR) supports staking, rewards, and decision-making.
    • Roles include DAO members (top-level governance), MPC nodes (hardware providers), Gatekeepers (traffic managers), Fishermen (independent monitors who report misbehavior), and users.
    • TEE-signed logs serve as evidence. Misbehaving nodes or Gatekeepers can be penalized (slashed), and Fishermen can earn rewards for reporting them.

Main Findings and Why They Matter

  • Smart contracts can securely control private keys without exposing them, enabling cross-chain actions.
  • MPC ensures that no single party holds the full key, and signatures look exactly like normal ones (not special multisig outputs).
  • TEEs add a hardware security layer, making it much harder to cheat or leak secrets.
  • The system scales by deriving child keys from a root key, avoiding costly repeated setup.
  • The governance model aligns incentives:
    • Honest node operators get rewarded.
    • Gatekeepers manage load and keep user interactions smooth.
    • Fishermen provide community oversight and get paid for catching bad behavior.
  • The paper demonstrates a real example: a passkey-based Bitcoin wallet. Here, the contract only authorizes signatures if the user’s device passkey (like Touch ID or Face ID) approves. That means the user’s device becomes the “permission slip,” and the MPC network safely produces the Bitcoin transaction signature.

Implications and Potential Impact

  • Chain-abstracted apps: Developers can build applications that act across multiple blockchains using one smart contract’s logic, instead of redeploying everywhere.
  • Safer wallets and policies: You can create flexible, high-security wallet features, such as:
    • Multi-signature without special on-chain setups,
    • Two-factor approval,
    • Seed phrase rotation,
    • Recovery flows,
    • Passkey-based login and signing.
  • Lower trust and higher resilience: By splitting the key and using hardware-secured nodes, the system reduces the risk of theft or misuse by any single operator.
  • Sustainable operations: With on-chain governance, transparent logs, and staking-based incentives, the protocol encourages stable performance, fair pricing, and accountable behavior over time.

In short, HOT Protocol gives smart contracts a secure, scalable way to “own” and use cryptographic keys, unlocking safer cross-chain actions and more advanced wallet features—without sacrificing decentralization or security.

Ai Sparkles Streamline Icon: https://streamlinehq.com View Paper Prompt List Streamline Icon: https://streamlinehq.com View All Prompts

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The following list highlights what remains missing, uncertain, or unexplored in the paper, framed as concrete and actionable items for future research and engineering work:

  • Formal security model and proofs for the composite architecture (TEE + threshold MPC + Gatekeeper + on-chain governance), including explicit adversary models (colluding nodes, abort attacks, side channels) and end-to-end security guarantees.
  • Remote attestation verification on-chain: how NEAR contracts can verify Intel TDX/AMD SEV attestation evidence without trusted oracles; on-chain anchoring of attestation roots, certificate chains, measurement whitelists, versioning, and revocation.
  • TEE vulnerability handling and fallback: procedures for network-wide response to newly discovered enclave exploits (e.g., Microcode/PSP/firmware issues), live rotation of measurements, staged rollouts, and liveness preservation during remediation.
  • Threshold Key Derivation Function specifics: precise derivation algorithm for threshold keys, including hardened vs non-hardened derivation, domain separation for key_id, collision resistance, path encoding, and security proofs (especially for cross-curve and multi-scheme derivations).
  • Key share storage, backup, and recovery: persistence model for shares inside TEEs, crash recovery, node re-joins, and disaster recovery workflows that avoid leakage; policies for re-sharing under churn and ensuring continuity after failures.
  • Nonce generation and randomness: specification for secure, unbiased per-signature nonces in threshold ECDSA/EdDSA, entropy sources inside TEE, concurrency safety, and provable protections against nonce reuse or bias across sessions and derived keys.
  • Authorization method semantics: a canonical message format, domain separation (including chain_id, contract_address, and purpose), strict anti-replay policies, explicit binding of metadata to the signed message, and handling of blockchain reorgs and finality depth.
  • Cross-chain read correctness: consistency rules for hot_verify across multiple chains when MPC nodes run light/full clients, including fork handling, finality thresholds per chain, and timeouts; how discrepancies are detected and resolved.
  • Gatekeeper selection and trust policies: documented algorithms for threshold node selection, fairness, anti-collusion, Sybil resistance, and preventing Gatekeepers from censoring or steering traffic to colluding nodes.
  • Gatekeeper security when “no TEE required”: a threat model and concrete mitigations for customized Gatekeepers without TEEs, including tamper-evident logging, signature schemes for receipts, and minimum evidence standards for slashing.
  • Capacity, rate limiting, and pricing: quantitative models translating gTOKEN quotas into concrete throughput and latency; adaptive rate-limit setting, demand forecasting, and performance SLAs for Gatekeepers and MPC nodes.
  • Slashing criteria and dispute resolution: formal definitions of misbehavior, evidentiary standards from TEE-signed logs, challenge windows, appeals, and protections against false-positive slashing or malicious DAO actions.
  • DAO governance capture risk: safeguards against coalition attacks and governance takeover, quorum thresholds, voting weights, onboarding/offboarding, emergency brakes, and how protocol parameters can be updated in contracts that “operate without access keys.”
  • Upgradability and migration for Controller and Key Registry: given the “no access keys” claim, how bug fixes, parameter changes, and contract migrations are executed; state continuity, rollback strategies, and auditability of changes.
  • Network synchrony and liveness assumptions: explicit assumptions and guarantees for DKG, resharing, and signing under asynchrony, partitions, and churn; expected failure modes and recovery procedures.
  • Threshold and membership parameters: recommended values for n and t, operator diversity requirements (geographic, jurisdictional, infrastructure), and guidance for tailoring thresholds to application-specific risk profiles.
  • Multi-curve, multi-chain support details: exact signature schemes and curves per chain, and how cross-curve authorization (e.g., secp256r1 passkeys authorizing secp256k1 Bitcoin signing) is standardized and secured; implications for KDF and derivations across curves.
  • Derived key lifecycle management: policies for allocating, rotating, retiring key_ids, preventing collisions/exhaustion, auditability of derivation paths, and per-contract multi-key policies.
  • Privacy of public logs: what request and metadata fields are logged, potential leakage risks, and options for redaction, aggregation, or delayed disclosure that preserve accountability while minimizing sensitive data exposure.
  • Third-party request standardization: a canonical structure for Gatekeeper co-signed requests (fields, canonicalization, deadlines, binding to key_id and contract policy), including replay protections and expiry semantics.
  • DoS resilience beyond node unavailability: robustness of DKG/resharing and signing under sustained adversarial churn, attacks on light clients/RPC endpoints, and poisoning of network configurations; mitigation playbooks and automated responses.
  • Economic sustainability and tokenomics: concrete inflation schedules, reward distribution formulas, staking requirements, and sensitivity analyses under varying demand/adversarial conditions to ensure long-term incentive alignment.
  • Chain-specific precondition compliance: standardized metadata schemas to encode transaction preimages and invariants (nonces, fees, spend conditions) across chains; reference libraries for invariant verification in hot_verify implementations.
  • Formal verification and benchmarking: plans for rigorous protocol proofs, reference implementations, testnets, performance benchmarks (latency/throughput), and fault-injection testing for abort/DoS scenarios.
  • Key deletion and revocation: procedures for decommissioning keys, revoking compromised key_ids, propagation of revocations to Gatekeepers and nodes, and guarantees on time-to-effect and completeness.
  • Attestation freshness and revocation workflows: expiry policies for attestation reports, distribution of revocation lists, and automated disabling of nodes with outdated or compromised measurements; on-chain representation and enforcement of allowable measurements.
Ai Sparkles Streamline Icon: https://streamlinehq.com View Paper Prompt List Streamline Icon: https://streamlinehq.com View All Prompts

Glossary

  • AMD SEV: A hardware-based virtualization technology providing memory encryption and isolation for virtual machines on AMD platforms. "SEV on AMD platforms"
  • Attestation: A TEE process that provides cryptographic proof of an enclave’s software identity and state to remote verifiers. "Attestation: The TEE can produce cryptographic proof of its software identity and state, allowing remote parties to verify that it runs trusted code."
  • BIP32: A Bitcoin standard for hierarchical deterministic wallets that enables deriving child keys from a parent key using a tweak. "This derivation model follows a mechanism similar to idea by \titlecite{bip32}, where a child public key can be derived from a parent public key using a known tweak"
  • Chain-Abstracted Applications: Applications that can authorize and execute actions across multiple blockchains under a unified control plane. "forming the basis for Chain-Abstracted Applications operating assets across multiple networks."
  • DAO: A Decentralized Autonomous Organization; an on-chain collective that governs protocol parameters and enforces integrity. "The DAO forms the top-level governance layer ensuring protocol integrity and parameter control."
  • Deterministic derivation: A method of deriving child cryptographic keys from a root key using a fixed algorithm and input tweak. "all subsequent operational keys are obtained through deterministic derivation."
  • Distributed Key Generation (DKG): A multi-party protocol that securely creates a private key and distributes shares to participants without any single party learning the full key. "Distributed Key Generation (DKG): securely generates a private key and distributes its shares across participating nodes."
  • ECDSA: Elliptic Curve Digital Signature Algorithm; widely used for digital signatures on Bitcoin and EVM chains. "ECDSA, used in Bitcoin, EVM-compatible chains, and Tron."
  • EdDSA: Edwards-curve Digital Signature Algorithm; a modern signature scheme used by networks like Solana, NEAR, Stellar, and TON. "EdDSA, used in Solana, NEAR, Stellar, and TON\@."
  • Enclave: An isolated, protected execution region within a TEE that keeps code and data confidential and tamper-resistant. "executed within an enclave remain isolated and unreadable to any external software layer"
  • EVM-compatible networks: Blockchains that support the Ethereum Virtual Machine, enabling smart contracts written for Ethereum to run with minimal changes. "across Stellar, TON, Solana, and EVM-compatible networks."
  • Fisherman: A role that monitors TEE-signed logs and opens disputes, earning rewards upon successful slashing of misbehaving actors. "Upon successful slashing, the Fisherman is rewarded with a share of the penalized stake."
  • Full node: A blockchain node that validates the entire chain state and transactions rather than relying on light-client proofs. "or a full node where a light node implementation is not available."
  • Gatekeeper: A rate-limiting and request-filtering intermediary that co-signs and relays user requests to the MPC network without handling private key material. "Gatekeepers never handle or store private key material."
  • Gatekeeper network: The dedicated layer that mediates access to MPC nodes, ensuring load balancing and abuse prevention. "Consequently, only the Gatekeeper network is permitted to access the MPC network directly."
  • Genesis block: The first block of a blockchain where foundational contracts can be deployed for initial configuration. "The MPC Controller Contract is deployed in the genesis block to serve two main purposes:"
  • gTOKEN: The protocol’s native governance and incentive token used for staking, collateral, capacity renting, and rewards. "At the core of the architecture is the gTOKEN, a native asset that underpins staking, incentive alignment, and governance execution across all protocol layers."
  • Group-testing (GBS-style) selection: A load-management strategy that selects responsive nodes using group-testing techniques to mitigate uncooperative behavior. "group-testing (GBS-style) selection"
  • Intel TDX: Intel Trust Domain Extensions; hardware support for isolating VMs and protecting their memory and state. "TDX on Intel platforms"
  • Key Registry: An on-chain contract that maps key_id values to their corresponding authorization (key-owner) contracts. "The Key Registry contract stores the mapping between key_id and its authorization contract."
  • Key Resharing: Refreshing and redistributing key shares to reflect updates in participants or thresholds while keeping the underlying key unchanged. "Key Resharing – enables the addition or removal of participants, or modification of the threshold value."
  • Key-owner contract: A smart contract that defines the authorization logic for message signing by keys associated with it. "The Key-Owner contract should make the key_id publicly accessible"
  • Light node: A blockchain client that verifies state using headers and proofs, avoiding the overhead of full-chain storage. "each MPC node must operate a light node for every supported network"
  • MPC Controller Contract: The on-chain coordination component that stores MPC network state, orchestrates voting, and triggers resharing. "The MPC Controller Contract is deployed in the genesis block to serve two main purposes:"
  • Multi-Party Computation (MPC): A cryptographic approach where multiple parties jointly compute functions (like signing) without revealing their private inputs. "The Multi-Party Computation (MPC) Network manages signing keys."
  • Multi-signature wallet: A wallet requiring multiple independent approvals; contrasted here with MPC’s single-signature outputs. "Bitcoin-style multi-signature wallets without new on-chain deployments for each policy"
  • NEAR Protocol: A layer-1 blockchain chosen for efficient, cost-effective on-chain state and coordination. "The NEAR Protocol provides a decentralized and efficient state layer."
  • NEP-141: NEAR’s fungible token standard defining how tokens behave and interoperate. "gTOKEN is a fungible token on NEAR Protocol (\titlecite{nep141})."
  • On-chain voting: Governance actions executed via blockchain transactions to update configurations and parameters. "handles configuration changes through on-chain voting"
  • Passkey: A passwordless authentication mechanism using public-key cryptography, with the private key stored on the user’s device. "A passkey is a passwordless authentication method based on public-key cryptography"
  • Passkey-based wallets: Wallets where transaction signing is authorized by a device-bound passkey (e.g., fingerprint or face ID). "Passkey-based wallets"
  • Remote attestation: A protocol where a TEE proves to a remote verifier that it is running trusted code with the expected identity. "Time-bound remote attestation, periodic re-attestation, code-identity checks pinned in Coordinator;"
  • Seed phrase rotation: Replacing the mnemonic used to authorize an MPC key, enabling key authorization to be updated without redeploying. "Seed phrase rotation (if a seed phrase is used to authorize a specific MPC key, this authorization seed can itself be rotated)"
  • Signature indistinguishability: The property that MPC-produced signatures are identical to signatures from a single key, unlike multisig outputs. "Signature indistinguishability: MPC-generated signatures are identical to those from the master private key, unlike traditional multisignature outputs."
  • Slashing: The punitive reduction of a staked amount for misbehavior or violations proven via logs and governance processes. "execute slashing when violations are proven"
  • Threshold cooperation: Requiring a minimum number of participants to jointly complete a signing operation. "Threshold cooperation: a minimum number of nodes must collaborate to successfully generate a valid signature."
  • Trusted Execution Environment (TEE): A hardware-enforced isolated context that provides confidentiality, integrity, and attestation for code and data. "A Trusted Execution Environment (TEE) is a hardware-enforced isolated execution context that offers the following guarantees:"
  • Tweak: A deterministic modifier used to derive child keys from a parent key without access to private shares. "Derived keys are referenced via a tweak, defined as the key_id."
Ai Sparkles Streamline Icon: https://streamlinehq.com View Paper Prompt List Streamline Icon: https://streamlinehq.com View All Prompts

Practical Applications

Below are practical, real-world applications derived from the paper’s findings, methods, and innovations. Each application includes sector alignment, potential tools/products/workflows that could emerge, and assumptions/dependencies that impact feasibility.

Immediate Applications

These can be piloted or deployed with the described architecture (MPC Network, TEE-attested nodes, NEAR-based Controller and Key Registry, Gatekeeper layer), and existing signature schemes (ECDSA/EdDSA).

  • Passkey-based Bitcoin wallets (implemented reference in the paper’s appendix)
    • Sector: Finance (retail crypto), Consumer software
    • Tools/Products/Workflows: Passkey-backed wallet app; Key-Owner contract on NEAR mapping key_id to passkey; Gatekeeper-routed signing; MPC threshold ECDSA
    • Assumptions/Dependencies: Device support for WebAuthn/passkeys; operational MPC Network and Gatekeepers; honest-majority MPC nodes; Intel TDX/AMD SEV for TEE; light/full nodes for Bitcoin and NEAR
  • Contract-controlled multi-signature wallets without redeploys per policy
    • Sector: Finance (DeFi, custodial services), Enterprise crypto operations
    • Tools/Products/Workflows: “Policy-as-code” hot_verify authorization; hierarchical key derivation (BIP32-like tweak-based key_id); Key Registry binding; threshold signing across EVM/Solana/TON/Stellar
    • Assumptions/Dependencies: Mature MPC DKG/resharing; contract read-only verification semantics; availability of chain clients on MPC nodes
  • Two-factor (2FA) authorization for dApps and wallets
    • Sector: Software, Finance (DeFi), Identity and access management
    • Tools/Products/Workflows: Second-factor checks encoded in hot_verify (e.g., passkey + OTP or device attestations); Gatekeeper-enforced rate limits to mitigate abuse
    • Assumptions/Dependencies: Reliable Gatekeeper routing; device authentication support; deterministic access to metadata/pre-images required for invariant checks
  • Seed phrase rotation and wallet recovery flows
    • Sector: Finance (non-custodial wallets), Consumer software
    • Tools/Products/Workflows: Recovery policies encoded in hot_verify; periodic re-binding of key_id to new authorization seed or recovery method; TEE-signed auditability of changes
    • Assumptions/Dependencies: User education and UI for rotation; DAO-governed slashing to deter malicious operator behavior; MPC resharing liveness
  • Chain-abstracted dApps managing assets across multiple networks
    • Sector: Finance (cross-chain DeFi), Software (Web3 app platforms)
    • Tools/Products/Workflows: Unified smart contract logic on NEAR controlling key_ids; MPC signing for transactions on Bitcoin/EVM/Solana/Stellar/TON; Gatekeeper request orchestration
    • Assumptions/Dependencies: Light/full node coverage per supported chain; correct hot_verify logic; consistent authorization metadata formats; cross-chain fee economics
  • Enterprise-grade co-signer for institutional custody and treasury operations
    • Sector: Finance (custody, exchanges, corporates), Compliance/RegTech
    • Tools/Products/Workflows: HOT MPC as an additional approval domain; TEE-attested logs for internal/external audits; rate-limited Gatekeeper tenancy
    • Assumptions/Dependencies: Institutional policy integration; audit acceptance of TEE-signed logs; gTOKEN staking and slashing live; DAO governance functioning
  • Oracle data signing and off-chain attestations with audit trails
    • Sector: Finance (DeFi oracles), Data infrastructure
    • Tools/Products/Workflows: Oracle feeds signed via MPC key_ids authorized by hot_verify; TEE logs provide evidence for disputes; Fishermen monitor for misbehavior
    • Assumptions/Dependencies: Oracles willing to integrate HOT authorization; Fishermen participation; network throughput adequate for data cadence
  • TEE-signed audit trails for compliance and dispute resolution
    • Sector: Compliance/RegTech, Policy
    • Tools/Products/Workflows: TEE-signed logs (requests, validation outcomes, protocol statuses) published for Fishermen and auditors; on-chain dispute resolution via Controller
    • Assumptions/Dependencies: Reliability of Intel TDX/AMD SEV attestation; DAO processes for slashing; legal frameworks receptive to hardware attestations
  • Developer toolchain for cross-chain key management
    • Sector: Software (developer tooling), Education (Web3 curricula)
    • Tools/Products/Workflows: SDKs for hot_verify patterns; templates for Key Registry and Controller integration; Gatekeeper APIs; example policies (2FA, social recovery, multi-tenant keying)
    • Assumptions/Dependencies: Documentation and sample contracts; availability of testnets; developer adoption
  • Rate-limited signing capacity leasing via Gatekeepers
    • Sector: Platform/SaaS for Web3 ops
    • Tools/Products/Workflows: Gatekeeper-operated tenancy; per-user capacity plans; receipts co-signed by Gatekeepers; public logs to deter quota abuse
    • Assumptions/Dependencies: Gatekeeper stake and incentives; deterministic rate-limit enforcement; DAO oversight

Long-Term Applications

These require further research, scaling, standardization, or sector-specific integration and regulatory acceptance.

  • Regulated institutional custody and audit standards built on TEE-MPC
    • Sector: Finance (banks, qualified custodians), Policy/RegTech
    • Tools/Products/Workflows: Standardized audit frameworks accepting TEE-signed logs; certification for MPC node operators; formal incident response tied to slashing
    • Assumptions/Dependencies: Regulatory approval of hardware attestation as evidence; mature DAO governance; standardized Gatekeeper APIs and SLAs
  • Cross-chain DAO governance and treasury management at scale
    • Sector: Finance (DAOs), Software (governance platforms)
    • Tools/Products/Workflows: Governance decisions translate to multi-chain actions via hot_verify; multi-tenant key derivation for sub-treasuries; automated resharing on membership changes
    • Assumptions/Dependencies: High-throughput MPC signing; robust key resharing on dynamic thresholds; resilient light/full node infrastructure across chains
  • Decentralized identity and verifiable credentials anchored by HOT-controlled keys
    • Sector: Identity, Education (credentials), Workforce
    • Tools/Products/Workflows: DID methods where hot_verify encodes issuance and revocation policies; passkey-based identity wallets; credential signing across chains
    • Assumptions/Dependencies: Interoperable DID standards; acceptance by institutions; privacy-preserving metadata handling
  • Healthcare consent and data access signatures with TEE-audited trails
    • Sector: Healthcare (EHR consent, data exchange)
    • Tools/Products/Workflows: Patient-provider consent policies encoded in hot_verify; TEE logs for audit; cross-organization key_ids; MPC as neutral co-signer
    • Assumptions/Dependencies: HIPAA/GDPR compliance; sector-specific legal acceptance of cryptographic logs; integration with healthcare data standards
  • Supply chain document signing and provenance across networks
    • Sector: Supply chain, Trade finance
    • Tools/Products/Workflows: Bills of lading/invoices signed via MPC keys; chain-abstracted provenance records; Gatekeeper throttling for high-volume operations
    • Assumptions/Dependencies: Industry standards for digital documents; cross-chain formats; integration with existing ERP systems
  • IoT/Robotics command authorization and rate-limited control
    • Sector: Robotics, Industrial IoT
    • Tools/Products/Workflows: hot_verify gates device commands; Gatekeeper rate limits for safety; TEE attestation for trusted edge signers; MPC-backed “operator of operators”
    • Assumptions/Dependencies: Low-latency MPC protocols; secure device identity mapping to key_id; safety certifications
  • Energy microgrid settlement and machine-to-machine payments
    • Sector: Energy
    • Tools/Products/Workflows: Autonomous agents sign settlement transactions across chains; policy-controlled key_ids for devices/substations; Fishermen and DAO for dispute resolution
    • Assumptions/Dependencies: Market and regulatory acceptance; integration with grid telemetry; economic predictability of gTOKEN costs
  • Formal verification and model checking of authorization policies (hot_verify)
    • Sector: Academia, Software assurance
    • Tools/Products/Workflows: Specification languages and toolchains to prove invariants (e.g., transaction pre-image verification, rate limits, quorum logic); test suites for cross-chain correctness
    • Assumptions/Dependencies: Availability of formal methods for target languages; adoption by developers; verified reference implementations
  • Post-quantum threshold signing and new schemes (e.g., BLS, PQC)
    • Sector: Cryptography research, Finance (future-proof custody)
    • Tools/Products/Workflows: MPC protocols for PQ signature schemes; migration pathways for key_ids; hybrid authorization policies
    • Assumptions/Dependencies: Mature PQC standards and efficient MPC implementations; TEE support for new primitives
  • MPC-as-a-Service and TEE-backed signer marketplaces
    • Sector: Cloud/Web3 infrastructure
    • Tools/Products/Workflows: Managed MPC nodes with attestation guarantees; Gatekeeper ecosystems offering differentiated SLAs; usage-based pricing denominated in gTOKEN or stablecoins
    • Assumptions/Dependencies: Operator diversity; robust slashing and reputation systems; standard APIs
  • Education and workforce credentials (cross-chain issuance and verification)
    • Sector: Education, HR
    • Tools/Products/Workflows: Universities issue degrees via HOT-controlled keys; employers verify via multi-chain signatures; revocation policies in hot_verify
    • Assumptions/Dependencies: Institutional participation; credential standards; privacy-preserving verifications
  • Public policy frameworks using TEE-signed logs for enforcement and oversight
    • Sector: Policy/RegTech
    • Tools/Products/Workflows: Official guidelines recognizing hardware-attested logs for digital asset operations; dispute resolution pipelines with Fishermen; standardized evidence formats
    • Assumptions/Dependencies: Legal update cycles; collaboration with standards bodies; demonstrable reliability of attestation
  • Large-scale cross-chain automation for structured financial products
    • Sector: Finance (asset management, trading)
    • Tools/Products/Workflows: Strategy engines that trigger multi-chain actions via MPC keys under encoded risk constraints; Gatekeeper-enforced throughput ceilings; audit-ready TEE logs
    • Assumptions/Dependencies: Market infrastructure integrations; performance/scaling of MPC under high-frequency loads; formalized risk policies

Key assumptions and dependencies that recur across applications:

  • Honest majority among MPC nodes; consistent liveness of DKG/resharing and threshold signing
  • Reliable TEE availability and attestation (Intel TDX, AMD SEV), with timely patches to mitigate hardware-level vulnerabilities
  • On-chain governance functioning (DAO), gTOKEN staking/slashing mechanisms, and Fishermen participation for monitoring
  • Gatekeeper networks enforcing rate limits and maintaining transparent, signed request receipts
  • Availability of light/full nodes for each supported chain; robust cross-chain metadata handling for hot_verify
  • Legal/regulatory acceptance of TEE-signed logs and MPC-based custody/authorization where applicable
  • Developer adoption of the Key Registry/Controller patterns and careful design of hot_verify to avoid logic errors and authorization gaps

These applications outline near-term deployments and longer-horizon opportunities that leverage HOT Protocol’s threshold MPC, TEE-based attestation, gatekeeper-mediated access control, and NEAR-based governance/state layers.

Ai Sparkles Streamline Icon: https://streamlinehq.com View Paper Prompt List Streamline Icon: https://streamlinehq.com View All Prompts

Open Problems

We're still in the process of identifying open problems mentioned in this paper. Please check back in a few minutes.

Collections

Sign up for free to add this paper to one or more collections.

User Circle Single Streamline Icon: https://streamlinehq.com Sign Up

Tweets

Sign up for free to view the 19 tweets with 713 likes about this paper.

User Circle Single Streamline Icon: https://streamlinehq.com Sign Up for Free