Exchange Ranking
Top Exchanges
24h Volume Ranking
Popularity Ranking
Exchange BTC Balance
Proof of Reserves
Decentralized Exchanges
Funding Rate
Funding Heatmap
Liquidation Data
Max Pain
Long/Short Ratio
Whale L/S Ratio
Binance/Okex/Huobi L/S
Bitfinex Margin L/S
ETF Tracker
Solana ETF
XRP ETF
Hong Kong ETF
Bitcoin Treasuries
Crypto Reversal
Ethereum Reserves
HyperLiquid Wallet Analysis
Hyperliquid Whale Watch
Large Transactions
On-chain Movement
Bitcoin ROI
Stablecoin Market Cap
Options Analysis
News
Articles
Economic Calendar
Features
Wallet
Contract Calculator
Security
Collections
Watchlist
Following
BTC 
ETH 
ICP One key, arbitrary response
On most blockchains, verifying the authenticity of a response requires running a light client-software that continuously tracks the heads of blocks on the chain to verify status. Internet computers take a completely different approach.
Each subnet on an Internet computer has a public key, but no single node holds the corresponding private key. Instead, the key is divided into multiple shares through threshold cryptography and distributed among various nodes of the subnet.
The private key is not held by a single node, but is divided into shares and distributed among subnet nodes, and the nodes jointly sign the message without having to rebuild the complete key.
On ICP, verifying a response means just checking whether a signature corresponds to a public key, no matter how many nodes the response was generated.
This is the core promise of what @dfinity calls "chain-key cryptography," which has important practical implications for the way clients interact with the network.
The root key fixed since the beginning of the world
protocol does not require clients to track any on-chain state, but instead generates a certificate that only needs to pass a signature check to be verified against the root public key of an Internet computer. This key never changes: it was fixed at creation and embedded in the ICP client library.
This means that any application or device that owns the library can immediately verify any response it receives from the network without having to continuously track on-chain status.
The threshold BLS signature feature that implements this functionality is the same as the one that implements fast response verification at the top level: you only need a subnet public key to verify any response from that subnet, because the private key is never held by any individual node, but instead, the signature is generated collectively through the threshold BLS.
Client applications only need to use the subnet public key to verify information retrieved from the subnet, making these applications both resource-saving and fully trustworthy.
This design also has broader implications: It allows canisters to sign transactions directly on other blockchains such as Bitcoin and Ethereum without relying on bridges or oracles.
The core component of chain key cryptography is a threshold signature scheme in which a secret signature key is distributed among all replica nodes of a subnet, making it impossible to steal the key even if a node or even a large number of replica nodes are breached.
The resulting verification model is both simpler for end users and more structurally flexible than traditional methods.
