From 792333d3e1187d437558ee89508c7cf52993fb48 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABl=20Blanchemain?= Date: Fri, 15 Nov 2024 11:28:51 -0800 Subject: [PATCH] fix: md > mdx conversion --- .../{03-public-chains.md => 03-public-chains.mdx} | 0 ...04-cross-chain-messaging.md => 04-cross-chain-messaging.mdx} | 0 .../build-decentralized-apps/token-bridging/01-overview.md | 2 +- .../token-bridging/03-token-bridge-erc20.md | 2 +- .../nitro/02-migrate-state-and-history-from-classic.md | 2 +- 5 files changed, 3 insertions(+), 3 deletions(-) rename arbitrum-docs/build-decentralized-apps/{03-public-chains.md => 03-public-chains.mdx} (100%) rename arbitrum-docs/build-decentralized-apps/{04-cross-chain-messaging.md => 04-cross-chain-messaging.mdx} (100%) diff --git a/arbitrum-docs/build-decentralized-apps/03-public-chains.md b/arbitrum-docs/build-decentralized-apps/03-public-chains.mdx similarity index 100% rename from arbitrum-docs/build-decentralized-apps/03-public-chains.md rename to arbitrum-docs/build-decentralized-apps/03-public-chains.mdx diff --git a/arbitrum-docs/build-decentralized-apps/04-cross-chain-messaging.md b/arbitrum-docs/build-decentralized-apps/04-cross-chain-messaging.mdx similarity index 100% rename from arbitrum-docs/build-decentralized-apps/04-cross-chain-messaging.md rename to arbitrum-docs/build-decentralized-apps/04-cross-chain-messaging.mdx diff --git a/arbitrum-docs/build-decentralized-apps/token-bridging/01-overview.md b/arbitrum-docs/build-decentralized-apps/token-bridging/01-overview.md index e624f8c9d..034c72fae 100644 --- a/arbitrum-docs/build-decentralized-apps/token-bridging/01-overview.md +++ b/arbitrum-docs/build-decentralized-apps/token-bridging/01-overview.md @@ -7,7 +7,7 @@ content_type: overview sidebar_position: 1 --- -Token bridging is a fundamental aspect of any Layer 2 (L2) protocol. Arbitrum uses its ability to pass messages between L1 and L2 (see [Cross-chain messaging](/build-decentralized-apps/04-cross-chain-messaging.md)) to allow projects to trustlessly move assets from Ethereum to an Arbitrum chain and back. Any asset and asset type can in principle be bridged, including Ether, ERC-20 tokens and ERC-721 tokens among others. +Token bridging is a fundamental aspect of any Layer 2 (L2) protocol. Arbitrum uses its ability to pass messages between L1 and L2 (see [Cross-chain messaging](/build-decentralized-apps/04-cross-chain-messaging.mdx)) to allow projects to trustlessly move assets from Ethereum to an Arbitrum chain and back. Any asset and asset type can in principle be bridged, including Ether, ERC-20 tokens and ERC-721 tokens among others. This section offers a series of conceptual documents explaining how asset bridging works and what options exist to bridge ether (ETH) and other types of asset between layers, as well as a series of how-tos showcasing the different methods available for making your token bridgeable. diff --git a/arbitrum-docs/build-decentralized-apps/token-bridging/03-token-bridge-erc20.md b/arbitrum-docs/build-decentralized-apps/token-bridging/03-token-bridge-erc20.md index 365d5559b..60a51e557 100644 --- a/arbitrum-docs/build-decentralized-apps/token-bridging/03-token-bridge-erc20.md +++ b/arbitrum-docs/build-decentralized-apps/token-bridging/03-token-bridge-erc20.md @@ -7,7 +7,7 @@ content_type: concept sidebar_position: 3 --- -The Arbitrum protocol itself technically has no native notion of any token standards, and gives no built-in advantage or special recognition to any particular token bridge. In this page we describe the "canonical bridge", which was implemented by Offchain Labs, and should be the primary bridge most users and applications use; it is (effectively) a decentralized app (dApp) with contracts on both Ethereum (the Layer 1, or L1) and Arbitrum (the Layer 2, or L2) that leverages Arbitrum's [cross-chain message passing system](/build-decentralized-apps/04-cross-chain-messaging.md) to achieve basic desired token-bridging functionality. We recommend that you use it! +The Arbitrum protocol itself technically has no native notion of any token standards, and gives no built-in advantage or special recognition to any particular token bridge. In this page we describe the "canonical bridge", which was implemented by Offchain Labs, and should be the primary bridge most users and applications use; it is (effectively) a decentralized app (dApp) with contracts on both Ethereum (the Layer 1, or L1) and Arbitrum (the Layer 2, or L2) that leverages Arbitrum's [cross-chain message passing system](/build-decentralized-apps/04-cross-chain-messaging.mdx) to achieve basic desired token-bridging functionality. We recommend that you use it! ## Design rationale diff --git a/arbitrum-docs/run-arbitrum-node/nitro/02-migrate-state-and-history-from-classic.md b/arbitrum-docs/run-arbitrum-node/nitro/02-migrate-state-and-history-from-classic.md index 67b08cc56..2ad1f1603 100644 --- a/arbitrum-docs/run-arbitrum-node/nitro/02-migrate-state-and-history-from-classic.md +++ b/arbitrum-docs/run-arbitrum-node/nitro/02-migrate-state-and-history-from-classic.md @@ -8,7 +8,7 @@ content_type: how-to sidebar_position: 11 --- -When running a Nitro node for the first time on a chain that produced [classic blocks](/build-decentralized-apps/03-public-chains.md#classic-deprecated) in the past (like Arbitrum One), you need to initialize its database to, at least, the state of the chain after executing the last classic block. The common, and recommended, way of doing that is to provide a database snapshot using the `--init.url` option (as mentioned in [How to run a full node (Nitro)](/run-arbitrum-node/03-run-full-node.md)). In this how-to we show you an alternative way for doing that, migrating the state and history of the chain from a fully synced classic node. +When running a Nitro node for the first time on a chain that produced [classic blocks](/build-decentralized-apps/03-public-chains.mdx#classic-deprecated) in the past (like Arbitrum One), you need to initialize its database to, at least, the state of the chain after executing the last classic block. The common, and recommended, way of doing that is to provide a database snapshot using the `--init.url` option (as mentioned in [How to run a full node (Nitro)](/run-arbitrum-node/03-run-full-node.md)). In this how-to we show you an alternative way for doing that, migrating the state and history of the chain from a fully synced classic node. :::info Is this How-to for you?