HOT Protocol: Decentralized Key Management

• HOT Protocol is a cryptographic and on-chain framework that decentralizes private key management using threshold cryptography and TEEs.
• Its architecture combines a NEAR-based governance layer, off-chain MPC nodes, and stateless gatekeepers to ensure robust, cross-chain signing.
• The protocol enforces confidentiality, unforgeability, and liveness via economic incentives, remote attestation, and a well-defined threat model.

HOT Protocol is a cryptographic and on-chain orchestration framework for secure, decentralized private key management and signing, enabling smart contracts to natively control cryptographic assets across multiple blockchains. Its architecture combines threshold cryptography (notably distributed key generation and threshold signing), a Multi-Party Computation (MPC) network running inside Trusted Execution Environments (TEE), and a coordination and slashing layer on the NEAR blockchain. HOT Protocol is designed to provide key-control decentralization, robust cross-chain authorization, cryptographic indistinguishability with monolithic key schemes, and economic incentives and penalties to enforce honest behavior among both cryptographic and infrastructural participants (Volnov et al., 1 Dec 2025).

1. Security Objectives and Threat Model

HOT Protocol enforces several core security guarantees:

• Threshold key control: At no point does any single party know or reconstruct the full private signing key. Instead, the key is secret-shared among $n$ MPC nodes.
• Signature indistinguishability: All group signatures produced by the protocol are byte-for-byte identical to those produced by conventional, single-holder private keys (ECDSA, EdDSA).
• Confidentiality: All message payloads, intermediate MPC transcripts, and secret shares remain confidential given an honest-majority threshold $t$ for the MPC network and unbroken cryptographic assumptions.
• Liveness: As long as at least $t$ of $n$ designated nodes are online and compliant, the signing service remains operational.
• Decentralization: No single party or enclave can make unilateral decisions regarding key generation, signing, or key-share resharing and recovery.

The adversary model assumes a computationally bounded adversary may corrupt up to $f<t$ MPC nodes simultaneously; collusion, message withholding, and active attempts at protocol deviation are mitigated via threshold cryptography, hardware attestation, and on-chain slashing. Additional untrusted "Gatekeeper" relayers merely route requests and cannot access secret data (Volnov et al., 1 Dec 2025).

2. Architectural Overview

The HOT Protocol is a composite system comprising:

• NEAR Protocol state layer: Hosts all governance and coordination smart contracts, notably the MPC Controller (network configuration, attestation, slashing decisions) and Key Registry (binding key IDs to external contract endpoints).
• Off-chain MPC network: An authenticated P2P set of $n$ nodes (minimum threshold $t$ for progress), each operating entirely inside a TEE (e.g., Intel TDX, AMD SEV), running cryptographic modules that implement distributed key generation (DKG), threshold signing (FROST for EdDSA, FastECDSA), and proactive key resharing.
• Gatekeepers: Stateless relay servers that aggregate user signing requests, randomly sample $t$ available MPC nodes, and coordinate signature combination and delivery without accessing secret data or affecting protocol liveness.
• Cross-chain Key-Owner contracts: Deployed on target blockchains (Stellar, TON, Solana, EVM), these contracts implement a standard read-only hot_verify method used for authorization before any signing operation (Volnov et al., 1 Dec 2025).

Architectural Flow

The high-level signing process is:

1. User submits $(\text{message}, \text{key\_id}, \text{metadata})$ to a Gatekeeper.
2. Gatekeeper verifies rate limits, selects $t$ MPC nodes.
3. Each MPC node verifies authorization by calling hot_verify against the target chain’s Key-Owner contract.
4. If permitted, each node computes a partial signature $\sigma_i$.
5. Gatekeeper reconstructs the final signature $\sigma = \sum_{i\in T} \lambda_i\sigma_i \mod q$ (Lagrange interpolation in the field).
6. Signature and receipt are returned to the user/client, who can then submit to the external chain.

3. Cryptographic Primitives

Distributed Key Generation and Sharing

• Shamir's Secret Sharing: A key $k$ is split as shares $s_i=f(i)$ using a random degree-$(t-1)$ polynomial $f$ in $GF(q)$; the secret can only be reconstructed with at least $t$ valid shares.
• Threshold Signing: For ECDSA/EdDSA, each node computes partial signatures. Lagrange interpolation is used both for share recovery and signature synthesis, ensuring that any $t$ out of $n$ nodes can produce a valid signature indistinguishable from that produced by a monolithic key.
• BIP-32-style Key Derivation: Child key shares and public keys are derived deterministically by applying a tweak function (e.g., $$P_{\text{child}} = P_{\text{root}}+HMAC(P_{\text{root}}\|t)\cdot G$$), supporting scalable per-contract and per-application keyscoping without repeating DKG (Volnov et al., 1 Dec 2025).

TEEs and Attestation

• Every MPC node runs within a TEE and proves this via remote attestation, pinned on-chain in the Controller contract.
• Keys and shares are only handled inside enclaves, and periodic re-attestation (e.g., every 5 minutes) defends against long-lived stake underservice or TEE compromise.

4. Workflow and Economic Incentives

Node Registration and Key Lifecycle

• Prospective MPC operators stake a minimum gTOKEN deposit and are registered after passing attestation.
• Distributed Key Generation is executed inside the trusted enclaves to establish the root key shares, which are never revealed or reassembled outside the threshold.
• Key derivation and registry is initiated via the NEAR-based MPC network, with chain- or contract-specific key derivation managed purely by on-chain pointers and tweaks.

Signing Operations

• Authorization for a signing operation is conducted by cross-chain read-only invocation of the hot_verify method on the relevant Key-Owner contract; mitigates unauthorized or replayed signatures.
• Gatekeepers aggregate at least $t$ partials for each signature request; the signature is then returned to the user, who finalizes the process with an on-chain transaction (e.g., ecrecover in EVM).

Governance, Staking, and Slashing

• All active participants (MPC nodes, Gatekeepers) post gTOKEN collateral.
• Rewards are distributed based on stake-weighted participation, measured by successful attestations and signing activity.
• Faulty or malicious participants (e.g., non-responsive MPC nodes, Gatekeepers violating quotas or replaying attacks) are subject to slashing—via a per-offense penalty fraction, with potential redistribution to "fisherman" actors who supply valid proofs of misbehavior (Volnov et al., 1 Dec 2025).

5. Cross-Chain Integration and Gas Costs

HOT Protocol is engineered to be agnostic to the target chain, integrating with EVM (via ecrecover), Solana and NEAR (EdDSA syscalls), and Stellar/TON (native checks). Threshold signatures produced by HOT MPC are fully compatible with these standard verification interfaces.

• On-chain verification imposes no signature size or verification cost penalty relative to single-key methods. For EVM, signature verification (including state update) costs ≈50,000 gas per operation, compared to ≈150,000 gas for traditional multisig systems.
• The only long-term per-key storage on NEAR is a key_id-to-contract mapping (32 bytes per key), with no persistent state or secret exposure on the target chains. Read-only hot_verify calls are free in the context of typical smart contract execution (Volnov et al., 1 Dec 2025).

6. Security and Performance Evaluations

HOT Protocol's correctness builds on the universally composable (UC) security of Shamir secret sharing and robust threshold signature schemes (FROST, FastECDSA), composed with trusted remote attestation and on-chain governance for fault recovery.

Key Security Properties

• Confidentiality: No single node can reconstruct or leak the full key; at most $t-1$ colluding nodes yield no information about the secret.
• Unforgeability: No adversary controlling less than $t$ nodes can produce a valid signature.
• Liveness: The system remains operational as long as at least $t$ nodes are responsive; exclusion and reshuffling of non-responsive or malicious nodes is coordinated through the on-chain governance process.

Performance Metrics

• Signing Latency: For $t=10, n=16$ nodes, average end-to-end signing latency is approximately 300 ms.
• Gas Consumption: Each EVM signature verification costs ~50,000 gas. Off-chain MPC coordination is amortized across signatures via batching and optimized aggregation strategies.
• Compared to on-chain multisig solutions, HOT reduces gas cost per signature by up to 66% and reduces signature confirmation latency to sub-second scales (Volnov et al., 1 Dec 2025).

7. Implementation, Deployment, and Limitations

HOT Protocol is implemented with Rust-based MPC and cryptographic modules (utilizing Intel TDX and AMD SEV), NEAR smart contracts (AssemblyScript/Rust), and TypeScript/Node.js Gatekeeper references. Testnet deployments launched with 12 MPC nodes on five cloud providers, with applications including a passkey-enabled Bitcoin wallet on NEAR mainnet, demonstrating the protocol's ability to manage private keys securely and cross-chain (Volnov et al., 1 Dec 2025).

Operational lessons include the necessity for frequent TEE re-attestation to maintain protocol availability, careful gatekeeper request quota calibration, and the key derivation mechanism's efficacy in preventing the need for repeated distributed key generation for each contract or user.

Known limitations include potential scalability constraints due to TEE operational costs, and the need for effective on-chain economic incentives to prevent sustained malicious (but undetected) node behavior. Ongoing enhancements may include more efficient threshold signature batching, adaptive node selection, and expanded chain support.