fix links

wiki-docs/docs/design/bridge/assets/erc/erc1155.md

@@ -2,13 +2,13 @@ ERC-1155 is a token standard that enables the creation of both fungible and non-
 
 ## ChildERC1155
 
-Developers can use the [`ChildERC1155`](../../../../../interfaces/erc1155/childerc1155/) token standard to create ERC-1155 tokens on an Edge-powered chain. To create a new ChildERC1155 token, developers can use the `ChildERC1155` contract as a template and deploy it on the Edge-powered chain. The contract requires a name and symbol to determine the unique identity of the token.
+Developers can use the [`ChildERC1155`](../../../../interfaces/erc1155/childerc1155.md) token standard to create ERC-1155 tokens on an Edge-powered chain. To create a new ChildERC1155 token, developers can use the `ChildERC1155` contract as a template and deploy it on the Edge-powered chain. The contract requires a name and symbol to determine the unique identity of the token.
 
 Once created, `ChildERC1155` tokens can be minted and burned on the Edge-powered chain through the corresponding ERC1155Predicate contract. This ensures that the supply of tokens on the rootchain and the Edge-powered chain remains in sync. The `ERC1155Predicate` contract also allows for the transfer of tokens between the two.
 
 ## Predicates
 
-The [`RootERC1155Predicate`](../../../../../interfaces/erc1155/rooterc1155-predicate/) contract serves as the root token contract, while the [`ChildERC1155Predicate`](../../../../../interfaces/erc1155/childerc1155-predicate) contract serves as the child token contract. When a user wants to deposit an ERC-1155 token on the rootchain into the Edge-powered chain, they call the deposit function on the `RootERC1155Predicate` contract with the appropriate parameters, including the token ID, sender, and receiver addresses.
+The [`RootERC1155Predicate`](../../../../interfaces/erc1155/rooterc1155-predicate.md) contract serves as the root token contract, while the [`ChildERC1155Predicate`](../../../../interfaces/erc1155/childerc1155-predicate.md) contract serves as the child token contract. When a user wants to deposit an ERC-1155 token on the rootchain into the Edge-powered chain, they call the deposit function on the `RootERC1155Predicate` contract with the appropriate parameters, including the token ID, sender, and receiver addresses.
 
 Once the child contract instance is created, the `RootERC1155Predicate` contract maps the root token to the child token using a mapping, allowing users to deposit and withdraw tokens between the root and Edge-powered chain. The ChildERC1155Predicate contract includes functions for minting and burning child tokens, which are triggered when the deposit and withdrawal functions are called.
 

wiki-docs/docs/design/bridge/assets/erc/erc20.md

@@ -2,13 +2,13 @@ Edge provides developers with two standards for creating ERC-20 fungible tokens
 
 ## ChildERC20
 
-The [`ChildERC20`](../../../../../interfaces/erc20/childerc20) token standard is used for tokens mapping and enables developers to create tokens on both the Edge-powered chain and the associated rootchain. To create a new `ChildERC20` token, developers can use the `ChildERC20` contract as a template and deploy it on their Edge-powered chain. The contract requires a name, symbol, and number of decimals to determine the minimum unit of the token.
+The [`ChildERC20`](../../../../interfaces/erc20/childerc20.md) token standard is used for tokens mapping and enables developers to create tokens on both the Edge-powered chain and the associated rootchain. To create a new `ChildERC20` token, developers can use the `ChildERC20` contract as a template and deploy it on their Edge-powered chain. The contract requires a name, symbol, and number of decimals to determine the minimum unit of the token.
 
-`ChildERC20` tokens are minted and burned on the Edge-powered chain through the corresponding [`ERC20Predicate`](../../../../../interfaces/erc20/childerc20-predicate/) contract. This ensures that the supply of tokens on the rootchain and the Edge-powered chain remains in sync. The `ERC20Predicate` contract also allows for the transfer of tokens between the two networks using the native bridge.
+`ChildERC20` tokens are minted and burned on the Edge-powered chain through the corresponding [`ERC20Predicate`](../../../../interfaces/erc20/childerc20-predicate.md) contract. This ensures that the supply of tokens on the rootchain and the Edge-powered chain remains in sync. The `ERC20Predicate` contract also allows for the transfer of tokens between the two networks using the native bridge.
 
 ## NativeERC20
 
-The [`NativeERC20`](../../../../../interfaces/erc20/native-erc20/) token standard represents native tokens on Edge and offers fast and inexpensive transactions. It is deployed only on the Edge-powered chain and relies on the native transfer precompile to make transfers. The `NativeERC20` tokens can be minted and burned by the associated predicate contract.
+The [`NativeERC20`](../../../../interfaces/erc20/native-erc20.md) token standard represents native tokens on Edge and offers fast and inexpensive transactions. It is deployed only on the Edge-powered chain and relies on the native transfer precompile to make transfers. The `NativeERC20` tokens can be minted and burned by the associated predicate contract.
 
 In addition, developers can use the `NativeERC20Mintable` contract to create and manage `NativeMintable` tokens, which are fungible tokens that represent assets on the Edge-powered chain. These tokens can be managed through the native bridge contract and transferred between an Edge-powered chain and rootchain networks.
 

wiki-docs/docs/design/bridge/assets/erc/erc721.md

@@ -3,13 +3,13 @@ ERC-721 is a token standard that allows for the creation of unique, non-fungible
 
 ## ChildERC721
 
-Developers can use the [`ChildERC721`](../../../../../interfaces/erc721/childerc721/) token standard to create ERC-721 tokens on the Edge-powered chain. To create a new ChildERC721 token, developers can use the ChildERC721 predicate contract as a template and deploy it on the Edge-powered chain. The contract requires a name and symbol to determine the unique identity of the token.
+Developers can use the [`ChildERC721`](../../../../interfaces/erc721/childerc721.md) token standard to create ERC-721 tokens on the Edge-powered chain. To create a new ChildERC721 token, developers can use the ChildERC721 predicate contract as a template and deploy it on the Edge-powered chain. The contract requires a name and symbol to determine the unique identity of the token.
 
 Once created, `ChildERC721` tokens can be minted and burned on the Edge-powered chain through the corresponding `ERC721Predicate` contract. This ensures that the supply of tokens on the rootchain and the Edge-powered chain remains in sync. The `ERC721Predicate` contract also allows for the transfer of tokens between the two networks using the native bridge.
 
 ## Predicates
 
-The [`RootERC721Predicate`](../../../../../interfaces/erc721/rooterc721-predicate/)  contract serves as the rootchain token predicate contract, while the [`ChildERC721Predicate`](../../../../../interfaces/erc721/childerc721-predicate/) contract serves as the Edge-powered chain token predicate contract. When a user wants to deposit an ERC-721 token on the rootchain into the Edge-powered chain, they call the `deposit` function on the `RootERC721Predicate` contract with the appropriate parameters, including the token ID, sender, and receiver addresses.
+The [`RootERC721Predicate`](../../../../interfaces/erc721/rooterc721-predicate.md)  contract serves as the rootchain token predicate contract, while the [`ChildERC721Predicate`](../../../../interfaces/erc721/childerc721-predicate.md) contract serves as the Edge-powered chain token predicate contract. When a user wants to deposit an ERC-721 token on the rootchain into the Edge-powered chain, they call the `deposit` function on the `RootERC721Predicate` contract with the appropriate parameters, including the token ID, sender, and receiver addresses.
 
 When a user deposits a token for the first time, the token mapping between the root and Edge-powered chain is created automatically. This mapping allows users to deposit and withdraw tokens between the root and Edge-powered chain.
 

wiki-docs/docs/design/consensus/polybft/overview.md

@@ -5,7 +5,7 @@ The consensus mechanism comprises two key components, a **consensus engine** and
 PolyBFT utilizes the IBFT consensus engine and a Proof-of-Stake architecture to seal blocks, provide specific network capabilities, and govern the network.
 The core smart contracts work in tandem with the consensus engine to define all the network's Proof-of-Stake rules.
 
-![bridge](/img/edge/polybft.excalidraw.png)
+![bridge](../../..//img/edge/polybft.excalidraw.png)
 
 The consensus engine of PolyBFT is based on the Istanbul Byzantine Fault Tolerance [<ins>(IBFT 2.0) protocol</ins>](https://github.com/0xPolygon/go-ibft), which is responsible for sealing blocks on the blockchain.
 The IBFT 2.0 protocol ensures that network integrity is maintained even in the presence of malicious or dishonest nodes.
@@ -15,7 +15,7 @@ Each PolyBFT node maintains a local copy of the blockchain, represented as a lis
 
 PolyBFT's consensus protocol is implemented through a set of core smart contracts. These contracts serve multiple purposes, including enabling staking functionality and defining an incentivization scheme for validators on the network, managing the validator set, and facilitating cross-chain communication through a native bridge.
 
-![bridge](/img/edge/contracts.excalidraw.png)
+![bridge](../../../img/edge/contracts.excalidraw.png)
 
 ## Bridge
 

wiki-docs/docs/design/consensus/polybft/protocol.md

@@ -114,10 +114,10 @@ the integrity of the blockchain.
 ## Native bridge integration
 
 With the help of PolyBFT, Edge supports an
-[in-built bridging mechanism (a two-way bridge)](/design/bridge/overview/),
+[in-built bridging mechanism (a two-way bridge)](../../bridge/overview.md),
 which enables arbitrary message passing between an Edge-powered chain and another Proof-of-Stake
 blockchain (`rootchain`). Transfers can occur without mapping.
 
-![bridge](/img/edge/contracts-bridge.excalidraw.png)
+![bridge](../../../img/edge/contracts-bridge.excalidraw.png)
 
-Learn more [here](/design/bridge/overview/)).
+Learn more [here](../../bridge/overview.md)).

wiki-docs/docs/design/overview.md

@@ -10,12 +10,12 @@ The following table breaks down each of these components.
 
 | Component | Description | Link |
 | --- | --- | --- |
-| libp2p | Provides the networking layer for Edge and is designed for peer-to-peer network architectures. | [<ins>libp2p Overview</ins>](/design/libp2p) |
-| Bridge | An in-built bridging mechanism enabled by PolyBFT that allows message passing between an Edge-powered chain and another Proof-of-Stake blockchain without mapping. | [<ins>Native Bridge overview</ins>](/design/bridge/overview) |
-| Mempool | Enables multiple validators to aggregate their signatures to create a single, aggregated signature representing all validators in the pool. | [<ins>mempool Overview</ins>](/design/mempool) |
-| Consensus | PolyBFT serves as the consensus mechanism of Polygon Edge and consists of a consensus engine, IBFT 2.0, and a consensus protocol that includes the bridge, staking, and other utilities. | [<ins>PolyBFT Overview</ins>](/design/consensus/polybft/overview/) |
-| Blockchain | Coordinates everything in the system, curates state transitions, and is responsible for state changes when a new block is added to the chain. | [<ins>Blockchain Overview</ins>](/design/blockchain) |
-| Runtime (EVM) | Uses the EVM as the runtime environment for executing smart contracts. | [<ins>Runtime Overview</ins>](/design/runtime/overview) |
-| TxPool | Represents the transaction pool, closely linked with other modules in the system. | [<ins>TxPool Overview</ins>](/design/txpool) |
-| JSON-RPC | Facilitates interaction between dApp developers and the blockchain, allowing developers to issue JSON-RPC requests to an Edge node and receive responses. | [<ins>JSON-RPC Overview</ins>](/design/jsonrpc) |
-| gRPC | Essential for operator interactions, allowing node operators to interact with the client easily and providing a seamless user experience. | [<ins>gRPC Overview</ins>](/design/grpc) |
+| libp2p | Provides the networking layer for Edge and is designed for peer-to-peer network architectures. | [<ins>libp2p Overview</ins>](libp2p.md) |
+| Bridge | An in-built bridging mechanism enabled by PolyBFT that allows message passing between an Edge-powered chain and another Proof-of-Stake blockchain without mapping. | [<ins>Native Bridge overview</ins>](bridge/overview.md) |
+| Mempool | Enables multiple validators to aggregate their signatures to create a single, aggregated signature representing all validators in the pool. | [<ins>mempool Overview</ins>](mempool.md) |
+| Consensus | PolyBFT serves as the consensus mechanism of Polygon Edge and consists of a consensus engine, IBFT 2.0, and a consensus protocol that includes the bridge, staking, and other utilities. | [<ins>PolyBFT Overview</ins>](consensus/polybft/overview.md) |
+| Blockchain | Coordinates everything in the system, curates state transitions, and is responsible for state changes when a new block is added to the chain. | [<ins>Blockchain Overview</ins>](blockchain.md) |
+| Runtime (EVM) | Uses the EVM as the runtime environment for executing smart contracts. | [<ins>Runtime Overview</ins>](runtime/overview.md) |
+| TxPool | Represents the transaction pool, closely linked with other modules in the system. | [<ins>TxPool Overview</ins>](txpool.md) |
+| JSON-RPC | Facilitates interaction between dApp developers and the blockchain, allowing developers to issue JSON-RPC requests to an Edge node and receive responses. | [<ins>JSON-RPC Overview</ins>](jsonrpc.md) |
+| gRPC | Essential for operator interactions, allowing node operators to interact with the client easily and providing a seamless user experience. | [<ins>gRPC Overview</ins>](grpc.md) |

wiki-docs/docs/faq.md

@@ -48,7 +48,7 @@ Yes, the bridge can connect to any EVM-compatible rootchain (e.g. Polygon PoS).
 
 ## What assets are supported on the bridge?
 
-The bridge currently supports ERC-20, ERC-721, and ERC-1155 tokens for transfer. However, support for other asset types will soon be available. It is important to keep in mind that not all tokens have the same functionality and capabilities. Users should review the [bridge document](/design/bridge/overview/) to understand how to use tokens with the bridge.
+The bridge currently supports ERC-20, ERC-721, and ERC-1155 tokens for transfer. However, support for other asset types will soon be available. It is important to keep in mind that not all tokens have the same functionality and capabilities. Users should review the [bridge document](design/bridge/overview.md) to understand how to use tokens with the bridge.
 
 As the Edge ecosystem evolves, the bridge will support additional assets, enhancing interoperability between various blockchain networks and applications.
 
@@ -73,7 +73,7 @@ To upgrade to a new blockchain with PolyBFT consensus using IBFT 2.0, you'll nee
 - Create a new genesis block for the new blockchain with PolyBFT consensus using IBFT 2.0.
 - Migrate the data and state from the old blockchain to the new blockchain. **Currently, the product suite only support state migration.**
 
-For more information on the migration process, please refer to the migration guide available [<ins>here</ins>](/operate/ibft-to-polybft/).
+For more information on the migration process, please refer to the migration guide available [<ins>here</ins>](operate/ibft-to-polybft.md).
 
 ## Does the current implementation support configuration of an RPC node and full node?
 

wiki-docs/docs/operate/deploy/access-control/allowlist-general.md

@@ -34,7 +34,7 @@ function readAddressList(address) returns (uint256)
 - `EnabledRole`: The address has some permissions.
 - `AdminRole`: The address has all permissions and can change the roles of other addresses.
 
-**For more information about how ACLs work in Edge, check out the overview guide [<ins>here</ins>](/design/runtime/allowlist).**
+**For more information about how ACLs work in Edge, check out the overview guide [<ins>here</ins>](../../../design/runtime/allowlist.md).**
 
 ```go
 NoRole      Role = Role(types.StringToHash("..."))

wiki-docs/docs/operate/deploy/genesis-validators.md

@@ -135,4 +135,4 @@ In the following example command, we use a placeholder hex-encoded private key o
 
 With all the necessary configurations in place for the Edge-powered chain, we are ready to proceed with starting the chain.
 
-Navigate to the [<ins>Start Your Chain</ins>](/operate/deploy/start-chain) deployment guide, which will provide you with instructions on how to initiate and launch the chain.
+Navigate to the [<ins>Start Your Chain</ins>](start-chain.md) deployment guide, which will provide you with instructions on how to initiate and launch the chain.

wiki-docs/docs/operate/deploy/genesis.md

@@ -347,7 +347,7 @@ Genesis written to ./genesis.json
 
 When setting up the initial chain state for a multiple-host validator setup, you'll need to specify the validator information using the `--validators` flag in the following format: `<multi_address>:<public_ECDSA_address>:<public_BLS_key>:<BLS_signature>`.
 
-This follows the [libp2p multiaddr format](/design/libp2p): `<ip4><ip_address><transport><port><p2p><node_id>`.
+This follows the [libp2p multiaddr format](../../design/libp2p.md): `<ip4><ip_address><transport><port><p2p><node_id>`.
 
 In this example, we will designate the first and second nodes as bootnodes for all other nodes. Nodes connecting to node 1 or 2 will receive information on how to connect to each other through the mutually contacted bootnode. For the ports, we will use `30301` for the first node and `30302` for the second node. Since we are running on localhost, it is safe to assume that the `ip_address` is `127.0.0.1`. If you are not running on your localhost, please update accordingly.
 
@@ -554,4 +554,4 @@ Genesis written to ./genesis.json
 
 With a **genesis.json** file containing the initial chain state, validator nodes, and chain admins for your new childchain instance, you are ready to proceed.
 
-To configure the associated rootchain of the Edge-powered chain and deploy the essential rootchain core contracts, navigate to the [<ins>Rootchain Deployment guide</ins>](/operate/deploy/rootchain-config).
+To configure the associated rootchain of the Edge-powered chain and deploy the essential rootchain core contracts, navigate to the [<ins>Rootchain Deployment guide</ins>](rootchain-config.md).