docs: ICP brand voice terminology — onchain, offchain, governance language

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
 

docs/concepts/sns-framework.md

@@ -3,7 +3,7 @@ title: "SNS framework"
 description: "How the Service Nervous System works: framework architecture, launch process, neurons, proposals, and configurable rewards"
 ---
 
-The Service Nervous System (SNS) is a governance framework built into ICP that lets any developer hand control of their application to a community-governed SNS. When an app is governed by an SNS, all upgrades, treasury decisions, and parameter changes require onchain proposals voted on by SNS asset holders.
+The Service Nervous System (SNS) is a governance framework built into ICP that lets any developer hand control of their application to a community-governed SNS. When an app is governed by an SNS, all upgrades, treasury decisions, and parameter changes require network-enforced proposals voted on by SNS asset holders.
 
 For a high-level introduction comparing the NNS and SNS, see [Governance](governance.md#the-service-nervous-system).
 

docs/concepts/verifiable-randomness.md

@@ -52,7 +52,7 @@ The threshold VRF is appropriate for a wide range of use cases where unpredictab
 
 - **Fair selection.** Lotteries, raffles, jury selection, random assignment of roles or rewards.
 - **Games.** Procedural generation, shuffle mechanics, NPC behavior, any outcome that must not be predictable by the player.
-- **Cryptographic protocols.** Generating nonces, challenge values, or session keys entirely onchain.
+- **Cryptographic protocols.** Generating nonces, challenge values, or session keys entirely on the network.
 - **Sampling.** Random subsets for audits, testing, or statistical processes.
 
 ### When to use additional mechanisms

docs/getting-started/choose-your-path.md

@@ -37,7 +37,7 @@ This is where most developers start after the quickstart. The backend guides cov
 
 - [HTTPS outcalls](../guides/backends/https-outcalls.md): call external APIs from your canister
 - [Timers](../guides/backends/timers.md): schedule recurring tasks
-- [Randomness](../guides/backends/randomness.md): generate unpredictable values onchain
+- [Randomness](../guides/backends/randomness.md): generate unpredictable values on the network
 - [Calling other canisters](../guides/canister-calls/inter-canister-calls.md): compose functionality across canisters
 
 ## Fullstack applications
@@ -73,9 +73,9 @@ Here is how Ethereum concepts map to ICP:
 | Bridges / oracles | [Chain-key signing](../concepts/chain-fusion/index.md), [HTTPS outcalls](../guides/backends/https-outcalls.md) | Canisters sign transactions on other chains natively; HTTPS outcalls fetch external data without oracles |
 | Immutable by default | Upgradeable by default | Canisters can be upgraded while preserving state |
 
-The biggest shift: on Ethereum, smart contracts are minimal programs that rely on offchain infrastructure. On ICP, a canister can be an entire application (frontend, backend, database, and scheduled jobs) all onchain.
+The biggest shift: on Ethereum, smart contracts are minimal programs that rely on offchain infrastructure. On ICP, a canister can be an entire application (frontend, backend, database, and scheduled jobs) end-to-end on the network.
 
-## Chain fusion (cross-chain)
+## Chain fusion (crosschain)
 
 **You want to:** Integrate with Bitcoin, Ethereum, or other blockchains.
 
@@ -106,7 +106,7 @@ ICP has a standard token framework (ICRC) and chain-key tokens that represent as
 
 **You want to:** Hand control of your application to a community through an SNS DAO.
 
-The Service Nervous System (SNS) lets you tokenize your application and create a decentralized autonomous organization that governs upgrades, treasury, and parameters through proposals and voting.
+The Service Nervous System (SNS) lets you issue a governance asset and transfer control of your application to a community that manages upgrades, treasury, and parameters through proposals and voting.
 
 **Start with:** [Launching an SNS](../guides/governance/launching.md): understand the process and requirements for decentralizing your application.
 

docs/getting-started/quickstart.md

@@ -22,7 +22,7 @@ npm install -g @icp-sdk/icp-cli @icp-sdk/ic-wasm
 This installs:
 
 - **icp-cli**: builds and deploys [canisters](../concepts/canisters.md) on the Internet Computer
-- **ic-wasm**: optimizes WebAssembly modules for onchain deployment
+- **ic-wasm**: optimizes WebAssembly modules for deployment to the network
 
 For Motoko projects, also install the Motoko package manager:
 

docs/guides/backends/onchain-ai.mdx → docs/guides/backends/ai-inference.mdx

@@ -1,13 +1,13 @@
 ---
-title: "Onchain AI"
+title: "AI inference"
 description: "Call large language models directly from canister code using the LLM canister"
 sidebar:
   order: 6
 ---
 
 import { Tabs, TabItem } from '@astrojs/starlight/components';
 
-The LLM canister is an onchain service that gives ICP canisters access to large language models without relying on HTTPS outcalls to external AI APIs. Your canister calls a shared system canister, which routes inference requests to nodes running model weights onchain. No API keys, no off-chain dependencies: AI inference becomes a native part of your canister logic.
+The LLM canister is a network service that gives ICP canisters access to large language models without relying on HTTPS outcalls to external AI APIs. Your canister calls a shared system canister, which routes inference requests to nodes running model weights on the network. No API keys, no external dependencies: AI inference becomes a native part of your canister logic.
 
 ## What the LLM canister provides