diff --git a/blog/news-and-updates/2024-12-11-update.mdx b/blog/news-and-updates/2024-12-11-update.mdx
new file mode 100644
index 0000000000..1f4ba03f13
--- /dev/null
+++ b/blog/news-and-updates/2024-12-11-update.mdx
@@ -0,0 +1,44 @@
+---
+title: Developer weekly update December 11, 2024
+description: This week, we have an important Motoko security update, an upgrade to the NNS Chain Fusion signer canister, and a new package from Mops- regex.
+tags: [Devs]
+image: /img/blog/dev-update-blog-dec-11.jpg
+---
+
+# Developer weekly update December 11, 2024
+
+![December 11 2024](../../static/img/blog/dev-update-blog-dec-11.jpg)
+
+Hello developers, and welcome to this week's developer weekly update! This week, we have an important Motoko security update, an upgrade to the NNS Chain Fusion signer canister, and a new package from Mops: regex. Let's get started!
+
+## Motoko security fix in dfx v0.24.3
+
+A security bug in Motoko was recently discovered that, under certain circumstances, may lead to unwanted memory reads or writes. This bug only affected those using the incremental garbage collector or enhanced orthogonal persistence and was hard to trigger depending on heap constellations, garbage collection scheduling, and specific language features used at a large scale.
+
+This bug has been fixed in Motoko v0.14.3, which is included in `dfx` v0.24.3 and newer. It is highly recommended to upgrade to the latest `dfx` version if you are using the incremental garbage collector or enhanced orthogonal persistence.
+
+[Learn more on the dev forum](https://forum.dfinity.org/t/security-fix-in-motoko-dfx-0-24-3/38656/1).
+
+## Upgrade NNS canister: Chain Fusion signer
+
+The latest update to the Chain Fusion signer canister can be used to sign transactions from APIs directly from a web browser or off-chain client.
+
+NNS proposal 134424 introduces Schnorr signatures to be added to the signer canister API, specifically adding the `schnorr_public_key()` and `schnorr_sign()` methods. The Schnorr API can also be used to sign Solana transactions.
+
+[Read more on the dev forum](https://forum.dfinity.org/t/upgrade-nns-canister-chain-fusion-signer/38623/1).
+
+## Mops regex package
+
+A new Mops package has been released: regex. This package allows you to use regex patterns for objects and flags. The team behind this package has published a [tutorial video](https://www.youtube.com/watch?v=O1dOZfK6DQA).
+
+You can install the Motoko regex package with:
+
+```
+mops add regex
+```
+
+[Learn more on the dev forum](https://forum.dfinity.org/t/motoko-regex-is-live-on-mops/37428/1).
+
+That'll wrap up this week. Tune back in next week for more developer updates!
+
+-DFINITY
\ No newline at end of file
diff --git a/docs/developer-docs/ai/ai-on-chain.mdx b/docs/developer-docs/ai/ai-on-chain.mdx
index 5595e8760e..7d9298e75d 100644
--- a/docs/developer-docs/ai/ai-on-chain.mdx
+++ b/docs/developer-docs/ai/ai-on-chain.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
ICP's unique ability to run compute at scale allows AI and neural networks to run directly onchain within a canister smart contract.
diff --git a/docs/developer-docs/ai/inference.mdx b/docs/developer-docs/ai/inference.mdx
index c161521e99..33b6c65c9a 100644
--- a/docs/developer-docs/ai/inference.mdx
+++ b/docs/developer-docs/ai/inference.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Inference in the context of decentralized AI refers to using a trained model to draw conclusions about new data.
It's possible for canister smart contracts to run inference in a number of ways depending on the decentralization and performance requirements.
diff --git a/docs/developer-docs/ai/machine-learning-sample.mdx b/docs/developer-docs/ai/machine-learning-sample.mdx
index 3c8db1b341..4982efc2fb 100644
--- a/docs/developer-docs/ai/machine-learning-sample.mdx
+++ b/docs/developer-docs/ai/machine-learning-sample.mdx
@@ -11,7 +11,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Machine learning is a form of artificial intelligence (AI) that observes statistical algorithms and their data to learn patterns and generalizations. By analyzing these data patterns, machine learning algorithms can execute tasks by predicting the correct result with high accuracy.
diff --git a/docs/developer-docs/ai/samples.mdx b/docs/developer-docs/ai/samples.mdx
index 4d546283a5..65f283425d 100644
--- a/docs/developer-docs/ai/samples.mdx
+++ b/docs/developer-docs/ai/samples.mdx
@@ -10,7 +10,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
ICP's unique ability to run compute at scale allows AI and neural networks to run directly onchain within a canister smart contract. Canisters can also interact with LLMs stored off-chain through HTTPS outcalls, or stored locally on a user's device.
diff --git a/docs/developer-docs/ai/training-models.mdx b/docs/developer-docs/ai/training-models.mdx
index b3ab656bbf..a02d9d137b 100644
--- a/docs/developer-docs/ai/training-models.mdx
+++ b/docs/developer-docs/ai/training-models.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Training AI models on ICP provides developers with a decentralized infrastructure and simplifies the setup process. ICP’s built-in computation and storage capabilities remove the need for external hardware. With GPU support on the roadmap, ICP will soon further enhance its AI capabilities and allow developers to train complex models, including large-scale AI systems.
diff --git a/docs/developer-docs/backend/rust/access-control.mdx b/docs/developer-docs/backend/rust/access-control.mdx
index 6220ce6be9..fec0a2f74c 100644
--- a/docs/developer-docs/backend/rust/access-control.mdx
+++ b/docs/developer-docs/backend/rust/access-control.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
To demonstrate access control using a Rust backend canister, you'll explore access control in the context of NFTs. NFTs (non-fungible tokens) are unique tokens with arbitrary
metadata, usually an image of some kind, to form the digital equivalent of trading cards.
diff --git a/docs/developer-docs/backend/rust/candid.mdx b/docs/developer-docs/backend/rust/candid.mdx
index 38003a57b6..b1ae7edbc4 100644
--- a/docs/developer-docs/backend/rust/candid.mdx
+++ b/docs/developer-docs/backend/rust/candid.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Candid is an **interface description language** with the primary purpose of describing the public interface of a service. A service is usually in the form of a program deployed as a canister. Candid is language-agnostic, meaning that it allows for the inter-operation between services and frontends written in different programming languages, including Rust.
diff --git a/docs/developer-docs/backend/rust/counter.mdx b/docs/developer-docs/backend/rust/counter.mdx
index bfddc269a1..4bd89cd61c 100644
--- a/docs/developer-docs/backend/rust/counter.mdx
+++ b/docs/developer-docs/backend/rust/counter.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
In this guide, you are going to write a dapp that provides a few basic functions to increment a counter value. by calling functions on a deployed canister. By calling the function to increment a value multiple times, you can verify that the variable state, that is, the value of the variable between calls, persists.
diff --git a/docs/developer-docs/backend/rust/deploying.mdx b/docs/developer-docs/backend/rust/deploying.mdx
index e372e38570..2eac673d90 100644
--- a/docs/developer-docs/backend/rust/deploying.mdx
+++ b/docs/developer-docs/backend/rust/deploying.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
In this guide, you'll learn the steps required to write, compile, deploy, and interact with a Rust backend canister.
diff --git a/docs/developer-docs/backend/rust/generating-candid.mdx b/docs/developer-docs/backend/rust/generating-candid.mdx
index 67f1ce1b56..09ea4e6fa0 100644
--- a/docs/developer-docs/backend/rust/generating-candid.mdx
+++ b/docs/developer-docs/backend/rust/generating-candid.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
In versions of the Rusk CDK `v0.11.0` and higher, the Candid export workflow has been changed.
You can call the `ic_cdk::export_candid!()` macro to enable the Candid export behavior, then use the [candid-extractor](https://github.com/dfinity/cdk-rs/tree/main/src/candid-extractor) to extract the Candid from the canister's Wasm.
diff --git a/docs/developer-docs/backend/rust/intercanister.mdx b/docs/developer-docs/backend/rust/intercanister.mdx
index 3068125950..7def78c59d 100644
--- a/docs/developer-docs/backend/rust/intercanister.mdx
+++ b/docs/developer-docs/backend/rust/intercanister.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Inter-canister calls can be used to update information between two or more canisters.
diff --git a/docs/developer-docs/backend/rust/message-inspect.mdx b/docs/developer-docs/backend/rust/message-inspect.mdx
index 43e792978b..86f961305f 100644
--- a/docs/developer-docs/backend/rust/message-inspect.mdx
+++ b/docs/developer-docs/backend/rust/message-inspect.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
A canister can inspect an ingress message and either accept or decline the message through the canister's HTTPS interface. If the message is accepted, the canister will execute it.
diff --git a/docs/developer-docs/backend/rust/optimizing.mdx b/docs/developer-docs/backend/rust/optimizing.mdx
index 717b9090d3..16283ceca6 100644
--- a/docs/developer-docs/backend/rust/optimizing.mdx
+++ b/docs/developer-docs/backend/rust/optimizing.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Compiling Rust to Wasm often increases the file size significantly. `dfx` versions `0.14.0` and newer include the `wasm-opt` package that can be used to optimize cycle consumption and binary size.
## Prerequisites
diff --git a/docs/developer-docs/backend/rust/project-organization.mdx b/docs/developer-docs/backend/rust/project-organization.mdx
index b9311036bc..b2993f1307 100644
--- a/docs/developer-docs/backend/rust/project-organization.mdx
+++ b/docs/developer-docs/backend/rust/project-organization.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
When a new Rust project is created with the command:
diff --git a/docs/developer-docs/backend/rust/quickstart.mdx b/docs/developer-docs/backend/rust/quickstart.mdx
index 2610ba7e1b..17319784c7 100644
--- a/docs/developer-docs/backend/rust/quickstart.mdx
+++ b/docs/developer-docs/backend/rust/quickstart.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Applications for ICP start as **projects**. You can create new projects for ICP using the IC SDK. This guide focuses on how to create, build, and deploy a Rust program by using the `dfx` parent command and its subcommands.
diff --git a/docs/developer-docs/backend/rust/rust-considerations.mdx b/docs/developer-docs/backend/rust/rust-considerations.mdx
index d14fbbecca..9d7f57b190 100644
--- a/docs/developer-docs/backend/rust/rust-considerations.mdx
+++ b/docs/developer-docs/backend/rust/rust-considerations.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This guide describes information that developers should consider when writing Rust canisters, specifically regarding canister observability and global state.
diff --git a/docs/developer-docs/backend/rust/rust-limitations.mdx b/docs/developer-docs/backend/rust/rust-limitations.mdx
index b03050052d..3c4ffada37 100644
--- a/docs/developer-docs/backend/rust/rust-limitations.mdx
+++ b/docs/developer-docs/backend/rust/rust-limitations.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
WebAssembly (Wasm) is a binary code format and does not provide network access, a filesystem, or other functionalities other than pure computation. Anything function that needs to communicate outside of the Wasm module must use an IC API. This guide details limitations imposed by Wasm on canisters written in Rust.
diff --git a/docs/developer-docs/backend/rust/searching-records.mdx b/docs/developer-docs/backend/rust/searching-records.mdx
index 445f392afc..524370eb99 100644
--- a/docs/developer-docs/backend/rust/searching-records.mdx
+++ b/docs/developer-docs/backend/rust/searching-records.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
In this guide, you are going to write a dapp that provides a few basic functions to add and retrieve simple profile records that consist of a name, description, and an array of keywords.
This program supports the following functions:
diff --git a/docs/developer-docs/backend/rust/stable-structures.mdx b/docs/developer-docs/backend/rust/stable-structures.mdx
index 149fd98e65..a4a0ea603a 100644
--- a/docs/developer-docs/backend/rust/stable-structures.mdx
+++ b/docs/developer-docs/backend/rust/stable-structures.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Stable structures are designed to use stable memory as the backing store, allowing them to grow to gigabytes in size without the need for `pre_upgrade`/`post_upgrade` hooks.
diff --git a/docs/developer-docs/backend/rust/timers.mdx b/docs/developer-docs/backend/rust/timers.mdx
index a43e1f2277..c57bbb7b69 100644
--- a/docs/developer-docs/backend/rust/timers.mdx
+++ b/docs/developer-docs/backend/rust/timers.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
This guide demonstrates how to create a small dapp with a periodic task. The task is triggered automatically by the ICP network with a specified interval.
## Prerequisites
diff --git a/docs/developer-docs/backend/rust/upgrading.mdx b/docs/developer-docs/backend/rust/upgrading.mdx
index 62755ff301..0184e2cd6a 100644
--- a/docs/developer-docs/backend/rust/upgrading.mdx
+++ b/docs/developer-docs/backend/rust/upgrading.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Unlike a canister reinstall that preserves the canister identifier but no state, a canister upgrade enables you to preserve the state of a deployed canister and change the code.
diff --git a/docs/developer-docs/cost-estimations-and-examples.mdx b/docs/developer-docs/cost-estimations-and-examples.mdx
index 07707f94fa..26beaa5418 100644
--- a/docs/developer-docs/cost-estimations-and-examples.mdx
+++ b/docs/developer-docs/cost-estimations-and-examples.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
To get a rough estimate of how much your project may cost, below is a pricing calculator that can be used to estimate the cost of a dapp deployed on ICP. Costs are charged to a canister in cycles, which are fixed against the price of [XDR](/docs/current/references/glossary#xdr), where **1 trillion cycles equals 1 XDR**.
Cycles costs are calculated based on:
diff --git a/docs/developer-docs/daos/nns/concepts/neurons/becoming-a-known-neuron.mdx b/docs/developer-docs/daos/nns/concepts/neurons/becoming-a-known-neuron.mdx
index fb909d1a7f..3ce4d7c190 100644
--- a/docs/developer-docs/daos/nns/concepts/neurons/becoming-a-known-neuron.mdx
+++ b/docs/developer-docs/daos/nns/concepts/neurons/becoming-a-known-neuron.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
A know neuron has a name and optionally a short description.
A known neuron can be registered in the NNS governance via a proposal, officially storing its name and description
within the NNS. This information can be used by other neurons to find known neurons and [follow](/docs/current/developer-docs/daos/nns/concepts/neurons/neuron-following) them.
diff --git a/docs/developer-docs/daos/nns/concepts/neurons/neuron-following.mdx b/docs/developer-docs/daos/nns/concepts/neurons/neuron-following.mdx
index cf0f160a53..7ae27b0f3e 100644
--- a/docs/developer-docs/daos/nns/concepts/neurons/neuron-following.mdx
+++ b/docs/developer-docs/daos/nns/concepts/neurons/neuron-following.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Users may not have the time or knowledge to participate in all voting decisions.
Therefore, instead of directly voting on proposals, neuron holders may choose to delegate their vote to other neurons that they trust with certain decisions.
This concept, where a neuron follows the decisions of some other neurons, is called **following** in the NNS DAO.
diff --git a/docs/developer-docs/daos/nns/concepts/neurons/neuron-management.mdx b/docs/developer-docs/daos/nns/concepts/neurons/neuron-management.mdx
index 664b2a51f3..5bbd35586a 100644
--- a/docs/developer-docs/daos/nns/concepts/neurons/neuron-management.mdx
+++ b/docs/developer-docs/daos/nns/concepts/neurons/neuron-management.mdx
@@ -15,7 +15,7 @@ This page is for you if you want to learn the technical details about neuron ope
Tutorials for users who want to interact with the NNS using the [NNS dapp](https://nns.ic0.app) frontend are available in the [NNS dapp quickguide](/docs/current/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart).
-## Overview
+
View the most up-to-date [`candid` definition for the NNS governance canister](https://github.com/dfinity/ic/blob/master/rs/nns/governance/canister/governance.did).
This page will explain some of the relevant definitions from this Candid file.
To keep up to date with new NNS release proposals from DFINITY, you can subscribe to [this forum thread](https://forum.dfinity.org/t/nns-updates-aggregation-thread/23551).
diff --git a/docs/developer-docs/daos/nns/concepts/neurons/staking-voting-rewards.mdx b/docs/developer-docs/daos/nns/concepts/neurons/staking-voting-rewards.mdx
index e1c2e28d61..ccdbf3e5d7 100644
--- a/docs/developer-docs/daos/nns/concepts/neurons/staking-voting-rewards.mdx
+++ b/docs/developer-docs/daos/nns/concepts/neurons/staking-voting-rewards.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Stakeholders gain voting power and can earn voting rewards by staking their ICP tokens in neurons and participating in governance.
The Internet Computer is a decentralized platform whose evolution is decided by its stakeholders through voting.
diff --git a/docs/developer-docs/daos/nns/concepts/proposals/direct-voting.mdx b/docs/developer-docs/daos/nns/concepts/proposals/direct-voting.mdx
index f38809424b..d4f228f424 100644
--- a/docs/developer-docs/daos/nns/concepts/proposals/direct-voting.mdx
+++ b/docs/developer-docs/daos/nns/concepts/proposals/direct-voting.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
The NNS DAO is an open governance system where anyone can become a participant by [staking some ICP in a neuron](https://internetcomputer.org/docs/current/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart#stake-icp-utility-tokens-in-a-neuron). At least 1 ICP is required to create a neuron.
Locking tokens for a period of time is known as the neuron's dissolve delay. If a neuron has more than 6 months dissolve delay, it is eligible to participate in voting. This means that it can both submit and vote on proposals.
diff --git a/docs/developer-docs/daos/nns/overview.mdx b/docs/developer-docs/daos/nns/overview.mdx
index 977e1af59c..740621c9ae 100644
--- a/docs/developer-docs/daos/nns/overview.mdx
+++ b/docs/developer-docs/daos/nns/overview.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
diff --git a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart.mdx b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart.mdx
index e031bad71e..3bb6c075e6 100644
--- a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart.mdx
+++ b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
There are different ways to interact with the NNS DAO to participate in governance.
diff --git a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-additional-features.mdx b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-additional-features.mdx
index 5df6b6de9f..39becd9bd2 100644
--- a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-additional-features.mdx
+++ b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-additional-features.mdx
@@ -10,7 +10,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
In addition to being the portal for interacting with the NNS DAO, the NNS dapp also provides access to the SNS DAOs, their launches, and allows users to manage canisters that they control.
This is a brief guide to some of these additional functionalities.
diff --git a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-advanced-neuron-operations.mdx b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-advanced-neuron-operations.mdx
index 4ee772d880..d7d0938828 100644
--- a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-advanced-neuron-operations.mdx
+++ b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-advanced-neuron-operations.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Once you are a bit more familiar with the NNS, you might want to use the NNS dapp to perform additional neuron operations.
For more background on neurons, including the concepts of voting rewards and what the different neuron operations do in details,
diff --git a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-following-other-neurons.mdx b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-following-other-neurons.mdx
index 486e3e0225..3ed27fba50 100644
--- a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-following-other-neurons.mdx
+++ b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-following-other-neurons.mdx
@@ -15,7 +15,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Neuron owners may find it hard to manually vote on every proposal submitted to the NNS.
For example, they may not have the time or necessary expertise to evaluate each individual proposal.
The NNS uses a form of liquid democracy to address these challenges called **following**.
diff --git a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-importing-tokens.mdx b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-importing-tokens.mdx
index 71a535021f..0ad634f781 100644
--- a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-importing-tokens.mdx
+++ b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-importing-tokens.mdx
@@ -15,7 +15,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
The NNS dapp focuses on providing a simple user interface where community members can interact with different on-chain governance systems deployed on the Internet Computer.
diff --git a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-making-neurons-public.mdx b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-making-neurons-public.mdx
index 75f66ba2c6..65f7055a47 100644
--- a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-making-neurons-public.mdx
+++ b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-making-neurons-public.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Neuron visibility settings are available in order to support a [neuron index](https://dashboard.internetcomputer.org/proposal/48491) while respecting neuron holders' privacy. A neuron can be private or public. For public neurons, anyone who knows the neuron's ID can see the full neuron's details, including how they vote on proposals. [Learn more about the differences between private and public neurons](/docs/current/developer-docs/daos/nns/concepts/neurons/neuron-management#neuron-visibility).
diff --git a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-manage-quill-neurons.mdx b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-manage-quill-neurons.mdx
index a43ef9c84e..2b2bbad661 100644
--- a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-manage-quill-neurons.mdx
+++ b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-manage-quill-neurons.mdx
@@ -15,7 +15,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
You may have neurons controlled by a principal ID that was created using [quill](../../../../../../docs/current/developer-docs/developer-tools/cli-tools/quill-cli-reference/quill-parent). In this case, it may be inconvenient to manage your neurons through the terminal. If you know the seed phrase of this principal ID, you can use a Ledger hardware wallet to manage your neurons through the [NNS dapp](https://nns.ic0.app/).
## How to access neurons controlled by a principal ID created with quill
diff --git a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-send-and-receive-tokens.mdx b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-send-and-receive-tokens.mdx
index 88e6e42f3e..c7b9b2ffdc 100644
--- a/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-send-and-receive-tokens.mdx
+++ b/docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-send-and-receive-tokens.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
When you log into the NNS dapp for the first time you will not yet have any ICP tokens in your wallet.
Therefore, you first might want transfer some tokens to the NNS dapp wallet.
This also the first step required for staking a neuron with the NNS dapp.
diff --git a/docs/developer-docs/daos/sns/index.mdx b/docs/developer-docs/daos/sns/index.mdx
index 64f6289449..c35b0243e6 100644
--- a/docs/developer-docs/daos/sns/index.mdx
+++ b/docs/developer-docs/daos/sns/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
These pages introduce instructions needed when considering handing over control of a
dapp to a Service Nervous System (SNS) or integrating with an SNS.
If this is the first time you hear about the SNS, it is recommended to take a look at the high level [SNS](/sns)
diff --git a/docs/developer-docs/daos/sns/launching/integrating.mdx b/docs/developer-docs/daos/sns/launching/integrating.mdx
index 7cad7720ff..74fd75ca09 100644
--- a/docs/developer-docs/daos/sns/launching/integrating.mdx
+++ b/docs/developer-docs/daos/sns/launching/integrating.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
When planning an SNS launch, one topic to consider is whether and how the SNS functionality should be integrated in the dapp.
For example, one may want to embed a frontend for the SNS swap or for the SNS governance in the dapp's UI.
diff --git a/docs/developer-docs/daos/sns/launching/launch-steps-1proposal.mdx b/docs/developer-docs/daos/sns/launching/launch-steps-1proposal.mdx
index 0f0adbf923..5a267c9baf 100644
--- a/docs/developer-docs/daos/sns/launching/launch-steps-1proposal.mdx
+++ b/docs/developer-docs/daos/sns/launching/launch-steps-1proposal.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
At a high level, the stages for launching an SNS in production are explained [here](../launching/launch-summary-1proposal.mdx).
diff --git a/docs/developer-docs/daos/sns/launching/launch-summary-1proposal.mdx b/docs/developer-docs/daos/sns/launching/launch-summary-1proposal.mdx
index c4a0b8ee93..4f08219e3b 100644
--- a/docs/developer-docs/daos/sns/launching/launch-summary-1proposal.mdx
+++ b/docs/developer-docs/daos/sns/launching/launch-summary-1proposal.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
During an SNS launch, a dapp is handed over to the NNS and the NNS both
creates the SNS canisters and starts a decentralization swap to decentralize the SNS and
thereby the dapp.
diff --git a/docs/developer-docs/daos/sns/managing/cycles-usage.mdx b/docs/developer-docs/daos/sns/managing/cycles-usage.mdx
index e690f7ed9e..b8d2f937c5 100644
--- a/docs/developer-docs/daos/sns/managing/cycles-usage.mdx
+++ b/docs/developer-docs/daos/sns/managing/cycles-usage.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
:::caution
An SNS community must ensure that all SNS and dapp canisters
have sufficient cycles by manually sending cycles when necessary to
diff --git a/docs/developer-docs/daos/sns/managing/making-proposals.mdx b/docs/developer-docs/daos/sns/managing/making-proposals.mdx
index a150aeb5cb..e3d3312474 100644
--- a/docs/developer-docs/daos/sns/managing/making-proposals.mdx
+++ b/docs/developer-docs/daos/sns/managing/making-proposals.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
To manage an SNS, the SNS community needs to understand how proposals work, how they can be submitted, voted on, and what effect they have.
diff --git a/docs/developer-docs/daos/sns/managing/manage-sns-intro.mdx b/docs/developer-docs/daos/sns/managing/manage-sns-intro.mdx
index f8bf013e45..645d0ff379 100644
--- a/docs/developer-docs/daos/sns/managing/manage-sns-intro.mdx
+++ b/docs/developer-docs/daos/sns/managing/manage-sns-intro.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
SNSs are protocol-provided DAOs on ICP that are to some extent maintained by the
NNS community, who for example approve new upgrades of SNS canister code.
This eliminates much of the maintenance burden from the SNS communities.
diff --git a/docs/developer-docs/daos/sns/managing/managing-nervous-system-parameters.mdx b/docs/developer-docs/daos/sns/managing/managing-nervous-system-parameters.mdx
index af1a2b9f35..609982f2fc 100644
--- a/docs/developer-docs/daos/sns/managing/managing-nervous-system-parameters.mdx
+++ b/docs/developer-docs/daos/sns/managing/managing-nervous-system-parameters.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The nervous system parameters define the settings of a particular SNS.
diff --git a/docs/developer-docs/daos/sns/managing/sns-asset-canister.mdx b/docs/developer-docs/daos/sns/managing/sns-asset-canister.mdx
index 4cd6eb69ea..3103de6511 100644
--- a/docs/developer-docs/daos/sns/managing/sns-asset-canister.mdx
+++ b/docs/developer-docs/daos/sns/managing/sns-asset-canister.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The [asset canister](https://github.com/dfinity/sdk/tree/master/src/canisters/frontend/ic-frontend-canister) provides users with a way to store and retrieve static assets from a canister deployed on ICP. Generally, asset canisters are used to serve HTML, CSS, or JavaScript assets, which are typically part of a dapp's frontend. For this reason, the asset canister is also referred to as the frontend canister. For purposes of this guide, it will be referred to as the asset canister.
diff --git a/docs/developer-docs/daos/sns/testing/testing-locally.mdx b/docs/developer-docs/daos/sns/testing/testing-locally.mdx
index c10f7adfa7..d689e3416a 100644
--- a/docs/developer-docs/daos/sns/testing/testing-locally.mdx
+++ b/docs/developer-docs/daos/sns/testing/testing-locally.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
To help developers, DFINITY has created the [sns-testing repo](https://github.com/dfinity/sns-testing) which has scripts that help developers test the SNS process. Developers can run a local version of the ICP execution environment on their local machine, deploy their dapp locally and run through [the stages](../launching/launch-summary-1proposal.mdx) of decentralizing their dapp.
diff --git a/docs/developer-docs/daos/sns/testing/testing-on-mainnet.mdx b/docs/developer-docs/daos/sns/testing/testing-on-mainnet.mdx
index ebd9160026..856eb3e47c 100644
--- a/docs/developer-docs/daos/sns/testing/testing-on-mainnet.mdx
+++ b/docs/developer-docs/daos/sns/testing/testing-on-mainnet.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Once a developer has tested the process of an SNS, it is highly recommended they do an **"SNS testflight" [on the mainnet](./testing-on-mainnet.mdx)**. An SNS testflight is when a developer deploys their dapp (to the mainnet) and hands control of it to a mock SNS (on the mainnet).
diff --git a/docs/developer-docs/daos/sns/tokenomics/index.mdx b/docs/developer-docs/daos/sns/tokenomics/index.mdx
index 3893719c98..57c6bb184b 100644
--- a/docs/developer-docs/daos/sns/tokenomics/index.mdx
+++ b/docs/developer-docs/daos/sns/tokenomics/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Launching an SNS entails many non-technical and technical preparations steps.
[The SNS launch checklist](sns-checklist.mdx) summarizes some of the most important preparation
diff --git a/docs/developer-docs/daos/sns/tokenomics/predeployment-considerations.mdx b/docs/developer-docs/daos/sns/tokenomics/predeployment-considerations.mdx
index 2b3cee79f4..8cd0402d64 100644
--- a/docs/developer-docs/daos/sns/tokenomics/predeployment-considerations.mdx
+++ b/docs/developer-docs/daos/sns/tokenomics/predeployment-considerations.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Preparing an SNS launch includes many non-technical considerations.
For example, to decentralize a dapp, the governance control has to be distributed
diff --git a/docs/developer-docs/daos/sns/tokenomics/preparation.mdx b/docs/developer-docs/daos/sns/tokenomics/preparation.mdx
index ba7b1ce15d..0c3bb39c46 100644
--- a/docs/developer-docs/daos/sns/tokenomics/preparation.mdx
+++ b/docs/developer-docs/daos/sns/tokenomics/preparation.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Typically, one would first decide on tokenomics and other configurations,
for examples using the
[SNS tokenomics training & tools](https://wiki.internetcomputer.org/wiki/How-To:_SNS_tokenomics_configuration)
diff --git a/docs/developer-docs/defi/cycles/converting_icp_tokens_into_cycles.mdx b/docs/developer-docs/defi/cycles/converting_icp_tokens_into_cycles.mdx
index 3e297f813d..91877872c3 100644
--- a/docs/developer-docs/defi/cycles/converting_icp_tokens_into_cycles.mdx
+++ b/docs/developer-docs/defi/cycles/converting_icp_tokens_into_cycles.mdx
@@ -11,7 +11,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
To convert ICP tokens into cycles, you first need to obtain some ICP and transfer to the right account. You can get ICP tokens on exchanges, or ask someone you know to send you some. To figure out which account to transfer the ICP tokens to, run the following:
``` bash
diff --git a/docs/developer-docs/defi/cycles/cycles-ledger.mdx b/docs/developer-docs/defi/cycles/cycles-ledger.mdx
index e0f999489c..229c885a98 100644
--- a/docs/developer-docs/defi/cycles/cycles-ledger.mdx
+++ b/docs/developer-docs/defi/cycles/cycles-ledger.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
When developing and deploying canisters on the Internet Computer, developers need to have cycles to pay for the resources used by their canisters. The **cycles ledger** canister has been developed as an alternative to the **cycles wallet** canister for cycles management.
diff --git a/docs/developer-docs/defi/cycles/cycles-wallet.mdx b/docs/developer-docs/defi/cycles/cycles-wallet.mdx
index 87a85fc74d..b090efca67 100644
--- a/docs/developer-docs/defi/cycles/cycles-wallet.mdx
+++ b/docs/developer-docs/defi/cycles/cycles-wallet.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
As discussed in [tokens and cycles](/docs/current/developer-docs/getting-started/tokens-and-cycles), ICP tokens can be converted into **cycles** to power canister operations. Cycles reflect the operational cost of communication, computation, and storage that dapps consume.
diff --git a/docs/developer-docs/defi/exchange-rate-canister.mdx b/docs/developer-docs/defi/exchange-rate-canister.mdx
index d927cacba5..f229fe57f4 100644
--- a/docs/developer-docs/defi/exchange-rate-canister.mdx
+++ b/docs/developer-docs/defi/exchange-rate-canister.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
The exchange rate canister, referred to as the XRC, is a canister that runs on the **uzr34 system subnet**. The XRC uses [HTTPS outcalls](https://internetcomputer.org/https-outcalls/) to fetch data from major cryptocurrency exchanges by using the exchange's public API to retrieve real time or historical cryptocurrency pricing information. The XRC also queries the public APIs for foreign exchange data providers around the world periodically in order to get forex rates.
diff --git a/docs/developer-docs/defi/icp-tokens/account-trimming.mdx b/docs/developer-docs/defi/icp-tokens/account-trimming.mdx
index 8dbace8a12..e818485f09 100644
--- a/docs/developer-docs/defi/icp-tokens/account-trimming.mdx
+++ b/docs/developer-docs/defi/icp-tokens/account-trimming.mdx
@@ -10,7 +10,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Even if the ledger can index a large number of accounts, it has a finite capacity.
To avoid saturation and maintain good performance,
some accounts are trimmed if the ledger capacity is reaching a threshold.
diff --git a/docs/developer-docs/defi/nfts/marketplaces.mdx b/docs/developer-docs/defi/nfts/marketplaces.mdx
index 1668efe77f..48dfc204c7 100644
--- a/docs/developer-docs/defi/nfts/marketplaces.mdx
+++ b/docs/developer-docs/defi/nfts/marketplaces.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
An NFT marketplace is a dapp used to mint, buy, sell, and trade NFTs. An NFT listed on a marketplace may be part of a large collection, or it may be a one-of-a-kind token.
diff --git a/docs/developer-docs/defi/nfts/nft-collections.mdx b/docs/developer-docs/defi/nfts/nft-collections.mdx
index 5221c6168c..a7532da87d 100644
--- a/docs/developer-docs/defi/nfts/nft-collections.mdx
+++ b/docs/developer-docs/defi/nfts/nft-collections.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
An NFT collection is a series of non-fungible tokens that each have a unique identifier value. Each token's metadata may be the same, such as the name, image, and description, or each token's data can be unique and associated with a 'rarity' value, where some metadata values are less common than others. Rarity metadata attributes are common in generative NFT collections, often referring to an NFT collection where the artwork for each image has been randomly generated and some components only appear in a select few of the generated images.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/index.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/index.mdx
index 44e9b6a572..bb0cf4c966 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/index.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section will give you an overview of how you can make transactions via Rosetta using the construction API.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/combine.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/combine.mdx
index f187db0660..d243ffc9d7 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/combine.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/combine.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section details how to call the `construction/combine` endpoint of the Rosetta construction API.
The request and response types can be found in the [official documentation](https://docs.cdp.coinbase.com/mesh/reference/constructioncombine).
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/derive.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/derive.mdx
index bfce2cbe33..1d5bd72e4a 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/derive.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/derive.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section details how to derive an ICP adress using the Rosetta construction API.
The ICP ledger is using `accountidentifiers` to represent public keys internally. To derive an `accountidentifier` from a public key the Rosetta API offers the `construction/derive` endpoint.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/index.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/index.mdx
index 34588637e8..3403168a8e 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/index.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/index.mdx
@@ -7,7 +7,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
# Flow of operations
-## Overview
+
This section will give you an overview of how the flow of operations in the construction API works. It will guide you through each of the necessary endpoints that you will have to call in order to post a valid transaction with your signature to the ICP ledger. As an example of such a transaction this guide will use a simple transfer between accounts.
It is recommended to first read through the interactions of each endpoint to acquire an understanding of how the flow of operations works. Although the example of transferring tokens is only one use case of the construction API of Rosetta, it serves as a good example on what to expect from the interaction with the Construction-API. The other functionalities that are supported by ICP Rosetta through the construction API follow a similar flow of operations.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/metadata.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/metadata.mdx
index fd32ac9d2d..e66c154d46 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/metadata.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/metadata.mdx
@@ -7,7 +7,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section details how to call the `construction/metadata` endpoint of the Rosetta construction API.
The request and response types can be found in the [official documentation](https://docs.cdp.coinbase.com/rosetta/reference/constructionmetadata).
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/payloads.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/payloads.mdx
index 9cf32167b4..1054fac4ad 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/payloads.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/payloads.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section details how to call the `construction/payloads` endpoint of the Rosetta construction API.
The request and response types can be found in the [official documentation](https://docs.cdp.coinbase.com/mesh/reference/constructionpayloads).
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/preprocess.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/preprocess.mdx
index 32edf9451a..a54445bff8 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/preprocess.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/preprocess.mdx
@@ -7,7 +7,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section details how to call the `construction/preprocess` endpoint of the Rosetta construction API.
Preprocess is called prior to `/construction/payloads` to construct a request for any metadata that is needed for transaction construction. The ICP Rosetta implementation will return the required list of public keys that has to be provided by the user and in the metadata it returns the request type that is associated with the given set of operations.
The metadata returned from this endpoint will be sent to the `/construction/metadata` endpoint UNMODIFIED by the caller (in an offline execution environment).
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/submit.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/submit.mdx
index 8acd3a81b6..b73d28b518 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/submit.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/submit.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section details how to call the `construction/submit` endpoint of the Rosetta construction API.
The request and response types can be found in the [official documentation](https://docs.cdp.coinbase.com/mesh/reference/constructionsubmit).
The endpoint sends to transactions to the IC. The first being the `Call Request` which contains the information of what submit, which canister, what function in the canister and with what arguments should be called.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/change_auto_stake_maturity.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/change_auto_stake_maturity.mdx
index 4960214427..2b09e8c055 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/change_auto_stake_maturity.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/change_auto_stake_maturity.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|--------|
| Since version | 1.7.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/derive_neuron_id.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/derive_neuron_id.mdx
index 5a5d191ed7..7f8658201f 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/derive_neuron_id.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/derive_neuron_id.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|---------------|-------|
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/disburse.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/disburse.mdx
index 87fb2d7a2c..e259f5b653 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/disburse.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/disburse.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|--------|
| Since version | 1.4.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/dissolve.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/dissolve.mdx
index f26bd609c9..08bd401ed7 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/dissolve.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/dissolve.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|------------|
| Since version | 1.1.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/hotkeys.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/hotkeys.mdx
index f0f8e39375..2afd0c5335 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/hotkeys.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/hotkeys.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section will explain how to generate a hotkey for neuron management and add or remove hotkeys to your neuron using ICP Rosetta.
The recommended way to get hotkeys is to programmatically
generate them using the same process used in the public `ic` repository.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/index.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/index.mdx
index f3ad3dbc0a..8f0503ebb1 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/index.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section will give you an overview of how how ICP staking on the Internet Computer using Rosetta works.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/lock_neuron.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/lock_neuron.mdx
index 4d6aefb5cd..425cd91928 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/lock_neuron.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/lock_neuron.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|------------|
| Since version | 1.1.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/neuron_info.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/neuron_info.mdx
index bbd754d1b6..c3de3c3895 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/neuron_info.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/neuron_info.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|--------|
| Since version | 1.5.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/spawn.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/spawn.mdx
index 8f5a2ab87e..cc9ef429ae 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/spawn.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/spawn.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|------------|
| Since version | 1.3.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/stake_icp.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/stake_icp.mdx
index 7d0c147bfa..ed4b016813 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/stake_icp.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/stake_icp.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|---------------|-------|
| Since version | 1.5.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/stake_maturity.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/stake_maturity.mdx
index 9ce5651750..b78b069d89 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/stake_maturity.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/staking/stake_maturity.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|------------|
| Since version | 1.4.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/follow.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/follow.mdx
index 2e5272c9ca..9ad9693c68 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/follow.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/follow.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|------------|
| Since version | 1.5.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/index.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/index.mdx
index 893f8dcf6e..5b73531469 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/index.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section will give you an overview of how to vote on NNS proposals using Rosetta.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/vote.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/vote.mdx
index c6a752ace5..9bf836cb6b 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/vote.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/voting/vote.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
| | |
|----------------------|--------|
| Since version | 1.7.0 |
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/balances.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/balances.mdx
index d4e2be420b..a6f4ad0ffa 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/balances.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/balances.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This endpoint allows you to fetch the balances for a certain account. It is the implementation of the [/account/balance endpoint](https://www.rosetta-api.org/docs/AccountApi.html#accountbalance) of the Rosetta API standard.
### Prerequisites
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/blocks.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/blocks.mdx
index 2e953bc8f3..b6c16891d0 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/blocks.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/blocks.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This endpoint allows you to fetch blocks at a certain block height. It is the implementation of the [/block endpoint](https://docs.cdp.coinbase.com/mesh/reference/block) of the Rosetta API standard.
### Prerequisites
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/get_pending_proposals.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/get_pending_proposals.mdx
index fe9296ee38..83c4fdee1f 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/get_pending_proposals.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/get_pending_proposals.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This endpoint allows you to fetch all pending proposals from the NNS. It is the implementation of the [/call endpoint](https://docs.cdp.coinbase.com/mesh/reference/call) of the Rosetta API standard. The call endpoint is very flexible as to what it can be used for. In the case of ICP Rosetta it is used to fetch various custom information that is not covered by the Rosetta API standard.
### Prerequisites
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/get_proposal_info.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/get_proposal_info.mdx
index aaefc01510..f420e7ead1 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/get_proposal_info.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/get_proposal_info.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This endpoint allows you to fetch more detailed information about a specific proposal from the NNS. It is the implementation of the [/call endpoint](https://docs.cdp.coinbase.com/mesh/reference//call) of the Rosetta API standard. The call endpoint is very flexible as to what it can be used for. In the case of ICP Rosetta it is used to fetch various custom information that is not covered by the Rosetta API standard.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/index.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/index.mdx
index 296a3d5751..1f9524028a 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/index.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section will give you an overview of what data can be fetched from the data API endpoints for the ICP Rosetta implementation.
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/list_known_neurons.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/list_known_neurons.mdx
index d6589cc17c..3e1e9418cd 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/list_known_neurons.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/list_known_neurons.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This endpoint allows you to fetch all neurons from the NNS that are publicly known. It is the implementation of the [/call endpoint](https://docs.cdp.coinbase.com/mesh/reference/call) of the Rosetta API standard. The call endpoint is very flexible as to what it can be used for. In the case of ICP Rosetta it is used to fetch various custom information that is not covered by the Rosetta API standard.
### Prerequisites
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/network.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/network.mdx
index 0f3f5879ee..7191446987 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/network.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/network.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
For most endpoints you will require some information about the network represented as a [NetworkIdentifier](https://www.rosetta-api.org/docs/models/NetworkIdentifier.html).
diff --git a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/transactions.mdx b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/transactions.mdx
index acf376c491..dd035ccd8e 100644
--- a/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/transactions.mdx
+++ b/docs/developer-docs/defi/rosetta/icp_rosetta/data_api/transactions.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
There exist two different entpoints that allow for querying of transaction.
This endpoint allows you to fetch a transaction at a certain block height. It is the implementation of the [/block/transaction endpoint](https://docs.cdp.coinbase.com/mesh/reference/blocktransaction) of the Rosetta API standard.
The `search_transactions` endpoint allows you to query for transactions given a set of parameters. It is the implementation of the [/search/transactions endpoint](https://docs.cdp.coinbase.com/mesh/reference/searchtransactions/)
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/approve.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/approve.mdx
index c9ac7b5f5a..bcfb5143cf 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/approve.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/approve.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section will show you how to use the ICRC Rosetta implementation to authorize a spender to spend your ICRC-1 tokens. Make sure you are familiar with the [flow of operations](/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/index.mdx) for Rosetta.
The request types used for making direct transfers are `APPROVE` and `SPENDER`. They consist of two operations, one for the the approve operation and another for the spender operation.
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/index.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/index.mdx
index e33894c31b..55eaee69f2 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/index.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This section will give you an overview on what types of asset transfers are supported by ICRC Rosetta and how to use them.
It is divided in the following topics:
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/transfer.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/transfer.mdx
index 58557a377f..2b9f07588f 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/transfer.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/asset_transfer/transfer.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The request type that is used for making direct transfers is `TRANSFER`. In the simplest form it consists of two operations, one for the debit operation and one for the credit operation.
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/index.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/index.mdx
index 0f3a511218..75cad51ffe 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/index.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/construction_api/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The construction API allows for offline signing of transactions and then posting them on ICP at a later point in time. It is recommended to first go through [flow of operations](/docs/developer-docs/defi/rosetta/icp_rosetta/construction_api/operations_flow/index.mdx) of the construction API to gain an understanding of how it works, what endpoints to call with what parameters, and where the user has to take action upon receiving certain responses.
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/balances.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/balances.mdx
index 27b0f1bd4f..4a6653b8a9 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/balances.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/balances.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The `account_balance` endpoint allows you to fetch the balances for a certain account. It is the implementation of the [/account/balance endpoint](https://www.rosetta-api.org/docs/AccountApi.html#accountbalance) of the Rosetta API standard.
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/blocks.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/blocks.mdx
index b1bc114a92..896d891e38 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/blocks.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/blocks.mdx
@@ -7,7 +7,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
# Fetch blocks
-## Overview
+
The `block` endpoint allows you to fetch blocks at a certain block height. It is the implementation of the [/block endpoint](https://docs.cdp.coinbase.com/mesh/reference/block) of the Rosetta API standard.
### Prerequisites
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/index.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/index.mdx
index 6e6cd474fa..8e60a7853d 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/index.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The following data can be fetched from the data API endpoints for the ICRC Rosetta implementation:
- [Network](/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/network.mdx): Fetch network specific information, such as the most recent block and what network Rosetta is connected to.
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/network.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/network.mdx
index 0090db1f9f..fa3d48d454 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/network.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/network.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Most endpoints require some information about the network represented as a [`NetworkIdentifier`](https://www.rosetta-api.org/docs/models/NetworkIdentifier.html).
diff --git a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/transactions.mdx b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/transactions.mdx
index 549611e566..3b788eff95 100644
--- a/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/transactions.mdx
+++ b/docs/developer-docs/defi/rosetta/icrc_rosetta/data_api/transactions.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
There are two endpoints that allow for querying transactions.
The `block_transaction` endpoint allows you to fetch a transaction at a certain block height. It is the implementation of the [/block/transaction endpoint](https://docs.cdp.coinbase.com/mesh/reference/blocktransaction) of the Rosetta API standard.
The `search_transactions` endpoint allows you to query for transactions given a set of parameters. It is the implementation of the [/search/transactions endpoint](https://docs.cdp.coinbase.com/mesh/reference/searchtransactions/).
diff --git a/docs/developer-docs/defi/rosetta/overview.mdx b/docs/developer-docs/defi/rosetta/overview.mdx
index 9ca9b9befe..fbdbe62d57 100644
--- a/docs/developer-docs/defi/rosetta/overview.mdx
+++ b/docs/developer-docs/defi/rosetta/overview.mdx
@@ -5,7 +5,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
# Rosetta
-## Overview
+
[Rosetta](https://www.rosetta-api.org/) is an open standard introduced by Coinbase to simplify the integration of blockchain-based tokens in exchanges, block explorers, and wallets.
This documentation might help if you want to deploy a token on ICP that aims to be tradable on CeFi exchanges or if you are working on a block explorer or wallet.
diff --git a/docs/developer-docs/defi/tokens/create.mdx b/docs/developer-docs/defi/tokens/create.mdx
index 9c6ee45ca6..5b974722e8 100644
--- a/docs/developer-docs/defi/tokens/create.mdx
+++ b/docs/developer-docs/defi/tokens/create.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Custom tokens can be created and deployed on ICP using the [ICRC-1](https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-1) or [ICRC-2](https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-2) token standards.
diff --git a/docs/developer-docs/defi/tokens/indexes.mdx b/docs/developer-docs/defi/tokens/indexes.mdx
index b77d1ed0c3..d66ed98cc2 100644
--- a/docs/developer-docs/defi/tokens/indexes.mdx
+++ b/docs/developer-docs/defi/tokens/indexes.mdx
@@ -12,7 +12,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
On ICP, an index canister is used in conjunction with a ledger canister to provide the ability for transactions to be queried for a specific account. Without an index canister, a ledger's transaction history cannot easily be parsed and used by applications, as the entire transaction history of a ledger would need to be processed.
diff --git a/docs/developer-docs/defi/tokens/token-standards.mdx b/docs/developer-docs/defi/tokens/token-standards.mdx
index da584fea88..7dbbe456a2 100644
--- a/docs/developer-docs/defi/tokens/token-standards.mdx
+++ b/docs/developer-docs/defi/tokens/token-standards.mdx
@@ -10,7 +10,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Tokens deployed on ICP must adhere to a standard. The network's native token, ICP, adheres to its own standard as it is unique on the network in the sense that it is used for network utility and governance. Tokens created for other purposes on the network typically adhere to one of the ICRC standards.
@@ -20,7 +20,7 @@ In the past, the [DIP-721](#dip-721) standard was promoted and used by projects
### How standards are created
-- The [ICRC working group](https://github.com/dfinity/ICRC) creates an initial proposal for an ICRC standard.
+- The [ICRC working group](https://github.com/dfinity/ICRC) creates an initial proposal for an ICRC standard.
- The proposal is agreed upon through a rough consensus of the working group as a starting point for the standard.
@@ -28,13 +28,13 @@ In the past, the [DIP-721](#dip-721) standard was promoted and used by projects
- Once the proposal is deemed ready for implementation by the working group, it is proposed to the NNS through an NNS proposal.
-- The ICRC standard is either adopted or rejected by the NNS.
+- The ICRC standard is either adopted or rejected by the NNS.
## ICP tokens
The ICP token is the network's native token used for various utility and governance functions, such as:
-- Paying for a canister's resources by being converted into cycles.
+- Using tokens and cycles by being converted into cycles.
- Rewarding node providers for contributing resources to the network.
diff --git a/docs/developer-docs/defi/wallets/self-custody/hardware-wallet-cli.mdx b/docs/developer-docs/defi/wallets/self-custody/hardware-wallet-cli.mdx
index 477f38ae37..2527bd07ce 100644
--- a/docs/developer-docs/defi/wallets/self-custody/hardware-wallet-cli.mdx
+++ b/docs/developer-docs/defi/wallets/self-custody/hardware-wallet-cli.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
A hardware wallet is a physical ledger device that is used to store assets. Hardware wallets are protected by a seed phase, similar to software wallets, but they can be disconnected from the internet whenever they are ejected from your computer.
diff --git a/docs/developer-docs/defi/wallets/self-custody/self-custody-quickstart.mdx b/docs/developer-docs/defi/wallets/self-custody/self-custody-quickstart.mdx
index bb9338257a..495ecb403d 100644
--- a/docs/developer-docs/defi/wallets/self-custody/self-custody-quickstart.mdx
+++ b/docs/developer-docs/defi/wallets/self-custody/self-custody-quickstart.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Within the Internet Computer ecosystem, ICP tokens the network's native utility token and are used in both the governance and economics of the network.
This self-custody guide scenario assumes:
diff --git a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/check-chunk-store.mdx b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/check-chunk-store.mdx
index bd468fe91f..02d3574220 100644
--- a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/check-chunk-store.mdx
+++ b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/check-chunk-store.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
A canister's chunk store must be empty before a Wasm module can be installed in the canister.
diff --git a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/dfx-migration.mdx b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/dfx-migration.mdx
index e4e2383429..8c59cf17c5 100644
--- a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/dfx-migration.mdx
+++ b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/dfx-migration.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
`dfxvm` is a new tool used for installing and managing different versions of `dfx`. In `dfx` versions 0.17.0 and newer, `dfxvm` is used to install and update `dfx`. This means CI jobs that install `dfx` will need to update their workflow.
diff --git a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/init-args.mdx b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/init-args.mdx
index ee7aff1387..303fd7bd2a 100644
--- a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/init-args.mdx
+++ b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/init-args.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
When installing a canister's code, it may require Candid initialization arguments to be passed with the `dfx canister install` command. Initialization arguments are initial configuration parameters that the canister's installation expects in order to install the code correctly. One example of a canister that requires these Candid initialization arguments is the [ICP ledger canister](/docs/developer-docs/defi/tokens/ledger/setup/icp_ledger_setup.mdx).
diff --git a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/networks-json.mdx b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/networks-json.mdx
index 35ff6589a3..67f97dc149 100644
--- a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/networks-json.mdx
+++ b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/networks-json.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
When developing multiple projects simultaneously, it can be beneficial to deploy each project to a different local network for simplicity or to support different development workflows. Custom networks can be configured with `dfx` at both the system-wide and project-specific levels.
diff --git a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/specifying-replica-version.mdx b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/specifying-replica-version.mdx
index 6ea2e4911f..a8111425e6 100644
--- a/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/specifying-replica-version.mdx
+++ b/docs/developer-docs/developer-tools/cli-tools/advanced-dfx/specifying-replica-version.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The replica version included in the most recent release of `dfx` may not reflect the most up to date replica release. In some workflows, such as testing new features of the replica, having the most recent version of the replica may be desirable.
diff --git a/docs/developer-docs/developer-tools/cli-tools/dfx-json-reference.mdx b/docs/developer-docs/developer-tools/cli-tools/dfx-json-reference.mdx
index 261fab6d26..a83420a877 100644
--- a/docs/developer-docs/developer-tools/cli-tools/dfx-json-reference.mdx
+++ b/docs/developer-docs/developer-tools/cli-tools/dfx-json-reference.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This is the schema reference for `dfx.json` in [JSON Schema](https://json-schema.org) format.
diff --git a/docs/developer-docs/developer-tools/cli-tools/dfx-json.mdx b/docs/developer-docs/developer-tools/cli-tools/dfx-json.mdx
index 1aa03f716a..4cac13434f 100644
--- a/docs/developer-docs/developer-tools/cli-tools/dfx-json.mdx
+++ b/docs/developer-docs/developer-tools/cli-tools/dfx-json.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Every project created and deployed with `dfx` requires a `dfx.json` file to be present in the project's root directory. The `dfx.json` file configures the project's settings such as the canisters in the project, their name, type, and source file, default project build settings, and other configuration parameters such as Wasm optimizations. This page will detail some of the most common configuration options. For a full list of the possible configuration settings in `dfx.json`, view the [`dfx.json` schema](/docs/current/developer-docs/developer-tools/cli-tools/dfx-json-reference).
diff --git a/docs/developer-docs/developer-tools/cli-tools/idl2json.mdx b/docs/developer-docs/developer-tools/cli-tools/idl2json.mdx
index 1c3510d08a..af541dc789 100644
--- a/docs/developer-docs/developer-tools/cli-tools/idl2json.mdx
+++ b/docs/developer-docs/developer-tools/cli-tools/idl2json.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
[`idl2json`](https://github.com/dfinity/idl2json/tree/main) is a command-line tool used to translate [Candid](https://github.com/dfinity/candid) textual values from `stdin` into JSON values outputted in `stdout`.
diff --git a/docs/developer-docs/developer-tools/dev-tools-overview.mdx b/docs/developer-docs/developer-tools/dev-tools-overview.mdx
index 9f85247401..d73b3e01c2 100644
--- a/docs/developer-docs/developer-tools/dev-tools-overview.mdx
+++ b/docs/developer-docs/developer-tools/dev-tools-overview.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Developer tools are used to create, manage, and interact with canisters. They can come in several formats, such as command line tools, onchain and off-chain libraries, and integrated development environments. For ICP developers, there are tools within each of these categories available for you to utilize when developing your ICP canisters.
diff --git a/docs/developer-docs/developer-tools/ide/codespaces.mdx b/docs/developer-docs/developer-tools/ide/codespaces.mdx
index 512bb6e828..5f8643ae45 100644
--- a/docs/developer-docs/developer-tools/ide/codespaces.mdx
+++ b/docs/developer-docs/developer-tools/ide/codespaces.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
GitHub Codespaces is a web-based cloud development environment that provides a platform for developing and deploying code without downloading any necessary tools or packages. GitHub Codespaces can be configured with a local ICP developer environment, including `dfx` and an instance of the ICP replica, to support canister development.
diff --git a/docs/developer-docs/developer-tools/ide/dev-containers.mdx b/docs/developer-docs/developer-tools/ide/dev-containers.mdx
index df63d12a89..75f7d67252 100644
--- a/docs/developer-docs/developer-tools/ide/dev-containers.mdx
+++ b/docs/developer-docs/developer-tools/ide/dev-containers.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Developer containers are a local development option that uses [Docker](https://www.docker.com/get-started/) and [VS Code](https://code.visualstudio.com/) to run local containerized environments. Containers are isolated from the rest of your local environment, and files within a container cannot be used by applications outside of the container unless explicitly mounted and given access. Developer containers are a good option for developers on Windows systems, since `dfx` is not natively supported for local development on Windows.
diff --git a/docs/developer-docs/developer-tools/ide/gitpod.mdx b/docs/developer-docs/developer-tools/ide/gitpod.mdx
index 42f512d223..8d50c5c768 100644
--- a/docs/developer-docs/developer-tools/ide/gitpod.mdx
+++ b/docs/developer-docs/developer-tools/ide/gitpod.mdx
@@ -11,7 +11,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Gitpod is a web-based cloud development environment that provides a platform for developing and deploying code without downloading any necessary tools or packages. Gitpod can be configured with a local ICP developer environment, including `dfx` and an instance of the ICP replica, to support canister development.
diff --git a/docs/developer-docs/developer-tools/ide/icp-ninja.mdx b/docs/developer-docs/developer-tools/ide/icp-ninja.mdx
index 6d4658bfed..5d21ce68d2 100644
--- a/docs/developer-docs/developer-tools/ide/icp-ninja.mdx
+++ b/docs/developer-docs/developer-tools/ide/icp-ninja.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
[ICP Ninja](https://icp.ninja/) is a web-based code editor and deployment environment for ICP canister smart contracts. Users can choose from a gallery of example projects, then edit and deploy the project directly to ICP without downloading `dfx` or obtaining cycles. Projects will be live for 20 minutes unless redeployed. The deployment timer resets on each deployment.
diff --git a/docs/developer-docs/developer-tools/ide/playground.mdx b/docs/developer-docs/developer-tools/ide/playground.mdx
index 22aebd7f8b..deddb9a878 100644
--- a/docs/developer-docs/developer-tools/ide/playground.mdx
+++ b/docs/developer-docs/developer-tools/ide/playground.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Deploying a canister to the playground is ICP's equivalent of deploying to a testnet network. It can be used through `dfx` using the `--network playground` flag, however the playground is also available through a frontend canister, which can be accessed at the following public URL:
diff --git a/docs/developer-docs/developer-tools/ide/vs-code.mdx b/docs/developer-docs/developer-tools/ide/vs-code.mdx
index 0e8fc10015..b6ca607c1e 100644
--- a/docs/developer-docs/developer-tools/ide/vs-code.mdx
+++ b/docs/developer-docs/developer-tools/ide/vs-code.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Visual Studio (VS) Code is a [widely used](https://survey.stackoverflow.co/2022/#section-worked-with-vs-want-to-work-with-integrated-development-environment) open-source IDE which supports canister development in [Motoko](/docs/current/motoko/main/getting-started/motoko-introduction) and [Rust](https://www.rust-lang.org/).
diff --git a/docs/developer-docs/developer-tools/off-chain/agents/javascript-agent.mdx b/docs/developer-docs/developer-tools/off-chain/agents/javascript-agent.mdx
index 96a8f6af82..c87bdb925d 100644
--- a/docs/developer-docs/developer-tools/off-chain/agents/javascript-agent.mdx
+++ b/docs/developer-docs/developer-tools/off-chain/agents/javascript-agent.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
An agent is an API client used to interact with ICP. The [ICP JavaScript agent](https://www.npmjs.com/package/@dfinity/agent) is used to interact with the public ICP API endpoints and canisters deployed on ICP. ICP JavaScript agent provides `call`, `query`, and `readState` methods, along with other utilities, to an actor.
diff --git a/docs/developer-docs/developer-tools/off-chain/agents/nodejs.mdx b/docs/developer-docs/developer-tools/off-chain/agents/nodejs.mdx
index ad43265796..0d61cf6484 100644
--- a/docs/developer-docs/developer-tools/off-chain/agents/nodejs.mdx
+++ b/docs/developer-docs/developer-tools/off-chain/agents/nodejs.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
[Node.js](https://nodejs.org/en) is a runtime environment for JavaScript. To interact with a canister through Node.js, you can use the [JavaScript agent](https://www.npmjs.com/package/@dfinity/agent). Using Node.js can enable use cases such as running an oracle, connecting an existing Node.js application to ICP, or introducing a websocket layer to your application.
diff --git a/docs/developer-docs/developer-tools/off-chain/agents/rust-agent.mdx b/docs/developer-docs/developer-tools/off-chain/agents/rust-agent.mdx
index 7dcd66e3e7..559726cf0c 100644
--- a/docs/developer-docs/developer-tools/off-chain/agents/rust-agent.mdx
+++ b/docs/developer-docs/developer-tools/off-chain/agents/rust-agent.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The [ICP Rust agent](https://docs.rs/ic-agent/latest/ic_agent/) by DFINITY is a simple library that enables you to build applications and interact with ICP, serving as a low-level Rust backend for the IC SDK.
diff --git a/docs/developer-docs/developer-tools/off-chain/canbench.mdx b/docs/developer-docs/developer-tools/off-chain/canbench.mdx
index b134bf5e52..4779db201d 100644
--- a/docs/developer-docs/developer-tools/off-chain/canbench.mdx
+++ b/docs/developer-docs/developer-tools/off-chain/canbench.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Canisters deployed on ICP use resources such as memory and compute. Resources are finite, and there are limits configured that restrict how many resources a canister may consume. The `canbench` Rust crate provides a way to benchmark a canister's resources so developers can gain an insight into how their canister uses memory, instructions, and other resources.
diff --git a/docs/developer-docs/developer-tools/off-chain/canpack.mdx b/docs/developer-docs/developer-tools/off-chain/canpack.mdx
index 842e8e025e..4bc198a15f 100644
--- a/docs/developer-docs/developer-tools/off-chain/canpack.mdx
+++ b/docs/developer-docs/developer-tools/off-chain/canpack.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Canpack is a code generation tool designed to simplify communication across canisters written in different languages. It currently supports calling a Rust crate from Motoko code. Canpack generates a separate canister for the host language, then combines the other language's code fragments that are defined across different libraries.
diff --git a/docs/developer-docs/developer-tools/on-chain/cdks.mdx b/docs/developer-docs/developer-tools/on-chain/cdks.mdx
index 7c635e2f4d..51b2841077 100644
--- a/docs/developer-docs/developer-tools/on-chain/cdks.mdx
+++ b/docs/developer-docs/developer-tools/on-chain/cdks.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Canister development kits (CDKs) are used to interface with the IC SDK and provide different programming languages with the necessary functionalities to develop canisters. These functionalities include the ability to create, deploy, call, and manage canisters, both locally deployed and deployed to the mainnet.
diff --git a/docs/developer-docs/developer-tools/on-chain/ic-js.mdx b/docs/developer-docs/developer-tools/on-chain/ic-js.mdx
index b7b0eb10b1..f05979a80c 100644
--- a/docs/developer-docs/developer-tools/on-chain/ic-js.mdx
+++ b/docs/developer-docs/developer-tools/on-chain/ic-js.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
`ic-js` is a collection of JavaScript libraries that can be used to interface with ICP. Each library can be used independently from one another, or a project can use all of the libraries together. The NNS dapp is an example demonstration of all `ic-js` libraries being used together.
diff --git a/docs/developer-docs/gas-cost.mdx b/docs/developer-docs/gas-cost.mdx
index 8a35ed2ae8..60ed6eb91f 100644
--- a/docs/developer-docs/gas-cost.mdx
+++ b/docs/developer-docs/gas-cost.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Canister smart contracts pay for consumed resources (storage, messaging, execution, and special features) by burning **cycles**. Developers can obtain cycles by converting ICP tokens into cycles using [`dfx`](/docs/current/developer-docs/defi/cycles/converting_icp_tokens_into_cycles).
diff --git a/docs/developer-docs/getting-started/deploy-and-manage.mdx b/docs/developer-docs/getting-started/deploy-and-manage.mdx
index e799e4b793..4371776652 100644
--- a/docs/developer-docs/getting-started/deploy-and-manage.mdx
+++ b/docs/developer-docs/getting-started/deploy-and-manage.mdx
@@ -10,17 +10,15 @@ import { BetaChip } from "/src/components/Chip/BetaChip";
import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-# Deploy and manage
+# Deploying and managing canisters
-## Overview
-
Once a canister's code has been written, it must be compiled into Wasm, installed into the canister itself, and then deployed to a network. The `dfx deploy` command executes each of these tasks as part of the deployment process; however, `dfx` commands also exist for running each step individually.
It is recommended to deploy canisters locally or to the temporary [playground](/docs/current/developer-docs/smart-contracts/deploy/overview#deploying-to-playground) network to test canister functionality and make adjustments before considering the canister production-ready and deploying it to the mainnet. Deploying canisters locally and to the playground is free and does not cost cycles. Once a canister is deployed to the mainnet, it will consistently consume cycles and will need to be topped up periodically.
-## Start the local replica
+## Starting the local replica
To deploy your canister locally, first start the local replica. This simulates the mainnet environment with a single node for local development and testing.
@@ -28,8 +26,7 @@ To deploy your canister locally, first start the local replica. This simulates t
- `dfx start --background`: Runs the processes in the background and allows you to continue running commands in the current terminal.
-
-## Deploy locally
+## Deploying the project locally
Deploy the backend canister that you have written code for:
@@ -73,7 +70,7 @@ Your deployed canister will now be executing two timers and printing the output
You can interact with the canister's public methods either in your web browser through the [Candid UI](/docs/current/developer-docs/smart-contracts/candid/candid-concepts) URL that was returned in the deployment output or using the command line. Candid is an interface description language used to interact with a canister's public methods.
-## Upgrades
+## Upgrading canisters
Canisters can be upgraded, allowing the same canister ID to be retained for an application. Upgrades preserve the state of a canister while allowing you to change the code. However, canister upgrades clear the canister's Wasm memory. Any data not stored in [stable memory](/docs/current/developer-docs/smart-contracts/maintain/storage) will be removed.
@@ -106,7 +103,7 @@ Confirm that the change you made results in the expected functionality or behavi
dfx canister stop PROJECT_NAME_backend --network=local
```
-## Deploy to the mainnet
+## Deploying your project to the mainnet
Now that the canister has been tested, you can deploy it to the mainnet. **Deploying to the mainnet costs [cycles](/docs/current/developer-docs/getting-started/tokens-and-cycles).**
@@ -142,7 +139,7 @@ URLs:
When a canister is running on the mainnet, you will always need to pass the `--network=ic` flag to interact with it.
:::
-## Settings
+## Canister settings
After a canister is deployed to the mainnet, it will constantly be consuming resources and cycles. To view information about how many resources and cycles currently being used, along with other information, view the canister's settings:
@@ -210,7 +207,7 @@ Log visibility: controllers
-## Topping up
+## Topping up canisters
A canister will burn cycles even in an idle state to pay for the network storage it uses. Additional costs will be charged whenever the canister sends and receives messages, uses compute resources, or uses special features like HTTPS outcalls and threshold signatures.
@@ -236,7 +233,7 @@ Manually monitoring canisters to determine when they are getting close to the fr
- [ICPTopup.com](https://www.icptopup.com/): A simplified version of CycleOps that allows you to top up several canisters (up to 50) at one time.
-### Freezing threshold
+### Cycles freezing threshold
To prevent a canister from running out of cycles and being deleted, you can set what is known as a **freezing threshold**. This threshold is a duration of time set in seconds, indicating the minimum duration that the canister should exist without running out of cycles. Once a canister hits this threshold, it will not execute messages. It will only pay for the network resources it uses, such as compute allocation, memory usage, and storage allocation.
@@ -251,7 +248,7 @@ If you set a freezing threshold longer than 1.5 years, you will need to include
:::
-## Logging
+## Canister logging
[Canister logs](/docs/current/developer-docs/smart-contracts/maintain/logs) can be used to gain insight into a canister's behavior and assist with debugging situations such as when a canister traps.
@@ -267,7 +264,7 @@ By default, canister logs are only visible to the canister's controllers, but th
dfx canister update-settings PROJECT_NAME_backend --network=ic --log-visibility public
```
-## Snapshots
+## Canister snapshots
Canister snapshots are used as a checkpoint that can be used to roll back your canister to a previous version in the event that the latest upgraded version becomes unresponsive or stops working as expected.
@@ -329,16 +326,12 @@ Any cycles remaining in the canister's balance will be returned to your develope
dfx canister delete PROJECT_NAME_backend --network=ic
```
-## Stopping `dfx`
+## Stopping the local replica
-To stop `dfx`, simply use the `dfx stop` command.
+To stop the local replica, simply use the `dfx stop` command.
For unresponsive `dfx` processes that are not stopped by `dfx stop`, you can use `dfx killall` to forcibly end them.
## Getting help
To view help information for `dfx`, you can use the `dfx help` command or view the [`dfx` reference documentation](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/).
-
-## Next steps
-
-- [x] View the [developer next steps](/docs/current/developer-docs/getting-started/next-steps).
diff --git a/docs/developer-docs/getting-started/deploy/local.mdx b/docs/developer-docs/getting-started/deploy/local.mdx
deleted file mode 100644
index 872a6b84a2..0000000000
--- a/docs/developer-docs/getting-started/deploy/local.mdx
+++ /dev/null
@@ -1,235 +0,0 @@
----
-keywords: [beginner, tutorial, local deployment, deploy]
----
-
-
-import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-
-
-# Local deployment
-
-
-
-## Overview
-
-When developing canisters and projects, it is recommended to first deploy your project to the local development environment. This is so you can fabricate cycles in your local development environment, which you cannot do on the mainnet. Cycles are charged for the resources used by your canister. [Learn more about cycles](/docs/current/developer-docs/gas-cost).
-
-Deploying to your local development environment is similar to deploying to a testnet. ICP does not have a testnet available for developers to deploy to. Instead, the IC SDK runs a local version of the ICP node software known as the **replica** and provides a single-node environment on your local machine for you to deploy canisters to.
-
-## Prerequisites
-
-Before you create your first canister, verify the following:
-
-- [x] You have an internet connection and access to a shell terminal on your local computer.
-
-- [x] You have `Node.js` `16.0.0` or newer installed if you want to include the default template files for frontend development in your project.
-
-- [x] You have downloaded and installed the IC SDK package as described in the [installing the IC SDK](/docs/current/developer-docs/getting-started/install/) page.
-
-## Start the local deployment
-
-Before you can build your first project, you need to connect to the local replica. As a best practice, this step requires you to have **two terminal shells** open, so that you can start and see canister execution operations in one terminal and manage your project in another.
-
-To prepare the local replica:
-
-- #### Step 1: Open a new second terminal window or tab on your local computer.
-
-- #### Step 2: Navigate to the root directory for your project, if necessary.
-
-You should now have **two terminals** open with your **project directory** as your **current working directory** in both terminals.
-
-- #### Step 3: Start the local replica on your computer in your second terminal by running the following command:
-
-```
-dfx start
-```
-
-Depending on your platform and local security settings, you might see a warning displayed. If you are prompted to allow or deny incoming network connections, click **Allow**.
-
-- #### Step 4: Leave the terminal window that displays canister execution operations open and switch your focus to the first terminal window where you created your new project.
-
-You should perform the remaining steps in the terminal that doesn’t display canister execution operations.
-
-## Register, build, and deploy the application
-
-After you connect to the local canister execution environment, you can register, build, and deploy your dapp locally.
-
-To deploy your first canister locally:
-
-- #### Step 1: Check that you are still in the root directory for your project, if needed.
-
-It is recommended to follow the [creating your first canister](/docs/current/developer-docs/getting-started/default-template) guide to have a simple 'Hello, world!' canister ready to deploy.
-
-- #### Step 2: Ensure that `node` modules are available in your project directory, if needed, by running the following command:
-
-```
-npm install
-```
-
-For more information about this step, see [ensuring node is available in a project](/docs/current/developer-docs/getting-started/install/#nodejs-is-not-properly-installed).
-
-- #### Step 3: Register, build, and deploy your first dapp by running the following command:
-
-```
-dfx deploy
-```
-
-The `dfx deploy` command output displays information about the operations it performs. For example, this step registers two identifiers. One is for the `hello_backend` main program, and the other is for the `hello_frontend` frontend user interface and installation information similar to the following:
-
-```
-Creating a wallet canister on the local network.
-The wallet canister on the "local" network for user "mainnet" is "rwlgt-iiaaa-aaaaa-aaaaa-cai"
-Deploying all canisters.
-Creating canisters...
-Creating canister hello_backend...
-hello_backend canister created with canister id: rrkah-fqaaa-aaaaa-aaaaq-cai
-Creating canister hello_frontend...
-hello_frontend canister created with canister id: ryjl3-tyaaa-aaaaa-aaaba-cai
-Building canisters...
-Building frontend...
-Installing canisters...
-Creating UI canister on the local network.
-The UI canister on the "local" network is "r7inp-6aaaa-aaaaa-aaabq-cai"
-Installing code for canister hello_backend, with canister ID rrkah-fqaaa-aaaaa-aaaaq-cai
-Installing code for canister hello_frontend, with canister ID ryjl3-tyaaa-aaaaa-aaaba-cai
-Uploading assets to asset canister...
-Starting batch.
-Staging contents of new and changed assets:
- /sample-asset.txt 1/1 (24 bytes)
- /logo2.svg 1/1 (15139 bytes)
- /index.js.map 1/1 (681670 bytes)
- /index.js.map (gzip) 1/1 (156940 bytes)
- /favicon.ico 1/1 (15406 bytes)
- /main.css 1/1 (537 bytes)
- /main.css (gzip) 1/1 (297 bytes)
- /index.html 1/1 (690 bytes)
- /index.html (gzip) 1/1 (386 bytes)
- /index.js (gzip) 1/1 (152884 bytes)
- /index.js 1/1 (637230 bytes)
-Committing batch.
-Deployed canisters.
-URLs:
- Frontend canister via browser
- hello_frontend: http://127.0.0.1:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai
- Backend canister via Candid interface:
- hello_backend: http://127.0.0.1:4943/?canisterId=r7inp-6aaaa-aaaaa-aaabq-cai&id=rrkah-fqaaa-aaaaa-aaaaq-cai
-```
-
-If you create a project with a different name, however, your canister names will match your project name instead of `hello_backend` and `hello_frontend`.
-
-## Call the canister from the CLI
-
-Call the `hello_backend` canister and the predefined `greet` function by running the following command:
-
-```
-dfx canister call hello_backend greet everyone
-```
-
-Let’s take a closer look at this example command:
-
-- The `dfx canister call` command requires you to specify a canister name and a method or function to call.
-
-- `hello_backend` specifies the name of the **canister** you want to call.
-
-- `greet` specifies the name of the **function** you want to call in the `hello` canister.
-
-- `everyone` is the text data type argument that you want to pass to the `greet` function.
-
-Remember, however, that if you create a project with a different name, the canister name will match your project name, and you’ll need to modify the command line to match the name you used instead of `hello_backend`. If you were to choose `test` as the project name, your backend canister would be called `test_backend` and the frontend canister `test_frontend`.
-
-Verify the command displays the return value of the `greet` function. For example:
-
-```
-("Hello, everyone!")
-```
-
-## Call the canister from the browser
-
-It is possible to access the frontend canister directly from the browser. You will need to navigate to the URL that was printed in the output of the `dfx deploy` command (your URL might differ):
-
-```
-Frontend canister via browser
- hello_frontend: http://127.0.0.1:4943/?canisterId=bd3sg-teaaa-aaaaa-qaaba-cai
-```
-
-This will render a webpage with a form that accepts a string and sends it to the backend canister.
-
-The source code of the webpage is defined in the `src/hello_frontend/src/index.{html,js}` files.
-
-```html title="src/hello_frontend/src/index.html"
-
-
-
-
-
- hello
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-```javascript title="src/hello_frontend/src/index.js"
-import { hello_backend } from "../../declarations/hello_backend";
-
-document.querySelector("form").addEventListener("submit", async (e) => {
- e.preventDefault();
- const button = e.target.querySelector("button");
-
- const name = document.getElementById("name").value.toString();
-
- button.setAttribute("disabled", true);
-
- // Interact with foo actor, calling the greet method
- const greeting = await hello_backend.greet(name);
-
- button.removeAttribute("disabled");
-
- document.getElementById("greeting").innerText = greeting;
-
- return false;
-});
-```
-
-The JavaScript code running in the browser uses the [ICP JavaScript agent](/docs/current/developer-docs/developer-tools/off-chain/agents/javascript-agent) library to interact with the backend canister. The library creates a wrapper JavaScript object based on the interface of the canister. That wrapper object provides convenience methods for calling the canister functions as if they were JavaScript functions:
-
-```
-const greeting = await hello_backend.greet(name);
-```
-
-## Stop the local canister execution environment
-
-After testing the application in the browser, you can stop the local canister execution environment so that it doesn’t continue running in the background.
-
-To stop the local deployment:
-
-- #### Step 1: In the terminal that displays the development server, press Control-C to interrupt the development server process.
-
-- #### Step 2: In the terminal that displays canister execution operations, press Control-C to interrupt the local network process.
-
-- #### Step 3: Stop the local replica running on your local computer by running the following command:
-
-```
-dfx stop
-```
-
-## Next steps
-
-Next, you can deploy your canister on the playground.
-
-- [Testnet deployment](/docs/current/developer-docs/getting-started/deploy/testnet)
\ No newline at end of file
diff --git a/docs/developer-docs/getting-started/deploy/mainnet.mdx b/docs/developer-docs/getting-started/deploy/mainnet.mdx
deleted file mode 100644
index 00af98dab0..0000000000
--- a/docs/developer-docs/getting-started/deploy/mainnet.mdx
+++ /dev/null
@@ -1,186 +0,0 @@
----
-keywords: [beginner, tutorial, mainnet deployment, deploy]
----
-
-import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-
-
-# Mainnet deployment
-
-
-
-## Overview
-
-To make your canister available to others, you must deploy it to the mainnet.
-
-If you are only deploying projects in a local development environment, see the [local development](/docs/current/developer-docs/getting-started/deploy/local) scenario.
-
-## Prerequisites
-
-Before you download and install this release of the IC SDK, verify the following:
-
-- [x] You have an internet connection and access to a shell terminal on your local computer.
-
-- [x] You have `Node.js` `16.0.0` or newer installed if you want to access the default frontend for the default project.
-
-- [x] You have ICP tokens or cycles available for you to use.
-
-:::info
-You must have **cycles** available to complete this guide. To get cycles, you must either convert ICP tokens to cycles or be provided cycles from another source, for example, from a canister controlled by another developer or from a third-party cycles provider. This guide assumes that you have an account with ICP tokens available and illustrates how to convert ICP tokens into cycles.
-
-For information about how to get ICP tokens, see [how you can get ICP tokens](/docs/current/developer-docs/defi/cycles/converting_icp_tokens_into_cycles).
-
-For an introduction to using the Network Nervous System application to manage ICP tokens, see [Network Nervous System dapp quickstart](/docs/current/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart).
-:::
-
-## Check the connection to the mainnet
-
-There is a reserved network alias that you can use to access the mainnet. The network alias is a system setting that’s defined internally, so there’s nothing you need to configure in your projects by default.
-
-To check your connection to ICP:
-
-- #### Step 1: Check that you are in the root directory for your project, if needed.
-
-- #### Step 2: Check the current status of ICP and your ability to connect to it by running the following command for the network alias `ic`:
-
-```
-dfx ping ic
-```
-
-- #### Step 3: Verify that the `dfx ping ic` command returns information about ICP.
-
- For example, you should see output similar to the following:
-```
-{
- "ic_api_version": "0.18.0" "impl_hash": "d639545e0f38e075ad240fd4ec45d4eeeb11e1f67a52cdd449cd664d825e7fec" "impl_version": "8dc1a28b4fb9605558c03121811c9af9701a6142" "replica_health_status": "healthy" "root_key": [48, 129, 130, 48, 29, 6, 13, 43, 6, 1, 4, 1, 130, 220, 124, 5, 3, 1, 2, 1, 6, 12, 43, 6, 1, 4, 1, 130, 220, 124, 5, 3, 2, 1, 3, 97, 0, 129, 76, 14, 110, 199, 31, 171, 88, 59, 8, 189, 129, 55, 60, 37, 92, 60, 55, 27, 46, 132, 134, 60, 152, 164, 241, 224, 139, 116, 35, 93, 20, 251, 93, 156, 12, 213, 70, 217, 104, 95, 145, 58, 12, 11, 44, 197, 52, 21, 131, 191, 75, 67, 146, 228, 103, 219, 150, 214, 91, 155, 180, 203, 113, 113, 18, 248, 71, 46, 13, 90, 77, 20, 80, 95, 253, 116, 132, 176, 18, 145, 9, 28, 95, 135, 185, 136, 131, 70, 63, 152, 9, 26, 11, 170, 174]
-}
-```
-
-## Register, build, and deploy the application
-
-After you have a [cycles balance](/docs/current/developer-docs/getting-started/tokens-and-cycles), you can register, build, and deploy your sample application.
-
-To deploy your first application on the mainnet:
-
-- #### Step 1: In your terminal shell, check that you are still in the root directory for your project.
-
-- #### Step 2: Ensure that `node` modules are available in your project directory, if needed, by running the following command:
-
-```
-npm install
-```
-
-For more information about this step, see [ensuring node is available in a project](/docs/current/developer-docs/getting-started/install).
-
-- #### Step 3: Register, build, and deploy your first application by running the following command:
-
-```
-dfx deploy --network ic
-```
-
-The `--network` option specifies the network alias or URL for deploying the dapp. This option is required to deploy your canister on the mainnet.
-
-The `dfx deploy` command output displays information about the operations it performs.
-
-For example, this step registers two identifiers—one for the `hello_backend` main program and one for the `hello_frontend` frontend user interface—and installation information similar to the following:
-
-```
-Deploying all canisters.
-Creating canisters...
-Creating canister "hello_backend"...
-"hello" canister created on network "ic" with canister id: "5o6tz-saaaa-aaaaa-qaacq-cai"
-Creating canister "hello_frontend"...
-"hello_assets" canister created on network "ic" with canister id: "5h5yf-eiaaa-aaaaa-qaada-cai"
-Building canisters...
-Building frontend...
-Installing canisters...
-Installing code for canister hello_backend, with canister_id 5o6tz-saaaa-aaaaa-qaacq-cai
-Installing code for canister hello_frontend, with canister_id 5h5yf-eiaaa-aaaaa-qaada-cai
-Authorizing our identity (default) to the asset canister...
-Uploading assets to asset canister...
- /index.html 1/1 (472 bytes)
- /index.html (gzip) 1/1 (314 bytes)
- /index.js 1/1 (260215 bytes)
- /index.js (gzip) 1/1 (87776 bytes)
- /main.css 1/1 (484 bytes)
- /main.css (gzip) 1/1 (263 bytes)
- /sample-asset.txt 1/1 (24 bytes)
- /logo.png 1/1 (25397 bytes)
- /index.js.map 1/1 (842511 bytes)
- /index.js.map (gzip) 1/1 (228404 bytes)
- /index.js.LICENSE.txt 1/1 (499 bytes)
- /index.js.LICENSE.txt (gzip) 1/1 (285 bytes)
-Deployed canisters.
-```
-
-If you didn’t convert enough ICP tokens to cycles to complete the operation, you can add cycles to your balance by running a command similar to the following:
-
-```
-dfx cycles convert 1.005 --network ic
-```
-
-This command converts an additional `1.005` ICP tokens to cycles. The command returns output similar to the following:
-
-```
-Transfer sent at BlockHeight: 81520
-Canister was topped up!
-```
-
-- #### Step 4: Call the `hello_backend` canister and the predefined `greet` function by running the following command:
-
-```
-dfx canister --network ic call hello_backend greet '("everyone": text)'
-```
-
-Let’s take a closer look at this example:
-
-- Using the `--network ic` option indicates that the canister you want to call is deployed on the `ic`. The `ic` network alias is an internally-reserved alias for accessing the Internet Computer blockchain mainnet.
-
-- Note that the `--network ic` option must precede the operation subcommand, which, in this case, is the `dfx canister call` command.
-
-- The `hello_backend` argument specifies the name of the canister you want to call.
-
-- The `greet` argument specifies the name of the function you want to call in the `hello` canister.
-
-- The text string `everyone` is the argument that you want to pass to the `greet` function.
-
-- #### Step 5: Verify the command displays the return value of the `greet` function. For example:
-
-```
-("Hello, everyone!")
-```
-
-- #### Step 6: Rerun the `dfx cycles balance --network ic` command or refresh the browser to see your new cycle balance and recent activity.
-
-## Test the dapp frontend
-
-Now that you have verified that your dapp has been deployed and tested its operation using the command line, let’s verify that you can access the frontend using your web browser.
-
-To access the dapp frontend:
-
-- #### Step 1: Open a browser.
-
-- #### Step 2: Navigate to the frontend for the dapp using a URL that consists of the `hello_frontend` identifier and the `boundary.icp0.io` suffix.
-
-If you didn’t make a note of the canister identifier, you can look it up by running the following command:
-
-```
-dfx canister --network ic id hello_assets
-```
-
-For example, the full URL should look similar to the following:
-
-```
-https://gsueu-yaaaa-aaaae-aaagq-cai.icp0.io
-```
-
-Navigating to this URL displays the HTML entry page for the template application. For example:
-
-
-
-- #### Step 3: Type a greeting, then click **Click Me** to return the greeting.
-
-## Next steps
-
-Want to go further? [Start the developer journey series](/docs/current/tutorials/developer-journey/).
diff --git a/docs/developer-docs/getting-started/deploy/testnet.mdx b/docs/developer-docs/getting-started/deploy/testnet.mdx
deleted file mode 100644
index 7a312f4306..0000000000
--- a/docs/developer-docs/getting-started/deploy/testnet.mdx
+++ /dev/null
@@ -1,83 +0,0 @@
----
-keywords: [beginner, tutorial, testnet, testnet deployment, deploy]
----
-
-import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-
-
-# Testnet deployment
-
-
-
-## Overview
-
-In contrast to other blockchain networks, ICP does not have a testnet network where smart contract developers can deploy their projects to test functionality.
-
-This is because canister smart contracts can be upgraded and changed once they have been deployed on the mainnet, and mainnet deployment is fairly cheap.
-
-For developers who are looking for a testnet environment, however, ICP offers the [playground](https://m7sm4-2iaaa-aaaab-qabra-cai.ic0.app/) that allows for simple, small-scale, temporary testing for free. It can be used to build and deploy canisters directly in the [web browser](/docs/current/developer-docs/developer-tools/ide/playground), or it can be utilized through the `dfx deploy --playground` command via the CLI.
-
-Canisters deployed to the playground use resources that are borrowed from a canister pool. Each canister has an initial amount of 0.5T cycles that it receives from the resource pool and can be used for 20 minutes once the canister has been deployed. Note that there are function [limitations and restrictions](/docs/current/developer-docs/smart-contracts/deploy/custom-testnets) imposed on canisters deployed to the playground.
-
-For advanced developers and use cases, there are [custom testnet options](/docs/current/developer-docs/smart-contracts/deploy/custom-testnets).
-
-## Deploying to the playground
-
-Through `dfx`, canisters can be deployed directly from the CLI to the playground using the `--playground` flag. When this flag is used, the specified canister is deployed to the playground canister pool, and a canister URL will be returned to the developer. If no canister is specified, all canisters within the project's `dfx.json` file will be deployed to the playground.
-
-This workflow enables developers to test canister functionality without needing to obtain cycles or configure other parameters that are required for deployment to the mainnet.
-
-### Prerequisites
-
-Before you start, verify the following:
-
-- [x] You have an internet connection and access to a shell terminal on your local macOS or Linux computer.
-
-- [x] You have a command line interface (CLI) window open. This window is also referred to as the 'terminal' window.
-
-- [x] You have downloaded and installed the IC SDK package as described in the [installing the IC SDK](/docs/current/developer-docs/getting-started/install/) page.
-
-:::info
-`dfx deploy --playground` is available in `dfx` versions v0.15.1 and above.
-:::
-
-To deploy a canister to the playground, first create a new `dfx` project with the command:
-
-```
-dfx new hello_world
-```
-
-This command will create a new default `dfx` project that contains a simple 'Hello, world!' sample that includes a `hello_world_backend` canister with a predefined `greet` function.
-
-Then, to deploy this canister to the playground, run the command:
-
-```
-dfx deploy hello_world_backend --playground
-```
-
-Once deployed, the canister can be interacted with using a command such as:
-
-```
-dfx canister call hello_world_backend greet '("everyone")' --network playground
-```
-
-This command calls the `hello_world_backend` canister that has been deployed to the playground using the `--network` flag since the playground is classified as a deployment network.
-
-:::info
-Any commands that intend to target a canister deployed to the playground must use the `--playground` or `--network playground` flag in order to target the borrowed canister(s).
-:::
-
-Verify the command displays the return value of the `greet` function.
-
-For example:
-
-```
-("Hello, everyone!")
-```
-
-## Next steps
-
-Next, you can deploy your canister on the mainnet.
-
-- [Mainnet deployment](/docs/current/developer-docs/getting-started/deploy/mainnet)
\ No newline at end of file
diff --git a/docs/developer-docs/getting-started/explore-examples.mdx b/docs/developer-docs/getting-started/explore-examples.mdx
index 09b7a23b46..7bb6f0b9e8 100644
--- a/docs/developer-docs/getting-started/explore-examples.mdx
+++ b/docs/developer-docs/getting-started/explore-examples.mdx
@@ -11,8 +11,6 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
-
[ICP Ninja](https://icp.ninja) is a web-based integrated development environment (IDE) for creating and deploying decentralized applications (dapps) on the Internet Computer (ICP).
ICP Ninja provides a gallery of example projects you can explore to learn about different application types, architectures, and use cases. Example projects can be edited and then deployed to ICP directly from your web browser. Once deployed, you can open the application's frontend in your browser, share the public link to your new onchain dapp, or make calls directly to the backend through the [Candid UI](/docs/current/developer-docs/smart-contracts/candid/candid-concepts).
@@ -25,7 +23,6 @@ ICP Ninja serves as an introduction to developing on ICP and learning about:
- ICP's unique features, such as [randomness](/docs/current/developer-docs/smart-contracts/advanced-features/randomness), [timers](/docs/current/developer-docs/smart-contracts/advanced-features/periodic-tasks), and [HTTPS outcalls](/docs/current/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-overview).
-
:::info
Want to skip directly to using CLI tools in a local dev environment? [Get started with the IC SDK](/docs/current/developer-docs/getting-started/install).
@@ -91,4 +88,4 @@ Once you are ready to either deploy your ICP Ninja project longer than the tempo
- [x] Download the ICP Ninja project files by selecting the dropdown menu next to the "Deploy" button, then select "Download files." **If you want to start a new project instead, you can skip this step.**
-- [x] [Install tools.](/docs/current/developer-docs/getting-started/install)
+- [x] [Installing developer tools.](/docs/current/developer-docs/getting-started/install)
diff --git a/docs/developer-docs/getting-started/identities.mdx b/docs/developer-docs/getting-started/identities.mdx
index 725a6ba051..15a9040b3a 100644
--- a/docs/developer-docs/getting-started/identities.mdx
+++ b/docs/developer-docs/getting-started/identities.mdx
@@ -5,12 +5,10 @@ keywords: [beginner, getting started, tutorial, accounts, developer account]
import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-# Create a developer identity
+# Creating a developer identity
-## Overview
-
On the Internet Computer (ICP), a developer **identity** is essential to developing canisters. Developer identities use a private/public key pair for authentication. The public key can be distributed openly as it will be used to encrypt messages. The private key must be kept secret and stored securely.
Developer identities have a **principal**, a generic identifier value used to identify users, canisters, and potentially other entities on the network in the future. Each developer identity's principal value is derived from the identity's public key.
@@ -41,8 +39,6 @@ Developer identities are not the only form of identity on ICP. Other ICP identit
:::
-## Creating your identity
-
By default, `dfx` will create and use the `default` identity. ***This identity is not stored securely. It is recommended you create your own personal identity.***
First, use `dfx` to list all current identities. If none exist, it will automatically create the `default` identity.
@@ -77,7 +73,7 @@ Identity names must use the characters `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmn
To recover an identity, use `dfx identity import --seed-file seedphrase.txt`, where `seedphrase.txt` contains the seed phrase shown when you created your identity.
:::
-### Storing the identity's private key
+### Storing the developer identity's private key
The private key for an identity is stored in the `~/.config/dfx/identity/IDENTITY_NAME/identity.pem`. ***This file should be backed up to a secure location.***
@@ -85,7 +81,7 @@ The private key for an identity is stored in the `~/.config/dfx/identity/IDENTIT
By default, `dfx` will store your identity in the local keyring/keychain. If a keyring/keychain is unavailable, it will prompt you to choose a password, then store your private key locally in a password-protected PEM file at `~/.config/dfx/identity/IDENTITY_NAME/identity.pem.encrypted`.
:::
-## Using your identity
+## Using your developer identity
Once your identity is created, you must tell `dfx` that this is the identity you want to use. If you do not, the `default` identity will be used, and any canister creation and management you execute will not be secure.
@@ -125,4 +121,4 @@ aez2y-7yvs5-e6dpq-gwlld-t6ozx-l5hoo-j4vwr-mimoy-me2xq-yrxkx-rae
Next, you must obtain cycles. Cycles are required to pay for the resources a canister consumes.
-- [x] [Tokens and cycles](/docs/current/developer-docs/getting-started/tokens-and-cycles)
+- [x] [Using tokens and cycles](/docs/current/developer-docs/getting-started/tokens-and-cycles)
diff --git a/docs/developer-docs/getting-started/install.mdx b/docs/developer-docs/getting-started/install.mdx
index ce5bc0a57f..920558e46e 100644
--- a/docs/developer-docs/getting-started/install.mdx
+++ b/docs/developer-docs/getting-started/install.mdx
@@ -7,12 +7,10 @@ import { AdornedTabs } from "/src/components/Tabs/AdornedTabs";
import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-# Install tools
+# Installing developer tools
-## Overview
-
The IC SDK is a software development kit used to develop and deploy applications on the Internet Computer (ICP) from a local developer environment. It is comprised of several tools.
## Installing the IC SDK
@@ -86,6 +84,8 @@ dfx --version
#### Prerequisites
+`dfx` is not natively supported on Windows. You will need to install a Linux instance via Windows Subsystem for Linux and run all commands within that Linux instance.
+
Download and install Windows Subsystem for Linux.
@@ -142,4 +142,4 @@ For troubleshooting common `dfx` errors, see [IC SDK troubleshooting](troublesho
Next, you must create a developer identity. This identity will be used to control and manage your project's canisters.
-- [x] [Create a developer identity](/docs/current/developer-docs/getting-started/identities).
+- [x] [Creating a developer identity](/docs/current/developer-docs/getting-started/identities).
diff --git a/docs/developer-docs/getting-started/next-steps.mdx b/docs/developer-docs/getting-started/next-steps.mdx
deleted file mode 100644
index fb87240ab7..0000000000
--- a/docs/developer-docs/getting-started/next-steps.mdx
+++ /dev/null
@@ -1,20 +0,0 @@
----
-keywords: [beginner, getting started, user journeys, developer paths, features, application types]
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-import NextSteps from "@site/src/components/Card/NextSteps";
-
-# Next steps
-
-
-
-Continue building with these suggested next steps.
-
-
-
-
-
-
diff --git a/docs/developer-docs/getting-started/quickstart/first-smart-contract.mdx b/docs/developer-docs/getting-started/quickstart/first-smart-contract.mdx
index de2e03f105..1b9c9f8e6f 100644
--- a/docs/developer-docs/getting-started/quickstart/first-smart-contract.mdx
+++ b/docs/developer-docs/getting-started/quickstart/first-smart-contract.mdx
@@ -7,7 +7,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
import TabItem from "@theme/TabItem";
import { OsType, useOs } from "/src/hooks/useOs";
-# Quick start
+# First smart contract
@@ -111,10 +111,21 @@ project.
#### Prerequisites
+`dfx` is not natively supported on Windows. You will need to install a Linux instance via Windows Subsystem for Linux and run all commands within that Linux instance.
+
Download and install Windows Subsystem for Linux.
- Download and install Node.js within your WSL environment.
+ Open a WSL terminal window.
+
+
+ Download and install a Linux distribution (i.e., Ubuntu) using Windows Subsystem for Linux: wsl --install -d ubuntu
+
+
+ Open the WSL Linux environment. Run all following commands within this environment.
+
+
+ Download and install Node.js within your WSL Linux environment.
---------
diff --git a/docs/developer-docs/getting-started/quickstart/react-quickstart.mdx b/docs/developer-docs/getting-started/quickstart/react-quickstart.mdx
index 9926b2d3a5..69ff57bcd1 100644
--- a/docs/developer-docs/getting-started/quickstart/react-quickstart.mdx
+++ b/docs/developer-docs/getting-started/quickstart/react-quickstart.mdx
@@ -7,7 +7,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
import TabItem from "@theme/TabItem";
import { AdornedTabs } from "/src/components/Tabs/AdornedTabs";
-# React quick start
+# First web app
@@ -66,10 +66,21 @@ dfx --version
#### Prerequisites
+`dfx` is not natively supported on Windows. You will need to install a Linux instance via Windows Subsystem for Linux and run all commands within that Linux instance.
+
Download and install Windows Subsystem for Linux.
- Download and install Node.js within your WSL environment.
+ Open a WSL terminal window.
+
+
+ Download and install a Linux distribution (i.e., Ubuntu) using Windows Subsystem for Linux: wsl --install -d ubuntu
+
+
+ Open the WSL Linux environment. Run all following commands within this environment.
+
+
+ Download and install Node.js within your WSL Linux environment.
---------
@@ -118,4 +129,4 @@ dfx deploy --playground
Open the `frontend` URL in a web browser. You'll see the template React frontend interface.
-*Congratulations, you just created your first internet-native React dapp!*
\ No newline at end of file
+*Congratulations, you just created your first internet-native React app!*
diff --git a/docs/developer-docs/getting-started/tokens-and-cycles.mdx b/docs/developer-docs/getting-started/tokens-and-cycles.mdx
index e773172e10..df76bc0aee 100644
--- a/docs/developer-docs/getting-started/tokens-and-cycles.mdx
+++ b/docs/developer-docs/getting-started/tokens-and-cycles.mdx
@@ -7,12 +7,10 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
import TabItem from "@theme/TabItem";
import { AdornedTabs } from "/src/components/Tabs/AdornedTabs";
-# Tokens and cycles
+# Using tokens and cycles
-## Overview
-
On the Internet Computer, there are three types of token assets: ICP tokens, cycles, and ICRC tokens. ICP and cycles are the most important for every developer to understand and use, as they are necessary for deploying and maintaining a canister.
ICP tokens are important because they can be converted into cycles and used to pay for a canister's resource consumption. Cycles reflect the real cost of operations for resources such as physical hardware, rack space, energy, storage devices, and bandwidth.
@@ -85,7 +83,7 @@ b0d7beee54be8679a42e999218a16a0d396f223d7e44d259ac089848c1b820bf
You can obtain [ICP tokens](https://internetcomputer.org/icp-tokens) from an [exchange](https://coinmarketcap.com/currencies/internet-computer/markets) or through a [developer grant](https://dfinity.org/grants). If you are using an exchange, initiate a withdrawal transaction, then enter the ledger account ID as the "destination" address to send ICP tokens to.
-### 3. Check the balance.
+### 3. Check the ICP balance.
```
dfx ledger balance --network=ic
@@ -135,7 +133,7 @@ The amount of cycles that your canister will use depends on a variety of factors
:::
-### 5. Confirm the balance.
+### 5. Confirm the cycles balance.
```
dfx cycles balance --network=ic
@@ -154,4 +152,4 @@ dfx cycles balance --network=ic
Next, it's time to write the code for a smart contract.
-- [x] [Write smart contracts](/docs/current/developer-docs/getting-started/write-smart-contracts).
+- [x] [Writing smart contracts](/docs/current/developer-docs/getting-started/write-smart-contracts).
diff --git a/docs/developer-docs/getting-started/troubleshooting.mdx b/docs/developer-docs/getting-started/troubleshooting.mdx
index 06197041f5..773c5d7d9b 100644
--- a/docs/developer-docs/getting-started/troubleshooting.mdx
+++ b/docs/developer-docs/getting-started/troubleshooting.mdx
@@ -8,8 +8,6 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
-
This section provides information to help you troubleshoot and resolve or work around common issues that are related to the following tasks:
- Downloading and installing the IC SDK.
diff --git a/docs/developer-docs/getting-started/write-smart-contracts.mdx b/docs/developer-docs/getting-started/write-smart-contracts.mdx
index 2f166120ae..593fa82ddf 100644
--- a/docs/developer-docs/getting-started/write-smart-contracts.mdx
+++ b/docs/developer-docs/getting-started/write-smart-contracts.mdx
@@ -10,12 +10,10 @@ import { BetaChip } from "/src/components/Chip/BetaChip";
import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-# Write smart contracts
+# Writing smart contracts
-## Overview
-
Canisters are an enhanced type of smart contract. Before a canister is deployed to ICP, the canister's code is compiled into a WebAssembly (Wasm) program, enabling it to store persistent data, be managed by entities such as DAOs, host entire applications, and more. Each canister has the following components:
@@ -121,7 +119,7 @@ The `frontend` canister stores the app's frontend assets, including files such a
/>
-## Writing code
+## Writing canister code
:::danger
@@ -292,14 +290,14 @@ fn get_current_number() -> Nat {
}>
-Azle code coming soon.
+
[Learn more about Azle](https://demergent-labs.github.io/azle/).
}>
-Kybra code coming soon.
+
[Learn more about Kybra](https://demergent-labs.github.io/kybra/).
@@ -413,21 +411,17 @@ fn get_current_number() -> Nat {
}>
-Azle code coming soon.
-
[Learn more about Azle](https://demergent-labs.github.io/azle/).
}>
-Kybra code coming soon.
-
[Learn more about Kybra](https://demergent-labs.github.io/kybra/).
-### 4. Retrieve data.
+### 4. Retrieve external data.
HTTPS outcalls can obtain data from any external source, including other blockchains, traditional Web2 APIs, and other web services. When HTTPS outcalls are used locally, the returned result is not validated since the local replica is only a single node. HTTPS outcalls used on the mainnet validate the returned result through the subnet's consensus, providing security that the data obtained has not been maliciously tampered with during transport.
@@ -676,14 +670,12 @@ fn transform(raw: TransformArgs) -> HttpResponse {
}>
-Azle code coming soon.
-
[Learn more about Azle](https://demergent-labs.github.io/azle/).
}>
-Kybra code coming soon.
+
[Learn more about Kybra](https://demergent-labs.github.io/kybra/).
@@ -898,15 +890,13 @@ fn print_results() {
}>
-Azle code coming soon.
-
[Learn more about Azle](https://demergent-labs.github.io/azle/).
+
}>
-Kybra code coming soon.
-
[Learn more about Kybra](https://demergent-labs.github.io/kybra/).
+
@@ -914,4 +904,4 @@ Kybra code coming soon.
Now that you have written the canister's code, the canister needs to be deployed.
-- [x] [Deploy and manage](/docs/current/developer-docs/getting-started/deploy-and-manage).
+- [x] [Deploying and managing dapps](/docs/current/developer-docs/getting-started/deploy-and-manage).
diff --git a/docs/developer-docs/getting-started/wsl-troubleshoot.mdx b/docs/developer-docs/getting-started/wsl-troubleshoot.mdx
index 4786d2f228..484512fef5 100644
--- a/docs/developer-docs/getting-started/wsl-troubleshoot.mdx
+++ b/docs/developer-docs/getting-started/wsl-troubleshoot.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The IC SDK is not natively supported on Windows operating systems. It is recommended for Windows users to install [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/install).
diff --git a/docs/developer-docs/identity/internet-identity/alternative-origins.mdx b/docs/developer-docs/identity/internet-identity/alternative-origins.mdx
index b509a15e4e..d65c18179c 100644
--- a/docs/developer-docs/identity/internet-identity/alternative-origins.mdx
+++ b/docs/developer-docs/identity/internet-identity/alternative-origins.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
If your application has reached the stage where you want to change domain names, and you have been authenticating with Internet Identity (II), you will want to make sure that your users can seamlessly keep the same principals they have already been using. To support this functionality, you can configure your application for alternative frontend origins using this guide.
![End Result](../_attachments/alternative-origins.png)
diff --git a/docs/developer-docs/identity/internet-identity/creating-ii.mdx b/docs/developer-docs/identity/internet-identity/creating-ii.mdx
index 51a3b96873..69f45747bc 100644
--- a/docs/developer-docs/identity/internet-identity/creating-ii.mdx
+++ b/docs/developer-docs/identity/internet-identity/creating-ii.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This guide walks through how to create an Internet Identity. Internet Identity is ICP's native form of identity. It is used by many dapps build on ICP for users to authenticate with.
diff --git a/docs/developer-docs/identity/internet-identity/integrate-internet-identity.mdx b/docs/developer-docs/identity/internet-identity/integrate-internet-identity.mdx
index 7285aa8a50..607c449197 100644
--- a/docs/developer-docs/identity/internet-identity/integrate-internet-identity.mdx
+++ b/docs/developer-docs/identity/internet-identity/integrate-internet-identity.mdx
@@ -12,7 +12,7 @@ import { BetaChip } from "/src/components/Chip/BetaChip";
-## Overview
+
This guide shows an example of how to integrate Internet Identity into an application by using a simple 'Who am I?' backend canister and a frontend UI that returns the Internet Identity principal of the user who calls the backend's `whoami` method.
This project uses the **pullable** version of the Internet identity canister. A pullable canister is a canister that provides a public service at a static canister ID. To learn more about pullable canisters, please [see the documentation](/docs/current/developer-docs/smart-contracts/maintain/import).
diff --git a/docs/developer-docs/identity/verifiable-credentials/how-it-works.mdx b/docs/developer-docs/identity/verifiable-credentials/how-it-works.mdx
index 1f0685e2e4..fb63d4542c 100644
--- a/docs/developer-docs/identity/verifiable-credentials/how-it-works.mdx
+++ b/docs/developer-docs/identity/verifiable-credentials/how-it-works.mdx
@@ -9,7 +9,7 @@ import useBaseUrl from "@docusaurus/useBaseUrl";
-## Overview
+
Verifiable credentials (VCs) on ICP rely on Internet Identity (II), which provides distinct identities that preserve unlinkability for each dapp. A dapp utilizing verifiable credentials can’t ask for a user's credentials from the [issuer](/docs/current/developer-docs/identity/verifiable-credentials/overview#terminology) of the verifiable credential directly. When a [relying party](/docs/current/developer-docs/identity/verifiable-credentials/overview#terminology) wants to obtain a credential from an issuer, it must request it through an [identity provider](/docs/current/developer-docs/identity/verifiable-credentials/overview#terminology) such as Internet Identity.
diff --git a/docs/developer-docs/identity/verifiable-credentials/issuer.mdx b/docs/developer-docs/identity/verifiable-credentials/issuer.mdx
index 6fd309f1e1..b3438db61d 100644
--- a/docs/developer-docs/identity/verifiable-credentials/issuer.mdx
+++ b/docs/developer-docs/identity/verifiable-credentials/issuer.mdx
@@ -9,7 +9,7 @@ import useBaseUrl from "@docusaurus/useBaseUrl";
-## Overview
+
An **issuer** is a service or app that can issue a verifiable credential (VC) to a user. On ICP, an issuer is an exposed API that receives calls from an identity provider and does not trigger any workflows itself. To become an issuer, your canister must implement the issuer API as described in the [verifiable credential spec](https://github.com/dfinity/internet-identity/blob/main/docs/vc-spec.md).
diff --git a/docs/developer-docs/identity/verifiable-credentials/relying-party.mdx b/docs/developer-docs/identity/verifiable-credentials/relying-party.mdx
index e48577c4ef..ccd5dede44 100644
--- a/docs/developer-docs/identity/verifiable-credentials/relying-party.mdx
+++ b/docs/developer-docs/identity/verifiable-credentials/relying-party.mdx
@@ -9,7 +9,7 @@ import useBaseUrl from "@docusaurus/useBaseUrl";
-## Overview
+
A **relying party** is a service or app that requests a user's verifiable credentials from an [issuer](issuer.mdx). Relying parties use an **identity provider**, such as Internet Identity, to communicate with the issuer. Identity providers must support the [verifiable credentials specification](https://github.com/dfinity/internet-identity/blob/main/docs/vc-spec.md). Communication with the identity provider uses the [`window.postMessage()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) communication channel.
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/btc-comparison.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/btc-comparison.mdx
index b2df1912b3..9b87508081 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/btc-comparison.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/btc-comparison.mdx
@@ -7,7 +7,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This guide is designed to help Bitcoin developers understand the core concepts of ICP in order to properly use ICP as a Layer-2 solution for Bitcoin.
## Terminology mapping
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/btc-dev-workflow.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/btc-dev-workflow.mdx
index 25caf4bbf8..ed41c69a9d 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/btc-dev-workflow.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/btc-dev-workflow.mdx
@@ -11,7 +11,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Developers on ICP can create canisters and dapps that interact directly with the Bitcoin mainnet and testnet networks through ICP's direct integration with Bitcoin. To use this integration, developers must implement a specific workflow to prepare transactions and submit them to the Bitcoin network. Developers can also integrate and interact with chain-key Bitcoin (ckBTC) from within a canister, which uses the ICRC-1 token implementation.
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/create-transactions.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/create-transactions.mdx
index fc178b5b71..0629f95e8a 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/create-transactions.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/create-transactions.mdx
@@ -11,7 +11,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
A Bitcoin transaction spends a number of unspent transaction outputs (UTXOs) and
creates new UTXOs. In order to create a Bitcoin transaction, you need to:
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/generate-addresses.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/generate-addresses.mdx
index 485edf60b7..159eef1fe2 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/generate-addresses.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/generate-addresses.mdx
@@ -11,7 +11,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
For a canister to receive Bitcoin payments, it must generate a Bitcoin address.
In contrast to most other blockchains, Bitcoin doesn't use accounts. Instead, it
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/local-development.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/local-development.mdx
index 18f940a79c..1bf5d45edf 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/local-development.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/local-development.mdx
@@ -10,7 +10,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
In this guide, you'll explore how you can develop and test a Bitcoin dapp
locally. Testing locally allows you to iterate and improve your dapp more quickly.
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/ordinals.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/ordinals.mdx
index cfe71eff34..1e6adf269b 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/ordinals.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/ordinals.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
On Bitcoin, the term 'satoshi' refers to the smallest denomination of BTC, equal to 100 millionth of 1 bitcoin. [Ordinal theory](https://docs.ordinals.com/digital-artifacts.html), or simply 'Ordinals', refers to a numbering scheme used to track and transfer individual satoshis. The term 'Ordinal' comes from the fact that each satoshi is numbered based on the order in which it has been mined and the order in which it is transferred, based on transaction inputs and outputs.
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/read-state.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/read-state.mdx
index d4b51c34f7..f072401a71 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/read-state.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/read-state.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
To read information from the Bitcoin network's state, the Bitcoin integration API exposes the following methods:
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/runes.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/runes.mdx
index 5f50342578..5dc075de01 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/runes.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/runes.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Bitcoin Runes are a type of fungible asset deployed on the Bitcoin network. Runes are not reliant on the [Ordinals protocol](ordinals.mdx) like other Bitcoin asset standards such as BRC-20 and SRC-20. Runes are designed to be an efficient and simple asset that utilizes Bitcoin's UTXO model and the `OP_RETURN` opcode. Although Runes aren't reliant on Ordinals, the Rune protocol was created and implemented by the same creator, and is part of the same open source project that Ordinals are.
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/sign-transactions.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/sign-transactions.mdx
index 8c46b22e02..9f293bd51d 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/sign-transactions.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/sign-transactions.mdx
@@ -10,7 +10,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Before a transaction can be sent to the Bitcoin network, each input must be
signed.
diff --git a/docs/developer-docs/multi-chain/bitcoin/using-btc/submit-transactions.mdx b/docs/developer-docs/multi-chain/bitcoin/using-btc/submit-transactions.mdx
index 9d098aa4e3..adb0358a1f 100644
--- a/docs/developer-docs/multi-chain/bitcoin/using-btc/submit-transactions.mdx
+++ b/docs/developer-docs/multi-chain/bitcoin/using-btc/submit-transactions.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
To submit transactions to the Bitcoin network, the Bitcoin integration API exposes the `bitcoin_send_transaction` method.
diff --git a/docs/developer-docs/multi-chain/chain-key-tokens/ckbtc/making-transactions.mdx b/docs/developer-docs/multi-chain/chain-key-tokens/ckbtc/making-transactions.mdx
index e302cc4ee8..e44e1222dd 100644
--- a/docs/developer-docs/multi-chain/chain-key-tokens/ckbtc/making-transactions.mdx
+++ b/docs/developer-docs/multi-chain/chain-key-tokens/ckbtc/making-transactions.mdx
@@ -11,7 +11,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
There are several different ways to interact with ckBTC:
diff --git a/docs/developer-docs/multi-chain/chain-key-tokens/ckbtc/using-ckbtc-in-dapps.mdx b/docs/developer-docs/multi-chain/chain-key-tokens/ckbtc/using-ckbtc-in-dapps.mdx
index db48fd9e34..905d8d5110 100644
--- a/docs/developer-docs/multi-chain/chain-key-tokens/ckbtc/using-ckbtc-in-dapps.mdx
+++ b/docs/developer-docs/multi-chain/chain-key-tokens/ckbtc/using-ckbtc-in-dapps.mdx
@@ -10,7 +10,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
ckBTC is an ICRC-2 compliant token, meaning it supports the [ICRC-1](https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-1) and [ICRC-2](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-2/README.md) token standards.
diff --git a/docs/developer-docs/multi-chain/chain-key-tokens/ckerc20/making-transactions.mdx b/docs/developer-docs/multi-chain/chain-key-tokens/ckerc20/making-transactions.mdx
index 3c70227949..de5975040c 100644
--- a/docs/developer-docs/multi-chain/chain-key-tokens/ckerc20/making-transactions.mdx
+++ b/docs/developer-docs/multi-chain/chain-key-tokens/ckerc20/making-transactions.mdx
@@ -11,7 +11,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
There are several different ways to interact with ckERC20 tokens:
diff --git a/docs/developer-docs/multi-chain/chain-key-tokens/ckerc20/using-ckerc20-in-dapps.mdx b/docs/developer-docs/multi-chain/chain-key-tokens/ckerc20/using-ckerc20-in-dapps.mdx
index daa9c575bf..85605a1615 100644
--- a/docs/developer-docs/multi-chain/chain-key-tokens/ckerc20/using-ckerc20-in-dapps.mdx
+++ b/docs/developer-docs/multi-chain/chain-key-tokens/ckerc20/using-ckerc20-in-dapps.mdx
@@ -10,7 +10,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
All ckERC20 tokens are ICRC-2 compliant tokens, which means that they support the [ICRC-1](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md) and [ICRC-2](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-2/README.md) token standards.
diff --git a/docs/developer-docs/multi-chain/chain-key-tokens/cketh/making-transactions.mdx b/docs/developer-docs/multi-chain/chain-key-tokens/cketh/making-transactions.mdx
index 270fc064f2..0d55fce044 100644
--- a/docs/developer-docs/multi-chain/chain-key-tokens/cketh/making-transactions.mdx
+++ b/docs/developer-docs/multi-chain/chain-key-tokens/cketh/making-transactions.mdx
@@ -11,7 +11,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
There are several different ways to interact with ckETH:
diff --git a/docs/developer-docs/multi-chain/chain-key-tokens/cketh/using-cketh-in-dapps.mdx b/docs/developer-docs/multi-chain/chain-key-tokens/cketh/using-cketh-in-dapps.mdx
index 823e732745..eecc24aa1a 100644
--- a/docs/developer-docs/multi-chain/chain-key-tokens/cketh/using-cketh-in-dapps.mdx
+++ b/docs/developer-docs/multi-chain/chain-key-tokens/cketh/using-cketh-in-dapps.mdx
@@ -10,7 +10,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
ckETH is an ICRC-2 compliant token, meaning it supports the [ICRC-1](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md) and [ICRC-2](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-2/README.md) token standards.
diff --git a/docs/developer-docs/multi-chain/ethereum/evm-rpc/costs.mdx b/docs/developer-docs/multi-chain/ethereum/evm-rpc/costs.mdx
index 87e58c7917..a3635724ca 100644
--- a/docs/developer-docs/multi-chain/ethereum/evm-rpc/costs.mdx
+++ b/docs/developer-docs/multi-chain/ethereum/evm-rpc/costs.mdx
@@ -11,7 +11,7 @@ import { AdornedTab } from "/src/components/Tabs/AdornedTab";
-## Overview
+
Each call made to the EVM RPC canister costs [cycles](/docs/current/developer-docs/getting-started/tokens-and-cycles).
diff --git a/docs/developer-docs/multi-chain/ethereum/evm-rpc/how-it-works.mdx b/docs/developer-docs/multi-chain/ethereum/evm-rpc/how-it-works.mdx
index de1383d145..b03b39ccf2 100644
--- a/docs/developer-docs/multi-chain/ethereum/evm-rpc/how-it-works.mdx
+++ b/docs/developer-docs/multi-chain/ethereum/evm-rpc/how-it-works.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The [Ethereum Virtual Machine](https://ethereum.org/en/developers/docs/evm/) (EVM) [Remote Procedure Call](https://ethereum.org/en/developers/docs/apis/json-rpc/) (RPC) canister enables communication between ICP canisters and RPC services. These services, such as Cloudflare and Alchemy, provide public APIs for interacting with blockchain networks. The EVM RPC canister acts as a gateway for a dapp's canisters to communicate with and query information from EVM-compatible chains. It provides endpoints that ICP developers can use to interact with Ethereum smart contracts and ensures that the responses received from the Ethereum network are secure and immediately useful within a canister.
diff --git a/docs/developer-docs/multi-chain/ethereum/using-eth/eth-comparison.mdx b/docs/developer-docs/multi-chain/ethereum/using-eth/eth-comparison.mdx
index f9aacedd4e..ceaa429997 100644
--- a/docs/developer-docs/multi-chain/ethereum/using-eth/eth-comparison.mdx
+++ b/docs/developer-docs/multi-chain/ethereum/using-eth/eth-comparison.mdx
@@ -7,7 +7,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This guide is designed to help Ethereum developers understand the core concepts of ICP, focusing on the terminology and functionalities that differ between the two protocols. While the underlying concepts might be similar, ICP utilizes different terms to describe them.
For a feature comparison between the two protocols, refer to the [quick comparison between ICP and Ethereum](/docs/current/developer-docs/getting-started/network-overview#quick-comparison-with-ethereum).
diff --git a/docs/developer-docs/multi-chain/ethereum/using-eth/eth-dev-workflow.mdx b/docs/developer-docs/multi-chain/ethereum/using-eth/eth-dev-workflow.mdx
index e1bd07ef5c..c3996d489c 100644
--- a/docs/developer-docs/multi-chain/ethereum/using-eth/eth-dev-workflow.mdx
+++ b/docs/developer-docs/multi-chain/ethereum/using-eth/eth-dev-workflow.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Developers on ICP can create canisters and dapps that interact with the Ethereum mainnet, Sepolia testnet, and other EVM-compatible networks through ICP's Ethereum integration. To use this integration, developers must implement a specific workflow that makes JSON-RPC calls to the EVM RPC canister in order to query network information and submit transactions to an EVM-compatible network. Developers can also integrate and interact with chain-key Ethereum (ckETH) from within a canister, which uses the ICRC-1 token implementation.
diff --git a/docs/developer-docs/multi-chain/ethereum/using-eth/generating-addresses.mdx b/docs/developer-docs/multi-chain/ethereum/using-eth/generating-addresses.mdx
index 363003dde6..ab5b838d57 100644
--- a/docs/developer-docs/multi-chain/ethereum/using-eth/generating-addresses.mdx
+++ b/docs/developer-docs/multi-chain/ethereum/using-eth/generating-addresses.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
On Ethereum, there are two types of addresses: wallet addresses for holding assets and contract addresses. Wallet addresses are public accounts that can send and receive ETH tokens. Contract addresses refer to a smart contract that has been executed on Ethereum and the transactions associated with that contract.
diff --git a/docs/developer-docs/multi-chain/ethereum/using-eth/signing-transactions.mdx b/docs/developer-docs/multi-chain/ethereum/using-eth/signing-transactions.mdx
index 19410fe153..d380705ca7 100644
--- a/docs/developer-docs/multi-chain/ethereum/using-eth/signing-transactions.mdx
+++ b/docs/developer-docs/multi-chain/ethereum/using-eth/signing-transactions.mdx
@@ -10,7 +10,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Before a transaction can be sent to the Ethereum network, it must be signed and formatted into a raw ETH transaction. Transactions are signed with [threshold ECDSA](/docs/current/developer-docs/smart-contracts/signatures/t-ecdsa). For this example, the transaction standard EIP1559 will be used.
diff --git a/docs/developer-docs/multi-chain/ethereum/using-eth/submit-transactions.mdx b/docs/developer-docs/multi-chain/ethereum/using-eth/submit-transactions.mdx
index df9c900d0c..0df229cfc9 100644
--- a/docs/developer-docs/multi-chain/ethereum/using-eth/submit-transactions.mdx
+++ b/docs/developer-docs/multi-chain/ethereum/using-eth/submit-transactions.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
To submit transactions to the Ethereum network, first the transaction must be signed and formatted as an ETH transaction. [Learn more about signing transactions](signing-transactions.mdx).
diff --git a/docs/developer-docs/multi-chain/examples.mdx b/docs/developer-docs/multi-chain/examples.mdx
index 63627a8cdf..4265719bfe 100644
--- a/docs/developer-docs/multi-chain/examples.mdx
+++ b/docs/developer-docs/multi-chain/examples.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
ICP's Chain Fusion technology allows developers to build dapps that can interact seamlessly with other blockchain networks without using an intermediary, such as an oracle or a bridge.
diff --git a/docs/developer-docs/multi-chain/overview.mdx b/docs/developer-docs/multi-chain/overview.mdx
index 13de2a38d2..4a1352fd7f 100644
--- a/docs/developer-docs/multi-chain/overview.mdx
+++ b/docs/developer-docs/multi-chain/overview.mdx
@@ -434,7 +434,7 @@ There are several building blocks available to augment non-ICP smart contracts w
- **[Threshold signatures](/docs/current/references/t-ecdsa-how-it-works)**: An ICP service implementing the threshold ECDSA and threshold Schnorr protocols.
-- **[HTTPS outcalls](/docs/current/developer-docs/security/security-best-practices/https-outcalls)**: Replicated calls into external web services.
+- **[HTTPS outcalls](/docs/current/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-overview)**: Replicated calls into external web services.
- **[Bitcoin API](/docs/current/references/bitcoin-how-it-works)**: A protocol API that allows canisters to interact with the Bitcoin blockchain directly.
@@ -442,4 +442,4 @@ There are several building blocks available to augment non-ICP smart contracts w
- [ICP Chain Fusion Educate - Bitcoin Edition: Introduction to ICP and Chain Fusion](https://www.youtube.com/watch?v=A0K9GXsfw74&list=PLfEHHr3qexv_L0t6KrCyJ-l2ZaHaO-m85).
-- [ICP Chain Fusion Educate Powered by Encode Club](https://www.youtube.com/playlist?list=PLfEHHr3qexv9bjbFNp3ItK7yBZ5IQVXjf).
\ No newline at end of file
+- [ICP Chain Fusion Educate Powered by Encode Club](https://www.youtube.com/playlist?list=PLfEHHr3qexv9bjbFNp3ItK7yBZ5IQVXjf).
diff --git a/docs/developer-docs/multi-chain/supported-chains.mdx b/docs/developer-docs/multi-chain/supported-chains.mdx
index 06efed3971..4b0cfdb6ba 100644
--- a/docs/developer-docs/multi-chain/supported-chains.mdx
+++ b/docs/developer-docs/multi-chain/supported-chains.mdx
@@ -41,7 +41,7 @@ import { BetaChip } from "/src/components/Chip/BetaChip";
-## Overview
+
Other blockchain networks can be integrated with ICP if they leverage an
authentication method that is supported by the threshold signing protocols of
diff --git a/docs/developer-docs/security/security-best-practices/resources.mdx b/docs/developer-docs/security/security-best-practices/resources.mdx
index 1cc7e29e6e..1de4ce1a02 100644
--- a/docs/developer-docs/security/security-best-practices/resources.mdx
+++ b/docs/developer-docs/security/security-best-practices/resources.mdx
@@ -10,7 +10,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Below are resources which cover security best practices for technologies you are likely using in your dapp. These best practices are equally important as our Internet Computer specific guidelines and should be studied carefully. They can be useful to reference when developing secure dapps or executing security reviews.
## General
diff --git a/docs/developer-docs/smart-contracts/advanced-features/async-code.mdx b/docs/developer-docs/smart-contracts/advanced-features/async-code.mdx
index 4ab1db4151..9a9089d24e 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/async-code.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/async-code.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
In programming, the [async/await pattern](https://en.wikipedia.org/wiki/Async/await) is a syntactic feature of many programming languages that allows an asynchronous, non-blocking function to be structured in a similar way to an ordinary synchronous function.
@@ -20,7 +20,7 @@ The `async/await` pattern makes this look straightforward, as the developer can
the callee is handled “synchronously”. However, given ICP's message passing model, one has to be careful in case there are [concurrent calls that
message executions can interleave](/docs/current/references/message-execution-properties) as these can lead to inconsistencies if they are not anticipated.
-## Overview of language runtime for asynchronous code
+ ## Language runtime for asynchronous code
Most languages implement asynchronous code through constructs that they typically call [futures](https://docs.rs/futures/latest/futures/)
([promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) in Javascript). A future is a representation
diff --git a/docs/developer-docs/smart-contracts/advanced-features/composite-query.mdx b/docs/developer-docs/smart-contracts/advanced-features/composite-query.mdx
index 7c2663b012..5f4db06c79 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/composite-query.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/composite-query.mdx
@@ -12,7 +12,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
The Internet Computer Protocol supports two types of messages: updates and queries. An update message is executed on all nodes and persists canister state changes. A query message discards state changes and typically executes on a single node. It is possible to execute a query message as an update. In such a case, the query still discards the state changes, but the execution happens on all nodes and the result of execution goes through consensus. This “query-as-update” execution mode is also known as replicated query.
An update can call other updates and queries. However a query cannot make any calls, which can hinder development of scalable decentralized applications, especially those that shard data across multiple canisters.
diff --git a/docs/developer-docs/smart-contracts/advanced-features/handling-get-post-requests.mdx b/docs/developer-docs/smart-contracts/advanced-features/handling-get-post-requests.mdx
index 1d1f801617..a739b45263 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/handling-get-post-requests.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/handling-get-post-requests.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Canisters running on ICP can use HTTP requests in two ways: incoming and outgoing. Incoming HTTP requests refer to HTTP requests that are sent to a canister and can be used to retrieve data from a canister or send new data to the canister. Outgoing HTTP requests refer to HTTP requests that the canister sends to other canisters or external services to retrieve data or send new data.
@@ -110,13 +110,9 @@ For outgoing HTTP requests, the [HTTPS outcalls](./https-outcalls/https-outcalls
## Incoming HTTP requests
-To handle incoming HTTP requests, canisters must define methods for `http_requests` and `http_requests_update` for `GET` and `POST` requests respectively.
+Every HTTP request first goes to `http_request`, and only if you return `upgrade: true` will it be upgraded and re-called as `http_request_update`. The HTTP method (`GET`, `POST`) does not matter.
-All HTTP requests are handled by the ICP HTTP Gateway, therefore you cannot make direct `POST` calls to a canister's `http_request_update` method with HTTP clients such as curl. Instead, you can make a `POST` call to a canister's HTTP endpoint, then configure the canister's `http_request` method to [upgrade the call to `http_request_update` if necessary](/docs/current/references/http-gateway-protocol-spec#upgrade-to-update-calls). Below is an example `POST` call to a canister's endpoint:
-
-```
-curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' https://.raw.ic0.app/
-```
+View the [HTTP Candid interface reference](/docs/current/references/http-gateway-protocol-spec#canister-http-interface) for more information.
## `GET` requests
@@ -152,7 +148,9 @@ Check out the [Rust documentation](https://docs.rs/ic-cdk/latest/ic_cdk/attr.que
## `POST` requests
-HTTP `POST` requests are used to send data to an endpoint with the intention of retaining that data. To handle incoming `POST` requests, the `http_request_update` method can be used. This method uses an `update` call, which can be used to change a canister's state. The following examples display how to configure `http_request_update` method within your canister.
+HTTP `POST` requests are used to send data to an endpoint with the intention of retaining that data. You cannot make direct `POST` calls to a canister's `http_request_update` method with HTTP clients such as curl. Instead, you can make a `POST` call to a canister's HTTP endpoint, then configure the canister's `http_request` method to [upgrade the call to `http_request_update`](/docs/current/references/http-gateway-protocol-spec#upgrade-to-update-calls).
+
+The following examples display how to configure `http_request_update` method within your canister.
diff --git a/docs/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-get.mdx b/docs/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-get.mdx
index 2dfc04365c..7782198d78 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-get.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-get.mdx
@@ -13,7 +13,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
A minimal example to make a `GET` HTTP request. The purpose of this dapp is only to show how to make HTTP requests from a canister. It sends a `GET` request to the Coinbase API and retrieves some historical data about the ICP token.
diff --git a/docs/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-post.mdx b/docs/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-post.mdx
index 59371eb8f4..d2d7b77b5b 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-post.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-post.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
A minimal example of how to make a `POST` HTTP request. The purpose of this dapp is only to show how to make HTTP requests from a canister. It sends a `POST` request with some JSON to a free API where you can verify the headers and body were sent correctly.
diff --git a/docs/developer-docs/smart-contracts/advanced-features/management-canister.mdx b/docs/developer-docs/smart-contracts/advanced-features/management-canister.mdx
index 28d74eeee9..ccd76a472b 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/management-canister.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/management-canister.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The ICP management canister is used to provide access to system features, such as managing canisters, integrating with Bitcoin, making HTTPS outcalls, signing with threshold signatures, and securely retrieving randomness.
diff --git a/docs/developer-docs/smart-contracts/advanced-features/periodic-tasks.mdx b/docs/developer-docs/smart-contracts/advanced-features/periodic-tasks.mdx
index b8aed0f245..1f79c87176 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/periodic-tasks.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/periodic-tasks.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Unlike other blockchains, ICP canisters can automatically execute tasks after a specified delay or interval.
There are two ways to schedule an automatic canister execution on ICP:
diff --git a/docs/developer-docs/smart-contracts/advanced-features/query-stats.mdx b/docs/developer-docs/smart-contracts/advanced-features/query-stats.mdx
index f5a7380992..d71d644ce1 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/query-stats.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/query-stats.mdx
@@ -1,6 +1,6 @@
# Query stats
-## Overview
+
When users interact with a dapp, query calls may be used. Query calls cannot modify a canister's state, making it impossible to track them from the canister's code.
diff --git a/docs/developer-docs/smart-contracts/advanced-features/randomness.mdx b/docs/developer-docs/smart-contracts/advanced-features/randomness.mdx
index 307b1c4993..bea955a696 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/randomness.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/randomness.mdx
@@ -13,7 +13,7 @@ import { BetaChip } from "/src/components/Chip/BetaChip";
-## Overview
+
The Internet Computer provides a secure and verifiable way to generate random numbers directly within canisters. This functionality is exposed through the [raw_rand](../../../references/ic-interface-spec.md) method offered by the [management canister](../advanced-features/management-canister.mdx) and the [Motoko Random module](/docs/current/motoko/main/base/Random).
diff --git a/docs/developer-docs/smart-contracts/advanced-features/simd.mdx b/docs/developer-docs/smart-contracts/advanced-features/simd.mdx
index aa7e0e87fd..82086b42c9 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/simd.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/simd.mdx
@@ -13,7 +13,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
ICP supports deterministic WebAssembly SIMD support. This is a significant milestone for smart contracts
demanding top onchain performance, such as artificial intelligence (AI), image processing (NFTs), games, scientific decentralized applications (dapps), and more.
diff --git a/docs/developer-docs/smart-contracts/advanced-features/system-canisters.mdx b/docs/developer-docs/smart-contracts/advanced-features/system-canisters.mdx
index 57d8564a23..e29c2574e4 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/system-canisters.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/system-canisters.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
System canisters are canisters that provide a necessary function to the ICP network. They are controlled by the NNS and upgraded via NNS proposals. These canisters have static canister IDs that projects can make calls to. One common example of a system canister that is used by projects is the Internet Identity canister.
diff --git a/docs/developer-docs/smart-contracts/advanced-features/time-and-timestamps.mdx b/docs/developer-docs/smart-contracts/advanced-features/time-and-timestamps.mdx
index e3a2d19857..01f84871a7 100644
--- a/docs/developer-docs/smart-contracts/advanced-features/time-and-timestamps.mdx
+++ b/docs/developer-docs/smart-contracts/advanced-features/time-and-timestamps.mdx
@@ -13,7 +13,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
System time is a publicly exposed and verified part of the [IC state tree](/docs/current/references/ic-interface-spec#state-tree). System time is expressed in nanoseconds since `1970-01-01` and indicates the time at which the state is current. It is exposed at `/time`, and all partial state trees include a timestamp.
diff --git a/docs/developer-docs/smart-contracts/best-practices/general.mdx b/docs/developer-docs/smart-contracts/best-practices/general.mdx
index 0ad4374f35..2f96d49b1a 100644
--- a/docs/developer-docs/smart-contracts/best-practices/general.mdx
+++ b/docs/developer-docs/smart-contracts/best-practices/general.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This guide outlines essential development best practices for building on the Internet Computer Protocol (ICP).
diff --git a/docs/developer-docs/smart-contracts/best-practices/idempotency.mdx b/docs/developer-docs/smart-contracts/best-practices/idempotency.mdx
index 66b2231a81..b20f6db610 100644
--- a/docs/developer-docs/smart-contracts/best-practices/idempotency.mdx
+++ b/docs/developer-docs/smart-contracts/best-practices/idempotency.mdx
@@ -9,7 +9,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
In the case of network issues or other unexpected behavior, ICP clients (such as agents) that issue
ingress update calls may be unable to determine whether their ingress
diff --git a/docs/developer-docs/smart-contracts/best-practices/reproducible-builds.mdx b/docs/developer-docs/smart-contracts/best-practices/reproducible-builds.mdx
index bce4af1759..e115bc91e7 100644
--- a/docs/developer-docs/smart-contracts/best-practices/reproducible-builds.mdx
+++ b/docs/developer-docs/smart-contracts/best-practices/reproducible-builds.mdx
@@ -10,7 +10,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
If you are using a canister that you did not develop yourself, you may want to verify that the canister is running the code that you expect it to be before giving it control to make important decisions for you, such as accepting ICP for a payment. Verifying a canister's code requires confirming that the Wasm module is the correct result of compiling the canister source code and that the canister is in fact running that Wasm module and not another Wasm module.
diff --git a/docs/developer-docs/smart-contracts/best-practices/storage.mdx b/docs/developer-docs/smart-contracts/best-practices/storage.mdx
index 3d09844bd0..c7bb0f33c7 100644
--- a/docs/developer-docs/smart-contracts/best-practices/storage.mdx
+++ b/docs/developer-docs/smart-contracts/best-practices/storage.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
There are two forms of storage available to ICP canisters: **heap memory** and **stable memory**.
diff --git a/docs/developer-docs/smart-contracts/best-practices/troubleshooting.mdx b/docs/developer-docs/smart-contracts/best-practices/troubleshooting.mdx
index 123fa74c0d..356e84d7f9 100644
--- a/docs/developer-docs/smart-contracts/best-practices/troubleshooting.mdx
+++ b/docs/developer-docs/smart-contracts/best-practices/troubleshooting.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
When a dapp or canister is running with a high amount of latency, there are some steps that developers can take to troubleshoot or optimize the performance of their canisters.
diff --git a/docs/developer-docs/smart-contracts/candid/candid-concepts.mdx b/docs/developer-docs/smart-contracts/candid/candid-concepts.mdx
index 724bea1ddf..0cb85a3dac 100644
--- a/docs/developer-docs/smart-contracts/candid/candid-concepts.mdx
+++ b/docs/developer-docs/smart-contracts/candid/candid-concepts.mdx
@@ -10,7 +10,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Candid is an **interface description language**. Its primary purpose is to describe the public interface of a **service**, usually in the form of a program deployed as a canister that runs on the Internet Computer. One of the key benefits of Candid is that it is language-agnostic, and allows inter-operation between services and frontends written in different programming languages, including Motoko, Rust, and JavaScript.
diff --git a/docs/developer-docs/smart-contracts/candid/candid-howto.mdx b/docs/developer-docs/smart-contracts/candid/candid-howto.mdx
index 3ee957c4db..11006e0e76 100644
--- a/docs/developer-docs/smart-contracts/candid/candid-howto.mdx
+++ b/docs/developer-docs/smart-contracts/candid/candid-howto.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Candid provides a language-agnostic way to interact with canisters.
diff --git a/docs/developer-docs/smart-contracts/candid/candid-tools.mdx b/docs/developer-docs/smart-contracts/candid/candid-tools.mdx
index cbfb0a6d05..bfe794f1cf 100644
--- a/docs/developer-docs/smart-contracts/candid/candid-tools.mdx
+++ b/docs/developer-docs/smart-contracts/candid/candid-tools.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Candid is an **interface description language** that can be used by ICP canisters to define the public interface of a service. Candid is language-agnostic and allows for the inter-operation of services and frontends written in different programming languages, including Motoko, Rust, and JavaScript.
diff --git a/docs/developer-docs/smart-contracts/compile.mdx b/docs/developer-docs/smart-contracts/compile.mdx
index 86c542753f..edbfa3f8ab 100644
--- a/docs/developer-docs/smart-contracts/compile.mdx
+++ b/docs/developer-docs/smart-contracts/compile.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
After you have [written the code](/docs/current/developer-docs/smart-contracts/write/overview) for your project's canisters and [created them](/docs/current/developer-docs/smart-contracts/create), you need to compile the code into a WebAssembly module before it can be deployed on ICP.
diff --git a/docs/developer-docs/smart-contracts/create.mdx b/docs/developer-docs/smart-contracts/create.mdx
index 75abc51005..131e109c99 100644
--- a/docs/developer-docs/smart-contracts/create.mdx
+++ b/docs/developer-docs/smart-contracts/create.mdx
@@ -14,7 +14,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Canisters contain both code and state. Once you have written the code for a canister, the canister doesn't exist until it is registered with ICP, either locally, on the playground, or on the mainnet.
diff --git a/docs/developer-docs/smart-contracts/deploy/custom-testnets.mdx b/docs/developer-docs/smart-contracts/deploy/custom-testnets.mdx
index 1675bc55a9..cbc1937c5a 100644
--- a/docs/developer-docs/smart-contracts/deploy/custom-testnets.mdx
+++ b/docs/developer-docs/smart-contracts/deploy/custom-testnets.mdx
@@ -5,7 +5,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
ICP does not have a public testnet network that developers can use to deploy and test canisters because canisters deployed to the mainnet can be upgraded and changed. Plus, deployment costs are fairly low compared to other chains.
diff --git a/docs/developer-docs/smart-contracts/encryption/using-vetkeys.mdx b/docs/developer-docs/smart-contracts/encryption/using-vetkeys.mdx
index 1c147ab3dc..7c5d27189b 100644
--- a/docs/developer-docs/smart-contracts/encryption/using-vetkeys.mdx
+++ b/docs/developer-docs/smart-contracts/encryption/using-vetkeys.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This demo provides a canister (`src/system_api`) that offers the [proposed vetKD system API](https://github.com/dfinity/interface-spec/pull/158), implemented demonstration, testing, and initial development purposes. We stress that it does not offer security yet as no threshold cryptography is used yet to secure the key.
diff --git a/docs/developer-docs/smart-contracts/install.mdx b/docs/developer-docs/smart-contracts/install.mdx
index 4e768572e8..ea21efd9b6 100644
--- a/docs/developer-docs/smart-contracts/install.mdx
+++ b/docs/developer-docs/smart-contracts/install.mdx
@@ -14,7 +14,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
When a canister has been initially created, it is empty and does not contain code or state. It only contains information such as the settings, canister ID, cycles balance, and controllers. [Learn more about creating a canister](/docs/current/developer-docs/smart-contracts/create).
diff --git a/docs/developer-docs/smart-contracts/maintain/control.mdx b/docs/developer-docs/smart-contracts/maintain/control.mdx
index 49c8878b1c..14965d0a05 100644
--- a/docs/developer-docs/smart-contracts/maintain/control.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/control.mdx
@@ -11,7 +11,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
A canister is managed by a list of controllers. A controller is specified by a principal, which can be self-authenticating, e.g. a `dfx` developer identity, or another canister. Canisters can have multiple controllers where each has the same administrative rights, or it can have no controller, in which case the canister becomes immutable (blackholed) and cannot be upgraded or deleted.
diff --git a/docs/developer-docs/smart-contracts/maintain/delete.mdx b/docs/developer-docs/smart-contracts/maintain/delete.mdx
index 72bb900183..69bb27b500 100644
--- a/docs/developer-docs/smart-contracts/maintain/delete.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/delete.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
If you want to permanently delete a specific canister or all canisters for a project, you can use the [`dfx canister delete `](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-delete) command.
diff --git a/docs/developer-docs/smart-contracts/maintain/history.mdx b/docs/developer-docs/smart-contracts/maintain/history.mdx
index 4d4aa075e7..cc57348522 100644
--- a/docs/developer-docs/smart-contracts/maintain/history.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/history.mdx
@@ -14,7 +14,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
The Internet Computer tracks the history of a deployed canister through the canister's Wasm module hashes and controller changes. This tracking provides insight into the canister's history, such as what code has been used to run the canister and which controller deployed that code.
diff --git a/docs/developer-docs/smart-contracts/maintain/import.mdx b/docs/developer-docs/smart-contracts/maintain/import.mdx
index 4aac16cab1..8a996401f9 100644
--- a/docs/developer-docs/smart-contracts/maintain/import.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/import.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
The interoperability of canisters is a vital feature for many developers. `dfx` provides a consistent developer workflow for creating, integrating and testing third-party canisters with local developer environments.
diff --git a/docs/developer-docs/smart-contracts/maintain/logs.mdx b/docs/developer-docs/smart-contracts/maintain/logs.mdx
index 6ed299224c..d49ae1444b 100644
--- a/docs/developer-docs/smart-contracts/maintain/logs.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/logs.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
The canister logging feature is designed to provide developers with insight into their canister's behavior and assist with scenarios where their canister traps. This feature supports log messages for:
diff --git a/docs/developer-docs/smart-contracts/maintain/recovery.mdx b/docs/developer-docs/smart-contracts/maintain/recovery.mdx
index 4b0a1f3730..d1a2a9cdb1 100644
--- a/docs/developer-docs/smart-contracts/maintain/recovery.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/recovery.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
A canister is managed and maintained by **controllers**. A controller can be a single developer identity, a list of developer identities, or another canister. If a canister does not have a controller, it cannot be upgraded, deleted, or otherwise maintained. This also applies if access to all canister's controllers identities are lost. If a canister's code traps with an unrecoverable error and cannot be upgraded, the canister can potentially be recovered using canister snapshots or an NNS proposal.
diff --git a/docs/developer-docs/smart-contracts/maintain/resource-limits.mdx b/docs/developer-docs/smart-contracts/maintain/resource-limits.mdx
index 1f1d6b151b..062fec3f77 100644
--- a/docs/developer-docs/smart-contracts/maintain/resource-limits.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/resource-limits.mdx
@@ -10,7 +10,7 @@ import { Tooltip } from "/src/components/Tooltip/Tooltip";
-## Overview
+
The Internet Computer uses WebAssembly as the platform for executing messages of smart contracts.
Since WebAssembly is [Turing-complete](https://en.wikipedia.org/wiki/Turing_completeness), it can express different kinds of computations including non-terminating computations.
diff --git a/docs/developer-docs/smart-contracts/maintain/settings.mdx b/docs/developer-docs/smart-contracts/maintain/settings.mdx
index 9e0efe905f..60e8a55dc4 100644
--- a/docs/developer-docs/smart-contracts/maintain/settings.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/settings.mdx
@@ -11,7 +11,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Each canister has a group of possible settings that control its behavior.
diff --git a/docs/developer-docs/smart-contracts/maintain/snapshots.mdx b/docs/developer-docs/smart-contracts/maintain/snapshots.mdx
index bd4ba13384..599e6d2d8b 100644
--- a/docs/developer-docs/smart-contracts/maintain/snapshots.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/snapshots.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
A canister contains compiled Wasm code and data, such as the canister ID, settings, and Wasm memory. If a canister stops working as expected, traps, or simply needs to be rolled back to a previous version, the developer can use canister snapshots. Developers can take a snapshot of a stopped canister to save the canister's current stable memory, heap memory, data, and Wasm module. This snapshot can be loaded at a later date, rolling the canister back to the code and data saved within that snapshot.
diff --git a/docs/developer-docs/smart-contracts/maintain/state.mdx b/docs/developer-docs/smart-contracts/maintain/state.mdx
index 36f1ab4edd..534e648e28 100644
--- a/docs/developer-docs/smart-contracts/maintain/state.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/state.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
After you deploy a canister, it can begin receiving and processing requests from users and from other canisters. Canisters that are available to send requests and receive replies are considered in be in a **Running** state.
diff --git a/docs/developer-docs/smart-contracts/maintain/storage.mdx b/docs/developer-docs/smart-contracts/maintain/storage.mdx
index 19847ca6c6..be53920b36 100644
--- a/docs/developer-docs/smart-contracts/maintain/storage.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/storage.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
When developing projects on ICP, there are two primary forms of data storage that your canisters can utilize. The first type of storage is the canister's **heap memory**, sometimes referred to as the canister's *main memory*. Heap memory is **temporary**, and any data stored in a canister's heap memory is cleared whenever the canister is reinstalled or upgraded.
diff --git a/docs/developer-docs/smart-contracts/maintain/trapping.mdx b/docs/developer-docs/smart-contracts/maintain/trapping.mdx
index 4f77674b52..474cbc5979 100644
--- a/docs/developer-docs/smart-contracts/maintain/trapping.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/trapping.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Trapping, in the context of WebAssembly code, refers to an interruption of code execution that returns an error. Trapping is defined by [the WebAssembly documentation](https://webassembly.github.io/spec/core/intro/overview.html) as:
diff --git a/docs/developer-docs/smart-contracts/maintain/upgrade.mdx b/docs/developer-docs/smart-contracts/maintain/upgrade.mdx
index 86b6d53bec..aed683d785 100644
--- a/docs/developer-docs/smart-contracts/maintain/upgrade.mdx
+++ b/docs/developer-docs/smart-contracts/maintain/upgrade.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Unlike a canister reinstall that preserves the canister identifier but no state, a canister upgrade enables you to preserve the state of a deployed canister and change the code.
diff --git a/docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx b/docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx
index 3c65c7ee6a..6035c6219f 100644
--- a/docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx
+++ b/docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Applications that provide DeFi or other valuable transactions, such as the ability to transfer assets, require that users trust the application to act honestly and reliably. How can one ensure that it is safe to entrust assets to a canister?
diff --git a/docs/developer-docs/smart-contracts/signatures/signing-messages-t-ecdsa.mdx b/docs/developer-docs/smart-contracts/signatures/signing-messages-t-ecdsa.mdx
index 562ee12ae6..240f9ec7e2 100644
--- a/docs/developer-docs/smart-contracts/signatures/signing-messages-t-ecdsa.mdx
+++ b/docs/developer-docs/smart-contracts/signatures/signing-messages-t-ecdsa.mdx
@@ -13,7 +13,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The threshold ECDSA API allows canisters to securely sign messages and transactions without the corresponding private keys ever existing. Each canister can control an unlimited number of keys by specifying different key `derivation_path`s.
The API provides two methods:
diff --git a/docs/developer-docs/smart-contracts/signatures/signing-messages-t-schnorr.mdx b/docs/developer-docs/smart-contracts/signatures/signing-messages-t-schnorr.mdx
index cf0145cc47..dc1caa918c 100644
--- a/docs/developer-docs/smart-contracts/signatures/signing-messages-t-schnorr.mdx
+++ b/docs/developer-docs/smart-contracts/signatures/signing-messages-t-schnorr.mdx
@@ -12,7 +12,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The threshold Schnorr API allows canisters to securely sign messages and transactions without the corresponding private keys ever existing. Each canister can control an unlimited number of keys by specifying different key `derivation_path`s and `key_id`s.
diff --git a/docs/developer-docs/smart-contracts/signatures/t-ecdsa.mdx b/docs/developer-docs/smart-contracts/signatures/t-ecdsa.mdx
index 4bca0319e1..ec6e029d66 100644
--- a/docs/developer-docs/smart-contracts/signatures/t-ecdsa.mdx
+++ b/docs/developer-docs/smart-contracts/signatures/t-ecdsa.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
The Internet Computer implements a novel threshold ECDSA protocol as part of its chain-key signatures suite. In this protocol, the private ECDSA key exists only as secret shares held by nodes. Secret shares are shards of the ECDSA private key. Signatures are computed using those secret shares without the private key ever being reconstructed. Each replica of such subnet holds a key share that provides no information on its own. More than one third of the nodes are required to generate a threshold signature using their respective key shares.
Besides the actual threshold signing protocol, chain-key ECDSA is comprised of protocols for secure, distributed key generation and periodic key resharing. Distributed key generation enables the nodes on a subnet to collaboratively generate keys, while periodic key resharing allows for ECDSA keys to be re-shared within the subnet. This makes chain-key ECDSA signatures much more powerful than any off-the-shelf threshold ECDSA protocol.
diff --git a/docs/developer-docs/smart-contracts/signatures/t-schnorr.mdx b/docs/developer-docs/smart-contracts/signatures/t-schnorr.mdx
index d936176e99..9516dca689 100644
--- a/docs/developer-docs/smart-contracts/signatures/t-schnorr.mdx
+++ b/docs/developer-docs/smart-contracts/signatures/t-schnorr.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Schnorr signatures are a type of digital signature scheme popularly used amongst blockchain networks because they are efficient, simple, and allow for multi-signatures, threshold signatures, and aggregated signatures to be used on the network. On ICP, threshold Schnorr signatures enable canisters to hold a wider range of digital assets and allow for direct integrations with other chains like Solana.
diff --git a/docs/developer-docs/smart-contracts/test/pocket-ic.mdx b/docs/developer-docs/smart-contracts/test/pocket-ic.mdx
index 9f0a76e226..eed7a4ecdd 100644
--- a/docs/developer-docs/smart-contracts/test/pocket-ic.mdx
+++ b/docs/developer-docs/smart-contracts/test/pocket-ic.mdx
@@ -10,7 +10,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
PocketIC is a lightweight, deterministic testing solution for programmatic testing of canisters.
It seamlessly integrates with existing testing infrastructure, such as `cargo test`, and runs as a standalone binary that doesn't require additional containers or virtual machines.
diff --git a/docs/developer-docs/smart-contracts/topping-up/cycles_management_services.mdx b/docs/developer-docs/smart-contracts/topping-up/cycles_management_services.mdx
index 378ac9766b..609c412605 100644
--- a/docs/developer-docs/smart-contracts/topping-up/cycles_management_services.mdx
+++ b/docs/developer-docs/smart-contracts/topping-up/cycles_management_services.mdx
@@ -5,7 +5,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Once a canister is deployed to the Internet Computer, the compute and storage it utilizes must be pre-paid. The process of burning ICP to obtain cycles and transferring them to a canister is referred to as "topping up" a canister.
diff --git a/docs/developer-docs/smart-contracts/topping-up/topping-up-canister.mdx b/docs/developer-docs/smart-contracts/topping-up/topping-up-canister.mdx
index 7cc81e5220..8d997a3609 100644
--- a/docs/developer-docs/smart-contracts/topping-up/topping-up-canister.mdx
+++ b/docs/developer-docs/smart-contracts/topping-up/topping-up-canister.mdx
@@ -9,7 +9,7 @@ import { AdornedTab } from "/src/components/Tabs/AdornedTab";
-## Overview
+
A canister needs to have cycles deposited continuously into it to pay for the resources it uses. This process is known as 'topping up' the canister. Topping up canisters is routine maintenance.
diff --git a/docs/developer-docs/web-apps/application-frontends/add-stylesheet.mdx b/docs/developer-docs/web-apps/application-frontends/add-stylesheet.mdx
index 253f721793..001d328aa6 100644
--- a/docs/developer-docs/web-apps/application-frontends/add-stylesheet.mdx
+++ b/docs/developer-docs/web-apps/application-frontends/add-stylesheet.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
[Cascading stylesheets (CSS)](https://www.w3schools.com/css/default.asp) are an important part of any frontend user interface. The default project template is configured to include a basic stylesheet that you can edit, but you may prefer to import your own custom stylesheet or use an alternate format. This guide illustrates how to style the [default frontend canister](default-frontend.mdx) using SCSS, the default format used by `dfx new` when creating React frontend canisters.
diff --git a/docs/developer-docs/web-apps/application-frontends/asset-security.mdx b/docs/developer-docs/web-apps/application-frontends/asset-security.mdx
index 58f20eb929..eedc9b0625 100644
--- a/docs/developer-docs/web-apps/application-frontends/asset-security.mdx
+++ b/docs/developer-docs/web-apps/application-frontends/asset-security.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
You can configure how a frontend canister responds to requests for specific assets by defining your
desired configuration in a file named `.ic-assets.json` Each entry in `.ic-assets.json` allows for specifying a [glob](https://code.visualstudio.com/docs/editor/glob-patterns) pattern along with the headers to be returned in the response for any file that matches the pattern. You may also dictate whether redirects are performed from the non-certified endpoint to a certified endpoint for any given filename pattern.
diff --git a/docs/developer-docs/web-apps/application-frontends/default-frontend.mdx b/docs/developer-docs/web-apps/application-frontends/default-frontend.mdx
index 92c7acb6e3..e38c8b07a9 100644
--- a/docs/developer-docs/web-apps/application-frontends/default-frontend.mdx
+++ b/docs/developer-docs/web-apps/application-frontends/default-frontend.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Dapps may have complex frontends that serve dynamic, interactive interfaces, or they can serve simple, static webpages such as HTML and CSS pages.
diff --git a/docs/developer-docs/web-apps/application-frontends/existing-frontend.mdx b/docs/developer-docs/web-apps/application-frontends/existing-frontend.mdx
index af258f87a7..fefab9b8ae 100644
--- a/docs/developer-docs/web-apps/application-frontends/existing-frontend.mdx
+++ b/docs/developer-docs/web-apps/application-frontends/existing-frontend.mdx
@@ -10,7 +10,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
While numerous starter projects and examples exist for those who prefer to start from scratch, deploying an existing frontend application as a frontend canister is also a viable option for building an application on ICP.
diff --git a/docs/developer-docs/web-apps/application-frontends/webpack.mdx b/docs/developer-docs/web-apps/application-frontends/webpack.mdx
index 06227f9a54..b332a80bb7 100644
--- a/docs/developer-docs/web-apps/application-frontends/webpack.mdx
+++ b/docs/developer-docs/web-apps/application-frontends/webpack.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Webpack is a popular and highly configurable module bundler for JavaScript-based applications. New projects created with `dfx new` that choose to create a default JavaScript frontend include a default `webpack.config.js` file that makes it easy to add specific modules such as `react` and `markdown`.
diff --git a/docs/developer-docs/web-apps/browser-js/js-frameworks.mdx b/docs/developer-docs/web-apps/browser-js/js-frameworks.mdx
index e5714945df..f7a3923b3a 100644
--- a/docs/developer-docs/web-apps/browser-js/js-frameworks.mdx
+++ b/docs/developer-docs/web-apps/browser-js/js-frameworks.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
To build user interfaces that utilize in-browser JavaScript, several frameworks can be used.
diff --git a/docs/developer-docs/web-apps/custom-domains/dns-setup.mdx b/docs/developer-docs/web-apps/custom-domains/dns-setup.mdx
index d5ab678687..20fee2a1bd 100644
--- a/docs/developer-docs/web-apps/custom-domains/dns-setup.mdx
+++ b/docs/developer-docs/web-apps/custom-domains/dns-setup.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This guide explains how to configure the DNS records of your domain for three popular
registrars: [Namecheap](#namecheap), [GoDaddy](#godaddy), and [Amazon Route 53](#amazonroute53).
diff --git a/docs/developer-docs/web-apps/custom-domains/using-custom-domains.mdx b/docs/developer-docs/web-apps/custom-domains/using-custom-domains.mdx
index 0935e24fa8..ec7800d8fe 100644
--- a/docs/developer-docs/web-apps/custom-domains/using-custom-domains.mdx
+++ b/docs/developer-docs/web-apps/custom-domains/using-custom-domains.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
By default, all canisters on the Internet Computer are accessible through the
domain `icp0.io` and their canister ID. In addition to that default domain, one
diff --git a/docs/developer-docs/web-apps/frameworks/juno.mdx b/docs/developer-docs/web-apps/frameworks/juno.mdx
index 9e59d5d148..8c1213adff 100644
--- a/docs/developer-docs/web-apps/frameworks/juno.mdx
+++ b/docs/developer-docs/web-apps/frameworks/juno.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Juno is a cutting-edge blockchain-as-a-service platform designed to enable developers to create decentralized applications at lightning speed. It can be thought of as an innovative, open-source alternative to Google Firebase, but with the added benefits of the Internet Computer technology.
diff --git a/docs/developer-docs/web-apps/independently-verifying-ic-signatures.mdx b/docs/developer-docs/web-apps/independently-verifying-ic-signatures.mdx
index 4136775964..5720384933 100644
--- a/docs/developer-docs/web-apps/independently-verifying-ic-signatures.mdx
+++ b/docs/developer-docs/web-apps/independently-verifying-ic-signatures.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Calls made on ICP require a cryptographic `signature` and `principal` to be included within the call. This is typically attached in the form of an identity. This identity can either be authenticated or anonymous. Canisters use this identity to respond to the call and process authentication-based workflows.
diff --git a/docs/references/dashboard/dashboard-apis.mdx b/docs/references/dashboard/dashboard-apis.mdx
index 56e70d76f7..96c689c165 100644
--- a/docs/references/dashboard/dashboard-apis.mdx
+++ b/docs/references/dashboard/dashboard-apis.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
## IC API
diff --git a/docs/references/dashboard/using-the-dashboard.mdx b/docs/references/dashboard/using-the-dashboard.mdx
index 306b4ec3a5..ec84e027f2 100644
--- a/docs/references/dashboard/using-the-dashboard.mdx
+++ b/docs/references/dashboard/using-the-dashboard.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
The ICP dashboard is a graphical user interface that can be used to obtain detailed data about the ICP network architecture, canisters deployed on the network, tokenomics and token transactions, and information about each active SNS. Data displayed by the dashboard can also be obtained through one of several [data APIs](dashboard-apis.mdx). This page will detail using the graphic user interface to obtain different data.
diff --git a/docs/references/ingress-messages.mdx b/docs/references/ingress-messages.mdx
index 525f9c9417..9bcd5c91ce 100644
--- a/docs/references/ingress-messages.mdx
+++ b/docs/references/ingress-messages.mdx
@@ -8,9 +8,9 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
-Ingress messages are requests to ICP canisters that are sent by external entities, such as users, usually through an [agent](/docs/current/developer-docs/developer-tools/dev-tools-overview/#agents) like [agent-js](https://github.com/dfinity/agent-js/tree/main) that runs within a web application, or [agent-rs](https://github.com/dfinity/agent-rs/tree/main) in a Rust application. See also the introductory [call overview](/docs/current/developer-docs/smart-contracts/call/overview).
+
+Ingress messages are requests to ICP canisters that are sent by external entities, such as users, usually through an [agent](/docs/current/developer-docs/developer-tools/dev-tools-overview/#agents) like [agent-js](https://github.com/dfinity/agent-js/tree/main) that runs within a web application, or [agent-rs](https://github.com/dfinity/agent-rs/tree/main) in a Rust application. See also the introductory [call overview](/docs/current/developer-docs/smart-contracts/call/overview).
For example, you can browse what ingress messages can be sent to the ckBTC ledger by browsing through its [API using the dashboard](https://dashboard.internetcomputer.org/canister/mxzaz-hqaaa-aaaar-qaada-cai). The tool also allows you to send messages, using agent-js behind the scenes.
@@ -18,27 +18,27 @@ This page discusses ICP's ingress message APIs. While these APIs are defined in
## Types of ingress messages
-ICP supports several types of calls, as defined in the [HTTPS interface specification](/docs/current/references/ic-interface-spec#http-interface). These include query and update calls.
+ICP supports several types of calls, as defined in the [HTTPS interface specification](/docs/current/references/ic-interface-spec#http-interface). These include query and update calls.
## Query calls
-Queries don't modify a canister's state and are answered and signed by a single replica. Responses can be obtained within milliseconds, but they are typically not signed by the subnet, meaning a malicious replica or boundary node could arbitrarily modify the response.
+Queries don't modify a canister's state and are answered and signed by a single replica. Responses can be obtained within milliseconds, but they are typically not signed by the subnet, meaning a malicious replica or boundary node could arbitrarily modify the response.
-Some applications may have higher authenticity requirements for query responses. For example, if a dapp queries a proposal description that the user then votes on, it may not be acceptable that the result could be tampered with, as it could trick users to vote in the attacker's favor. As an alternative, you can issue query calls as update calls instead. While that's easy to implement, it makes the calls significantly slower.
+Some applications may have higher authenticity requirements for query responses. For example, if a dapp queries a proposal description that the user then votes on, it may not be acceptable that the result could be tampered with, as it could trick users to vote in the attacker's favor. As an alternative, you can issue query calls as update calls instead. While that's easy to implement, it makes the calls significantly slower.
Another alternative approach is to sign the data beforehand and provide *certified variables* (see [tutorial](/docs/current/tutorials/developer-journey/level-3/3.3-certified-data/), [security best practices](/docs/current/developer-docs/security/security-best-practices/data-integrity-and-authenticity#certified-variables)) in query responses. While this approach has better performance than sending query calls as update calls, it can be complex to implement depending on the specific use case. An example where certified variables are used is within the [HTTP asset certification](/docs/current/developer-docs/security/security-best-practices/data-integrity-and-authenticity#use-http-asset-certification-and-avoid-serving-your-dapp-through-rawicp0io).
-Error handling for queries is typically simple: on error, one can simply retry until a successful response is received.
+Error handling for queries is typically simple: on error, one can simply retry until a successful response is received.
## Update calls
Updates can modify a canister's state and thus must go through consensus, typically taking 1-3 seconds. They return certified responses (signed by the subnet), providing authenticity within the subnet's corruption bounds.
-Update calls can be [synchronous](/docs/current/references/ic-interface-spec#http-sync-call-overview) or [asynchronous](/docs/current/references/ic-interface-spec#http-async-call-overview).
+Update calls can be [synchronous](/docs/current/references/ic-interface-spec#http-sync-call-overview) or [asynchronous](/docs/current/references/ic-interface-spec#http-async-call-overview).
-A [synchronous `call`](https://internetcomputer.org/docs/current/references/ic-interface-spec#http-call) follows the "call and await" pattern. In the success case, it maintains the HTTPS connection until a certified response is produced, as illustrated below.
+A [synchronous `call`](https://internetcomputer.org/docs/current/references/ic-interface-spec#http-call) follows the "call and await" pattern. In the success case, it maintains the HTTPS connection until a certified response is produced, as illustrated below.
![Dev containers 1](./_attachments/ingress_sync_call.png)
-Compared to the [asynchronous `call`](/docs/current/references/ic-interface-spec#http-async-call) endpoint, where the [`read_state`](/docs/current/references/ic-interface-spec#http-read-state) endpoint is used to poll for the request status and obtain the reply, the synchronous endpoint removes the need to poll for the response in the success case.
+Compared to the [asynchronous `call`](/docs/current/references/ic-interface-spec#http-async-call) endpoint, where the [`read_state`](/docs/current/references/ic-interface-spec#http-read-state) endpoint is used to poll for the request status and obtain the reply, the synchronous endpoint removes the need to poll for the response in the success case.
However, a response may not be produced until some implementation-specific timeout is reached. In that case, the synchronous endpoint behaves like the asynchronous one: it returns a `202` response, and the client must poll [`read_state`](/docs/current/references/ic-interface-spec#http-read-state) to get the request status and eventually obtain the reply, as illustrated below.
@@ -65,7 +65,7 @@ In general, there are cases where it is impossible to determine if a call was su
* The client loses its connection until the request status has been removed from the state tree. (Recall that ICP will remove the request from the system state tree some time after ingress expiry.)
* There is no application specific way to tell if the call successfully executed. For example, the canister does not provide a way to find out if the call happened.
-In this situation, it is indistinguishable if the call was successful, but all information has already been removed from the system state tree, or the call never made it into the state tree in the first place and hasn't been executed.
+In this situation, it is indistinguishable if the call was successful, but all information has already been removed from the system state tree, or the call never made it into the state tree in the first place and hasn't been executed.
### Recommendations and best practices for secure update call handling
@@ -81,13 +81,13 @@ In summary, there are two options for a client:
* _No retries, only poll `read_state`:_ Submit the `call` once, and poll `read_state` until at least one of the following conditions is met:
* A certified response was produced. That is, the call status is `replied`, `rejected`, or `done`.
* The subnet time exceeds`ingress_expiry`, and the call status is not `processing`.
-
- Evaluating the second condition may be hard if the subnet time and local time of the user differ.
-* _Retry the call while polling `read_state`_ Do the same as above, but resubmit the initial `call` (same `request_id`) periodically (e.g. every `30s`) until at least one of the following conditions is met:
+
+ Evaluating the second condition may be hard if the subnet time and local time of the user differ.
+* _Retry the call while polling `read_state`_ Do the same as above, but resubmit the initial `call` (same `request_id`) periodically (e.g. every `30s`) until at least one of the following conditions is met:
* The call is known to the system. That is, the call status is `received`, `processing`, `replied`, `rejected`, or `done`.
* `ingress_expiry` is reached.
- This can be beneficial because a call that didn’t make it is retried. For example, if the first call was dropped due to a network issue or by a malicious replica, a subsequent call could make it through e.g. if it is successfully routed to an honest replica.
+ This can be beneficial because a call that didn’t make it is retried. For example, if the first call was dropped due to a network issue or by a malicious replica, a subsequent call could make it through e.g. if it is successfully routed to an honest replica.
At the time of writing, both agent-js (v2.1.3) and agent-rs (v0.39.1) don't retry `call`, so they follow the first option above. By default, both agent-rs and agent-js use `ingress_expiry` of four minutes and poll for five minutes. Additionally, agent-rs resets the timer to allow for an additional five minutes of polling whenever it observes a `received` or `processing` status.
diff --git a/docs/references/ledger.mdx b/docs/references/ledger.mdx
index 84e3e5c4d4..745e1a153e 100644
--- a/docs/references/ledger.mdx
+++ b/docs/references/ledger.mdx
@@ -4,7 +4,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This document is a specification of the public interface of the ledger canister. It provides an overview of the functionality, details some internal aspects, and documents publicly available methods. It also provides an abstract mathematical model precisely describing the expected behavior of the methods implemented by the canister, albeit at a somewhat high level of abstraction.
:::info
diff --git a/docs/references/node-providers/node-metrics.mdx b/docs/references/node-providers/node-metrics.mdx
index 25938d2e03..5508acbfe6 100644
--- a/docs/references/node-providers/node-metrics.mdx
+++ b/docs/references/node-providers/node-metrics.mdx
@@ -9,7 +9,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
ICP publishes node metrics publicly and provides an observability stack to collect, inspect, and analyze these metrics. By publishing these metrics worldwide, anyone can monitor the health of ICP nodes, therefore decentralizing the monitoring process, ensuring that more nodes stay healthy, and decreasing the amount of time it takes to resolve any issues. This feature provides increased overall transparency and a more stable network.
diff --git a/docs/references/subnets/overview.mdx b/docs/references/subnets/overview.mdx
index 095ac85589..8197d5833b 100644
--- a/docs/references/subnets/overview.mdx
+++ b/docs/references/subnets/overview.mdx
@@ -9,7 +9,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Internet Computer **subnet blockchains** are formed by a number of independently owned and controlled high-performance hardware devices called **node machines**, that run the Internet Computer Protocol (ICP).
diff --git a/docs/references/subnets/subnet-types.mdx b/docs/references/subnets/subnet-types.mdx
index a72f319c06..b59dc9c315 100644
--- a/docs/references/subnets/subnet-types.mdx
+++ b/docs/references/subnets/subnet-types.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
A subnet on ICP is a collection of interacting replicas that run their own, separate instance of the ICP consensus mechanism, effectively creating their own blockchain on which a set of canisters can run. Each subnet can communicate with other subnets and is controlled by a root subnet. The root subnet uses chain-key cryptography to delegate its authority to the various subnets.
diff --git a/docs/references/t-sigs-how-it-works.mdx b/docs/references/t-sigs-how-it-works.mdx
index 8c0b0ddbd3..81ee3874cc 100644
--- a/docs/references/t-sigs-how-it-works.mdx
+++ b/docs/references/t-sigs-how-it-works.mdx
@@ -4,7 +4,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
This page gives a high-level outline of threshold signatures on ICP.
Some of the information in this section is not required to use threshold signing features, but may be of interest to the technically inclined reader for obtaining background information on the technology.
ICP currently supports **threshold Schnorr** signing and **threshold ECDSA** signing.
diff --git a/docs/references/vetkeys-overview.mdx b/docs/references/vetkeys-overview.mdx
index ef6186dc09..1bdeb1f0b5 100644
--- a/docs/references/vetkeys-overview.mdx
+++ b/docs/references/vetkeys-overview.mdx
@@ -4,7 +4,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
vetKeys on the Internet Computer allow developers to more easily perform encryption, threshold decryption, and signing when building dapps on ICP. It is powered by a protocol called **vetKD (Verifiably Encrypted Threshold Key Derivation)** that allows to derive decryption keys on demand.
## Key derivation on demand
diff --git a/docs/tutorials/developer-journey/index.mdx b/docs/tutorials/developer-journey/index.mdx
index 5dcaa7c73b..10230161b3 100644
--- a/docs/tutorials/developer-journey/index.mdx
+++ b/docs/tutorials/developer-journey/index.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Are you ready to get started developing on the Internet Computer, but not sure where to begin?
diff --git a/docs/tutorials/developer-journey/level-0/01-ic-overview.mdx b/docs/tutorials/developer-journey/level-0/01-ic-overview.mdx
index cbfb3be778..2fbfaf8116 100644
--- a/docs/tutorials/developer-journey/level-0/01-ic-overview.mdx
+++ b/docs/tutorials/developer-journey/level-0/01-ic-overview.mdx
@@ -17,7 +17,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
The **Internet Computer Protocol (ICP)** is a secure and transparent blockchain-based network that can be used to host data and programs. Programs and their data hosted on ICP are referred to as **decentralized applications**, often abbreviated to **dapps**.
diff --git a/docs/tutorials/developer-journey/level-0/02-ic-terms.mdx b/docs/tutorials/developer-journey/level-0/02-ic-terms.mdx
index dcfd9fffdd..f417d1deaf 100644
--- a/docs/tutorials/developer-journey/level-0/02-ic-terms.mdx
+++ b/docs/tutorials/developer-journey/level-0/02-ic-terms.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
This page introduces some of the most commonly used terminology that developers should be aware of when building on the Internet Computer. This page covers many terms, but does not include every single term that is related to the Internet Computer. [View the full glossary of terms](/docs/current/references/glossary).
diff --git a/docs/tutorials/developer-journey/level-0/03-dev-env.mdx b/docs/tutorials/developer-journey/level-0/03-dev-env.mdx
index 9c0d9e6fca..af0b434226 100644
--- a/docs/tutorials/developer-journey/level-0/03-dev-env.mdx
+++ b/docs/tutorials/developer-journey/level-0/03-dev-env.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Before you can begin the developer ladder, you need to set up a developer environment. A developer environment consists of tools and packages that are required to develop code projects. Usually, developer environments are stored and hosted on your local computer, but there are some situations where a virtual, web-based development environment exists.
diff --git a/docs/tutorials/developer-journey/level-0/04-intro-canisters.mdx b/docs/tutorials/developer-journey/level-0/04-intro-canisters.mdx
index ef433d13b7..fa4e0d0eee 100644
--- a/docs/tutorials/developer-journey/level-0/04-intro-canisters.mdx
+++ b/docs/tutorials/developer-journey/level-0/04-intro-canisters.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Smart contracts on the Internet Computer are known as **canisters**. A canister contains both the source code and software state. A canister's source code is compiled into a WebAssembly module and is associated with a module of stable memory.
diff --git a/docs/tutorials/developer-journey/level-0/05-intro-languages.mdx b/docs/tutorials/developer-journey/level-0/05-intro-languages.mdx
index 64942b9790..a04a9cc819 100644
--- a/docs/tutorials/developer-journey/level-0/05-intro-languages.mdx
+++ b/docs/tutorials/developer-journey/level-0/05-intro-languages.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
When developing canisters, the most common development workflow is to use a software development kit (SDK). The Internet Computer SDK is the most commonly used, which natively supports Motoko and Rust out of the box.
diff --git a/docs/tutorials/developer-journey/level-0/06-intro-dfx.mdx b/docs/tutorials/developer-journey/level-0/06-intro-dfx.mdx
index 9363851f66..210fae6a31 100644
--- a/docs/tutorials/developer-journey/level-0/06-intro-dfx.mdx
+++ b/docs/tutorials/developer-journey/level-0/06-intro-dfx.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
`dfx` is a command line utility that is used to interact with the IC SDK. It is the primary tool that is used for creating, managing, and deploying dapps onto the Internet Computer.
diff --git a/docs/tutorials/developer-journey/level-1/1.1-live-demo.mdx b/docs/tutorials/developer-journey/level-1/1.1-live-demo.mdx
index 45048c1422..017705d09a 100644
--- a/docs/tutorials/developer-journey/level-1/1.1-live-demo.mdx
+++ b/docs/tutorials/developer-journey/level-1/1.1-live-demo.mdx
@@ -18,7 +18,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
In the previous segment of our developer ladder, introduction to `dfx`, you created a new `dfx` project using the default 'Hello, world' template and looked into the project's structure and code. However, you didn't build or deploy the canister.
diff --git a/docs/tutorials/developer-journey/level-1/1.2-motoko-lvl1.mdx b/docs/tutorials/developer-journey/level-1/1.2-motoko-lvl1.mdx
index 1bd3fa8fe4..6b7b929bd4 100644
--- a/docs/tutorials/developer-journey/level-1/1.2-motoko-lvl1.mdx
+++ b/docs/tutorials/developer-journey/level-1/1.2-motoko-lvl1.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Motoko is a programming language that has been developed and optimized for creating programs built on the Internet Computer. In this module, you'll cover the fundamental basics of Motoko that you'll use when you build your [first dapp](/docs/current/tutorials/developer-journey/level-1/1.3-first-dapp).
diff --git a/docs/tutorials/developer-journey/level-1/1.3-first-dapp.mdx b/docs/tutorials/developer-journey/level-1/1.3-first-dapp.mdx
index 6c600cf950..a379ea86b7 100644
--- a/docs/tutorials/developer-journey/level-1/1.3-first-dapp.mdx
+++ b/docs/tutorials/developer-journey/level-1/1.3-first-dapp.mdx
@@ -21,7 +21,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
The video corresponding to this tutorial is outdated and follows a different project structure than what is written on this page.
:::
-## Overview
+
At this point in your developer ladder, you've covered the fundamentals of canister development and deployed the default 'Hello, world' project template on the playground. It's time to get into writing code and developing your first dapp!
diff --git a/docs/tutorials/developer-journey/level-1/1.4-using-cycles.mdx b/docs/tutorials/developer-journey/level-1/1.4-using-cycles.mdx
index 3e860517f8..96c3dae404 100644
--- a/docs/tutorials/developer-journey/level-1/1.4-using-cycles.mdx
+++ b/docs/tutorials/developer-journey/level-1/1.4-using-cycles.mdx
@@ -17,7 +17,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
If you recall from the previous module, [Internet Computer terminology](/docs/current/tutorials/developer-journey/level-0/ic-terms), cycles are used to measure the resources, such as memory, storage, and compute power, that are used by a canister. When a canister is deployed on the mainnet, cycles are 'charged' for every action that a canister performs.
diff --git a/docs/tutorials/developer-journey/level-1/1.5-deploying-canisters.mdx b/docs/tutorials/developer-journey/level-1/1.5-deploying-canisters.mdx
index a7908ef799..7ab9e695e4 100644
--- a/docs/tutorials/developer-journey/level-1/1.5-deploying-canisters.mdx
+++ b/docs/tutorials/developer-journey/level-1/1.5-deploying-canisters.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Now that you have some cycles to pay for your canister's resources, you can deploy your dapp on the mainnet. When a canister is deployed to the mainnet, it's code will be hosted on the nodes that make up one of the mainnet's subnets. The canister will be hosted on these nodes until it is manually uninstalled by the developer, or until it runs out of cycles and is uninstalled automatically.
diff --git a/docs/tutorials/developer-journey/level-1/1.6-managing-canisters.mdx b/docs/tutorials/developer-journey/level-1/1.6-managing-canisters.mdx
index ed868ae122..7f42a0653f 100644
--- a/docs/tutorials/developer-journey/level-1/1.6-managing-canisters.mdx
+++ b/docs/tutorials/developer-journey/level-1/1.6-managing-canisters.mdx
@@ -16,7 +16,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Now that you have canisters deployed on the mainnet, the next step is to learn how to manage those canisters. Managing a canister includes workflows such as obtaining information, setting an identity as the canister's owner, and deleting a canister. You'll dive into these different workflows and more in this guide to assure that you have the core fundamentals of how to maintain canisters.
diff --git a/docs/tutorials/developer-journey/level-2/2.1-storage-persistence.mdx b/docs/tutorials/developer-journey/level-2/2.1-storage-persistence.mdx
index 1fdb682f73..c2e42f03e2 100644
--- a/docs/tutorials/developer-journey/level-2/2.1-storage-persistence.mdx
+++ b/docs/tutorials/developer-journey/level-2/2.1-storage-persistence.mdx
@@ -18,7 +18,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
The Internet Computer handles persistent data storage using a feature known as **stable memory**. **Stable memory** is a unique feature of the Internet Computer that defines a data store separate from the canister's regular Wasm memory data store, which is known as **heap memory**. A canister's heap memory is not persistent storage and does not persist across canister upgrades; canister data and state stored in heap memory is removed when a canister is upgraded or reinstalled. For immutable canisters that use less than the heap memory limit of 4GiB, heap memory can be used. For larger canisters, and especially those that intend to be upgraded and changed over time, stable memory is important since it persists across canister upgrades, has a much larger storage capacity than heap memory, and is very beneficial for vertically scaling a dapp.
diff --git a/docs/tutorials/developer-journey/level-2/2.2-advanced-canister-calls.mdx b/docs/tutorials/developer-journey/level-2/2.2-advanced-canister-calls.mdx
index a33395e8bb..bda989a24a 100644
--- a/docs/tutorials/developer-journey/level-2/2.2-advanced-canister-calls.mdx
+++ b/docs/tutorials/developer-journey/level-2/2.2-advanced-canister-calls.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
In the previous tutorial where you [created your first dapp](/docs/current/tutorials/developer-journey/level-1/1.3-first-dapp), the developer ladder briefly discussed query and update canister calls. In this tutorial, you'll dive deeper into these types of canister calls, but also take a look at advanced canister calls such as composite queries, certified variables, and inter-canister calls.
diff --git a/docs/tutorials/developer-journey/level-2/2.3-third-party-canisters.mdx b/docs/tutorials/developer-journey/level-2/2.3-third-party-canisters.mdx
index 08f6bb4838..16861819eb 100644
--- a/docs/tutorials/developer-journey/level-2/2.3-third-party-canisters.mdx
+++ b/docs/tutorials/developer-journey/level-2/2.3-third-party-canisters.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Third-party canisters are canisters that provide a public service at a static canister ID. Some examples are the DFINITY NNS and Internet Identity canisters, but third-party canisters can also be made by community developers. Using third-party canisters can be a good way to add additional functionalities to your dapp. For example, by integrating the Internet Identity canister into your dapp, you can enable identity and authentication for the users of your application.
diff --git a/docs/tutorials/developer-journey/level-2/2.4-intro-candid.mdx b/docs/tutorials/developer-journey/level-2/2.4-intro-candid.mdx
index aff7247042..1c8e6f9821 100644
--- a/docs/tutorials/developer-journey/level-2/2.4-intro-candid.mdx
+++ b/docs/tutorials/developer-journey/level-2/2.4-intro-candid.mdx
@@ -16,7 +16,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Candid is an interface description language that is used to describe the public interface of a service. A **service** is usually in the form of an application deployed as a canister on ICP. Public interfaces of canisters are used to interact with the canister. Candid supports interactions through the IC SDK via the terminal, through a web browser, or through the use of agents. It also provides a way to specify input argument values and display return values from different canister **methods**, regardless of the manner used to interact with the canister. Recall that a method is a piece of code specifying a task which declares a sequence of arguments and their associated result types.
diff --git a/docs/tutorials/developer-journey/level-2/2.5-unit-testing.mdx b/docs/tutorials/developer-journey/level-2/2.5-unit-testing.mdx
index 2f17abc20b..b5978d14bc 100644
--- a/docs/tutorials/developer-journey/level-2/2.5-unit-testing.mdx
+++ b/docs/tutorials/developer-journey/level-2/2.5-unit-testing.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
Testing code is an important stage of any development workflow. Without proper testing before the code is put into production, bugs and errors that may have been caught during testing can be detrimental to production environments. At this point of the developer ladder, it's time to explore tools that can be used to test our code.
diff --git a/docs/tutorials/developer-journey/level-2/2.6-motoko-lvl2.mdx b/docs/tutorials/developer-journey/level-2/2.6-motoko-lvl2.mdx
index fd256620d3..8e47fd8fe9 100644
--- a/docs/tutorials/developer-journey/level-2/2.6-motoko-lvl2.mdx
+++ b/docs/tutorials/developer-journey/level-2/2.6-motoko-lvl2.mdx
@@ -15,7 +15,7 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
-## Overview
+
As you've seen so far, **actors** are at the core functionality of canisters written in Motoko. In this tutorial, you'll explore actors further by taking a look at actor type definitions, how actors interact with async data, actor classes, and using multiple actors.
diff --git a/docs/tutorials/developer-journey/level-3/3.1-package-managers.mdx b/docs/tutorials/developer-journey/level-3/3.1-package-managers.mdx
index 62aa662f97..6dbfb4e5b1 100644
--- a/docs/tutorials/developer-journey/level-3/3.1-package-managers.mdx
+++ b/docs/tutorials/developer-journey/level-3/3.1-package-managers.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
[Mops](https://mops.one) and [Vessel](https://github.com/dfinity/vessel) are package managers for Motoko. In this guide, you'll explore how to download and install Mops and Vessel, then how to import and use different libraries that have been downloaded through a package manager.
diff --git a/docs/tutorials/developer-journey/level-3/3.2-https-outcalls.mdx b/docs/tutorials/developer-journey/level-3/3.2-https-outcalls.mdx
index 2252d3bf31..e6d789527e 100644
--- a/docs/tutorials/developer-journey/level-3/3.2-https-outcalls.mdx
+++ b/docs/tutorials/developer-journey/level-3/3.2-https-outcalls.mdx
@@ -15,7 +15,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
In the past, blockchain networks were only able to communicate with external servers through blockchain oracles, or third-party entities that relayed calls from the blockchain to an external server, then routed the response back to the blockchain. This is because blockchains are a form of replicated state machine, where each replica must perform the same computations within the same state to make the same transitions each round. Since doing computations with results from an external source may lead to a state divergence, tools like oracles have been used in the past. However, on the Internet Computer, canisters can communicate directly with external servers or other blockchains through **HTTPS outcalls**.
diff --git a/docs/tutorials/developer-journey/level-3/3.3-certified-data.mdx b/docs/tutorials/developer-journey/level-3/3.3-certified-data.mdx
index 54cf4234af..eb4ae0ea39 100644
--- a/docs/tutorials/developer-journey/level-3/3.3-certified-data.mdx
+++ b/docs/tutorials/developer-journey/level-3/3.3-certified-data.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
In a previous module, [2.2: Advanced canister calls](/docs/current/tutorials/developer-journey/level-2/2.2-advanced-canister-calls), you briefly touched on certified variables. In this guide, you'll dive deeper into certified data and take a look at an example that displays how to use certified data.
diff --git a/docs/tutorials/developer-journey/level-3/3.4-intro-to-agents.mdx b/docs/tutorials/developer-journey/level-3/3.4-intro-to-agents.mdx
index f69860c7a2..aab45fa174 100644
--- a/docs/tutorials/developer-journey/level-3/3.4-intro-to-agents.mdx
+++ b/docs/tutorials/developer-journey/level-3/3.4-intro-to-agents.mdx
@@ -16,7 +16,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
When you have a canister running, either locally or on the mainnet, you have two primary ways for interacting with the canister: using the API through an agent, or using the canister's HTTP interface. On the Internet Computer, an **agent** is a library used to make calls to ICP's public interface.
diff --git a/docs/tutorials/developer-journey/level-3/3.5-identities-and-auth.mdx b/docs/tutorials/developer-journey/level-3/3.5-identities-and-auth.mdx
index 74e931c1e3..6fd7e2758b 100644
--- a/docs/tutorials/developer-journey/level-3/3.5-identities-and-auth.mdx
+++ b/docs/tutorials/developer-journey/level-3/3.5-identities-and-auth.mdx
@@ -16,7 +16,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
When developing on the Internet Computer, there are several types of identities and methods of authentication that you'll encounter. In the previous module where you obtained a cycles coupon, [1.4: acquiring and using cycles](/docs/current/tutorials/developer-journey/level-1/1.4-using-cycles), you created a **developer identity** that has a **cycles balance**. You also looked at how to convert ICP tokens stored in a **ledger account** into cycles.
diff --git a/docs/tutorials/developer-journey/level-3/3.6-motoko-lvl3.mdx b/docs/tutorials/developer-journey/level-3/3.6-motoko-lvl3.mdx
index 1381c7e081..f9f08b5d75 100644
--- a/docs/tutorials/developer-journey/level-3/3.6-motoko-lvl3.mdx
+++ b/docs/tutorials/developer-journey/level-3/3.6-motoko-lvl3.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
In the previous module, [3.5: Identities and authentication](/docs/current/tutorials/developer-journey/level-3/3.5-identities-and-auth) you covered different forms of identities and authentication on ICP. In this Motoko level, you'll look into caller identification, adding access control with identities, plus other non-identity related functionalities such as pattern matching and periodic tasks.
diff --git a/docs/tutorials/developer-journey/level-4/4.1-icp-ledger.mdx b/docs/tutorials/developer-journey/level-4/4.1-icp-ledger.mdx
index 1de4aa6288..c1b8565efd 100644
--- a/docs/tutorials/developer-journey/level-4/4.1-icp-ledger.mdx
+++ b/docs/tutorials/developer-journey/level-4/4.1-icp-ledger.mdx
@@ -17,7 +17,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Recall from previous modules that ICP is the native token of the Internet Computer. ICP tokens have three key functionalities on the Internet Computer:
diff --git a/docs/tutorials/developer-journey/level-4/4.2-icrc-tokens.mdx b/docs/tutorials/developer-journey/level-4/4.2-icrc-tokens.mdx
index a23fdeb212..bfaafa4075 100644
--- a/docs/tutorials/developer-journey/level-4/4.2-icrc-tokens.mdx
+++ b/docs/tutorials/developer-journey/level-4/4.2-icrc-tokens.mdx
@@ -16,7 +16,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
For developers to create their own fungible tokens on the Internet Computer, the ICRC-1 token standard can be used. The acronym "ICRC" stands for "Internet Computer Request for Comments", as the standard was created by the Internet Computer working group. [Learn more about the working group](https://github.com/dfinity/ICRC).
diff --git a/docs/tutorials/developer-journey/level-4/4.3-ckbtc-and-bitcoin.mdx b/docs/tutorials/developer-journey/level-4/4.3-ckbtc-and-bitcoin.mdx
index 38d44f0ecb..ca751d9313 100644
--- a/docs/tutorials/developer-journey/level-4/4.3-ckbtc-and-bitcoin.mdx
+++ b/docs/tutorials/developer-journey/level-4/4.3-ckbtc-and-bitcoin.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
One of the key features of the Internet Computer is known as **chain-key cryptography**. Chain-key cryptography is a feature that encompasses several cryptographic mechanisms that enable novel workflows and functionalities such as chain-key tokens. Chain-key tokens are not wrapped tokens; they are twin tokens that are backed 1:1 with the original token (BTC, ETH) that use chain-key cryptography to transfer and use the original tokens with less fees and higher transfer speeds than using the token's native blockchain network.
diff --git a/docs/tutorials/developer-journey/level-4/4.4-nns-governance.mdx b/docs/tutorials/developer-journey/level-4/4.4-nns-governance.mdx
index c50a3b4068..3dde42c03c 100644
--- a/docs/tutorials/developer-journey/level-4/4.4-nns-governance.mdx
+++ b/docs/tutorials/developer-journey/level-4/4.4-nns-governance.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
When blockchain networks need to be upgraded, traditionally they use a method known as a 'hard fork', which involves substantial work and manual coordination. In comparison, the Internet Computer upgrades itself weekly, which can be seen on the [ICP dashboard](https://dashboard.internetcomputer.org/releases).
diff --git a/docs/tutorials/developer-journey/level-4/4.5-using-quill.mdx b/docs/tutorials/developer-journey/level-4/4.5-using-quill.mdx
index 35f5ba8437..b643d26f23 100644
--- a/docs/tutorials/developer-journey/level-4/4.5-using-quill.mdx
+++ b/docs/tutorials/developer-journey/level-4/4.5-using-quill.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Now that you've covered both the ICP ledger and the NNS, it's time to take a look at a CLI tool that can be used to interact with both. Quill is a ledger and governance toolkit that provides support for self-custody of ICP or ckBTC tokens and functionality to interact with the NNS, SNSs, and ICP ledger from a **cold wallet**.
diff --git a/docs/tutorials/developer-journey/level-4/4.6-motoko-lvl4.mdx b/docs/tutorials/developer-journey/level-4/4.6-motoko-lvl4.mdx
index 6a306ce0eb..9bfa1fb679 100644
--- a/docs/tutorials/developer-journey/level-4/4.6-motoko-lvl4.mdx
+++ b/docs/tutorials/developer-journey/level-4/4.6-motoko-lvl4.mdx
@@ -14,7 +14,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
In this final Motoko module of the developer ladder series, you'll cover the following Motoko concepts and components:
diff --git a/docs/tutorials/developer-journey/level-5/5.1-vetKeys-tutorial.mdx b/docs/tutorials/developer-journey/level-5/5.1-vetKeys-tutorial.mdx
index 15aa03d90e..d6bd8394d3 100644
--- a/docs/tutorials/developer-journey/level-5/5.1-vetKeys-tutorial.mdx
+++ b/docs/tutorials/developer-journey/level-5/5.1-vetKeys-tutorial.mdx
@@ -16,7 +16,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Many types of applications rely on secure ways to store user data and keep certain aspects of the dapp private. On a blockchain, transactions are traditionally public and dapps might rely on the storage within a web browser to store user-side secrets, which can lead to potential security risks.
diff --git a/docs/tutorials/developer-journey/level-5/5.2-ICP-ETH-tutorial.mdx b/docs/tutorials/developer-journey/level-5/5.2-ICP-ETH-tutorial.mdx
index 16c6e83584..01fda73be0 100644
--- a/docs/tutorials/developer-journey/level-5/5.2-ICP-ETH-tutorial.mdx
+++ b/docs/tutorials/developer-journey/level-5/5.2-ICP-ETH-tutorial.mdx
@@ -17,7 +17,7 @@ import useBaseUrl from "@docusaurus/useBaseUrl";
-## Overview
+
As you explored in a previous tutorial, the Internet Computer is integrated with the Bitcoin network, allowing for smart contracts to seamlessly communicate from ICP to Bitcoin for multi-chain functionality. ICP also has an integration with Ethereum and EVM networks, but in a different manner than the Bitcoin integration.
diff --git a/docs/tutorials/developer-journey/level-5/5.3-token-swap-tutorial.mdx b/docs/tutorials/developer-journey/level-5/5.3-token-swap-tutorial.mdx
index 3cb68ccaf7..e15f34f64b 100644
--- a/docs/tutorials/developer-journey/level-5/5.3-token-swap-tutorial.mdx
+++ b/docs/tutorials/developer-journey/level-5/5.3-token-swap-tutorial.mdx
@@ -17,7 +17,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
The Internet Computer enables decentralized finance (DeFi) applications through its design that includes complex, onchain computation. One primary example of a DeFi application is a decentralized exchange (DEX). A DEX is an exchange that can be used to buy, sell, trade, and withdraw cryptocurrencies and other digital assets without a centralized authority that authorizes the trades, such as bank. Decentralized exchanges are extremely useful, as they allow users to buy and hold cryptocurrencies, trade it directly for another token or coin, then withdraw the tokens to be used elsewhere.
diff --git a/docs/tutorials/developer-journey/level-5/5.4-NFT-tutorial.mdx b/docs/tutorials/developer-journey/level-5/5.4-NFT-tutorial.mdx
index 3b994efeae..27de1e93bd 100644
--- a/docs/tutorials/developer-journey/level-5/5.4-NFT-tutorial.mdx
+++ b/docs/tutorials/developer-journey/level-5/5.4-NFT-tutorial.mdx
@@ -17,7 +17,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
A **non-fungible token**, commonly referred to as an NFT, is a type of tokenized asset that is assigned a unique identifier that is used to distinguish one NFT from another. An NFT cannot be replicated or reproduced since it is cryptographically unique. A non-fungible token is a type of token that cannot be exchanged 1:1 with another token of the same type, as the value of the NFT token can vary. In comparison, a **fungible** token can always be transferred 1:1 for another token of the same type.
diff --git a/docs/tutorials/developer-journey/level-5/5.5-auction-tutorial.mdx b/docs/tutorials/developer-journey/level-5/5.5-auction-tutorial.mdx
index 4de9493fde..94bf2fa02e 100644
--- a/docs/tutorials/developer-journey/level-5/5.5-auction-tutorial.mdx
+++ b/docs/tutorials/developer-journey/level-5/5.5-auction-tutorial.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Until this point in the developer ladder series, each tutorial has focused on a specific use case or feature of ICP. To wrap up the series, this tutorial will showcase how to create a general purpose dapp that provides a real-world use case. In this tutorial, you'll create the foundation for a simple auction dapp.
diff --git a/docs/tutorials/developer-journey/level-5/5.6-next-steps.mdx b/docs/tutorials/developer-journey/level-5/5.6-next-steps.mdx
index 7f54573111..851341cfa6 100644
--- a/docs/tutorials/developer-journey/level-5/5.6-next-steps.mdx
+++ b/docs/tutorials/developer-journey/level-5/5.6-next-steps.mdx
@@ -8,7 +8,7 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
-## Overview
+
Congratulations! You've completed the ICP developer ladder series, and are now an ICP astronaut!
diff --git a/docs/tutorials/hackathon-prep-course/1-what-is-icp.mdx b/docs/tutorials/hackathon-prep-course/1-what-is-icp.mdx
index 9414129a0d..3b7683e0e4 100644
--- a/docs/tutorials/hackathon-prep-course/1-what-is-icp.mdx
+++ b/docs/tutorials/hackathon-prep-course/1-what-is-icp.mdx
@@ -11,7 +11,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
The Internet Computer (ICP) is a transparent and secure blockchain network that enables developers to create and deploy fully decentralized applications. Decentralized applications are created through deploying smart contracts, which are known as **canisters** on ICP. Canisters are highly scalable to directly serve user experiences. Each canister on the Internet Computer is hosted on an independent version of the blockchain network called a **subnet**. **Subnets** can seamlessly communicate with each other.
diff --git a/docs/tutorials/hackathon-prep-course/2-deploying-first-fullstack-dapp.mdx b/docs/tutorials/hackathon-prep-course/2-deploying-first-fullstack-dapp.mdx
index 4fa745910c..1278f842b1 100644
--- a/docs/tutorials/hackathon-prep-course/2-deploying-first-fullstack-dapp.mdx
+++ b/docs/tutorials/hackathon-prep-course/2-deploying-first-fullstack-dapp.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
To get started developing on ICP, there are several sample projects, boilerplate templates, and other resources to help you get started. In this tutorial, you'll learn how to deploy your first full-stack dapp using a boilerplate sample. This sample dapp uses Motoko for the backend canister and the frameworks Vite and React to create a frontend user interface (UI) that makes calls to a simple counter method in the backend canister. When the button in the UI is clicked, the counter function increases the value of the count by an increment of 1. The updated count value is then reflected in the UI.
diff --git a/docs/tutorials/hackathon-prep-course/3-exploring-the-backend.mdx b/docs/tutorials/hackathon-prep-course/3-exploring-the-backend.mdx
index db07240115..a3db8e4d6f 100644
--- a/docs/tutorials/hackathon-prep-course/3-exploring-the-backend.mdx
+++ b/docs/tutorials/hackathon-prep-course/3-exploring-the-backend.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
In the previous tutorial, you deployed a sample full-stack dapp using the `vite-react-motoko` example boilerplate. This tutorial builds off of that previous tutorial, so if you haven't followed [2: Deploying your first fullstack dapp](/docs/current/tutorials/hackathon-prep-course/deploying-first-fullstack-dapp), it is recommended that you complete it prior to starting this tutorial.
diff --git a/docs/tutorials/hackathon-prep-course/4-exploring-the-frontend.mdx b/docs/tutorials/hackathon-prep-course/4-exploring-the-frontend.mdx
index ee79c07349..810e950c97 100644
--- a/docs/tutorials/hackathon-prep-course/4-exploring-the-frontend.mdx
+++ b/docs/tutorials/hackathon-prep-course/4-exploring-the-frontend.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Recall that a frontend canister is used to contain an application's user interface assets. In this tutorial, you will explore the frontend canister code to learn more.
diff --git a/docs/tutorials/hackathon-prep-course/5-integrating-with-tokens.mdx b/docs/tutorials/hackathon-prep-course/5-integrating-with-tokens.mdx
index 42cf363818..766bfb62d4 100644
--- a/docs/tutorials/hackathon-prep-course/5-integrating-with-tokens.mdx
+++ b/docs/tutorials/hackathon-prep-course/5-integrating-with-tokens.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
When building dapps on the Internet Computer, integrating tokens into your dapp may be necessary for enabling DeFi, governance, marketplace, or other tokenomic functions. There are several types of tokens in the Internet Computer ecosystem, such as the protocol's native token ICP, fungible tokens that use the ICRC-1 or ICRC-2 standards, and soon non-fungible tokens that will use the upcoming ICRC-7 standard.
diff --git a/docs/tutorials/hackathon-prep-course/6-authentication.mdx b/docs/tutorials/hackathon-prep-course/6-authentication.mdx
index 97018a6c74..0d66d44f30 100644
--- a/docs/tutorials/hackathon-prep-course/6-authentication.mdx
+++ b/docs/tutorials/hackathon-prep-course/6-authentication.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
For end-users to interact with the frontend of applications on ICP, Internet Identity can be used. Internet Identity is ICP's native form of digital identity that can be used to authenticate with apps, such as the NNS dashboard, without having to manage a username or password. Instead, Internet Identity uses a cryptographic key pair that's stored in your local device's hardware.
diff --git a/docs/tutorials/hackathon-prep-course/7-obtaining-cycles.mdx b/docs/tutorials/hackathon-prep-course/7-obtaining-cycles.mdx
index e21cbc9fae..b0350eb8f9 100644
--- a/docs/tutorials/hackathon-prep-course/7-obtaining-cycles.mdx
+++ b/docs/tutorials/hackathon-prep-course/7-obtaining-cycles.mdx
@@ -11,7 +11,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Cycles are used to measure the resources, such as memory, storage, and compute power, that are used by a canister. When a canister is deployed on the mainnet, cycles are 'charged' for every action that a canister performs.
diff --git a/docs/tutorials/hackathon-prep-course/8-managing-canisters.mdx b/docs/tutorials/hackathon-prep-course/8-managing-canisters.mdx
index 2aff9956de..423e42763f 100644
--- a/docs/tutorials/hackathon-prep-course/8-managing-canisters.mdx
+++ b/docs/tutorials/hackathon-prep-course/8-managing-canisters.mdx
@@ -10,7 +10,7 @@ import '/src/components/CenterImages/center.scss';
-## Overview
+
Now that you have canisters deployed on the mainnet, it's important to learn how to manage and maintain those canisters. Basic canister management includes obtaining information about a canister, adding an identity as a controller of a canister, topping up a canister, starting and stopping a canister, and deleting a canister.
diff --git a/docusaurus.config.js b/docusaurus.config.js
index ca75c2206d..013e249e17 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -198,6 +198,11 @@ const marketingNav = {
href: "/capabilities/sustainability",
description: "Building green, efficient tech",
},
+ {
+ name: "Library",
+ href: "/library",
+ description: "Resources to get you started",
+ },
/*
{
name: "ICP as a Bitcoin L2",
diff --git a/how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md b/how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md
index a6a0529ed1..2e7a630861 100644
--- a/how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md
+++ b/how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md
@@ -75,12 +75,12 @@ dapps on the IC can be governed by an out-of-the-box deployable governance syste
If you want to learn in more detail how the IC works and realizes the vision of a World Computer, read through the sections of the page and the referenced Medium articles, or watch the YouTube videos. If you prefer to have a single source of information, the [White Paper](https://dfinity.org/whitepaper.pdf) is highly recommended. However, note that it is a little technical at times.
-[Internet Computer for Geeks – White Paper](https://dfinity.org/whitepaper.pdf)
-[Internet Computer Dashboard](https://dashboard.internetcomputer.org/)
-[Internet Computer Source Code](https://github.com/dfinity/ic)
-[Public Repositories for the Internet Computer](https://github.com/dfinity?q=&type=public&language=&sort=)
-[Internet Computer Interface Specification Docs](https://internetcomputer.org/docs/current/references/ic-interface-spec)
-[Internet Computer Primer - Deck](https://dfinity.org/deck/)
-[Internet Computer SDK](https://github.com/dfinity/sdk)
+- [Internet Computer for Geeks – White Paper](https://internetcomputer.org/whitepapers/The%20Internet%20Computer%20for%20Geeks.pdf)
+- [Internet Computer Dashboard](https://dashboard.internetcomputer.org/)
+- [Internet Computer Source Code](https://github.com/dfinity/ic)
+- [Public Repositories for the Internet Computer](https://github.com/dfinity?q=&type=public&language=&sort=)
+- [Internet Computer Interface Specification Docs](https://internetcomputer.org/docs/current/references/ic-interface-spec)
+- [Internet Computer Primer - Deck](https://dfinity.org/deck/)
+- [Internet Computer SDK](https://github.com/dfinity/sdk)
[![Watch youtube video](https://i.ytimg.com/vi/YWHTNr8RZHg/maxresdefault.jpg)](https://www.youtube.com/watch?v=YWHTNr8RZHg)
diff --git a/showcase.json b/showcase.json
index 038f2b67a8..b14d487ae5 100644
--- a/showcase.json
+++ b/showcase.json
@@ -334,13 +334,13 @@
{
"id": "catalyze",
"name": "Catalyze",
- "website": "https://aqs24-xaaaa-aaaal-qbbea-cai.ic0.app/",
+ "website": "https://catalyze.one/",
"tags": [
"SocialFi",
"DAO"
],
+ "description": "Catalyze is building the new Web3 social learning hub: Communities, Events & Seamless Token Transfer, all in one place.",
"twitter": "https://x.com/catalyze_one",
- "description": "Catalyze is building the new Web3 social learning hub: Communities, Events & Seamless Token Transfer. Now onboarding KOLs.",
"usesInternetIdentity": true,
"oneLiner": "Manage your Web3 communities and events",
"display": "Large",
@@ -4841,5 +4841,21 @@
],
"github": "https://github.com/tolgayayci/dfx-dashboard",
"website": "https://dfx-dashboard-docs.netlify.app/"
+ },
+ {
+ "id": "icptokens",
+ "name": "ICP Tokens",
+ "tags": [
+ "Tools / Infrastructure"
+ ],
+ "stats": "15,000+ users",
+ "website": "https://icptokens.net",
+ "github": "https://github.com/CyberNinjasLab",
+ "youtube": "https://www.youtube.com/watch?v=2hKfVcJviTM",
+ "twitter": "https://x.com/ICPTokens",
+ "description": "Advanced tool for tracking ICP tokens, designed to simplify the way you monitor, analyze, and manage tokens within the Internet Computer DeFi ecosystem. Portfolio insights, advanced charts and bubble maps for visual insights.",
+ "usesInternetIdentity": true,
+ "display": "Normal",
+ "logo": "/img/showcase/icptokens_logo.svg"
}
]
diff --git a/sidebars.js b/sidebars.js
index bbff85da62..64b175562f 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -14,7 +14,7 @@ const sidebars = {
},
{
type: "doc",
- label: "React",
+ label: "First web app",
id: "developer-docs/getting-started/quickstart/react-quickstart",
},
],
@@ -35,34 +35,29 @@ const sidebars = {
},
{
type: "doc",
- label: "Install tools",
+ label: "Installing developer tools",
id: "developer-docs/getting-started/install",
},
{
type: "doc",
- label: "Create an identity",
+ label: "Creating a developer identity",
id: "developer-docs/getting-started/identities",
},
{
type: "doc",
- label: "Tokens and cycles",
+ label: "Using tokens and cycles",
id: "developer-docs/getting-started/tokens-and-cycles",
},
{
type: "doc",
- label: "Write smart contracts",
+ label: "Writing smart contracts",
id: "developer-docs/getting-started/write-smart-contracts",
},
{
type: "doc",
- label: "Deploy and manage",
+ label: "Deploying and managing dapps",
id: "developer-docs/getting-started/deploy-and-manage",
},
- {
- type: "doc",
- label: "Next steps",
- id: "developer-docs/getting-started/next-steps",
- },
],
},
{
diff --git a/static/img/blog/dev-update-blog-dec-11.jpg b/static/img/blog/dev-update-blog-dec-11.jpg
new file mode 100644
index 0000000000..a219d0ce29
Binary files /dev/null and b/static/img/blog/dev-update-blog-dec-11.jpg differ
diff --git a/static/img/showcase/icptokens_logo.svg b/static/img/showcase/icptokens_logo.svg
new file mode 100644
index 0000000000..989baa37fa
--- /dev/null
+++ b/static/img/showcase/icptokens_logo.svg
@@ -0,0 +1,34 @@
+
+
\ No newline at end of file