diff --git a/docusaurus.config.ts b/docusaurus.config.ts index 99596b3..70656fa 100644 --- a/docusaurus.config.ts +++ b/docusaurus.config.ts @@ -42,6 +42,15 @@ const config: Config = { ], }, ], + [ + '@docusaurus/plugin-content-docs', + { + id: 'labs', + path: 'labs', + routeBasePath: 'labs', + sidebarPath: './sidebars.ts', + }, + ], ], presets: [ @@ -52,7 +61,6 @@ const config: Config = { sidebarPath: './sidebars.ts', remarkPlugins: [remarkMath], rehypePlugins: [rehypeKatex], - }, blog: false, // { @@ -96,14 +104,21 @@ const config: Config = { items: [ { type: 'docSidebar', - sidebarId: 'sidebar', + sidebarId: 'sidebarDocs', position: 'left', label: 'Docs', - hideable: true, activeBaseRegex: 'docs/(next|v8)', - baseUrl: '/docs/', to: '/docs/index', }, + { + type: 'docSidebar', + sidebarId: 'sidebarDocs', + docsPluginId:"labs", + position: 'left', + label: 'Labs', + // activeBaseRegex: 'labs/(next|v8)', + // to: '/labs', + }, // {to: '/blog', label: 'Blog', position: 'left'}, { label: "GitHub", diff --git a/labs/contract-addresses/_category_.json b/labs/contract-addresses/_category_.json new file mode 100644 index 0000000..376c9f1 --- /dev/null +++ b/labs/contract-addresses/_category_.json @@ -0,0 +1,4 @@ +{ + "position": 3, + "label": "Contract Addresses" +} diff --git a/labs/contract-addresses/mainnet.md b/labs/contract-addresses/mainnet.md new file mode 100644 index 0000000..adf96fc --- /dev/null +++ b/labs/contract-addresses/mainnet.md @@ -0,0 +1,72 @@ +--- +sidebar_position: 1 +--- + +# Mainnet + +## Ethereum + +- chainId: 1 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://etherscan.io/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnOppositeBridge(v2): [0x48d769d5C7ff75703cDd1543A1a2ed9bC9044A23](https://etherscan.io/address/0x48d769d5C7ff75703cDd1543A1a2ed9bC9044A23) + +## Arbitrum One + +- chainId: 42161 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://arbiscan.io/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnOppositeBridge(v2): [0x48d769d5C7ff75703cDd1543A1a2ed9bC9044A23](https://arbiscan.io/address/0x48d769d5C7ff75703cDd1543A1a2ed9bC9044A23) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://arbiscan.io/address/0xbA5D580B18b6436411562981e02c8A9aA1776D10) + +## Darwinia + +- chainId: 46 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://darwinia.subscan.io/account/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnOppositeBridge(v2): [0x48d769d5C7ff75703cDd1543A1a2ed9bC9044A23](https://darwinia.subscan.io/account/0x48d769d5C7ff75703cDd1543A1a2ed9bC9044A23) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://darwinia.subscan.io/account/0xbA5D580B18b6436411562981e02c8A9aA1776D10) + +## Pologon Pos + +- chainId: 137 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://polygonscan.com/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://polygonscan.com/address/0xbA5D580B18b6436411562981e02c8A9aA1776D10) + +## zkSync era + +- chainId: 324 +- LnDefaultBridge(v2): [0x767Bc046c989f5e63683fB530f939DD34b91ceAC](https://era.zksync.network/address/0x767Bc046c989f5e63683fB530f939DD34b91ceAC) + +## Binance Smart Chain + +- chinaId: 56 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://bscscan.com/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://bscscan.com/address/0xbA5D580B18b6436411562981e02c8A9aA1776D10) + +## Linea + +- chainId: 59144 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://lineascan.build/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://lineascan.build/address/0xbA5D580B18b6436411562981e02c8A9aA1776D10) + +## Mantle + +- chainId: 5000 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://explorer.mantle.xyz/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://explorer.mantle.xyz/address/0xbA5D580B18b6436411562981e02c8A9aA1776D10) + +## Scroll + +- chainId: 534352 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://scrollscan.com/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://scrollscan.com/address/0xbA5D580B18b6436411562981e02c8A9aA1776D10) + +## OP + +- chainId: 10 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://optimistic.etherscan.io/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://optimistic.etherscan.io/address/0xbA5D580B18b6436411562981e02c8A9aA1776D10) + +## Gnosis Chain + +- chainId: 100 +- LnDefaultBridge(v2): [0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337](https://gnosisscan.io/address/0x94C614DAeFDbf151E1BB53d6A201ae5fF56A9337) +- LnBridge(v3): [0xbA5D580B18b6436411562981e02c8A9aA1776D10](https://gnosisscan.io/address/0xbA5D580B18b6436411562981e02c8A9aA1776D10) diff --git a/labs/contract-addresses/testnet.md b/labs/contract-addresses/testnet.md new file mode 100644 index 0000000..07c2d96 --- /dev/null +++ b/labs/contract-addresses/testnet.md @@ -0,0 +1,30 @@ +--- +sidebar_position: 2 +--- + +# Testnet + +## Ethereum Sepolia + +- chainId: 11155111 +- LnDefaultBridge(v2): [0x8429D7Dfd91D6F970ba89fFC005e67D15f1E4739](https://sepolia.etherscan.io/address/0x8429D7Dfd91D6F970ba89fFC005e67D15f1E4739) +- LnOppositeBridge(v2): [0xbA96d83E2A04c4E50F2D6D7eCA03D70bA2426e5f](https://sepolia.etherscan.io/address/0xbA96d83E2A04c4E50F2D6D7eCA03D70bA2426e5f) +- LnBridge(v3): [0x38627Cb033De66a1E07e73f5D0a7a7adFB6741fa](https://sepolia.etherscan.io/address/0x38627Cb033De66a1E07e73f5D0a7a7adFB6741fa) + +## Arbitrum Sepolia + +- chainId: 421614 +- LnDefaultBridge(v2): [0x8429D7Dfd91D6F970ba89fFC005e67D15f1E4739](https://sepolia.arbiscan.io/address/0x8429D7Dfd91D6F970ba89fFC005e67D15f1E4739) +- LnOppositeBridge(v2): [0xbA96d83E2A04c4E50F2D6D7eCA03D70bA2426e5f](https://sepolia.arbiscan.io/address/0xbA96d83E2A04c4E50F2D6D7eCA03D70bA2426e5f) +- LnBridge(v3): [0x38627Cb033De66a1E07e73f5D0a7a7adFB6741fa](https://sepolia.arbiscan.io/address/0x38627Cb033De66a1E07e73f5D0a7a7adFB6741fa) + +## zkSync Sepolia + +- chainId: 300 +- LnDefaultBridge(v2): [0xBe23e871318E49C747CB909AC65aCCFAEAac3a37](https://sepolia.explorer.zksync.io/address/0xBe23e871318E49C747CB909AC65aCCFAEAac3a37) +- LnBridge(v3): [0xDc55fF59F82AA50D8A4A61dB8CcaDffD26Fb7dD2](https://sepolia.explorer.zksync.io/address/0xDc55fF59F82AA50D8A4A61dB8CcaDffD26Fb7dD2) + +## Base Sepolia + +- chainId: 84532 +- LnBridge(v3): [0x29D148A9e87C763292a33A55B9dBcAf44A194102](https://sepolia.basescan.org/address/0x29D148A9e87C763292a33A55B9dBcAf44A194102) diff --git a/labs/introduction/_category_.json b/labs/introduction/_category_.json new file mode 100644 index 0000000..7317fd6 --- /dev/null +++ b/labs/introduction/_category_.json @@ -0,0 +1,4 @@ +{ + "position": 1, + "label": "Introduction" +} diff --git a/labs/introduction/what-is-helix.md b/labs/introduction/what-is-helix.md new file mode 100644 index 0000000..b68e759 --- /dev/null +++ b/labs/introduction/what-is-helix.md @@ -0,0 +1,29 @@ +--- +sidebar_position: 1 +slug: / +--- + +# What is Helix Bridge? + + +Helixbox Bridge is a fully open-source and decentralized cross-chain asset bridge. It's built on top of common messaging bridges that already exist between chains, and provides secure, fast, and low-cost cross-chain functionality for users. + +## Features + +- **Secure** + + Helixbox Bridge separates the underlying generic messages and the asset bridging, which helps to reduce risk. + + While Helixbox's security does not entirely rely on generic messages, we take great care in selecting the generic message bridges we use. By combining the security of the generic message bridges with other security measures, we minimize the risk of security incidents. + +- **Fast** + + Additionally, Helixbox's Asset Cross-Chain Protocol can complete the cross-chain process in as little as 10 seconds to a minute, making it a fast and efficient option for users. + +- **Low Cost** + + The low cost of Helixbox's cross-chain process is due to its innovative design, which avoids the need for complex messaging bridges. Instead, simple interactions between the user and the contract allow for direct asset transfers, minimizing the cost of the process. + +- **Trustless** + + The Helixbox protocol is trustless, meaning that users do not need to rely on any centralized system to exchange assets. Instead, the protocol relies on a variety of roles to ensure the safety and stable operation of the cross-chain process. This trustless design makes the protocol more secure and resilient to failure, as it does not depend on any single point of failure. diff --git a/labs/protocol/_category_.json b/labs/protocol/_category_.json new file mode 100644 index 0000000..b9fa159 --- /dev/null +++ b/labs/protocol/_category_.json @@ -0,0 +1,4 @@ +{ + "position": 2, + "label": "Protocol" +} diff --git a/labs/protocol/img/cba01.png b/labs/protocol/img/cba01.png new file mode 100644 index 0000000..9e9c367 Binary files /dev/null and b/labs/protocol/img/cba01.png differ diff --git a/labs/protocol/img/cba02.png b/labs/protocol/img/cba02.png new file mode 100644 index 0000000..9e9c367 Binary files /dev/null and b/labs/protocol/img/cba02.png differ diff --git a/labs/protocol/img/mapping-token.svg b/labs/protocol/img/mapping-token.svg new file mode 100644 index 0000000..b5cd0e1 --- /dev/null +++ b/labs/protocol/img/mapping-token.svg @@ -0,0 +1 @@ +Burn - RedeemLock - IssueBackingIssuing1. register assetUserMessage Relayer2. get message3. submitcreate mapping token4. confirm resultRegister1. lock tokenlock2. get message3. submitmint mapping token4. confirm result1. burn tokenburn mapping token2. get message3. sumbitredeem original token4.confirm result \ No newline at end of file diff --git a/labs/protocol/liquidity-node-v2.md b/labs/protocol/liquidity-node-v2.md new file mode 100644 index 0000000..b9e58e9 --- /dev/null +++ b/labs/protocol/liquidity-node-v2.md @@ -0,0 +1,248 @@ +--- +sidebar_position: 1 +--- + +# Liquidity Node(v2) + +## Protocol Overview + +**This protocol can only be used when tokens are natively issued on both the source chain and the target chains, and their exchange values are equal.** + +## LnProvider + +This protocol establishes a liquidity provider role called the LnProvider (Liquidity Node Provider). When a user transfers tokens between two chains, the LnProvider receives tokens on one chain and transfers an equivalent amount of tokens to the user on the other chain. + +During the cross-chain transfer process, the asset token goes through the following flow 👇: Snipaste_2024-01-24_17-15-36 + +1. **Source Chain: User → LnProvider** + + On the source chain, the user sends tokens to the LnProvider’s source chain account. + +2. **Target Chain: LnProvider → User** + + On the target chain, the LnProvider sends an equivalent amount of tokens to the user. + +The user pays a fee for using the cross-chain transfer service, and the LnProvider earns a fee for providing liquidity. So, a LnProvider is a market-maker of Helix Token Protocol. + +**When LnProvider acts according to the protocol, there is no need for the underlying cross-chain messaging channel, which simplifies the process of asset cross-chain transfer and reduce the cost.** + +## LnProvider’s Collateral + +According to the protocol, when a LnProvider registers, it must stake collateral to ensure the safety of user assets during the cross-chain process. + +1. When a user initiates a cross-chain transfer, the user's assets are transferred to the LnProvider's account. At the same time, an equivalent amount of the LnProvider's collateral is locked. This ensures that the user's assets are protected. +2. When the cross-chain transfer is successful, the user receives the asset on the target chain, and the LnProvider's locked collateral is released on the source chain. + +In normal circumstances, these two processes do not need to work with the messaging channel, but bridge messages are still used to track the execution process. + +> 💡The locking of collateral occurs on the source chain, while the user’s assets receiving happens on the target chain. Both the two processes are auditable and have proofs on their respective chains. + +Snipaste_2024-01-24_17-58-53 + +### Pledged Collateral + +Pledged Collateral is the LnProvider's fixed total collateral and does not fluctuate when user do cross-chain transfers. + +The only way the pledged collateral changes is: + +- when the slasher handles exceptions, or, +- when the LnProvider deposits or withdraws collateral from it. This ensures that the collateral is always sufficient to cover any potential losses or penalties. + +### Available Collateral + +The available collateral is equal to the pledged collateral minus the collateral locked for pending transactions. The available collateral fluctuates as the status of user cross-chain transactions changes. + +When a user initiates a transaction, a certain amount of collateral is locked, reducing the available collateral. Once the transaction is confirmed by LnProvider, the available collateral increases. + +## LnProvider Failure + +LnProvider may fail, but even if it fails, the user's assets are safe. + +If a user initiates a transfer, but the LnProvider fails to transfer tokens to the user on the target chain. + +There are two situations: + +- If the LnProvider fails to transfer tokens to the user, and [the collateral is on the target chain(Default Type)](https://www.notion.so/Helix-Token-Protocol-c12817f371404edc8c381eefd55e7917?pvs=21). + + The user can submit the transfer proof to the target chain through the messaging channel. The target chain combines the proof with evidence that the LnProvider failed to transfer the tokens, and extracts collateral from the LnProvider to compensate the user. + + > 💡This should be the situation users prefer. + +- If the LnProvider fails to transfer tokens to the user, and **[the collateral is on the source chain](https://www.notion.so/Helix-Token-Protocol-c12817f371404edc8c381eefd55e7917?pvs=21)**. + + The user can use the messaging channel to send proof of the failed transfer to the source chain. The source chain can then combine this proof with the original transfer proof to verify the LnProvider's failure. Once the source chain has verified the LnProvider's failure, it can extract collateral from the LnProvider to compensate the user. + +Either of the above methods is used to ensure the security of the user's assets during the process. The choice between them depends on the direction of the bridge message. + +# Key Terms Explaination + +## LnProvider(Liquidity Node Provider) + +A LnProvider has two components: an account and a client program. + +* **LnProvider Account** + + The account exists on both the source chain and the target chain. On the source chain, the account receives assets from users who initiate cross-chain transfers. On the target chain, the account distributes those assets to users who have successfully completed a cross-chain transfer. The account is registered to the asset bridge and has a collateral. + +* **LnProvider Client Program** + + The client program, which is associated with the account, monitors user transfer events and automatically transfers tokens from the account on the target chain to the user's account, completing the cross-chain process. + +## Slasher + +This compensation mechanism ensures the security of users' assets during the process, although they add some complexity for regular users. To address this issue, a separate role called a "slasher" is introduced. + +Slasher is responsible for monitoring the behavior of LnProviders and, in the event of an LnProvider failure, helping users complete transactions through alternative means. When necessary, slasher utilizes the messaging channel to extract the LnProvider's collateral and impose penalties. This ensures that the user's transaction will eventually be completed, even in exceptional circumstances. The slasher helps users complete the process without having to understand the underlying details. This improves the user experience and makes it easier for regular users to take advantage of cross-chain transfers. + +## TransferId + + +$TransferId = Hash(params，lastTransferId)$ +Where: + +* **params**: + + The params refers to the specific parameters of the cross-chain transfer, including token address, quantity, LnProvider, receiver, etc. + +* **lastTransferId**: + + The lastTransferId of the first transaction is 0. For the k-th transaction, the lastTransferId is the transferId of the (k-1)th transaction. + +### Purpose + +The purpose of this TransferId mechanism are for: + +- **Uniqueness** + + The system maintains a 'lastTransferId' value, which is updated after each transaction is completed. This current lastTransferId value is used to generate the TransferId for the next transaction, ensuring that no two transactions share the same TransferId. This mechanism prevents data duplication and ensures the integrity of the system. + +- **Ordering** + + In each transaction, the Hash parameter includes the TransferId of the previous transaction, ensuring the sequencing of transactions. + + + +## Type 1(Opposite) - Collateral on Source Chain + +This type need a messaging channel **from Target Chain** to **Source Chain**. + +For this type we implement the following asset bridge cross-chain protocol. + +### Safety Assumptions + +1. There should be a secure and reliable general-purpose messaging channel for communication from the source chain to the target chain. This channel must maintain the integrity and confidentiality of messages sent from source chain to target chain. +2. The source chain and the target chain use the same time(the same world clock), allowing for consistent timestamping and handling of time-sensitive events across both chains. + +### Interaction Flow - LnProvider Registration + +LnProvider registration is the process by which a LnProvider becomes part of the cross-chain asset transfer protocol. This process involves a few key steps, during which the LnProvider provides information about itself and commits to certain obligations. Once registered, the LnProvider is responsible for facilitating cross-chain transfers and adhering to the protocol's rules. + +1. Decide the tokens to support + + The LnProvider must select which tokens it will support for cross-chain transfers. These tokens must exist on both the source and target chains, so that transfers can be facilitated. + +2. Decide the pledging collateral + + In order to participate in the cross-chain asset transfer protocol, the LnProvider must pledge a certain amount of tokens as collateral on source chain. + +3. Decide on the fees to charge + + The LnProvider must determine the fee charged for cross-chain transfer. The fee are intended to cover the cost of the LnProvider's activities on the target chain, including **1. gas fee**, as well as **2. LnProvider’s profit**. + +4. Completing registration by sending a transaction **on source chain** + + The LnProvider completes the registration process by calling an interface on the source chain, submitting collateral, and setting the fees. + + Once registration is complete, the LnProvider will be recognized by the protocol and can begin offering cross-chain transfer services. + +5. Running the client program + + After registration, the LnProvider needs to run a client program that constantly monitors the network for cross-chain transfer requests. When a request is received, the program automatically executes a transaction to complete the transfer. + +The registration process described above allows the LnProvider to become a liquidity provider and participate in the cross-chain asset transfer protocol. + +### Interaction Flow - Transfer + +1. To initiate a cross-chain transfer, a user first selects the token they wish to transfer, specify the amount, and choose an LnProvider to facilitate the transfer. + + > 💡An intermediary party can assist the user in selecting an appropriate LnProvider, if necessary. + +2. The user retrieves the latest state from the blockchain and takes a snapshot of the state. Then, the user check the available collateral amount of the LnProvider to ensure it is sufficient. If not, the cross-chain transfer cannot proceed. + + > 💡In actual products, this step will be completed by the front-end code of users. + +3. If the collateral is sufficient, the user then calls the on-chain api with the snapshot, initiating the transfer. + +4. The blockchain verifies that the snapshot is valid. If the on-chain state has changed since the snapshot was taken, the transfer fails. Otherwise, the user's assets are transferred to the LnProvider’s account on source chain, and a transfer proof is generated. + +5. The LnProvider monitors the event confirming the transfer **on the source chain**. Upon confirmation, LnProvider transfer the tokens to the user's account **on the target chain** and generate a proof of this transaction. + + In this step, **a timeout period is set**, and the LnProvider is required to complete the transfer within this time limit. If the LnProvider fails to do so, the slasher can do slashing operation. + +### Interaction Flow - Slashing + +1. On the target chain, the `Slasher` will transfer tokens from its own account to the user's account to cover the transaction (this is known as "slash and cover"), and generate a transfer proof. +2. The `Slasher` will then send this transfer proof to the source chain through the underlying bridge messaging system. Upon receiving the message, the source chain will verify the transaction. If the verification is successful, the source chain will extract the `LnProvider's` collateral to compensate the slasher for covering the assets and to impose a penalty on the `LnProvider`. +3. The determination of whether the transfer is within the timeout period is based on comparing the time when the user sends the transaction (the timestamp of the block on the source chain where the transaction is included) with the current time on the target chain. The synchronization of clocks between the two chains is ensured by the safety assumptions, allowing the timeout time to be effective within a certain error range. +4. This mechanism ensures that the `LnProvider` fulfills its responsibility to complete the transfer within the specified time, and in the event of a failure, the slasher steps in to cover the assets and initiate penalties, thus maintaining the security and reliability of the cross-chain asset transfer protocol. + +### Ordering Mechanism + +- Every cross-chain transaction on the target chain must be executed or be subject to a 'slash' operation. +- 'Slash' operations cannot be executed before the timeout period has expired. +- For every cross-chain transaction on the target chain, it must follow a preceding transaction that was executed. +- When validating a "slash" transaction on the source chain, it must be ensured that all preceding transactions have not been subjected to a "slash" operation, or if any "slash" operations were applied, they have all been executed and completed. + +The above content describes how to ensure the execution order in the cross-chain asset transfer protocol, ensuring that before any transaction is completed, all preceding transactions have been completed.This sequencing mechanism effectively prevents malicious withdrawals of collateral, ensuring that users only need to consider the available collateral when sending a cross-chain transfer. + +With this mechanism, users can be confident that their transactions will be processed reliably. + +> 💡 The specific implementation of maintaining the sequence is as follows: +> +> 1. Set SId(1) to a certain initial value, indicating that there were no slash transactions before the first transaction. +> 2. For each transaction (the k-th transaction) on the target chain, check if the previous transaction (the (k-1)-th transaction) has been sent and further determine whether it has been slashed. Based on the status of the previous transaction, determine the closest slash transaction Id (SId(k)) before the k-th transaction. +> 3. If the previous transaction is a slash transaction, meaning that the (k-1)-th transaction has been subject to a slash operation, then SId(k) = Id(k-1), which means that SId(k) for the k-th transaction is set to the Id(k-1) of the (k-1)-th transaction. +> 4. If the previous transaction is not a slash transaction, meaning that the (k-1)-th transaction was normally executed by LnProvider, then SId(k) = SId(k-1), which means that SId(k) for the k-th transaction is set to the SId(k-1) of the (k-1)-th transaction. + +By following this approach, when sending the slash transaction Id(k) from the target chain to the source chain, the information of SId(k) is included. The source chain, when validating the slash transaction, verifies whether SId(k) has been completed, ensuring that the execution process of the k-th transaction is correctly ordered. This sequencing mechanism effectively prevents transactions from being maliciously tampered with or prematurely executed, ensuring the security and reliability of the transactions. + + + +## Type 2(Default) - Collateral on Target Chain + +**This type need a messaging channel from Source Chain** to **Target Chain.** + +For this type we implement the following asset bridge cross-chain protocol. + +### Safety Assumptions + +1. A secure and reliable message channel connects the source chain to the target chain. This channel ensures that messages can be reliably sent from the source chain to the target chain, and the integrity and confidentiality of the messages are maintained. +2. The source chain and the target chain use the same time(the same world clock), allowing for consistent timestamping and handling of time-sensitive events across both chains. + +### Differences from Type1 + +The basic interaction process is similar to the message channel from the target chain to the source chain, with the following differences: + +- LnProvider's collateral is pledged on the target chain. + +- Slashing + + When the slasher executes a slash operation, it sends a transaction to the target chain that does not require to cover the user any tokens. + + If the provider delivers after the timeout period, a portion of its collateral will be deducted as a penalty. This penalty compensates the slasher for the fees incurred during the slash operation. + + When the slashing request arrives at the target chain, it checks whether the transaction needs to be slashed in the following scenarios: + + 1. If the cross-chain transaction is not past the timeout period, the slashing request is considered invalid and will not be executed. + 2. If the cross-chain transaction is already past the timeout period and the LnProvider has been slashed, then the slashing request is considered invalid and will not be executed. + 3. If the cross-chain transaction is past the timeout period and has not yet been delivered, the slashing request will be executed. The user will receive the transferred assets, and the slasher will receives fees and the penalty assets. + 4. If the cross-chain transaction is past the timeout period, but the provider delivered the transaction within the allowed time, then the slash operation is not permitted and will not be executed. + 5. If the cross-chain transaction is past the timeout period and the LnProvider delivered after the timeout, the slash operation is only partially valid. The slasher can receive some of the penalty assets, but not the full amount, to compensate for the gas and bridge fees incurred by the user. + +- Ordering + + The ordering requirement states that any transaction on the target chain must have its preceding transaction completed before the current transaction can be finalized. This can be accomplished in two ways: by the LnProvider completing the transaction as normal, or by the slasher executing a slash operation. + + That is, before a transaction is slashed, it's important to make sure that any collateral associated with that transaction cannot be extracted by its subsequent transactions. + + Additionally, we demand that LnProvider includes the state of the extraction into the snapshot when withdrawing collateral. At the time of extraction, all transactions prior to that state must have been completed, ensuring that the available collateral does not decrease during the period from the initiation of the cross-chain transaction to its execution on the target chain. diff --git a/labs/protocol/liquidity-node-v3.md b/labs/protocol/liquidity-node-v3.md new file mode 100644 index 0000000..e3ac403 --- /dev/null +++ b/labs/protocol/liquidity-node-v3.md @@ -0,0 +1,52 @@ +--- +sidebar_position: 2 +--- + +# Liquidity Node(v3) + +## Overview + +In the v2 version of the Liquidity Node Protocol, we have implemented a collateral mechanism to protect user assets. In this v2 protocol, the amount of collateral staked by the LnProvider determines the transfer limit for a single transaction in that direction. To enhance trading depth, LnProviders must stake more collateral. However, since collateral cannot be shared across different directions, this leads to increased collateral costs. Consequently, the v2 protocol is more suitable for frequent, small-value transactions. + +To address this issue, we are introducing a new protocol version, v3, which eliminates the requirement for collateral staking. When registering, LnProviders will only need to stake a modest penalty reserve amount. This reserve ensures the timely completion of message delivery by the LnProvider and imposes penalties if expectations are not met. + +## Security Assumptions + +1. We make the assumption that there exists a secure and reliable general-purpose messaging channel for communication from the target chain to the source chain. This assumption ensures the reliable transmission of messages from the target chain to the source chain. +2. We assume that both the source chain and the target chain's blocks are synchronized with the same world clock. This assumption allows for consistent timestamping and the handling of time-sensitive events across both chains. + +## Interactions + +### LnProvider Registration + +The LnProvider stores its configuration information on the source chain and stakes a specific amount of penalty reserve, which can be shared across different paths. + +1. Select the supported source chain, target chain, and token. Register the LnProvider and configure transaction fees and transfer limits accordingly. + +2. Deposit the penalty reserve on the source chain. + +3. Run the relayer client. + +### Cross-Chain Tranfer by Users + +1. A user choose the direction for cross-chain token transfer and specify the LnProvider to initiate the transaction on the source chain. + +2. The user lock tokens, fees, and a single LnProvider penalty collateral on the source chain. + +3. The user waits to see the tokens arrive in his/her account on the target chain. + + Once the LnProvider sees the transfer event, it transfers the tokens to the user-specified account on the target chain and generates a transfer proof at the same time. + + If the LnProvider did not complete the transfer within a specified timeout, the Slasher on the target chain transfers tokens to the user and sends a reverse message to the source chain, extracting the locked assets as per the second step. + +> A Slasher does not need to register. Any account including the user themselves is considered a Slasher as long as it completes the this. +> +> Slashers play a crucial role throughout the entire cross-chain transaction cycle and assists in finalizing transactions when LnProvider is not functioning. + +### Liquidity Withdrawal by LnProvider + +After a regular transaction is successfully completed, the liquidity for each transaction remains locked within the source chain. + +To withdraw this liquidity, LnProvider must send a cross-chain message from the target chain to the source chain. LnProvider has the option to withdraw liquidity from multiple transactions simultaneously, which can notably reduce cross-chain messaging gas fees. + +> However, accumulating too many transactions may lead to the liquidity over-occupation, thereby weakening the LnProvider's liquidity capabilities. Therefore, LnProvider must carefully determine the number of transactions to batch withdraw liquidity from. diff --git a/labs/relayer/_category_.json b/labs/relayer/_category_.json new file mode 100644 index 0000000..a8568c3 --- /dev/null +++ b/labs/relayer/_category_.json @@ -0,0 +1,4 @@ +{ + "position": 5, + "label": "Relayer" +} diff --git a/labs/relayer/client.md b/labs/relayer/client.md new file mode 100644 index 0000000..4d875e4 --- /dev/null +++ b/labs/relayer/client.md @@ -0,0 +1,36 @@ +--- +sidebar_position: 1 +sidebar_label: Client +--- + +# Helix Relayer Client + +This is an open-source JavaScript software, and you can find more information about it on their [GitHub repository](https://github.com/helix-bridge/relayer). Refer to the README file in the repository for detailed guides. + +Please make sure to carefully follow the instructions provided in the README for a successful setup and deployment of the Helix Relayer Client. + +Here's a brief overview of the steps to deploy a Relayer: + +- **Indexer Service Preparation (Skip if using Helix's public service)** + + If you're not using Helix's public service, you'll need to deploy your own Indexer service. This may involve setting up and configuring an Indexer to index and provide on-chain data. + + If you are not connected to the Helix public service, the Helix app will not be able to display your relayer information and will be unable to complete recommendations when users send transactions. + +- **Building from Source** + + Download the Relayer's source code and compile it according to the instructions in the project's documentation. Typically, this involves installing build tools, dependencies, and running build commands. + +- **Configuration** + + In the Relayer's configuration file, specify information about the bridges you want to interact with. This includes details about the source and target chains, such as chain types, connection details, contract addresses, etc. + +- **Running** + + Run the client and ensure it remains online, ready to handle relaying requests. Relayers usually listen on a specific port, awaiting requests from users. + +- **On-chain Registeration** + + Depending on the bridge's requirements, you may need to register the Relayer's identity on-chain, stake a certain amount as a bond, and establish the fee structure. This ensures the credibility and availability of the Relayer. + +It's crucial to ensure that the Relayer client runs smoothly and remains online before attempting to register as a Relayer. Failing to do so could result in penalties or other consequences, as reliability and uptime are typically essential criteria for becoming and remaining a Relayer in most bridge ecosystems. Therefore, it's essential to thoroughly test and monitor your Relayer setup to meet the required standards before registering and actively participating in the bridge network. diff --git a/labs/relayer/indexer.md b/labs/relayer/indexer.md new file mode 100644 index 0000000..125c722 --- /dev/null +++ b/labs/relayer/indexer.md @@ -0,0 +1,38 @@ +--- +sidebar_position: 3 +sidebar_label: Indexer +--- + +# Helix Data Indexing + +Before attempting to run a relay, it's essential to have a comprehensive understanding of Helix data indexing. The index plays a pivotal role in the proper functioning and security of the relayer, as it heavily relies on and trusts indexed data. + +## Structure + +Helix indexing employs a two-tier structure. The first tier directly indexes data on the chain, often utilizing established solutions like thegraph. The second tier then aggregates and correlates the data gathered from the first tier. + +``` ++------------------------------+ +------------------------------+ +| blockchain(contract) | | blockchain(contract) | ++----------------+-------------+ +----------------+-------------+ + | | + |event | event + | | ++----------------v--------------+ +-------------v-------------+ +| indexer(level1) | | indexer(level1) | +| thegraph | | thegraph | ++----------------+--------------+ +--------------+------------+ + | | + | | + +-v------------------------------------------------v--+ + | indexer(level2) | + +--^----------------------^-----------------------^---+ + | | | ++--------------+ | +------------+ | +-----------+ | +| relayer +---+ | relayer +-+ | relayer +-+ ++--------------+ +------------+ +-----------+ +``` + +Each indexer on the first layer is responsible for indexing and storing data from a single chain. The second layer's service is unique; it connects to the first layer's services, requests data from them sequentially, and associates data from different chains while performing global sorting. The Relayer only requests data from the second-layer indexer and trusts the data from that indexer. + +Each first-layer indexer is responsible for indexing and storing data from a single chain. The second-layer indexer connects to the first-layer services, sequentially requests data from them, and performs global sorting to associate data from different chains. The Relayer exclusively relies on data from the second-layer indexer. diff --git a/labs/relayer/register.gif b/labs/relayer/register.gif new file mode 100644 index 0000000..d5d0d2b Binary files /dev/null and b/labs/relayer/register.gif differ diff --git a/labs/relayer/register.md b/labs/relayer/register.md new file mode 100644 index 0000000..b152f93 --- /dev/null +++ b/labs/relayer/register.md @@ -0,0 +1,224 @@ +--- +sidebar_position: 2 +--- + +# Run a Relayer Node + +## Overview + +Helix is a completely open system where anyone can register as a Relayer without any barriers, contribute liquidity to the system, and earn profits. Before becoming a Relayer, you should have basic knowledge of blockchain, especially in the area of contract interaction. The code for Helix is open-source, and Relayers can either use the default code to run a Node or optimize the client according to their needs, promptly fixing any issues encountered. + +Each Relayer entity is associated with two chains (the source chain and the target chain of the bridge) and a Token. + +Prerequisites: + +1. Prepare two accounts with same address on the two intended chains and deposit a certain amount of Token in each. +2. Register as a Relayer on the Helix UI, which involves staking a certain amount of collateral. +3. Pull the client code to your local environment, configure bridge information, and compile and run the code. + +Now, let's run a Relayer Node (v2 opposite type for example) on the testnet using the example of (arbitrum-sepolia -> sepolia, USDC). + +## Registration + +Open the Helix UI and navigate to the [Relayer Dashboard](https://testnet.helixbridge.app/relayer/dashboard). + +- **(1/3) Select Chain and Token** + + Choose the source chain as `arbitrum-sepolia`, the target chain as `sepolia`, and the Token as `USDC`. Click **Confirm** and the page will provide basic information about the bridge you are about to register. Here, you can find the bridge type is Opposite. Click **Next** to proceed. + :::info{title=BridgeType} + For LnBridge V2, there are only two types: Default and Opposite. The difference between these two types lies in the location of the Relayer's staked collateral. In Default type, the collateral is staked on the target chain, while in Opposite type, the collateral is staked on the source chain. + ::: + +- **(2/3) Deposit Collateral & Set Fees** + + - Enter the desired amount of collateral and click **Confirm**. Subsequently, a wallet confirmation prompt will appear (this transaction is executed on the target chain). If your wallet is not currently connected to the target chain, you will be prompted to switch to the target chain before proceeding with the collateral pledge. + :::info{title=Collateral} + Helix does not impose any restrictions on the amount of collateral that a Relayer can stake; it is entirely specified by the Relayer. The more collateral pledged, the better the depth available for each transfer. However, it's important to note that higher collateral amounts correspond to increased pledge costs for the Relayer. + ::: + + - Entering the baseFee and liquidityFee rate. Click **Confirm**, and a wallet confirmation prompt will appear afterward(this transaction is executed on the source chain). + :::info{title=Fee} + The Relayer's final income per transfer is calculated as the `baseFee + liquidityFeeRate * Amount`, where Amount is the transfer amount. + ::: + +- **(3/3) Approve** + + Authorize the contract to transfer Token `USDC` on the target chain. This authorization ensures that the `Relayer Client` can perform relay operations successfully on the target chain. Since there is also authorization in the second step, this step can be skipped if the authorized amount is sufficiently large. + +After completing the registration, you can open the `Manage` tab to view the registered information. You will notice that the status of the relayer is `Offline` because you have not ye started the relayer client. Please note that there may be some delay in the synchronization of registration information. + +![Register](./register.gif) + +## Run the client + +Access the client code on [GitHub](https://github.com/helix-bridge/relayer) and pull it to your local machine. + +### Configuration + +The configuration information for the Relayer is stored in the file `.maintain/configure.json`. + +```js +{ + "indexer": "https://apollo-test.helixbridge.app/graphql", + "relayGasLimit": 600000, + "rpcnodes": [ + { + "name": "sepolia", + "rpc": "https://rpc2.sepolia.org" + }, + { + "name": "arbitrum-sepolia", + "rpc": "https://sepolia-rollup.arbitrum.io/rpc" + } + ], + "bridges": [ + { + "direction": "arbitrum-sepolia->sepolia", + "encryptedPrivateKey": "", + "feeLimit": 0.01, + "reorgThreshold": 20, + "bridgeType": "lnv2-opposite", + "tokens": [ + { + "symbol": "usdc->usdc", + "swapRate": 2000 + } + ] + } + ] +} +``` + +- **indexer**[option]: It's the second-layer index service introduced in this [section](https://docs.helixbridge.app/helixbridge/relayer_indexer) can be accessed through the following link. + + + + + + + + + + +
NetworkURL
Testnethttps://apollo-test.helixbridge.app/graphql
Mainnethttps://apollo.helixbridge.app/graphql
+ +- **relayGasLimit**[option]: The gas limit for the client to send the relay transaction. If not set, it will automatically estimate a reasonable value. +- **rpcnodes**: The list of information about the chains that the relayer needs, including name(must match the names defined in [section](http://localhost:8000/helixbridge/supported_chains)), chainId, and the URL for accessing the RPC node. +- **bridges**: The list of token bridge paths that can support multiple directions simultaneously. The fields include: + - **direction**: Must match the names defined in fileld **chains** + - **encryptedPrivateKey**: It's the relayer's encrypted private key, corresponding to the account registered during registration + :::info{title=EncryptPrivateKey} + Execute the command `yarn crypto`. Follow the prompts to input your password and private key. After pressing Enter, it will print the private key encrypted with the provided password. Then replace the `` in the configuration file with the encrypted private key obtained. + ::: + - **feeLimit**: Controls the maximum cost of a relay operation, protecting the relayer from excessive gas fees + - **reorgThreshold**: It's an assumption about the block confirmation of transactions initiated by users on the source chain – the larger, the safer + - **bridgeType**: Indicates the type of bridge, currently taking values of `lnv2-default`, `lnv2-opposite`, and `lnv3`, consistent with the type displayed during relayer registration + - **minProfit[optional]**: Relayer's minimum profit expected. + - **maxProfit[optional]**: Relayer's maximum profit expected, both minProfit and maxProfix configured, then when the profit range jumps out of the interval [minProfit, maxProfit], it is automatically adjusted to (minProfit+maxProfit)/2. + - **tokens**: List the addresses of token pairs on the source and target chains, as well as the exchange rate for the native token on the target chain. + :::info{title=swapRate} + Parameter swapRate is the conversion rate from the native token on the target chain to the transfer token. For example, the native token on Ethereum is ETH, and the token to be transferred is USDC, the conversion rate might be approximately 2500 at 16/01/2024. As prices fluctuate, the Relayer needs to periodically adjust this ratio. + ::: + :::info{title=withdrawLiquidity} + For the lnv3 bridge, the relayer can set two parameters in this section, including withdrawLiquidityAmountThreshold and withdrawLiquidityCountThreshold. The relayer client will check every 6 hours, and if either threshold is met, the relayer client will initiate the settlement process. + ::: + :::info{title=useDynamicBaseFee} + This parameter useDynamicBaseFee is only valid for LnbridgeV2 of type opposite, and needs to be used in conjunction with the minProfit parameter. When it is true, the relayer will query the cost of the current relay from the target chain in real time, and convert it into a dynamic cost signature on the source chain for the user. + ::: + +### SafeWallet + +You can also use safewallet to run relayer, just configure the following 3 parameters in the bridges field of the configuration file. + +- **safeWalletAddress:** + the wallet address, must exist both on source chain and target chain. +- **safeWalletUrl:** + the safe wallet service url. eg. https://safe-transaction-goerli.safe.global +- **safeWalletRole:** + the Role of the account, can be `signer` or `executor`, the `executor` will send execution transaction when there are enough signatures. + +### Advanced Features +You can leverage the decentralized lending feature to achieve two purposes: +- Earn interest on account assets from the lending market during relayer idle times, reducing the cost of funds as a relayer. +- Provide relay services for an asset bridge without needing to hold that specific asset. + +Currently, Helix relayer supports the AAVE lending pool. This feature is only supported for SafeWallet accounts. To use this feature, you need to create a SafeWallet with the same address across different networks and then transfer the tokens to this wallet. + +For example, if you want to use the lending feature on Arbitrum, you will need to add configuration information similar to the example below. +```js +"rpcnodes": [ + { + "name": "arbitrum", + "rpc": "https://arb1.arbitrum.io/rpc", + "lendMarket": [ + { + "protocol": "aave", + "healthFactorLimit": 3.0, + "collaterals": [ + { + "symbol": "weth", + "autosupplyAmount": 0.2 + }, + { + "symbol": "usdt", + "autosupplyAmount": 2000 + } + ], + "tokens": [ + { + "symbol": "weth", + "minRepay": 0.0001, + "minReserved": 0 + } + ] + } + ] + }, +] +``` +- **lenMarket**: Represents the list of lending markets. +- `healthFactorLimit` represents the lending risk factor, with a recommended value of 3. The larger the value, the safer it is, but the corresponding lending amount is lower. +- `collaterals` represents the collateral, and `autosupplyAmount` indicates the automatic collateral limit when the account has a balance and the collateral amount has not reached this value. +- `tokens` represent the lending tokens, and the client will also automatically repay the loan when the account has a balance of these assets. +- `Priority Usage` When a relay order is generated, the usage order of relay account assets is **Account Balance** > **Collateral Redemption** > **Lending Assets**. The redemption of collateral or the use of lending assets will only be enabled if they are in the configuration list. +- `Native Token Handling` The handling of any native token assets, including supply, withdraw, or lending, is represented by its wrapped token in configure file. However, the use of assets in the account remains as native tokens. + +### Install & Run + +After completing the configuration, you can execute the following commands one by one to compile and start the client: + +``` +>> yarn install +>> yarn build +>> yarn start +``` + +After the execution is complete, it will prompt you to enter a password. This password is the one used to encrypt the private key using `yarn crypto`. + +``` +>> yarn start +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [NestFactory] Starting Nest application... +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] UtilsModule dependencies initialized +49ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] DataworkerModule dependencies initialized +0ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] DiscoveryModule dependencies initialized +1ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] TasksModule dependencies initialized +0ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] ConfigHostModule dependencies initialized +1ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] AppModule dependencies initialized +0ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] ScheduleModule dependencies initialized +0ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] ConfigModule dependencies initialized +1ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] ConfigureModule dependencies initialized +1ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [InstanceLoader] RelayerModule dependencies initialized +1ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [RoutesResolver] AppController {/}: +6ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [RouterExplorer] Mapped {/, GET} route +3ms +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [dataworker] data worker started +[Nest] 46997 - 01/16/2024, 5:42:11 PM LOG [relayer] relayer service start +Password:****** +``` + +### Client Run Status + +Return to the Relayer Dashboard page on the UI, enter the **Manage** page, and you will observe that the status of your Relayer has changed to `Online`. + +## Tips + +If the token bridge is the `Default` type, there will be slight differences in the registration process, and in the client's configuration, the bridgeType should be modified to lnv2-default. Or if the token bridge is the `v3` type, the bridgeType should be modified to `lnv3`. diff --git a/labs/user-guide/_category_.json b/labs/user-guide/_category_.json new file mode 100644 index 0000000..0df704e --- /dev/null +++ b/labs/user-guide/_category_.json @@ -0,0 +1,4 @@ +{ + "position": 4, + "label": "User Guide" +} diff --git a/labs/user-guide/fee.md b/labs/user-guide/fee.md new file mode 100644 index 0000000..813024e --- /dev/null +++ b/labs/user-guide/fee.md @@ -0,0 +1,23 @@ +--- +sidebar_position: 3 +--- + +# Fee + +The fee structure consists of two components: a base fee to cover the gas fees incurred by the LnProvider when executing transactions on the target chain and a liquidity fee designed to compensate the LnProvider for the loss of liquidity. + +1. Base Fee + + The base fee is determined and set by the LnProvider, remaining a fixed value until the LnProvider updates it. Users are required to pay this fee to the LnProvider at the time they initiate the transfer. + +2. Liquidity Fee + + Similar to the base fee, the liquidity fee is also determined by the LnProvider. However, this fee is directly related to the amount of the transfer initiated by the user. As the transfer amount increases, the corresponding fee also increases. + +Assuming the user's transfer quantity is denoted as "Amount," the base fee as "BaseFee," and the liquidity rate as "LiquidityRate," then the total fee for the transfer can be calculated as follows: + +``` +TotalFee = BaseFee + Amount * LiquidityRate +``` + +It's important to note that these fees are separate from the actual transfer and need to be accounted for by users. Users should set aside a portion of the token to cover the cross-chain fees. LnProvider registration is permission-less, and their fee is freely configurable. Helix's backend system will gather information from various LnProviders and choose the most suitable one for users based on their preferences. For instance, an LnProvider with a lower fee will have a higher chance of being recommended by the system. diff --git a/labs/user-guide/img/confirm.png b/labs/user-guide/img/confirm.png new file mode 100644 index 0000000..b349ff8 Binary files /dev/null and b/labs/user-guide/img/confirm.png differ diff --git a/labs/user-guide/img/history-detail.png b/labs/user-guide/img/history-detail.png new file mode 100644 index 0000000..a7f62e9 Binary files /dev/null and b/labs/user-guide/img/history-detail.png differ diff --git a/labs/user-guide/img/transfer.png b/labs/user-guide/img/transfer.png new file mode 100644 index 0000000..46f5ef4 Binary files /dev/null and b/labs/user-guide/img/transfer.png differ diff --git a/labs/user-guide/supported-chains.md b/labs/user-guide/supported-chains.md new file mode 100644 index 0000000..f2ceed2 --- /dev/null +++ b/labs/user-guide/supported-chains.md @@ -0,0 +1,27 @@ +--- +sidebar_position: 2 +--- + +# Supported Chains + +## LnBridge + +### Testnet + +- arbitrum-sepolia +- sepolia +- zksync-sepolia + +### Mainnet + +- ethereum +- arbitrum +- darwinia-dvm +- polygon +- zksync +- bsc +- linea +- mantle +- scroll +- op +- gnosis diff --git a/labs/user-guide/transfer.md b/labs/user-guide/transfer.md new file mode 100644 index 0000000..8bf6e0b --- /dev/null +++ b/labs/user-guide/transfer.md @@ -0,0 +1,24 @@ +--- +sidebar_position: 1 +--- + +# Transfer + +## Steps + +- Visit Helix Bridge at [mainnet](https://helixbridge.app/) or [testnet](https://helix-stg-test.vercel.app/). +- Select source chain, target chain and token you want to transfer. +- Switch wallet to the source chain and connect wallet. +- Fill the transfer amount, and then you can find the transfer information include fee, estimated time if there are bridges avaliable. +- Click `Transfer` and you will receive a popup for transfer confirmation. Then click `Confirm` after every detail is checked. +- Then you will be prompted to confirm the transaction in your wallet. After confirming in your wallet, you have submitted the transaction. You can track the transfer progress by clicking on the `transaction history` in the pop-up window. +- All the transfer histories can be found in `Explorer`, and you can filter the history by account address or transaction hash. Click the record, you can see the detail of the transfer. +![History Detail](./img/history-detail.png) + +## Attention + +There may be multiple bridges for the same transfer path, and Helix selects one by default for the user, but the user is free to choose which bridge to use to complete the cross-chain in order to ensure that the costs and efficiency of the transfer are reasonable. + +Once the transfer is submitted, it cannot be canceled, please double check the amount, target chain and other information before initiating the cross-chain transfer from your wallet. + +The costs, arrival times, caps, etc. given in the hints are all estimates, and there will be some error between them and the actual values. diff --git a/sidebars.ts b/sidebars.ts index 05568eb..35ca00f 100644 --- a/sidebars.ts +++ b/sidebars.ts @@ -13,21 +13,9 @@ import type {SidebarsConfig} from '@docusaurus/plugin-content-docs'; Create as many sidebars as you want. */ const sidebars: SidebarsConfig = { - // By default, Docusaurus generates a sidebar from the docs folder structure - sidebar: [{type: 'autogenerated', dirName: '.'}], - // But you can create a sidebar manually - /* - tutorialSidebar: [ - 'intro', - 'hello', - { - type: 'category', - label: 'Tutorial', - items: ['tutorial-basics/create-a-document'], - }, - ], - */ + // By default, Docusaurus generates a sidebar from the docs folder structure + sidebarDocs: [{type: 'autogenerated', dirName: '.'}], }; export default sidebars;