diff --git a/.sources/VERSIONS b/.sources/VERSIONS index f61c90b6..f47398c0 100644 --- a/.sources/VERSIONS +++ b/.sources/VERSIONS @@ -56,7 +56,7 @@ chain-fusion-signer v0.4.0 a18c52a papi v0.1.1 168bc9d ic-pub-key v1.0.1 f89fa55 -icp-cli v0.3.1 c4c4618 +icp-cli v1.0.0 9eed60c motoko v1.9.0 e7c78d7 motoko-core v2.4.0 cd37dbf cdk-rs ic-cdk v0.20.1 / ic-cdk-timers v1.0.0 / ic-cdk-executor v2.0.0 317f55c diff --git a/.sources/icp-cli b/.sources/icp-cli index c4c4618d..9eed60c8 160000 --- a/.sources/icp-cli +++ b/.sources/icp-cli @@ -1 +1 @@ -Subproject commit c4c4618d94c5e05d73544afeb5eb937acad5e140 +Subproject commit 9eed60c87336d9ac665e7fc72bab5bfd529cdc18 diff --git a/.sources/icp-cli-recipes b/.sources/icp-cli-recipes index 87ae9c1f..8dda3d08 160000 --- a/.sources/icp-cli-recipes +++ b/.sources/icp-cli-recipes @@ -1 +1 @@ -Subproject commit 87ae9c1f6511242e0ccc68358e2ce24313386179 +Subproject commit 8dda3d080702c6b8df69aa5082bacd1b1fb1439b diff --git a/.sources/icp-cli-templates b/.sources/icp-cli-templates index 4f6e608f..9f1e8194 160000 --- a/.sources/icp-cli-templates +++ b/.sources/icp-cli-templates @@ -1 +1 @@ -Subproject commit 4f6e608fdd4b8101207669ea5808692b654eae62 +Subproject commit 9f1e81941db9742d07ddae76dd2ac50d3841711e diff --git a/.sources/icskills b/.sources/icskills index 1d125a92..d8dad4c7 160000 --- a/.sources/icskills +++ b/.sources/icskills @@ -1 +1 @@ -Subproject commit 1d125a926fd628283b5ce0352661473a456e5b98 +Subproject commit d8dad4c75046e85906fc08e8f02994231a09c1ee diff --git a/docs/concepts/edge-infrastructure.md b/docs/concepts/edge-infrastructure.md index 41478a88..ec4e2350 100644 --- a/docs/concepts/edge-infrastructure.md +++ b/docs/concepts/edge-infrastructure.md @@ -33,13 +33,13 @@ Around 20 API boundary nodes are currently deployed worldwide. An up-to-date lis HTTP gateways translate standard HTTP requests into IC API calls and forward them to API boundary nodes. Because of this translation layer, browsers and other HTTP clients can access canisters directly without installing any special software. For example, a website fully hosted on ICP is accessible in any browser through a normal HTTPS URL. -The HTTP Gateway Protocol (defined in the [HTTP Gateway Protocol Specification](../references/http-gateway-spec.md)) specifies exactly how this translation works. HTTP gateways are not part of ICP itself and can be operated by anyone. This open model encourages a diverse set of gateways, enhancing redundancy and availability. +The HTTP Gateway Protocol (defined in the [HTTP Gateway Protocol Specification](../references/http-gateway-protocol-spec.md)) specifies exactly how this translation works. HTTP gateways are not part of ICP itself and can be operated by anyone. This open model encourages a diverse set of gateways, enhancing redundancy and availability. ## HTTP Gateway Protocol When a browser opens a URL hosted by a canister, the following happens: -1. The browser makes a normal HTTPS request to the domain (for example, `https://.icp0.io`). It has no awareness that the site runs on ICP. +1. The browser makes a normal HTTPS request to the domain (for example, `https://.icp.net`). It has no awareness that the site runs on ICP. 2. The HTTP gateway receives the request and translates it into a query call to the canister's `http_request` method, placing the path, headers, and body into the call payload. 3. An API boundary node receives the IC API call and forwards it to a replica on the subnet that hosts the target canister. 4. The canister executes the `http_request` query, constructs an HTTP response (status, headers, body), and returns it. @@ -66,7 +66,7 @@ For practical guidance on certifying canister responses, see [Certified variable ## Further reading -- [HTTP Gateway Protocol Specification](../references/http-gateway-spec.md): detailed protocol definition +- [HTTP Gateway Protocol Specification](../references/http-gateway-protocol-spec.md): detailed protocol definition - [ic-http-gateway library](https://github.com/dfinity/ic-http-gateway-protocol/tree/main/packages/ic-http-gateway-protocol): the main implementation of the HTTP Gateway Protocol - [response-verification](https://github.com/dfinity/response-verification): libraries for certifying canister responses to work with the HTTP gateway protocol - [Certified variables guide](../guides/backends/certified-variables.md): how to certify canister responses diff --git a/docs/concepts/network-economics.md b/docs/concepts/network-economics.md index 5e1e84c8..177566ae 100644 --- a/docs/concepts/network-economics.md +++ b/docs/concepts/network-economics.md @@ -15,7 +15,7 @@ ICP has four protocol-level uses: **2. Cycle conversion.** ICP can be burned to mint cycles through the Cycles Minting Canister (CMC). Cycles are pegged to the XDR basket of currencies at a rate of 1 trillion cycles = 1 XDR. This means developer infrastructure costs are stable in fiat terms even as ICP's market price changes. See [Cycles](cycles.md) for details. -**3. Node provider rewards.** Nodes that run the Internet Computer are owned by independent node providers. These providers are compensated in newly minted ICP. Rewards are specified in XDR and converted to ICP based on a 30-day moving average exchange rate, so providers receive stable real-world compensation regardless of price fluctuations. The Cycles Minting Canister (CMC) fetches the ICP/XDR rate every 5 minutes from the [exchange rate canister](chain-fusion/exchange-rate-canister.md#how-rates-are-computed), which aggregates rates from external sources. It uses the start-of-day rates for the past 30 days to compute the moving average. The current conversion rate is available on the [ICP dashboard](https://dashboard.internetcomputer.org/network) and from the [CMC metrics endpoint](https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp0.io/metrics). +**3. Node provider rewards.** Nodes that run the Internet Computer are owned by independent node providers. These providers are compensated in newly minted ICP. Rewards are specified in XDR and converted to ICP based on a 30-day moving average exchange rate, so providers receive stable real-world compensation regardless of price fluctuations. The Cycles Minting Canister (CMC) fetches the ICP/XDR rate every 5 minutes from the [exchange rate canister](chain-fusion/exchange-rate-canister.md#how-rates-are-computed), which aggregates rates from external sources. It uses the start-of-day rates for the past 30 days to compute the moving average. The current conversion rate is available on the [ICP dashboard](https://dashboard.internetcomputer.org/network) and from the [CMC metrics endpoint](https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp.net/metrics). **4. SNS decentralization swaps.** Users can commit ICP to participate in the decentralization swap of an SNS. In return they receive the SNS's governance assets at a uniform price. The ICP raised enters the SNS treasury under NNS control and funds future development and operations. diff --git a/docs/concepts/network-overview.md b/docs/concepts/network-overview.md index 90a44d04..0d1c08c9 100644 --- a/docs/concepts/network-overview.md +++ b/docs/concepts/network-overview.md @@ -42,7 +42,7 @@ For how the protocol achieves this (block making, notarization, finalization, an Boundary nodes are the entry point for all external traffic to ICP. They serve two purposes: -1. **HTTP gateway.** When a user's browser requests `https://.icp0.io`, a boundary node translates that HTTP request into a canister message, routes it to the correct subnet, and returns the response. +1. **HTTP gateway.** When a user's browser requests `https://.icp.net`, a boundary node translates that HTTP request into a canister message, routes it to the correct subnet, and returns the response. 2. **API endpoint.** Agent libraries (like [`@icp-sdk/core/agent`](https://js.icp.build/core/latest/libs/agent) in JavaScript) send ingress messages to boundary nodes, which forward them to the target canister's subnet. Boundary nodes also cache query responses and provide TLS termination. They are not part of consensus and cannot modify canister state: they are routing infrastructure. diff --git a/docs/concepts/principals.md b/docs/concepts/principals.md index 940b6817..0d894a1c 100644 --- a/docs/concepts/principals.md +++ b/docs/concepts/principals.md @@ -13,7 +13,7 @@ ICP defines five principal classes, though one (derived IDs) has never been impl **2. Canister IDs:** Each canister on ICP has a unique principal derived when the canister is created. Canister principals look like `ryjl3-tyaaa-aaaaa-aaaba-cai`. When a canister makes a call to another canister, the callee sees the calling canister's canister ID as the caller principal. -**3. Self-authenticating IDs:** User identities are derived from public keys using a domain-separated hash. Anyone holding the corresponding private key can authenticate and call canisters under that principal. Self-authenticating principals look like `o2ivq-5dsbb-hhfso-w2o5v-7qiaq-g4fbm-6qhhb-xbj6w-szpxa-lflfa-mae` for Ed25519 keys or similar for ECDSA keys. The [Internet Identity](https://identity.ic0.app/) service manages key-backed identities for end users. +**3. Self-authenticating IDs:** User identities are derived from public keys using a domain-separated hash. Anyone holding the corresponding private key can authenticate and call canisters under that principal. Self-authenticating principals look like `o2ivq-5dsbb-hhfso-w2o5v-7qiaq-g4fbm-6qhhb-xbj6w-szpxa-lflfa-mae` for Ed25519 keys or similar for ECDSA keys. The [Internet Identity](https://id.ai/) service manages key-backed identities for end users. **4. Anonymous principal (`2vxsx-fae`):** Messages that are not signed use the anonymous principal as their caller identity. Any canister can check whether a caller is anonymous and decide how to handle unsigned requests (for example, allowing public reads but rejecting state changes from anonymous callers). diff --git a/docs/getting-started/project-structure.mdx b/docs/getting-started/project-structure.mdx index c8214720..cc3b6611 100644 --- a/docs/getting-started/project-structure.mdx +++ b/docs/getting-started/project-structure.mdx @@ -82,15 +82,22 @@ Each canister has its own `canister.yaml` that defines how to build and deploy i -The Motoko backend uses the `@dfinity/motoko` recipe: +The Motoko backend uses the `@dfinity/motoko` recipe, which compiles via `mops build`: ```yaml name: backend recipe: - type: "@dfinity/motoko@v4.1.0" - configuration: - main: src/main.mo - candid: backend.did + type: "@dfinity/motoko@v5.0.0" +``` + +The recipe takes no source or Candid configuration. Instead, the source file (and optionally the Candid file and compiler flags) are declared in a `mops.toml` at the project root. The `[canisters]` key must match the canister `name`: + +```toml +[toolchain] +moc = "1.9.0" + +[canisters] +backend = "src/main.mo" ``` @@ -99,12 +106,13 @@ The Rust backend uses the `@dfinity/rust` recipe: ```yaml name: backend recipe: - type: "@dfinity/rust@v3.2.0" + type: "@dfinity/rust@v3.3.0" configuration: - package: backend shrink: true candid: backend.did ``` + +The `package` parameter (the Cargo package to build) defaults to the canister `name`, so it can be omitted when they match. Set it explicitly only when they differ. diff --git a/docs/guides/authentication/internet-identity.mdx b/docs/guides/authentication/internet-identity.mdx index 0488993f..9bf736f7 100644 --- a/docs/guides/authentication/internet-identity.mdx +++ b/docs/guides/authentication/internet-identity.mdx @@ -21,7 +21,7 @@ When a user authenticates through Internet Identity, the following happens: 4. Your frontend receives this delegation and uses it to sign canister calls. 5. The backend canister sees the user's **principal** (derived from the delegation chain) as `msg.caller`. -**Principal-per-app isolation:** II derives a different principal for each frontend origin. A user logging into `https://app-a.icp0.io` gets a different principal than when logging into `https://app-b.icp0.io`, even with the same passkey. This prevents apps from correlating users across services. +**Principal-per-app isolation:** II derives a different principal for each frontend origin. A user logging into `https://app-a.icp.net` gets a different principal than when logging into `https://app-b.icp.net`, even with the same passkey. This prevents apps from correlating users across services. **Delegations expire.** The frontend sets a `maxTimeToLive` when requesting the delegation (default recommendation: 8 hours). After expiry, the user must re-authenticate. The maximum allowed delegation lifetime is 30 days (2,592,000,000,000,000 nanoseconds). @@ -381,7 +381,7 @@ canisters: settings: environment_variables: trusted_attribute_signers: "rdmx6-jaaaa-aaaaa-aaadq-cai" # required - frontend_origins: "https://your-app.icp0.io" # required, comma-separated + frontend_origins: "https://your-app.icp.net" # required, comma-separated trusted_sso_domains: "your-org.com" # optional; omit to reject all sso:* keys ``` @@ -400,7 +400,7 @@ use std::cell::RefCell; use std::collections::HashSet; const II_PRINCIPAL: &str = "rdmx6-jaaaa-aaaaa-aaadq-cai"; -const TRUSTED_ORIGIN: &str = "https://your-app.icp0.io"; +const TRUSTED_ORIGIN: &str = "https://your-app.icp.net"; const FRESHNESS_NS: u64 = 300_000_000_000; // 5 minutes thread_local! { @@ -553,7 +553,7 @@ icp deploy -e ic ## Alternative origins -By default, each frontend origin produces a different user principal. If you serve your app from multiple domains (for example, migrating from `.icp0.io` to a custom domain), users would get different principals on each domain. +By default, each frontend origin produces a different user principal. If you serve your app from multiple domains (for example, migrating from `.icp.net` to a custom domain), users would get different principals on each domain. :::note II now automatically handles the `icp0.io` vs `ic0.app` domain difference: you do **not** need to use `derivationOrigin` or `ii-alternative-origins` for that case. Use alternative origins only when you have two genuinely distinct custom domains that should share the same user principal. @@ -595,7 +595,7 @@ To keep principals consistent across your own custom domains, configure **altern ```javascript const authClient = new AuthClient({ identityProvider: "https://id.ai", - derivationOrigin: "https://xxxxx.icp0.io", // primary origin A + derivationOrigin: "https://xxxxx.icp.net", // primary origin A }); ``` @@ -625,4 +625,4 @@ For full details, see the [Internet Identity specification](../../references/int {/* TODO: Add Unity native app integration via deep links: see portal native-apps/unity_ii_* */} -{/* Upstream: informed by dfinity/portal (docs/building-apps/authentication/overview.mdx, docs/building-apps/authentication/integrate-internet-identity.mdx, docs/building-apps/authentication/alternative-origins.mdx); dfinity/icskills (skills/internet-identity/SKILL.md); dfinity/icp-js-sdk-docs (public/auth/latest.zip api/client/ — AuthClient, scopedKeys, SignedAttributes, AuthClientCreateOptions; public/core/latest.zip libs/identity/api.md — AttributesIdentity); dfinity/cdk-rs (ic-cdk/src/api.rs); dfinity/motoko-identity-attributes (README.md, src/lib.mo, src/Internal/Verify.mo @ v0.4.1 — the mixin and its verification order); caffeinelabs/motoko-core (src/CallerAttributes.mo getAttributes wrapper, src/Map.mo); caffeinelabs/motoko (src/prelude/prim.mo callerInfoData/Signer, test/run-drun/caller-info/caller-info.mo); dfinity/icp-cli (docs/reference/canister-settings.md#environment_variables) */} +{/* Upstream: informed by dfinity/portal (docs/building-apps/authentication/overview.mdx, docs/building-apps/authentication/integrate-internet-identity.mdx, docs/building-apps/authentication/alternative-origins.mdx); dfinity/icskills (skills/internet-identity/SKILL.md); dfinity/icp-js-sdk-docs (public/auth/latest.zip api/client/: AuthClient, scopedKeys, SignedAttributes, AuthClientCreateOptions; public/core/latest.zip libs/identity/api.md: AttributesIdentity); dfinity/cdk-rs (ic-cdk/src/api.rs); dfinity/motoko-identity-attributes (README.md, src/lib.mo, src/Internal/Verify.mo @ v0.4.1: the mixin and its verification order); caffeinelabs/motoko-core (src/CallerAttributes.mo getAttributes wrapper, src/Map.mo); caffeinelabs/motoko (src/prelude/prim.mo callerInfoData/Signer, test/run-drun/caller-info/caller-info.mo); dfinity/icp-cli (docs/reference/canister-settings.md#environment_variables) */} diff --git a/docs/guides/authentication/verifiable-credentials.md b/docs/guides/authentication/verifiable-credentials.md index c769c600..235833e1 100644 --- a/docs/guides/authentication/verifiable-credentials.md +++ b/docs/guides/authentication/verifiable-credentials.md @@ -75,7 +75,7 @@ Returns the consent text shown to the user in the II dialog. This message must c Returns the URL used to derive the user's principal for this issuer. If you do not use [alternative derivation origins](../../references/internet-identity-spec.md), return the canister's default URL: ``` -https://.icp0.io +https://.icp.net ``` If you use alternative origins, return the same value as your `derivationOrigin` login parameter. The returned value is verified via `.well-known/ii-alternative-origins`. @@ -365,10 +365,10 @@ See the [demo relying party implementation](https://github.com/dfinity/vc-playgr ### Live demo environment A demo relying party is deployed on ICP for testing: -[https://l7rua-raaaa-aaaap-ahh6a-cai.icp0.io/](https://l7rua-raaaa-aaaap-ahh6a-cai.icp0.io/) +[https://l7rua-raaaa-aaaap-ahh6a-cai.icp.net/](https://l7rua-raaaa-aaaap-ahh6a-cai.icp.net/) Use the II staging instance to avoid using real user credentials: -[https://fgte5-ciaaa-aaaad-aaatq-cai.ic0.app/](https://fgte5-ciaaa-aaaad-aaatq-cai.ic0.app/) +[https://fgte5-ciaaa-aaaad-aaatq-cai.icp.net/](https://fgte5-ciaaa-aaaad-aaatq-cai.icp.net/) A demo issuer is deployed that will issue any requested credential. Explore the issuer canister on the [NNS dashboard](https://dashboard.internetcomputer.org/canister/qdiif-2iaaa-aaaap-ahjaq-cai) or browse its implementation in the [vc-playground repository](https://github.com/dfinity/vc-playground). diff --git a/docs/guides/canister-calls/candid.mdx b/docs/guides/canister-calls/candid.mdx index f89732a5..1a2da584 100644 --- a/docs/guides/canister-calls/candid.mdx +++ b/docs/guides/canister-calls/candid.mdx @@ -103,16 +103,23 @@ For the complete type reference, including subtyping rules, see the [Candid spec The Motoko compiler generates Candid descriptions automatically from your actor's type signature. When you build with icp-cli, the `.did` file is placed in the build output directory. No manual authoring needed. -You can also provide a hand-written `.did` file by setting the `candid` field in `icp.yaml`. This is useful when you want an explicit API contract that is versioned independently of the implementation: +You can also provide a hand-written `.did` file by setting the `candid` field for the canister in `mops.toml` (the `@dfinity/motoko` recipe v5 and later builds with `mops build`). This is useful when you want an explicit API contract that is versioned independently of the implementation: ```yaml +# icp.yaml canisters: - name: backend recipe: - type: "@dfinity/motoko@v4.1.0" - configuration: - main: backend/app.mo - candid: backend/backend.did # Optional: overrides auto-generation + type: "@dfinity/motoko@v5.0.0" +``` + +Declare the source and Candid file under the canister's entry in `mops.toml`: + +```toml +# mops.toml +[canisters.backend] +main = "backend/app.mo" +candid = "backend/backend.did" # Optional: overrides auto-generation ``` If `candid` is omitted, the Motoko recipe auto-generates the interface from the source. @@ -159,9 +166,8 @@ Reference the generated `.did` file in your `icp.yaml`: canisters: - name: my_canister recipe: - type: "@dfinity/rust@v3.2.0" + type: "@dfinity/rust@v3.3.0" configuration: - package: my_canister candid: src/my_canister/my_canister.did ``` @@ -439,7 +445,7 @@ For type selector configuration and advanced options, see the [`ic-cdk-bindgen` | `didc decode ` | Decode binary Candid back to text | | `didc subtype new.did old.did` | Check that `new` is a safe upgrade from `old` | -**Candid UI**: a web interface for calling canister methods directly from a browser, generated automatically for every deployed canister. Useful for testing and debugging without writing frontend code. Access it at `https://a4gq6-oaaaa-aaaab-qaa4q-cai.icp0.io/?id=` for mainnet canisters. +**Candid UI**: a web interface for calling canister methods directly from a browser, generated automatically for every deployed canister. Useful for testing and debugging without writing frontend code. Access it at `https://a4gq6-oaaaa-aaaab-qaa4q-cai.icp.net/?id=` for mainnet canisters. ## Next steps diff --git a/docs/guides/canister-management/canister-migration.md b/docs/guides/canister-management/canister-migration.md index 53f42edf..3a661dd5 100644 --- a/docs/guides/canister-management/canister-migration.md +++ b/docs/guides/canister-management/canister-migration.md @@ -31,7 +31,7 @@ Your options depend on whether the canister ID can change: - **Threshold signatures (tECDSA / tSchnorr)**: The IC derives signing keys by cryptographically binding them to the calling canister's principal. Any Bitcoin or Ethereum addresses derived from those keys are permanently tied to the original canister ID. Changing the ID means losing access to those signing keys and any assets they control. - **vetKeys**: vetKey derivation includes the canister's principal. A new ID produces entirely different decryption keys, making previously encrypted data permanently inaccessible. -- **External references**: Other canisters, frontends, or external third-party systems that reference the canister by ID will break. This includes Internet Identity: users who authenticated via a canister-ID-based domain (for example, `.icp0.io`) will lose access to their sessions. +- **External references**: Other canisters, frontends, or external third-party systems that reference the canister by ID will break. This includes Internet Identity: users who authenticated via a canister-ID-based domain (for example, `.icp.net`) will lose access to their sessions. :::danger If your canister uses threshold signatures (tECDSA / tSchnorr) or vetKeys, snapshot transfer splits state from keys: the target canister gets a new ID and therefore different signing and decryption keys. Any Bitcoin or Ethereum addresses and any encrypted data tied to the original canister ID become inaccessible from the new canister. diff --git a/docs/guides/canister-management/cycles-management.mdx b/docs/guides/canister-management/cycles-management.mdx index 29f3f117..02f62471 100644 --- a/docs/guides/canister-management/cycles-management.mdx +++ b/docs/guides/canister-management/cycles-management.mdx @@ -340,7 +340,7 @@ icp canister status -e ic **Automated monitoring services**: Third-party services can monitor balances and alert or auto-top-up: - [CycleOps](https://cycleops.dev): Network-based monitoring with automated top-ups and email notifications -- [Canistergeek](https://cusyh-iyaaa-aaaah-qcpba-cai.raw.icp0.io/): Cycles, memory, and log monitoring in one place +- [Canistergeek](https://cusyh-iyaaa-aaaah-qcpba-cai.raw.icp.net/): Cycles, memory, and log monitoring in one place **Automated top-up libraries:** - Rust: [canfund](https://github.com/dfinity/canfund): DFINITY-maintained library for automated canister funding @@ -364,7 +364,7 @@ icp canister top-up backend --amount 1T -n ic **Confusing local and mainnet cycles**: Local deployments use fabricated cycles and never freeze. Test with realistic amounts on a staging environment before going to production. -**Using `ExperimentalCycles` in Motoko**: In `mo:core`, the module is `Cycles`, not `ExperimentalCycles`. `import ExperimentalCycles "mo:base/ExperimentalCycles"` will fail with `mo:core`. Use `import Cycles "mo:core/Cycles"`. +**Using `ExperimentalCycles` in Motoko**: In `mo:core`, the module is `Cycles`, not `ExperimentalCycles`. The legacy `ExperimentalCycles` import from the old base library does not exist in `mo:core`; use `import Cycles "mo:core/Cycles"` instead. ## Next steps diff --git a/docs/guides/canister-management/large-wasm.md b/docs/guides/canister-management/large-wasm.md index a532fb25..eeb9bdeb 100644 --- a/docs/guides/canister-management/large-wasm.md +++ b/docs/guides/canister-management/large-wasm.md @@ -34,9 +34,8 @@ The Rust and prebuilt recipes expose a `compress` flag that gzip-compresses the canisters: - name: backend recipe: - type: "@dfinity/rust@v3.2.0" + type: "@dfinity/rust@v3.3.0" configuration: - package: backend shrink: true compress: true ``` diff --git a/docs/guides/canister-management/logs.md b/docs/guides/canister-management/logs.md index 1bfbf91a..724eb3d4 100644 --- a/docs/guides/canister-management/logs.md +++ b/docs/guides/canister-management/logs.md @@ -155,9 +155,7 @@ You can configure log visibility per canister in `icp.yaml` so it is applied on canisters: - name: backend recipe: - type: "@dfinity/rust@v3.2.0" - configuration: - package: backend + type: "@dfinity/rust@v3.3.0" settings: log_visibility: controllers # "controllers" | "public" | allowed_viewers object ``` diff --git a/docs/guides/canister-management/optimization.md b/docs/guides/canister-management/optimization.md index 104352c7..d280082d 100644 --- a/docs/guides/canister-management/optimization.md +++ b/docs/guides/canister-management/optimization.md @@ -26,13 +26,12 @@ This guide covers the main tools and techniques available: canisters: - name: backend recipe: - type: "@dfinity/rust@v3.2.0" + type: "@dfinity/rust@v3.3.0" configuration: - package: backend shrink: true ``` -**Using the official Motoko recipe:** +**Using the official Motoko recipe:** enable `shrink` in the recipe configuration. The source file is declared separately in `mops.toml`: ```yaml canisters: @@ -40,7 +39,6 @@ canisters: recipe: type: "@dfinity/motoko@" configuration: - main: src/main.mo shrink: true ``` @@ -73,23 +71,20 @@ For binary size over speed, use `opt-level = "z"` (optimize for size, disabling The Motoko compiler uses the **incremental GC** by default starting with Motoko 0.15 and enhanced orthogonal persistence. You cannot choose a different GC when enhanced orthogonal persistence is active. The GC is fixed. -For projects using legacy persistence (without enhanced orthogonal persistence), you can select an alternative GC by passing compiler arguments through the Motoko recipe: +For projects using legacy persistence (without enhanced orthogonal persistence), you can select an alternative GC by passing compiler flags through the canister's `args` entry in `mops.toml`. The `@dfinity/motoko` recipe (v5 and later) builds with `mops build`, so these flags belong in `mops.toml` rather than the recipe configuration. When `--legacy-persistence` is specified, you can use `--copying-gc`, `--compacting-gc`, or `--generational-gc`: -```yaml -canisters: - - name: backend - recipe: - type: "@dfinity/motoko@" - configuration: - main: src/main.mo - args: --incremental-gc +```toml +# mops.toml +[canisters.backend] +main = "src/main.mo" +args = ["--legacy-persistence", "--compacting-gc"] ``` -> **New projects:** If you are using enhanced orthogonal persistence (the current default), no `args` configuration is needed. The incremental GC is already selected automatically. The `args` field only becomes relevant when selecting an alternative GC under `--legacy-persistence`. +The compacting GC supports larger heap sizes than the default 2-space copying collector, while the generational GC performs well when most heap data has a short lifetime. -The incremental GC is designed to scale for large heap sizes and is more efficient on average than the older copying or compacting collectors. It is the recommended choice for most workloads. +> **New projects:** If you are using enhanced orthogonal persistence (the current default), no GC configuration is needed. The incremental GC is already selected automatically. -For legacy-persistence projects: if `--legacy-persistence` is specified, you can use `--copying-gc`, `--compacting-gc`, or `--generational-gc`. The compacting GC supports larger heap sizes than the default 2-space copying collector, while the generational GC performs well when most heap data has a short lifetime. +The incremental GC is designed to scale for large heap sizes and is more efficient on average than the older copying or compacting collectors. It is the recommended choice for most workloads. ## WebAssembly SIMD (Rust only) diff --git a/docs/guides/canister-management/settings.mdx b/docs/guides/canister-management/settings.mdx index b7a14d64..d0424a0b 100644 --- a/docs/guides/canister-management/settings.mdx +++ b/docs/guides/canister-management/settings.mdx @@ -44,12 +44,12 @@ icp canister settings update backend --add-controller PRINCIPAL # Remove a controller icp canister settings update backend --remove-controller PRINCIPAL -# Replace the entire controller list -icp canister settings update backend --set-controller PRINCIPAL_1 --set-controller PRINCIPAL_2 +# Replace the entire controller list: clear it, then add the principals you want +icp canister settings update backend --remove-all-controllers --add-controller PRINCIPAL_1 --add-controller PRINCIPAL_2 ``` :::caution -Removing yourself from the controller list or using `--set-controller` without including yourself will cause you to permanently lose control of the canister. +Removing yourself from the controller list, or using `--remove-all-controllers` without adding yourself back with `--add-controller` in the same command, will cause you to permanently lose control of the canister. ::: ### Compute allocation diff --git a/docs/guides/canister-management/troubleshooting.md b/docs/guides/canister-management/troubleshooting.md index cb4f490a..4746e232 100644 --- a/docs/guides/canister-management/troubleshooting.md +++ b/docs/guides/canister-management/troubleshooting.md @@ -87,7 +87,7 @@ For patterns around bounded and unbounded inter-canister calls, see [Inter-canis A frontend deployed to the mainnet returns a blank screen and the browser console shows "Failed to load resource" errors. -**Check for client-side firewall or proxy interference.** Some corporate firewalls and browser extensions block requests to `*.icp0.io` or `*.ic0.app` domains. If the frontend loads on a different network, a firewall or proxy is the likely cause. +**Check for client-side firewall or proxy interference.** Some corporate firewalls and browser extensions block requests to `*.icp.net` domains. If the frontend loads on a different network, a firewall or proxy is the likely cause. **Verify the asset canister is deployed correctly.** Run `icp canister status -e ic` and confirm the module hash is populated. If the hash is `None`, the canister exists but has no code installed. diff --git a/docs/guides/chain-fusion/ethereum.mdx b/docs/guides/chain-fusion/ethereum.mdx index cb854fe0..637edfe3 100644 --- a/docs/guides/chain-fusion/ethereum.mdx +++ b/docs/guides/chain-fusion/ethereum.mdx @@ -593,9 +593,7 @@ Add the EVM RPC canister to your `icp.yaml` as a pre-built canister for local de canisters: - name: backend recipe: - type: "@dfinity/motoko@v4.1.0" - configuration: - main: src/backend/main.mo + type: "@dfinity/motoko@v5.0.0" - name: evm_rpc build: steps: @@ -604,6 +602,14 @@ canisters: init_args: "(record {})" ``` +The `@dfinity/motoko` recipe (v5 and later) builds with `mops build`, so the backend's source file is declared in `mops.toml` rather than the recipe configuration: + +```toml +# mops.toml +[canisters] +backend = "src/backend/main.mo" +``` + {/* Needs human verification: The pre-built URL version (v2.2.0) should be verified against the latest EVM RPC canister release. */} ### Local deployment diff --git a/docs/guides/frontends/asset-canister.md b/docs/guides/frontends/asset-canister.md index 54a81a87..0421b902 100644 --- a/docs/guides/frontends/asset-canister.md +++ b/docs/guides/frontends/asset-canister.md @@ -17,7 +17,7 @@ The asset canister is a pre-built Rust canister maintained by DFINITY. It implem 2. Creates the canister (if new) and installs the WASM 3. Syncs your build output directory to the canister (uploading, updating, and deleting files as needed) -Users access your frontend at `https://.icp0.io` (mainnet) or `http://.localhost:8000` (local). You can also register a [custom domain](custom-domains.md). +Users access your frontend at `https://.icp.net` (mainnet) or `http://.localhost:8000` (local). You can also register a [custom domain](custom-domains.md). ### What the asset canister provides @@ -72,9 +72,7 @@ canisters: - npm run build - name: backend recipe: - type: "@dfinity/rust@v3.2.0" - configuration: - package: backend + type: "@dfinity/rust@v3.3.0" ``` For more on project configuration, see [Project structure](../../getting-started/project-structure.md). @@ -115,7 +113,7 @@ Here is a recommended configuration: Key settings explained: - **`security_policy: "standard"`** applies a set of security headers (Content-Security-Policy, X-Frame-Options, etc.). If these headers block your application, override individual headers in the `headers` object rather than removing the security policy entirely. -- **`allow_raw_access: false`** prevents assets from being served on the `raw.icp0.io` domain, where responses are not verified by HTTP gateways. Only enable raw access when strictly needed (e.g., for assets that must be embedded in iframes on other domains). +- **`allow_raw_access: false`** prevents assets from being served on the `raw.icp.net` domain, where responses are not verified by HTTP gateways. Only enable raw access when strictly needed (e.g., for assets that must be embedded in iframes on other domains). - **`enable_aliasing: true`** tells the asset canister to serve `index.html` when a requested path has no matching file. This is required for single-page applications where the client-side router handles URL paths like `/about` or `/settings`. Rules are applied in order. Later rules override earlier ones for overlapping paths. @@ -143,7 +141,7 @@ After deployment, open your browser to `http://.localhost:8000/`. T icp deploy -e ic frontend ``` -Your frontend is accessible at `https://.icp0.io` or `https://.ic0.app`. +Your frontend is accessible at `https://.icp.net`. ### Updating the frontend diff --git a/docs/guides/frontends/certification.md b/docs/guides/frontends/certification.md index 5b1199c7..4c8052f9 100644 --- a/docs/guides/frontends/certification.md +++ b/docs/guides/frontends/certification.md @@ -46,8 +46,8 @@ The asset canister supports two serving modes: | Domain | Certification | Notes | |--------|--------------|-------| -| `.icp0.io` | Verified | Boundary node checks every response | -| `.raw.icp0.io` | None | Responses not verified: use only when necessary | +| `.icp.net` | Verified | Boundary node checks every response | +| `.raw.icp.net` | None | Responses not verified: use only when necessary | Raw access is enabled by default. Disable it in `.ic-assets.json5` for any assets that must not be served unverified: @@ -60,7 +60,7 @@ Raw access is enabled by default. Disable it in `.ic-assets.json5` for any asset ] ``` -With `allow_raw_access` set to `false`, requests to the `raw.icp0.io` domain are redirected to the certified domain automatically. +With `allow_raw_access` set to `false`, requests to the `raw.icp.net` domain are redirected to the certified domain automatically. ## What the asset canister handles automatically @@ -301,7 +301,7 @@ For the full working example including a backend canister, see the [certified-co ## Common mistakes -**Not disabling raw access for sensitive assets.** By default `allow_raw_access` is `true`, meaning assets are also available on `raw.icp0.io` where no verification occurs. Set `"allow_raw_access": false` in `.ic-assets.json5` for any assets that must not be served unverified. +**Not disabling raw access for sensitive assets.** By default `allow_raw_access` is `true`, meaning assets are also available on `raw.icp.net` where no verification occurs. Set `"allow_raw_access": false` in `.ic-assets.json5` for any assets that must not be served unverified. **Not certifying Content-Type and security headers.** Headers not listed in `.ic-assets.json5` are not included in the certification. A malicious replica could inject arbitrary values for uncertified headers. Always certify `Content-Type` and any security headers your application relies on. diff --git a/docs/guides/frontends/custom-domains.md b/docs/guides/frontends/custom-domains.md index a0da3875..da6611a8 100644 --- a/docs/guides/frontends/custom-domains.md +++ b/docs/guides/frontends/custom-domains.md @@ -5,7 +5,7 @@ sidebar: order: 2 --- -By default, every canister on ICP is accessible at `https://.icp0.io`. To serve your frontend under your own domain (e.g., `app.example.com`), you register it with the HTTP gateway custom domain service. +By default, every canister on ICP is accessible at `https://.icp.net`. To serve your frontend under your own domain (e.g., `app.example.com`), you register it with the HTTP gateway custom domain service. The service handles TLS certificate provisioning, renewal, and routing automatically. You configure three DNS records, deploy a domain ownership file to your canister, and call a registration API. @@ -95,7 +95,7 @@ Replace `frontend` with your canister's name as defined in `icp.yaml`. Verify the file is accessible: ```bash -curl -sL https://.icp0.io/.well-known/ic-domains +curl -sL https://.icp.net/.well-known/ic-domains ``` You should see your domain listed in the response. @@ -105,7 +105,7 @@ You should see your domain listed in the response. Before registering, validate that your DNS records and canister file are correct: ```bash -curl -sL -X GET "https://icp0.io/custom-domains/v1/CUSTOM_DOMAIN/validate" | jq +curl -sL -X GET "https://icp.net/custom-domains/v1/CUSTOM_DOMAIN/validate" | jq ``` A successful response: @@ -136,7 +136,7 @@ If validation fails, the response indicates what is wrong: ## Step 5: Register the domain ```bash -curl -sL -X POST "https://icp0.io/custom-domains/v1/CUSTOM_DOMAIN" | jq +curl -sL -X POST "https://icp.net/custom-domains/v1/CUSTOM_DOMAIN" | jq ``` A successful response: @@ -163,7 +163,7 @@ Common registration errors: Registration takes a few minutes. Poll the status endpoint: ```bash -curl -sL -X GET "https://icp0.io/custom-domains/v1/CUSTOM_DOMAIN" | jq +curl -sL -X GET "https://icp.net/custom-domains/v1/CUSTOM_DOMAIN" | jq ``` The `registration_status` field progresses from `registering` → `registered`: @@ -199,13 +199,13 @@ foo.bar.com ```bash # Validate -curl -sL -X GET "https://icp0.io/custom-domains/v1/foo.bar.com/validate" | jq +curl -sL -X GET "https://icp.net/custom-domains/v1/foo.bar.com/validate" | jq # Register -curl -sL -X POST "https://icp0.io/custom-domains/v1/foo.bar.com" | jq +curl -sL -X POST "https://icp.net/custom-domains/v1/foo.bar.com" | jq # Check status -curl -sL -X GET "https://icp0.io/custom-domains/v1/foo.bar.com" | jq +curl -sL -X GET "https://icp.net/custom-domains/v1/foo.bar.com" | jq ``` ## HttpAgent configuration for custom domains @@ -233,13 +233,13 @@ To point an existing custom domain at a different canister: 2. Notify the service: ```bash - curl -sL -X PATCH "https://icp0.io/custom-domains/v1/CUSTOM_DOMAIN" | jq + curl -sL -X PATCH "https://icp.net/custom-domains/v1/CUSTOM_DOMAIN" | jq ``` 3. Check the registration status to track progress: ```bash - curl -sL -X GET "https://icp0.io/custom-domains/v1/CUSTOM_DOMAIN" | jq + curl -sL -X GET "https://icp.net/custom-domains/v1/CUSTOM_DOMAIN" | jq ``` ## Removing a custom domain @@ -249,18 +249,18 @@ To point an existing custom domain at a different canister: 2. Notify the service: ```bash - curl -sL -X DELETE "https://icp0.io/custom-domains/v1/CUSTOM_DOMAIN" | jq + curl -sL -X DELETE "https://icp.net/custom-domains/v1/CUSTOM_DOMAIN" | jq ``` 3. Confirm deletion. The status endpoint should return 404: ```bash - curl -sL -X GET "https://icp0.io/custom-domains/v1/CUSTOM_DOMAIN" | jq + curl -sL -X GET "https://icp.net/custom-domains/v1/CUSTOM_DOMAIN" | jq ``` ## Internet Identity and custom domains -Internet Identity (II) derives user principals from the origin domain. If your users authenticate using the canister URL (`.icp0.io`) and you switch to a custom domain, they will get different principals on the new domain. +Internet Identity (II) derives user principals from the origin domain. If your users authenticate using the canister URL (`.icp.net`) and you switch to a custom domain, they will get different principals on the new domain. To preserve the same principals across both origins, configure alternative origins. See [Internet Identity](../authentication/internet-identity.md) for the setup. @@ -334,7 +334,7 @@ The `.well-known/ic-domains` file is not accessible on your canister. Check: Verify directly: ```bash -curl -sL https://.icp0.io/.well-known/ic-domains +curl -sL https://.icp.net/.well-known/ic-domains ``` **Certificate renewal failing** diff --git a/docs/guides/frontends/frameworks.md b/docs/guides/frontends/frameworks.md index 74742201..113d5980 100644 --- a/docs/guides/frontends/frameworks.md +++ b/docs/guides/frontends/frameworks.md @@ -360,7 +360,7 @@ After deployment, the asset canister URL depends on your canister ID: | Environment | URL | |-------------|-----| | Local | `http://.localhost:8000` | -| Mainnet | `https://.ic0.app` | +| Mainnet | `https://.icp.net` | Get your canister ID with: diff --git a/docs/guides/governance/launching.md b/docs/guides/governance/launching.md index 8f50a01b..4d00b3d4 100644 --- a/docs/guides/governance/launching.md +++ b/docs/guides/governance/launching.md @@ -219,7 +219,7 @@ dfx sns propose --network ic --neuron $NEURON_ID sns_init.yaml There can only be one SNS creation proposal active in the NNS at a time. If another project's proposal is currently being voted on, you must wait for it to resolve before submitting yours. -After submitting, monitor your proposal's status on the [NNS app](https://nns.ic0.app) or by querying NNS governance directly. +After submitting, monitor your proposal's status on the [NNS app](https://nns.icp.net) or by querying NNS governance directly. ### Stages 4–11: Automatic diff --git a/docs/guides/security/canister-control.md b/docs/guides/security/canister-control.md index 73b175e3..6eb4d134 100644 --- a/docs/guides/security/canister-control.md +++ b/docs/guides/security/canister-control.md @@ -13,7 +13,7 @@ If single entities or small groups control canisters, they can apply changes or Furthermore, the controller of canisters serving web content (such as e.g., the asset canister) could maliciously modify the web application to e.g., steal user funds or perform security-sensitive actions on the user's behalf. For example, if [Internet Identity](../authentication/internet-identity.md) is used, the user principal's private key for the given origin is stored in the browser storage, and a malicious app can therefore fully control the private key, the user's session, and any assets controlled by that key. -Dapps are commonly reachable over their own custom domain name instead of ic0.app. These domains are registered with a DNS registrar by one of the developers. The developer can choose to have this domain point at a completely different web application, even one not hosted on ICP. Users will trust this domain and the app it serves. This could allow such a developer to steal funds, leak data, etc. +Dapps are commonly reachable over their own custom domain name instead of icp.net. These domains are registered with a DNS registrar by one of the developers. The developer can choose to have this domain point at a completely different web application, even one not hosted on ICP. Users will trust this domain and the app it serves. This could allow such a developer to steal funds, leak data, etc. An app might have privileged features that are only accessible to principals that are on an allow list. For example, minting new tokens, debugging functions, managing permissions, removing NFTs for digital rights violations, etc. This means that whoever controls that principal (such as the app developers) may have central control over these privileged features. @@ -58,7 +58,7 @@ If you interact with a canister that you require to be decentralized, make sure ### Security concern -Loading untrusted JavaScript from domains other than `.icp0.io` means you completely trust that domain. Also, assets loaded from these domains (incl. `.raw.icp0.io`) will not use asset certification. +Loading untrusted JavaScript from domains other than `.icp.net` means you completely trust that domain. Also, assets loaded from these domains (incl. `.raw.icp.net`) will not use asset certification. If they deliver malicious JavaScript, they can take over the web app or account. This could, for example, happen by reading the private key managed by the ICP JavaScript agent from the browser's local storage. diff --git a/docs/guides/security/data-integrity-and-authenticity.md b/docs/guides/security/data-integrity-and-authenticity.md index 378a3add..eaa5d62c 100644 --- a/docs/guides/security/data-integrity-and-authenticity.md +++ b/docs/guides/security/data-integrity-and-authenticity.md @@ -608,17 +608,17 @@ function bigEndian(n) { } ``` -## Use HTTP asset certification and avoid serving your app through `raw.icp0.io` +## Use HTTP asset certification and avoid serving your app through `raw.icp.net` ### Security concern -Apps on ICP can use [asset certification](../frontends/certification.md) to make sure the HTTP assets delivered to the browser are authentic (i.e., threshold-signed by the subnet). If an app does not do asset certification, it can only be served insecurely through `raw.icp0.io`, where no asset certification is checked. This is insecure since a single malicious node or boundary node can freely modify the assets delivered to the browser. +Apps on ICP can use [asset certification](../frontends/certification.md) to make sure the HTTP assets delivered to the browser are authentic (i.e., threshold-signed by the subnet). If an app does not do asset certification, it can only be served insecurely through `raw.icp.net`, where no asset certification is checked. This is insecure since a single malicious node or boundary node can freely modify the assets delivered to the browser. -If an app is served through `raw.icp0.io` in addition to `icp0.io`, an adversary may trick users (phishing) into using the insecure `raw.icp0.io`. +If an app is served through `raw.icp.net` in addition to `icp.net`, an adversary may trick users (phishing) into using the insecure `raw.icp.net`. ### Recommendation -- Only serve assets through `.icp0.io`, where the boundary nodes enforce response verification on the served assets. Do not serve through `.raw.icp0.io`. +- Only serve assets through `.icp.net`, where the boundary nodes enforce response verification on the served assets. Do not serve through `.raw.icp.net`. - Serve assets using the asset canister, which creates asset certification automatically, or add the `ic-certificate` header including the asset certification as, e.g., done in the [NNS app](https://github.com/dfinity/nns-dapp) and [Internet Identity](https://github.com/dfinity/internet-identity). diff --git a/docs/references/application-canisters.md b/docs/references/application-canisters.md index 4518344e..a787cfa9 100644 --- a/docs/references/application-canisters.md +++ b/docs/references/application-canisters.md @@ -105,7 +105,7 @@ Create `.ic-assets.json5` in your `dir` directory (or `public/`/`static/` so you ``` - `security_policy: "standard"`: applies the default Content Security Policy and security headers -- `allow_raw_access: false`: disables serving assets on the uncertified `raw.ic0.app` domain +- `allow_raw_access: false`: disables serving assets on the uncertified `raw.icp.net` domain - `enable_aliasing: true`: enables SPA fallback, serving `index.html` for unmatched paths ### Programmatic uploads diff --git a/docs/references/cycle-costs.md b/docs/references/cycle-costs.md index db7c9ab3..f30450aa 100644 --- a/docs/references/cycle-costs.md +++ b/docs/references/cycle-costs.md @@ -7,7 +7,7 @@ sidebar: Canisters pay for the resources they consume and operations they perform using [**cycles**](../concepts/cycles.md). The price of cycles is pegged to [XDR](glossary.md#xdr) (Special Drawing Rights): **1 trillion cycles = 1 XDR**. USD values throughout this page use **1 XDR = $1.366430**; see [XDR exchange rate](#xdr-exchange-rate) at the end of this page for the current rate and how to look it up programmatically. -You can use the [pricing calculator](https://3d5wy-5aaaa-aaaag-qkhsq-cai.icp0.io/) to estimate the cost for your app. +You can use the [pricing calculator](https://3d5wy-5aaaa-aaaag-qkhsq-cai.icp.net/) to estimate the cost for your app. ## Cycle units @@ -244,7 +244,7 @@ Example: ICP/USD = $2.67, ICP/XDR = 19482 / 10000 = 1.9482 → XDR/USD = 2.67 / The ICP Dashboard API is not certified: responses are unsigned and not verifiable by the network. -**CMC metrics endpoint (Prometheus, unsigned):** The CMC exposes a Prometheus metrics endpoint at `https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp0.io/metrics` that includes `cmc_icp_xdr_conversion_rate` (current ICP/XDR) and `cmc_avg_icp_xdr_conversion_rate` (30-day moving average used for node provider rewards). Neither is certified. Apply the same formula to derive XDR/USD. +**CMC metrics endpoint (Prometheus, unsigned):** The CMC exposes a Prometheus metrics endpoint at `https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp.net/metrics` that includes `cmc_icp_xdr_conversion_rate` (current ICP/XDR) and `cmc_avg_icp_xdr_conversion_rate` (30-day moving average used for node provider rewards). Neither is certified. Apply the same formula to derive XDR/USD. **From canister code (certified):** Call the XRC for `ICP/USD` as a crypto/fiat pair (1B cycles, refunded if unused), and call the CMC `get_icp_xdr_conversion_rate` for ICP/XDR. Derive XDR/USD = ICP_USD / (xdr_permyriad_per_icp / 10_000). See [Fetch exchange rates](../guides/chain-fusion/exchange-rates.md) for XRC integration code. diff --git a/docs/references/glossary.md b/docs/references/glossary.md index 7c6bb9ff..af872b2d 100644 --- a/docs/references/glossary.md +++ b/docs/references/glossary.md @@ -71,7 +71,7 @@ hosted on this subnet. These blockchains interact using [chain-key cryptography] **Boundary nodes** are gateways to the Internet Computer. These nodes allow users to access the [canisters](#canister) running on ICP. The boundary nodes have several purposes: they aid in discover-ability (the -`icp0.io` domain name points to a set of boundary nodes), they are +`icp.net` domain name points to a set of boundary nodes), they are geo-aware and can route incoming requests to the nearest subnet [node](#node) that hosts the [canister](#canister) involved, they can help load balance query diff --git a/docs/references/system-canisters.md b/docs/references/system-canisters.md index 29bc353c..f8d53aa7 100644 --- a/docs/references/system-canisters.md +++ b/docs/references/system-canisters.md @@ -72,7 +72,7 @@ The lifeline canister is responsible for upgrading the NNS root canister itself. **Canister ID:** [`qoctq-giaaa-aaaaa-aaaea-cai`](https://dashboard.internetcomputer.org/canister/qoctq-giaaa-aaaaa-aaaea-cai) -The NNS UI canister hosts the NNS app frontend at [nns.ic0.app](https://nns.ic0.app). It provides a browser-based interface for staking neurons, voting on proposals, managing ICP tokens, and participating in SNS launches. +The NNS UI canister hosts the NNS app frontend at [nns.icp.net](https://nns.icp.net). It provides a browser-based interface for staking neurons, voting on proposals, managing ICP tokens, and participating in SNS launches. ## Cycles minting canister (CMC) @@ -113,7 +113,7 @@ get_icp_xdr_conversion_rate : () -> (record { data: record { xdr_permyriad_per_i `xdr_permyriad_per_icp` is the amount of XDR per ICP expressed in units of 1/10000. For example, `19482` means 1 ICP = 1.9482 XDR. This is an ICP/XDR rate; the CMC does not track XDR/USD. -The CMC also exposes a Prometheus metrics endpoint at `https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp0.io/metrics` with the following relevant fields: +The CMC also exposes a Prometheus metrics endpoint at `https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp.net/metrics` with the following relevant fields: | Metric | Description | |--------|-------------|