fix(chain-fusion): revert chain-key technical term and address review feedback

- Revert title and all prose in chain-key-tokens.md from "chain-key digital assets" back to "chain-key tokens" (technical term must be preserved)
- Use "assets" instead of "digital assets" where usage was excessive
- Table headings: "Deployed assets" and "Asset" column (not "digital assets")
- Apply same revert across ethereum.md, solana.md, dogecoin.md, index.md, chain-key-cryptography.md
- bitcoin.md: add ICRC-1/ICRC-2 link on ledger description and remove "digital asset" qualifier

Author: marc0olo

docs/concepts/chain-fusion/bitcoin.md

@@ -52,7 +52,7 @@ Two canisters run on the [pzp6e subnet](https://dashboard.internetcomputer.org/s
 | ckBTC minter | `mqygn-kiaaa-aaaar-qaadq-cai` |
 | ckBTC ledger | `mxzaz-hqaaa-aaaar-qaada-cai` |
 
-The **ledger** is an ICRC-1/ICRC-2 compliant digital asset ledger. It records all ckBTC balances and handles transfers. The transfer fee is 0.0000001 ckBTC (10 satoshi), sent to the minter's fee subaccount.
+The **ledger** is an [ICRC-1/ICRC-2](../../references/icrc-standards.md) compliant ledger. It records all ckBTC balances and handles transfers. The transfer fee is 0.0000001 ckBTC (10 satoshi), sent to the minter's fee subaccount.
 
 The **minter** manages the BTC side: it controls Bitcoin addresses, tracks UTXOs, triggers minting when deposits arrive, and signs and submits Bitcoin transactions when users withdraw.
 

docs/concepts/chain-fusion/chain-key-tokens.md

@@ -1,56 +1,56 @@
 ---
-title: "Chain-Key Digital Assets"
+title: "Chain-Key Tokens"
 description: "Trustless 1:1 representations of external chain assets on ICP"
 ---
 
-Chain-key digital assets are ICP digital assets backed 1:1 by assets native to another chain. ckBTC represents bitcoin, ckETH represents ether, ckUSDC represents USDC on Ethereum, and so on. Each is fully backed by the underlying asset (held in a canister-controlled address on the origin chain), and all minting and burning happens entirely onchain, with no third-party custodian.
+Chain-key tokens are ICP-native assets backed 1:1 by assets native to another chain. ckBTC represents bitcoin, ckETH represents ether, ckUSDC represents USDC on Ethereum, and so on. Each is fully backed by the underlying asset (held in a canister-controlled address on the origin chain), and all minting and burning happens entirely onchain, with no third-party custodian.
 
-## Why chain-key digital assets instead of wrapped assets
+## Why chain-key tokens instead of wrapped assets
 
 Traditional wrapped assets depend on an offchain custodian that holds the underlying asset and instructs a contract to mint or burn the wrapped version. If the custodian is compromised, hacked, or goes out of business, the backing can be lost entirely. Additionally, nothing prevents a dishonest custodian from using the custodied assets for other purposes, risking a depeg.
 
-Chain-key digital assets eliminate the custodian. The underlying assets are held by a minter canister at a network address derived from a chain-key key, an address no single party controls. Minting and burning are triggered by verifiable onchain events (confirmed Bitcoin UTXOs, Ethereum event logs), and the minter signs withdrawal transactions using threshold cryptography distributed across a subnet's nodes.
+Chain-key tokens eliminate the custodian. The underlying assets are held by a minter canister at a network address derived from a chain-key key, an address no single party controls. Minting and burning are triggered by verifiable onchain events (confirmed Bitcoin UTXOs, Ethereum event logs), and the minter signs withdrawal transactions using threshold cryptography distributed across a subnet's nodes.
 
 ## Architecture
 
-Every chain-key digital asset uses a set of canisters:
+Every chain-key token uses a set of canisters:
 
-1. **Minter**: manages the underlying asset on the origin chain. It controls the deposit address (or Ethereum helper contract), detects incoming deposits, instructs the ledger to mint digital assets, and signs and submits withdrawals when digital assets are burned.
-2. **Ledger**: an ICRC-1/ICRC-2 compliant digital asset ledger. It records all balances and executes mint, burn, and transfer operations.
+1. **Minter**: manages the underlying asset on the origin chain. It controls the deposit address (or Ethereum helper contract), detects incoming deposits, instructs the ledger to mint tokens, and signs and submits withdrawals when tokens are burned.
+2. **Ledger**: an ICRC-1/ICRC-2 compliant ledger. It records all balances and executes mint, burn, and transfer operations.
 3. **Index**: provides indexed access to ledger transactions, enabling efficient lookup of an account's transaction history.
 4. **Archive** (optional): stores historical transaction data that has been offloaded from the ledger to keep it compact.
 
-All canisters in a chain-key digital asset system are controlled by the NNS, making the digital asset governance fully decentralized.
+All canisters in a chain-key token system are controlled by the NNS, making the asset governance fully decentralized.
 
-## Minting (getting chain-key digital assets)
+## Minting (getting chain-key tokens)
 
 The minting process differs slightly by chain:
 
 **Bitcoin-based tokens (ckBTC, ckDOGE).** The user requests a deposit address from the minter. This is a chain-key ECDSA address controlled by the minter. The user sends the underlying asset to this address on the Bitcoin or Dogecoin network. Once the transaction reaches the required confirmation threshold (6 confirmations for ckBTC), the user calls `update_balance` on the minter. The minter verifies the deposit via the Bitcoin canister and mints the corresponding amount on the ledger.
 
-**EVM-based tokens (ckETH, ckERC20).** A helper smart contract deployed on Ethereum receives deposits. When a user sends ETH or an ERC-20 asset to the helper contract, it emits an event. The minter periodically queries these event logs via the [EVM RPC canister](ethereum.md) and mints the corresponding chain-key digital assets on the ICP ledger.
+**EVM-based tokens (ckETH, ckERC20).** A helper smart contract deployed on Ethereum receives deposits. When a user sends ETH or an ERC-20 asset to the helper contract, it emits an event. The minter periodically queries these event logs via the [EVM RPC canister](ethereum.md) and mints the corresponding chain-key tokens on the ICP ledger.
 
 ## Burning (redeeming underlying assets)
 
-All chain-key digital asset redemptions use ICRC-2 approval:
+All chain-key token redemptions use ICRC-2 approval:
 
 1. The user calls `icrc2_approve` on the ledger to authorize the minter to withdraw the desired amount.
 2. The user calls the minter's withdrawal endpoint (for example, `retrieve_btc_with_approval` for ckBTC).
-3. The minter burns the chain-key digital assets from the user's account.
+3. The minter burns the chain-key tokens from the user's account.
 4. The minter constructs a transaction on the origin chain, signs it using chain-key cryptography (threshold ECDSA for Bitcoin and Ethereum; threshold Ed25519 for Solana), and submits it.
 
 For EVM-based tokens, the gas fee on Ethereum must be covered. ckETH acts as the fee currency: when redeeming ckERC20 tokens, the user also approves a small ckETH amount to cover the Ethereum gas cost.
 
-## Chain-key digital asset security
+## Chain-key token security
 
-The security of a chain-key digital asset rests on two properties:
+The security of a chain-key token rests on two properties:
 
-- **Supply bound.** The minter never mints more chain-key digital assets than the underlying assets it controls. The total ckBTC supply, for example, is always at most equal to the BTC held at minter-controlled Bitcoin addresses.
+- **Supply bound.** The minter never mints more chain-key tokens than the underlying assets it controls. The total ckBTC supply, for example, is always at most equal to the BTC held at minter-controlled Bitcoin addresses.
 - **Threshold custody.** The minter's private key is never held by a single party. Withdrawal transactions are signed collectively by the subnet nodes through the chain-key protocol, so a single compromised node cannot authorize unauthorized withdrawals.
 
-## Deployed digital assets
+## Deployed assets
 
-| Digital asset | Underlying | Origin chain | Integration method |
+| Asset | Underlying | Origin chain | Integration method |
 |---|---|---|---|
 | ckBTC | BTC | Bitcoin | Direct |
 | ckETH | ETH | Ethereum | EVM RPC canister |
@@ -63,7 +63,7 @@ The security of a chain-key digital asset rests on two properties:
 - [Bitcoin integration](bitcoin.md): ckBTC minter and ledger in detail
 - [Ethereum integration](ethereum.md): ckETH and ckERC20 architecture
 - [Chain Fusion overview](index.md): the full landscape of ICP crosschain capabilities
-- [Chain-key digital assets guide](../../guides/digital-assets/chain-key-tokens.md): how to integrate chain-key digital assets into an application
-- [Chain-key cryptography](../chain-key-cryptography.md): the threshold signing that makes chain-key digital assets possible
+- [Chain-key tokens guide](../../guides/digital-assets/chain-key-tokens.md): how to integrate chain-key tokens into an application
+- [Chain-key cryptography](../chain-key-cryptography.md): the threshold signing that makes chain-key tokens possible
 
 <!-- Upstream: informed by Learn Hub articles "Chain-Key Tokens" (migrated, source retired) -->

docs/concepts/chain-fusion/dogecoin.md

@@ -13,7 +13,7 @@ Canister-controlled Dogecoin addresses are derived from chain-key ECDSA public k
 
 ## Chain-key DOGE (ckDOGE)
 
-ckDOGE is the chain-key digital asset representing Dogecoin on ICP, backed 1:1 by real DOGE held in a canister-controlled address. The minter-plus-ledger architecture is the same as [ckBTC](bitcoin.md#chain-key-bitcoin-ckbtc): users deposit DOGE to a minter-controlled address, the minter mints ckDOGE on the ledger, and withdrawals trigger an onchain Dogecoin transaction signed with threshold ECDSA.
+ckDOGE is the chain-key token representing Dogecoin on ICP, backed 1:1 by real DOGE held in a canister-controlled address. The minter-plus-ledger architecture is the same as [ckBTC](bitcoin.md#chain-key-bitcoin-ckbtc): users deposit DOGE to a minter-controlled address, the minter mints ckDOGE on the ledger, and withdrawals trigger an onchain Dogecoin transaction signed with threshold ECDSA.
 
 ## Next steps
 

docs/concepts/chain-fusion/ethereum.md

@@ -36,29 +36,29 @@ The EVM RPC canister supports the standard JSON-RPC Ethereum API, including:
 
 - `eth_getBlockByNumber`, `eth_getBlockByHash`: block data
 - `eth_getTransactionCount`, `eth_getTransactionByHash`, `eth_getTransactionReceipt`: transaction data
-- `eth_getLogs`: event logs (used to detect deposits for chain-key digital assets)
+- `eth_getLogs`: event logs (used to detect deposits for chain-key tokens)
 - `eth_feeHistory`, `eth_gasPrice`: fee estimation
 - `eth_sendRawTransaction`: broadcast a signed transaction
 - `eth_call`: call a smart contract read function
 
 Beyond Ethereum mainnet, the canister also has partial support for Polygon, Avalanche, and other popular EVM networks.
 
-## Chain-key Ether and ERC-20 digital assets
+## Chain-key Ether and ERC-20 tokens
 
-ckETH and ckERC20 digital assets (such as ckUSDC and ckUSDT) are chain-key digital assets backed 1:1 by assets on Ethereum. They follow the same architecture as ckBTC (a minter canister plus an ICRC-1/ICRC-2 ledger canister) but use a different deposit mechanism.
+ckETH and ckERC20 tokens (such as ckUSDC and ckUSDT) are chain-key tokens backed 1:1 by assets on Ethereum. They follow the same architecture as ckBTC (a minter canister plus an ICRC-1/ICRC-2 ledger canister) but use a different deposit mechanism.
 
-**Deposits.** Because ICP cannot observe Ethereum state directly (unlike Bitcoin, which uses a native adapter), ckETH uses a helper smart contract deployed on Ethereum. Users send ETH or ERC-20 assets to this helper contract, which emits an event. The ckETH minter periodically queries the event log via the EVM RPC canister to discover deposits and mints the corresponding chain-key digital assets.
+**Deposits.** Because ICP cannot observe Ethereum state directly (unlike Bitcoin, which uses a native adapter), ckETH uses a helper smart contract deployed on Ethereum. Users send ETH or ERC-20 assets to this helper contract, which emits an event. The ckETH minter periodically queries the event log via the EVM RPC canister to discover deposits and mints the corresponding chain-key tokens.
 
-**Withdrawals.** The user approves the minter to burn their chain-key digital assets (via ICRC-2), then calls the withdrawal endpoint. The minter burns the digital assets, signs an Ethereum transaction using chain-key ECDSA, and submits it via the EVM RPC canister.
+**Withdrawals.** The user approves the minter to burn their chain-key tokens (via ICRC-2), then calls the withdrawal endpoint. The minter burns the tokens, signs an Ethereum transaction using chain-key ECDSA, and submits it via the EVM RPC canister.
 
-For a full description of chain-key digital asset architecture, see [Chain-key digital assets](chain-key-tokens.md).
+For a full description of chain-key token architecture, see [Chain-key tokens](chain-key-tokens.md).
 
 ## Next steps
 
 - [Ethereum guide](../../guides/chain-fusion/ethereum.md): code examples for reading state and sending transactions
 - [Chain Fusion overview](index.md): integration patterns and supported chains
 - [HTTPS outcalls](../https-outcalls.md): how canisters reach external HTTP endpoints
 - [Chain-key cryptography](../chain-key-cryptography.md): threshold ECDSA signing
-- [Chain-key digital assets](chain-key-tokens.md): ckETH and ckERC20 architecture
+- [Chain-key tokens](chain-key-tokens.md): ckETH and ckERC20 architecture
 
 <!-- Upstream: informed by Learn Hub articles "Ethereum Integration", "EVM RPC Canister" (migrated, source retired) -->

docs/concepts/chain-fusion/index.md

@@ -66,19 +66,19 @@ The combination of signing, reading, and submitting creates three integration pa
 
 Direct integration provides the strongest trust guarantees. The only assumption is that a supermajority of subnet nodes are honest. RPC-based integration adds the assumption that at least one of the queried RPC providers returns correct data, which is mitigated by querying multiple independent providers and comparing results.
 
-## Chain-key digital assets
+## Chain-key tokens
 
-Chain-key digital assets are digital twins of native assets from other chains (for example, ckBTC for Bitcoin and ckETH for Ethereum). Each is backed 1:1 by the native asset, which is held in a canister-controlled address on the source chain. Minting and burning happen entirely onchain. No bridge, no custodian.
+Chain-key tokens are ICP-native assets backed 1:1 by assets native to another chain (for example, ckBTC for Bitcoin and ckETH for Ethereum). Each is held in a canister-controlled address on the source chain. Minting and burning happen entirely onchain. No bridge, no custodian.
 
-These digital assets implement the [ICRC-2](../../guides/digital-assets/ledgers.md) standard, so they can be transferred and traded within the ICP ecosystem with the same speed and cost as any other ICP digital asset. When a user wants to redeem the underlying asset, the minter canister signs and submits a withdrawal transaction on the source chain.
+These tokens implement the [ICRC-2](../../guides/digital-assets/ledgers.md) standard, so they can be transferred and traded within the ICP ecosystem with the same speed and cost as any other ICP asset. When a user wants to redeem the underlying asset, the minter canister signs and submits a withdrawal transaction on the source chain.
 
-For details on chain-key digital asset architecture, see [Chain-key digital assets](chain-key-tokens.md). For integration guides, see the [Chain-key digital assets guide](../../guides/digital-assets/chain-key-tokens.md).
+For details on chain-key token architecture, see [Chain-key tokens](chain-key-tokens.md). For integration guides, see the [Chain-key tokens guide](../../guides/digital-assets/chain-key-tokens.md).
 
 ## Supported chains
 
 Any chain whose transactions use ECDSA (secp256k1), Schnorr (BIP340 over secp256k1), or Ed25519 signatures can be integrated with ICP. The following table lists chains with established integrations or community-built tooling:
 
-| Chain | Signature scheme | Integration method | Chain-key digital asset |
+| Chain | Signature scheme | Integration method | Chain-key token |
 |-------|-----------------|-------------------|-----------------|
 | Bitcoin | ECDSA, Schnorr | Direct | ckBTC |
 | Ethereum | ECDSA | EVM RPC canister | ckETH, ckERC20 |
@@ -104,7 +104,7 @@ Several reusable canisters and protocol APIs are available for building Chain Fu
 - **Bitcoin API.** The management canister exposes `bitcoin_get_utxos`, `bitcoin_get_balance`, and `bitcoin_send_transaction`: a direct protocol-level integration with no intermediary. See [Bitcoin integration](bitcoin.md) and the [Bitcoin guide](../../guides/chain-fusion/bitcoin.md).
 - **EVM RPC canister** (`7hfb6-caaaa-aaaar-qadga-cai`). A canister providing a typed Candid interface for Ethereum and EVM-compatible chains. Queries multiple RPC providers and returns consensus results. See [Ethereum integration](ethereum.md) and the [Ethereum guide](../../guides/chain-fusion/ethereum.md).
 - **SOL RPC canister.** A similar canister for Solana, providing typed access to Solana's JSON-RPC API. See [Solana integration](solana.md) and the [Solana guide](../../guides/chain-fusion/solana.md).
-- **Chain-key digital assets.** Minter and ledger canisters that implement ckBTC, ckETH, and ckERC20: trustless 1:1 representations of external assets on ICP. See [Chain-key digital assets](chain-key-tokens.md) and the [integration guide](../../guides/digital-assets/chain-key-tokens.md).
+- **Chain-key tokens.** Minter and ledger canisters that implement ckBTC, ckETH, and ckERC20: trustless 1:1 representations of external assets on ICP. See [Chain-key tokens](chain-key-tokens.md) and the [integration guide](../../guides/digital-assets/chain-key-tokens.md).
 - **Chain Fusion Signer.** A reusable canister that exposes threshold signature APIs directly to web apps and CLI users, with cycle payments via ICRC-2 approval. [OISY Wallet](https://oisy.com) is a prominent production example: a multichain wallet built on ICP that uses the Chain Fusion Signer to manage keys for Bitcoin, Ethereum, and other chains. See the [chain-fusion-signer repository](https://github.com/dfinity/chain-fusion-signer).
 
 ## Example use cases
@@ -122,7 +122,7 @@ Chain Fusion enables application patterns that are difficult or impossible with
 - [Bitcoin integration](bitcoin.md): how the Bitcoin adapter and ckBTC work
 - [Ethereum integration](ethereum.md): Ethereum, EVM chains, and the EVM RPC canister
 - [Solana integration](solana.md): the SOL RPC canister
-- [Chain-key digital assets](chain-key-tokens.md): architecture of trustless crosschain digital assets
+- [Chain-key tokens](chain-key-tokens.md): architecture of trustless crosschain assets
 - [Exchange rate canister](exchange-rate-canister.md): onchain oracle for asset prices
 - [Bitcoin guide](../../guides/chain-fusion/bitcoin.md): build with BTC on ICP
 - [Ethereum guide](../../guides/chain-fusion/ethereum.md): interact with Ethereum and EVM chains

docs/concepts/chain-fusion/solana.md

@@ -19,7 +19,7 @@ Solana uses Ed25519 signatures. Canisters can derive Ed25519 public keys and req
 
 ## Chain-key SOL (ckSOL)
 
-ckSOL is the chain-key digital asset representing SOL on ICP. Like ckETH, it is backed 1:1 by SOL held in a canister-controlled Solana address. The minter canister monitors Solana deposits via the SOL RPC canister and mints ICRC-1/ICRC-2 compliant ckSOL digital assets on ICP. Withdrawals follow the same pattern: burn ckSOL, sign a Solana transfer using chain-key Ed25519, and broadcast via the SOL RPC canister.
+ckSOL is the chain-key token representing SOL on ICP. Like ckETH, it is backed 1:1 by SOL held in a canister-controlled Solana address. The minter canister monitors Solana deposits via the SOL RPC canister and mints ICRC-1/ICRC-2 compliant ckSOL tokens on ICP. Withdrawals follow the same pattern: burn ckSOL, sign a Solana transfer using chain-key Ed25519, and broadcast via the SOL RPC canister.
 
 ## Next steps