MXCzkEVM · sheenhx · Aug 2, 2024 · Aug 2, 2024 · Aug 2, 2024
diff --git a/docs/Designs/Bridge.md b/docs/Designs/Bridge.md
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 4
+sidebar_position: 5
 ---
 
 # Bridge to L1/L2
@@ -26,7 +26,6 @@ The bridge, a technological masterpiece, comprises a set of intelligent contract
 
 It is worth noting that this bridge is just one of the many possibilities built on top of zkEVM, and it serves as a testament to the platform's immense potential. In fact, anyone can leverage the signal service to build bridges, which underscores the flexibility and scalability of this innovative platform. If you're curious about the bridge, you can explore its features and functionalities by [trying it out yourself](https://wannsee).
 
-
 ## How to bridge ETH
 
 Even though ETH is not the default gas fee in MXC zkEVM, there is still a possibility to bridge and use ETH on the platform. This is made possible by the existence of Wrapped ETH [(WETH)](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1) in the Arbitrum chain, which can be effortlessly ported to MXC SupernodeV2 using the bridge.

diff --git a/docs/Designs/DA.md b/docs/Designs/DA.md
@@ -1,8 +1,9 @@
 ---
-sidebar_position: 9
+sidebar_position: 10
 ---
 
 # Data Availability
+
 > With the MXC zkEVM DA module leveraging IPNS for data storage, only state roots and a necessary subset of transaction data are sent to Arbitrum (L2), while the bulk of the transaction batch data is posted to IPNS. For decentralized applications (dApps) with high gas consumption, they can operate at the same cost as a standard transaction (like a transfer) on MXC zkEVM, and the Arbitrum fee will not escalate with the complexity of L3 transaction execution. As a result, for transactions of high complexity, this approach can save up to approximately 70% of the cost compared to traditional L2 rollup fees on Arbitrum.
 
 :::tip Ontario Upgrade

diff --git a/docs/Designs/Gas.md b/docs/Designs/Gas.md
@@ -1,6 +1,7 @@
 ---
-sidebar_position: 8
+sidebar_position: 9
 ---
+
 # Gas Fee for Layer3
 
 There are two parties a user pays when submitting a tx:
@@ -16,7 +17,7 @@ The L3 component consists of the traditional fees Geth would pay to stakers in a
 
 Every zkEVM transaction has two costs: An L3 (execution) fee and an L2 (security) fee. At a high level, the L3 fee is the cost to execute your transaction in L3 and the L2 fee is the estimated cost to publish your transaction on L2 (in a rollup batch). Typically the L2 security fee is much higher than the L3 execution fee, so if you can wait it makes sense to postpone transactions until gas prices are lower (for example, over the weekend).
 
-L3 execution fee is charged as tx.gasPrice * l3GasUsed (up to tx.gasLimit). You can check the current L3 gas price in explorer. The transaction gas price is composed of two components: a base fee and a priority fee, because we are EIP 1559 compliant (although with different parameter values).
+L3 execution fee is charged as tx.gasPrice \* l3GasUsed (up to tx.gasLimit). You can check the current L3 gas price in explorer. The transaction gas price is composed of two components: a base fee and a priority fee, because we are EIP 1559 compliant (although with different parameter values).
 
 L2 security fee that pays for the cost of publishing the transaction on L2 (the cost of Ethereum equivalent security). It is deducted automatically from the supernode's ETH balance on Arbitrum One. It is based on three factors that are multiplied together:
 

diff --git a/docs/Designs/Hexagons.md b/docs/Designs/Hexagons.md
@@ -1,39 +1,44 @@
 ---
-sidebar_position: 10
+sidebar_position: 11
 ---
 
 ## Hexagon-Based Geographical Partitioning
 
 ![hex](https://raw.githubusercontent.com/MXCzkEVM/SupernodeV2-devdocs/main/docs/Tutorials/img/name-hexagon/step2/getHexagonAddress.png)
 
-
 ### Concept Overview:
+
 - **World Segmentation**: Divides the world into approximately 98 million hexagonal cells.
 - **Hexagon Dimensions**: Each hexagon covers an area of roughly 5 km², with a diameter of about 2 km.
 - **Origin Point**: The hexagonal grid originates in Berlin, Germany, serving as the anchor point for this global grid system.
 
 ### Technical Details:
+
 - **H3 Geospatial Indexing**: Utilizes the H3 Geospatial Indexing Framework, as detailed on [H3Geo's documentation](https://h3geo.org/docs/core-library/restable/).
 - **Resolution Choice**: MXC has selected 'Resolution 7' for this grid, balancing granularity and computational efficiency.
 - **Balance of Detail and Efficiency**: The resolution choice balances the detail of geospatial data and the processing efficiency.
 
 ## Privacy Considerations
 
 ### Key Feature:
+
 - **Privacy through Hexagons**: Enhanced privacy through hexagon-based geolocation.
 - **Hexagon ID Sharing**: Users share only their hexagon ID, not precise coordinates.
 
 ### Privacy Mechanism:
+
 - **Location Ambiguity**: By sharing just a hexagon ID, an individual's exact location remains ambiguous within a 5 km² area.
 - **Reduced Tracking Risk**: This system significantly reduces the risk of location tracking and personal data exposure.
 
 ## Web3 Integration
 
 ### Core Concept:
+
 - **Web3 Native Design**: The system is inherently Web3-oriented, integrating seamlessly with decentralized technologies.
 - **Unique Hexagon Identification**: Hexagons can be uniquely identified and interacted with using MXC domain names (e.g., berlin.mxc).
 
 ### Applications:
+
 - **Infrastructure for DApps**: Provides a robust infrastructure for DApps (Decentralized Applications) focusing on geolocation-based services.
 - **Innovative Applications**: Enables innovative applications such as secure tracking systems and decentralized Point of Interest (DePIN) inscriptions.
 
@@ -42,7 +47,7 @@ sidebar_position: 10
 ES6 usage:
 
 ```js
-import {latLngToCell} from "h3-js";
+import { latLngToCell } from "h3-js";
 ```
 
 CommonJS usage:
@@ -73,7 +78,6 @@ const hexBoundary = h3.cellToBoundary(h3Index);
 // -> [ [37.341099093235684, -122.04156135164334 ], ...]
 ```
 
-
 ## Name a hexagon
 
 The hexagons can be indexed and named using MNS : https://doc.mxc.com/docs/Tutorials/name-hexagon#5-navigate-back-to-wannsee-mns-and-set-hexagon-to-your-domain-name

diff --git a/docs/Designs/LPWAN.md b/docs/Designs/LPWAN.md
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 4
 ---
 
 # IoT LPWAN Protocol
@@ -18,12 +18,11 @@ A more detailed illustration is as follows:
 
 MEP stands for MXC Evolution Proposal. Each MEP will be a proposal document providing information to the MXC zkEVM ecosystem and community.
 
-
 Here is the list of subjects of MEPs:
 
-| MEP Number                        | Title                                                    | Type      | Status |
-| --------------------------------- | -------------------------------------------------------- | --------- | ------ |
-| [MEP-1](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1.md) | Purpose and Guidelines | Process   | Living |
+| MEP Number                                                                   | Title                                                    | Type      | Status |
+| ---------------------------------------------------------------------------- | -------------------------------------------------------- | --------- | ------ |
+| [MEP-1](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1.md)       | Purpose and Guidelines                                   | Process   | Living |
 | [MEP-20](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-20.md)     | Tokens Standrds on MXC zkEVM Chain                       | Standards | Living |
 | [MEP-721](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-721.md)   | Non-Fungible Token Standard on MXC zkEVM Chain           | Standards | Draft  |
 | [MEP-801](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-801.md)   | ISO Application Contract                                 | Standards | Draft  |
@@ -32,8 +31,6 @@ Here is the list of subjects of MEPs:
 | [MEP-804](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-804.md)   | ISO Reward Token Contract                                | Standards | Draft  |
 | [MEP-1002](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1002.md) | Nestable Non-Fungible Tokens Tied to IoT Geolocations    | Standards | Living |
 | [MEP-1004](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1004.md) | Non-Fungible Tokens Tied to IoT Radio Base Station Miner | Standards | Living |
-| [MEP-1759](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1759.md) | MXC DApp Store Metadata Standard                         | Standards | Living|
+| [MEP-1759](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1759.md) | MXC DApp Store Metadata Standard                         | Standards | Living |
 | [MEP-600](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-600.md)   | NFT NFC Contract                                         | Standards | Draft  |
-| [MEP-2542](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-2542.md) | Multi-Token Mining for MEP-1004 Radio Miners           | Standards | Living  |
-
-
+| [MEP-2542](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-2542.md) | Multi-Token Mining for MEP-1004 Radio Miners             | Standards | Living |