docs: ICP brand voice terminology — onchain, offchain, governance language (#277)

## Summary

- Replaces `onchain`/`on-chain` with precise attribute language (e.g.
\"runs on the network\", \"canister code\", \"network-enforced\") across
26 pages. Domain exceptions retained for DeFi/MEV context and governance
API identifiers per brand voice rules.
- Normalizes compound terms to no-hyphen style consistent with
`tamperproof`: `offchain`, `crosschain`. Replaces \"tokenize your
application\" with \"issue a governance asset and transfer control\".
- Retains `decentralized` in governance/trust contexts where it
describes no-single-party control (not a marketing claim). Replaces
`distributed` back to `decentralized` where the PR had incorrectly
substituted it.
- Renames `onchain-ai` page to `ai-inference`; updates title and
internal links.
- Fixes Motion proposal description: replaces \"no direct network
effect\" with \"Non-binding vote\".
- Replaces `Onchain encryption` heading with `Encryption` in
chain-key-cryptography concept page.
- Applies review suggestions: `DAO-governed` → `Community-governed`,
`token holders` → `asset holders`, `offchain systems` → `external
systems`, `offchain dependencies` → `external dependencies`, `network
oracle` → descriptive system service label, `Offchain availability` →
`Availability` / `client-side` in the IC interface spec.

28 files changed, 42 insertions, 42 deletions.

## Why a separate PR

These changes were originally part of #272. Splitting them out so
reviewers can focus on the structural content changes in #272 without
terminology noise.

**Merge this PR first. Once merged, #272 will be rebased on top of it
and the two terminology commits removed from that branch.**

## Sync recommendation

hand-written

Author: marc0olo

docs/concepts/chain-fusion/bitcoin.md

@@ -69,7 +69,7 @@ Both endpoints return `Passed` or `Failed`. The canister itself is controlled by
 
 ## Chain-key Bitcoin (ckBTC)
 
-ckBTC is an asset on ICP backed 1:1 by real bitcoin. 1 ckBTC can always be redeemed for 1 BTC and vice versa. Unlike wrapped assets, ckBTC relies on no third-party custodian: the bitcoin is held by a canister-controlled address on the Bitcoin network, and the minting and burning happen entirely onchain.
+ckBTC is an asset on ICP backed 1:1 by real bitcoin. 1 ckBTC can always be redeemed for 1 BTC and vice versa. Unlike wrapped assets, ckBTC relies on no third-party custodian: the bitcoin is held by a canister-controlled address on the Bitcoin network, and the minting and burning happen entirely on the network.
 
 ckBTC transactions settle in seconds with minimal fees, making it practical for high-frequency or low-value transfers that would be uneconomical on Bitcoin directly.
 

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

@@ -3,13 +3,13 @@ title: "Chain-key tokens"
 description: "Trustless 1:1 representations of external chain assets on ICP"
 ---
 
-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.
+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 on the network, with no third-party custodian.
 
 ## 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 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.
+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 verified events on the origin chain (confirmed Bitcoin UTXOs, Ethereum event logs), and the minter signs withdrawal transactions using threshold cryptography distributed across a subnet's nodes.
 
 ## Architecture
 
@@ -20,7 +20,7 @@ Every chain-key token uses a set of canisters:
 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 token system are controlled by the NNS, making the asset governance fully decentralized.
+All canisters in a chain-key token system are controlled by the NNS, making the asset governance controlled by the NNS.
 
 ## Minting (getting chain-key tokens)
 

docs/concepts/chain-fusion/dogecoin.md

@@ -15,7 +15,7 @@ Canister-controlled Dogecoin addresses are derived from chain-key ECDSA public k
 
 ## Chain-key DOGE (ckDOGE)
 
-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.
+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 a Dogecoin transaction signed by the network using threshold ECDSA.
 
 ### Depositing DOGE (DOGE to ckDOGE)
 

docs/concepts/chain-fusion/ethereum.md

@@ -13,7 +13,7 @@ Canisters on ICP can interact with Ethereum and any EVM-compatible chain (Polygo
 
 **Submitting Ethereum transactions.** The signed transaction is submitted via the EVM RPC canister's `eth_sendRawTransaction` endpoint, which relays it to multiple JSON-RPC providers for broadcast.
 
-This flow (query, sign, submit) lets canisters call any Ethereum smart contract, hold ETH or ERC-20 assets, and participate in DeFi protocols entirely from onchain ICP code.
+This flow (query, sign, submit) lets canisters call any Ethereum smart contract, hold ETH or ERC-20 assets, and participate in DeFi protocols entirely from ICP canister code.
 
 ## EVM RPC canister
 

docs/concepts/chain-fusion/index.md

@@ -5,7 +5,7 @@ sidebar:
   order: 10
 ---
 
-Chain Fusion is ICP's approach to crosschain interoperability. Instead of relying on bridges or oracles, canisters interact with other networks directly: they can read state, hold assets, and sign and submit transactions on Bitcoin, Ethereum, Solana, and dozens of other chains. All of this runs onchain with the same trust assumptions as the Internet Computer itself.
+Chain Fusion is ICP's approach to crosschain interoperability. Instead of relying on bridges or oracles, canisters interact with other networks directly: they can read state, hold assets, and sign and submit transactions on Bitcoin, Ethereum, Solana, and dozens of other chains. All of this runs on the Internet Computer with the same trust assumptions.
 
 The foundation is [chain-key cryptography](../chain-key-cryptography.md). Each canister can derive keys for external signature schemes (ECDSA and Schnorr) and request threshold signatures from the protocol. This means a canister can control a Bitcoin address, an Ethereum account, or a Solana wallet: without any single node ever holding the private key.
 
@@ -68,7 +68,7 @@ Direct integration provides the strongest trust guarantees. The only assumption
 
 ## Chain-key tokens
 
-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.
+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 on the network. No bridge, no custodian.
 
 These tokens implement the [ICRC-2](../../guides/digital-assets/ledgers.md#approve-and-transfer-from-icrc-2) 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.
 
@@ -123,7 +123,7 @@ Chain Fusion enables application patterns that are difficult or impossible with
 - [Ethereum integration](ethereum.md): Ethereum, EVM chains, and the EVM RPC canister
 - [Solana integration](solana.md): the SOL RPC canister
 - [Chain-key tokens](chain-key-tokens.md): architecture of trustless crosschain assets
-- [Exchange rate canister](exchange-rate-canister.md): onchain oracle for asset prices
+- [Exchange rate canister](exchange-rate-canister.md): system service to fetch asset prices from external exchanges
 - [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
 - [Chain-key cryptography](../chain-key-cryptography.md): the threshold signing protocols behind Chain Fusion

docs/concepts/chain-key-cryptography.md

@@ -17,7 +17,7 @@ This design has several consequences for developers:
 - **Certified data.** Canisters can set certified variables that the subnet signs at each block. Query responses that include these certificates are cryptographically authenticated, bridging the gap between fast queries and trusted updates. See [Certified data](certified-data.md) for the conceptual explanation and [Certified variables](../guides/backends/certified-variables.md) for the implementation guide.
 - **Verifiable randomness.** The threshold BLS scheme produces unique signatures: for a given message and key, only one valid signature exists. ICP exploits this property to generate unpredictable, unbiased random numbers that canisters can consume. See [Verifiable randomness](verifiable-randomness.md).
 - **Crosschain signing.** Canisters can request threshold ECDSA and Schnorr signatures, giving them the ability to control addresses and sign transactions on external chains. This is the foundation of [Chain Fusion](chain-fusion/index.md).
-- **Onchain encryption.** VetKeys extend threshold cryptography to enable canisters to derive encryption keys on behalf of users, making onchain encryption practical. See [VetKeys](vetkeys.md).
+- **Encryption.** VetKeys extend threshold cryptography to enable canisters to derive encryption keys on behalf of users, making encryption by network canisters practical. See [VetKeys](vetkeys.md).
 
 ## Core protocols
 
@@ -117,7 +117,7 @@ For more on how upgrades work at the protocol level, see [Chain evolution](evolu
 - [Chain Fusion](chain-fusion/index.md): how canisters use chain-key signatures to interact with other chains
 - [Certified data](certified-data.md): how the subnet's threshold BLS key enables certified query responses
 - [Ethereum integration](../guides/chain-fusion/ethereum.md): using threshold ECDSA with Ethereum and EVM chains
-- [VetKeys](vetkeys.md): a related cryptographic primitive for onchain encryption
+- [VetKeys](vetkeys.md): a related cryptographic primitive for network-enforced encryption
 - [Management canister reference](../references/management-canister.md): the threshold signing API
 
 <!-- Upstream: informed by dfinity/portal (docs/references/t-sigs-how-it-works.mdx, docs/building-apps/chain-fusion/overview.mdx, docs/building-apps/chain-fusion/supported-chains.mdx); informed by Learn Hub articles "Chain-Key Cryptography", "Subnet Keys and Subnet Signatures", "Chain-Key Signatures" (migrated, source retired) -->

docs/concepts/governance.md

@@ -11,7 +11,7 @@ Understanding both systems is important for developers. NNS proposals can affect
 
 ## The Network Nervous System
 
-The NNS is an onchain governance system that controls the Internet Computer at the protocol level. It is implemented as a set of system canisters running on a dedicated NNS subnet.
+The NNS is a governance system enforced by the network that controls the Internet Computer at the protocol level. It is implemented as a set of system canisters running on a dedicated NNS subnet.
 
 Decisions made through the NNS include:
 

docs/concepts/index.md

@@ -37,9 +37,9 @@ Understand the ideas behind the Internet Computer before you build on it. These
 
 ## Cryptography
 
-- **[Chain-key cryptography](chain-key-cryptography.md)**: Threshold signatures that enable cross-chain integration, fast finality, and chain evolution.
+- **[Chain-key cryptography](chain-key-cryptography.md)**: Threshold signatures that enable crosschain integration, fast finality, and chain evolution.
 - **[Certified data](certified-data.md)**: How canisters certify query responses using the subnet's threshold BLS key.
-- **[VetKeys](vetkeys.md)**: Verifiable encrypted threshold key derivation for onchain encryption and secret management.
+- **[VetKeys](vetkeys.md)**: Verifiable encrypted threshold key derivation for network-enforced encryption and secret management.
 
 ## Chain Fusion
 

docs/concepts/protocol/execution.md

@@ -44,7 +44,7 @@ Memory pages representing canister state are persisted to SSD automatically by t
 
 ## Random number generation
 
-Many applications require a secure source of randomness. Generating random numbers naively in a replicated setting destroys determinism, since each node would produce different values. ICP solves this with the **random tape**: a decentralized pseudorandom number generator built using chain-key cryptography.
+Many applications require a secure source of randomness. Generating random numbers naively in a replicated setting destroys determinism, since each node would produce different values. ICP solves this with the **random tape**: a distributed pseudorandom number generator built using chain-key cryptography.
 
 Each round, the subnet produces a fresh threshold BLS signature. This signature is unpredictable and uniformly distributed by its nature. It is used as a seed for a cryptographic pseudorandom generator, giving canisters access to a secure, efficient, and verifiable source of randomness.
 

docs/concepts/security.md

@@ -41,7 +41,7 @@ As an app developer, you should understand who trusts whom in the IC stack:
 - **Query call integrity.** A single replica responds to query calls. Without certified data, the response is not verified by consensus.
 - **Canister code correctness.** The protocol executes whatever code you deploy. If your code has bugs, the protocol faithfully executes the buggy code.
 - **Access control.** There is no built-in permission system. Every update method is callable by anyone on the internet unless your code explicitly checks the caller.
-- **Memory confidentiality on application subnets.** Node operators on standard application subnets can read canister memory. The network is gradually rolling out SEV-SNP (hardware-level memory encryption) to mitigate this, but until full deployment, do not store secrets (private keys, API tokens, passwords) in canister state. For onchain secret management, see [VetKeys](vetkeys.md).
+- **Memory confidentiality on application subnets.** Node operators on standard application subnets can read canister memory. The network is gradually rolling out SEV-SNP (hardware-level memory encryption) to mitigate this, but until full deployment, do not store secrets (private keys, API tokens, passwords) in canister state. For secret management on the network, see [VetKeys](vetkeys.md).
 
 ### Boundary nodes