swapData , executeData and requestMetadata and the functionality of this function are similar to those in the reserve token transfer which can be found [here](./transfer-reserve-token#swap-data).
diff --git a/docs/develop/asset-transfer/voyager/different-functions/transfer-non-reserve-token-arbitrary-instruction.md b/docs/develop/asset-transfer/voyager/different-functions/transfer-non-reserve-token-arbitrary-instruction.md
deleted file mode 100644
index 010b2a44..00000000
--- a/docs/develop/asset-transfer/voyager/different-functions/transfer-non-reserve-token-arbitrary-instruction.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Transfer of Non-Reserve Tokens with Arbitrary Instruction
-sidebar_position: 5
----
-
-```javascript
-function depositNonReserveTokenAndExecute(
- bool isSourceNative,
- bool isAppTokenPayer,
- bytes calldata swapData,
- bytes calldata executeData,
- bytes calldata arbitraryData,
- bytes calldata requestMetadata
- ) external payable;
-```
-
-The flow is just the same as that of the Non-Reserve token transfer explained in previous section. The only difference here is the arbitrary data that you need to pass and state whether the tokens that need to be swapped are to be deducted from the user or the application for which the details can be found [here](./transfer-reserve-token-arbitrary-instruction#arbitrary-data).
diff --git a/docs/develop/asset-transfer/voyager/different-functions/transfer-non-reserve-token.md b/docs/develop/asset-transfer/voyager/different-functions/transfer-non-reserve-token.md
deleted file mode 100644
index f96f8b7e..00000000
--- a/docs/develop/asset-transfer/voyager/different-functions/transfer-non-reserve-token.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Transfer of Non-Reserve Tokens
-sidebar_position: 4
----
-
-```javascript
-function depositNonReserveToken(
- bool isSourceNative,
- bytes calldata swapData,
- bytes calldata executeData,
- bytes calldata requestMetadata
- ) external payable;
-```
-
-Non-Reserve tokens include all those tokens which are not kept as reserve tokens for the Voyager and are not the LP tokens for any of these reserve tokens. These can be any random token.
-
-When a user wants to transfer any non-reserve token from source chain to any other token on the destination chain, this function is to be called. After this function is called, the Voyager’s infrastructure will handle the transfer of tokens to the other chain.
-
-**Parameters:**
-
-| isSourceNative | If the source token is the native token for that chain, this should be true. |
-| --------------- | ---------------------------------------------------------------------------- |
-| swapData | abi encoded data for the swap which is created by an API |
-| executeData | abi encoded data for the destination chain which is created by an API |
-| requestMetadata | |
-
-The **Swap Data** includes:
-
-1. **srcTokenAmount:** Amount of the non-reserve token the user wants to transfer to the other chain.
-2. **srcStableTokenAmount:** Amount of the stable token equivalent to the amount of source token user wants to transfer.
-3. **destChainIdBytes:** The Chain ID identifier for the destination chain.
-4. **srcTokenAddress:** Address of the token the user wants to transfer to the other chain.
-5. **srcStableTokenAddress:** Address of the stable token in which the stable amount (srcStableTokenAmount) equivalent to the srcTokenAmount is calculated.
-6. **dataTx:** Data for the transaction for swap to convert the non-reserve token to the stable token on source chain (received from the API).
-7. **path:** Data for the transaction for swap to convert the non-reserve token to the stable token on source chain (received from the API).
-8. **flags:** The identifiers of DEXes that will be used for swap on source chain (received from the API).
-
-The details for the Execute Data can be found [here](./transfer-reserve-token#execute-data).
-
-The details for the Request Metadata can be found [here](./transfer-reserve-token.md)
-
-:::info
-💡 Note: Swap data and Execute data will directly be generated by the API. You don’t need to worry about generating this data.
-:::
diff --git a/docs/develop/asset-transfer/voyager/different-functions/transfer-reserve-token-arbitrary-instruction.md b/docs/develop/asset-transfer/voyager/different-functions/transfer-reserve-token-arbitrary-instruction.md
deleted file mode 100644
index 9c0a85e3..00000000
--- a/docs/develop/asset-transfer/voyager/different-functions/transfer-reserve-token-arbitrary-instruction.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Transfer of Reserve Tokens with Arbitrary Instruction
-sidebar_position: 3
----
-
-```javascript
-function depositReserveTokenAndExecute(
- bool isSourceNative,
- bool isAppTokenPayer,
- bytes calldata swapData,
- bytes calldata executeData,
- bytes calldata arbitraryData,
- bytes calldata requestMetadata
- ) external payable;
-```
-
-The flow is just the same as that of the reserve token transfer explained before. The only difference here is the arbitrary data that you need to pass and state whether the tokens that need to be swapped are to be deducted from the user or the application.
-
-### Arbitrary Data
-
-**Arbitrary Data** is the abi encoded data that comprises of:
-
-1. **destContractAddress:** Address of the contract which will be called after the transfer is complete. This contract needs to implement the voyagerReceive function (details given below).
-2. **data:** This is the abi encoded arguments that will be passed to the function that should be called on the destination contract address. The data should exclude the address and amount of tokens received as the amount may vary according to the fees. The address of the token and exact amount of tokens received by the user will be accessible into the handler function directly on the destination chain.
-3. **gasLimit:** The gas limit required for your function to be executed on the destination chain. The fees that we deduct from you will depend on this.
-4. **gasPrice:** Current gas price of the destination chain. The fees that we deduct from you will depend on this.
-
-### voyagerReceive
-
-The arbitrary instruction that you provide here will be executed on the destination chain on the contract address that you specify. That contract must implement the **voyagerReceive** function given below.
-
-```javascript
-function voyagerReceive(
- address sourceSenderAddress,
- bytes32 srcChainIdBytes,
- bytes memory data,
- address settlementToken,
- uint256 settlementAmount
- ) external;
-```
-
-With this function, you will receive:
-
-1. **sourceSenderAddress:** the address of the sender of transaction from the source chain.
-2. **srcChainIdBytes:** the identifier of the source chain.
-3. **data:** Data for the params to the function for which the selector was received passed from the source chain.
-4. **settlementToken:** Address of the token which was received to the recipient after the transfer.
-5. **settlementAmount:** Amount of the settlement tokens received to the recipient after the transfer.
-
-Inside the **voyagerReceive** function on the destination chain, you will decode the data according to the requirements of the function selector and call that function which will complete the instruction execution.
diff --git a/docs/develop/asset-transfer/voyager/different-functions/transfer-reserve-token.md b/docs/develop/asset-transfer/voyager/different-functions/transfer-reserve-token.md
deleted file mode 100644
index e9ef4de7..00000000
--- a/docs/develop/asset-transfer/voyager/different-functions/transfer-reserve-token.md
+++ /dev/null
@@ -1,159 +0,0 @@
----
-title: Transfer of Reserve Tokens
-sidebar_position: 2
----
-import RelayerAPIData from '../../../../../src/utils/RelayerFees'
-
-
-```javascript
-function depositReserveToken(
- bool isSourceNative,
- bytes calldata swapData,
- bytes calldata executeData,
- bytes calldata requestMetadata
- ) external payable;
-```
-
-Reserve tokens are the tokens that have been kept in reserve by the Voyager protocol. The Voyager keeps reserves of some selected tokens on each chain so that it is able to provide fund transfers by locking funds on source chain and unlocking the funds on the destination chain. These include some stable tokens, wrapped native tokens for that chain as well as other tokens according to the needs as well as partnerships of projects with the Voyager .
-
-When a user wants to transfer any of these reserve tokens from source chain to any other token on the destination chain, this function is to be called. After this function is called, the Voyager’s infrastructure will handle the transfer of tokens to the other chain.
-
-**Parameters:**
-
-| isSourceNative | If the source token is the native token for that chain, this should be true. |
-| --------------- | -------------------------------------------------------------------------------------- |
-| swapData | abi encoded data for the required swap which is created by an API |
-| executeData | abi encoded data for the execution on the destination chain which is created by an API |
-| requestMetadata | abi encoded data |
-
-The **Swap Data** includes:
-
-1. **srcStableTokenAmount:** Amount of the reserve token the user wants to transfer to the other chain.
-2. **srcStableTokenAddress:** Address of the reserve token the user wants to transfer to the other chain.
-3. **srcTokenAddress:** Address of the token the user wants to transfer to the other chain. This will be the same as srcStableTokenAddress in case of reserve tokens.
-4. **destChainIdBytes:** The Chain ID identifier for the destination chain.
-
-The **Execute Data** includes:
-
-1. **destTokenAmount:** Amount of destination tokens user will receive. This will be checked in the middleware and if this amount (USD Value) is larger than what user deposited, the transaction will be reverted.
-2. **destTokenAddress:** Address of the token user will receive on the destination chain.
-3. **isDestNative:** If the token to be received on the destination chain is native token for that chain, this is set to 1 else 0.
-4. **destStableTokenAddress:** Address of the stable token in which USD value for the tokens to be received will be calculated on the middleware.
-5. **recipient:** Address of the recipient on the destination chain.
-6. **dataTx:** Data for the transaction for swap on destination chain received from the API. If the token to be received on the destination chain is a reserve token or an LP token for that chain, the dataTx will be an empty bytes array.
-7. **path:** Path for the swap on destination chain received from the API. If the token to be received on the destination chain is a reserve token or an LP token for that chain, the path will be an empty address array.
-8. **flags:** The identifiers of DEXes that will be used for swap on destination chain received from the API. If the token to be received on the destination chain is a reserve token or an LP token for that chain, the flags will be an empty uint256 array.
-9. **partnerId:** An ID assigned to the partner who has integrated the Voyager Widget. If you are not a partner, you can pass uint256 0 as partnerId.
-
-:::info
-Swap data and Execute data will directly be generated by the API. You don’t need to worry about generating this data.
-:::
-
-The **Request Metadata** includes:
-
-1. **destGasLimit:** Gas limit required for execution of the request on the destination chain. This can be calculated using tools like [hardhat-gas-reporter](https://www.npmjs.com/package/hardhat-gas-reporter).
-
-2. **destGasPrice:** Gas price of the destination chain. This can be calculated using the RPC of destination chain.
-
-```jsx
-// using ethers.js
-const gasPrice = await provider.getGasPrice();
-
-// using web3.js
-const gasPrice = web3.eth.getGasPrice().then((result) => {
- console.log(web3.utils.fromWei(result, 'ether'));
-});
-```
-
-To avoid the need for calculation, it can be passed as 0. The Router chain will then estimate the real-time gas price for them.
-
-3. **ackGasLimit:** Gas limit required for the execution of the acknowledgment on the source chain. This can be calculated using tools like [hardhat-gas-reporter](https://www.npmjs.com/package/hardhat-gas-reporter).
-
-4. **ackGasPrice:** Gas price of the source chain. This can be calculated using the RPC of source chain as shown in the above snippet. To avoid the need for calculation, it can be passed as 0. The Router chain will then estimate the real-time gas price for them.
-
-5. **relayerFees:** This parameter functions similarly to the priority fees on other blockchain networks. Since the Router chain relayers handle the execution of cross-chain requests on the destination chain, setting a higher `relayerFees` will increase the likelihood of your request being prioritized by relayers. If a very low `relayerFees` is provided, the Router chain will automatically adjust it to the minimum required amount to ensure that it is executed. If it is passed as 0, the Router chain will default it to the minimum set Relayer fee value.
-
- Minimum relayer fees based on network is as follows -
- isSourceNative parameter is true, then you need to send native tokens also with the call using the value method of solidity.
-:::
-```javascript
-uint256 amountOfNativeTokens = abi.decode(swapData, (uint256));
-(success, data) = voyagerDepositHandler.call{value: amountOfNativeTokens}(
- abi.encodeWithSelector(
- depositFunctionSelector,
- isSourceNative,
- swapData,
- executeData
- )
- );
-```
-
-:::caution
-The Voyager deducts tokens to be transferred from the contract or the user which called the Voyager’s deposit function. Hence, in case your contract is the one calling the deposit function then before calling the deposit function on the Deposit Handler please make sure to -
-1. Transfer the funds from user’s wallet to your contract
-2. Approve the Voyager Deposit Handler contract from your contract to deduct those tokens from your contract
-:::
\ No newline at end of file
diff --git a/docs/develop/asset-transfer/voyager/different-use-cases/sequenced-transfers.md b/docs/develop/asset-transfer/voyager/different-use-cases/sequenced-transfers.md
deleted file mode 100644
index 49b357f1..00000000
--- a/docs/develop/asset-transfer/voyager/different-use-cases/sequenced-transfers.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: Sequenced Transfers (Asset + Instruction)
-sidebar_position: 2
----
-
-As we discussed in the previous section, Voyager allows us to transfer assets and arbitrary instructions in a single sequenced request. In this section, we will explore how you can integrate Voyager into your smart contracts for sequencing cross-chain token and instruction transfers.
-
-The functions that can be called on Voyager for cross-chain sequencing are:
-
-1. depositReseveTokenAndExecute
-2. depositLPTokenAndExecute
-3. depositNonReserveTokenAndExecute
-
-While you can definitely integrate only one of these functionalities into your contracts according to your needs, we suggest you to use the call with selector method to be able to call any of these functions from your contracts.
-
-### Getting the data for the token transfer
-
-We will provide an API for the developers which will provide you the calldata for the swap directly. You won’t need to do anything, just call the API, get the data and call the Voyager using that data for token transfers. For the arbitrary instructions, we will demonstrate how you can create the arbitrary data too in this section.
-
-The params for the API call to get data for the swap are:
-
-1. **fromTokenAddress:** Address of the token to be transferred from the source chain.
-2. **toTokenAddress:** Address of the token to be received on the destination chain.
-3. **fromChainId:** Chain ID of the source chain.
-4. **fromChainType:** Chain type of source chain.
-5. **toTokenChainId:** Chain ID of the destination chain.
-6. **toChainType:** Chain type of destination chain.
-7. **isDestNative:** Whether the required token on the destination chain is the native token for that chain.
-8. **recipientAddress:** Address of the recipient.
-9. **isOnlyTokenTransfer:** This is a boolean value indicating whether the goal is token transfer only. In this case, since we don’t just want token transfers but the sequencing also, we will send false in its place.
-
-The data received from the API response will give you the function selector for deposit function that needs to be called on the Voyager Deposit Handler and the data pertaining to the swap.
-
-### Creating the data for the arbitrary instruction
-
-Arbitrary instructions are custom pieces of code which are executed on the destination chain after the token transfer is complete. The arbitrary data needs to be sent along with the token transfers on the source chain. This data is sent as it is to the destination chain without tampering with it. You can handle the execution of this data on your contract on the destination chain.
-
-Let’s start with a simple token transfer and stake functionality where user will call a function which will transfer the tokens to another chain and then call the stake function to stake the tokens received into the contract.
-
-Let’s say you want to create a function to transfer your funds and then stake it on another chain, then you will need to create a function to create that request on the source chain and a function to handle that request on the destination chain.
-
-Let’s create a function to create that request on the source chain. For the details regarding the Arbitrary Data that needs to be generated, please check [this](../different-functions/transfer-reserve-token-arbitrary-instruction#arbitrary-data).
-
-The arbitrary data consists of six fields:
-
-1. Destination contract address which will handle the request.
-2. The selector to the function which has the logic for handling the request.
-3. The data which contains the parameters for the function for which selector was passed. Note that this data won’t contain information regarding the token that will be received or the amount of tokens that will be received on the destination chain since this can vary in some cases depending on the fee and liquidity conditions.
-4. The address which will get the gas refund if there is some gas left after the execution.
-5. The gas limit that needs to be used while executing the call on the destination chain..
-6. The gas price that needs to be used while executing the call on the destination chain.
-
-Let’s consider that the handler function for the call on the destination chain is a stake function which looks like:
-
-```javascript
-function stake(address user, address token, uint256 amount) internal
-```
-
-Then the selector that needs to be passed can be generated easily. So we generate the selector to the function and store it in the **STAKE_FUNCTION_SELECTOR** variable. We take the address of the recipient in whose address the stake will be registered, the refund address, the gas limit and the gas price for the destination chain in the parameters and return the arbitrary data.
-
-```javascript
-address public destContractAddress;
-// function stake(address user, address token, uint256 amount);
-bytes4 public constant STAKE_FUNCTION_SELECTOR = bytes4(keccak256("stake(address,address,uint256)"));
-
-function createDataForStaking(
- address recipient,
- address refundAddress,
- uint256 gasLimit,
- uint256 gasPrice
-) public returns (bytes memory) {
- bytes memory data = abi.encode(recipient);
-
- return abi.encode(
- destContractAddress,
- STAKE_FUNCTION_SELECTOR,
- data,
- refundAddress,
- gasLimit,
- gasPrice
- );
-}
-```
-
-This gives us the arbitrary data which can be used to call the functions of the Deposit Handler.
-
-### Calling the Voyager Deposit function
-
-```javascript
-address public voyagerDepositHandler = "address of voyager deposit handler";
-// depositReserveTokenAndExecute(bool,bool,bytes,bytes,bytes)
-bytes4 public constant DEPOSIT_RESERVE_AND_EXECUTE_SELECTOR = 0xf64d944a;
-// depositNonReserveTokenAndExecute(bool,bool,bytes,bytes,bytes)
-bytes4 public constant DEPOSIT_NON_RESERVE_AND_EXECUTE_SELECTOR = 0x79334b17;
-// depositLPTokenAndExecute(bool,bytes,bytes,bytes)
-bytes4 public constant DEPOSIT_LP_AND_EXECUTE_SELECTOR = 0xe18cfa35;
-
-function callVoyager(
- bytes4 selector,
- bool isSourceNative,
- bool isAppTokenPayer,
- bytes memory swapData,
- bytes memory executeData,
- bytes memory arbitraryData
-) public
-{
- bool success;
-
- if (selector == DEPOSIT_RESERVE_AND_EXECUTE_SELECTOR || selector == DEPOSIT_NON_RESERVE_AND_EXECUTE_SELECTOR) {
- (success, ) = voyagerDepositHandler.call{ value: msg.value }(
- abi.encodeWithSelector(selector, isSourceNative, isAppTokenPayer, swapData, executeData, arbitraryData)
- );
- } else {
- (success, ) = voyagerDepositHandler.call{ value: msg.value }(
- abi.encodeWithSelector(selector, isAppTokenPayer, swapData, executeData, arbitraryData)
- );
- }
-
- require(success == true, "Voyager deposit failed");
-}
-```
-
-### Handling the request on the destination chain contract
-
-The entry point of the cross-chain request for arbitrary instructions is the **voyagerReceive** function which needs to be implemented on each contract that wants to handle an arbitrary instruction from the Voyager. The detailed explanation for this function can be found [here](../different-functions/transfer-reserve-token-arbitrary-instruction#voyagerreceive).
-
-```javascript
-function voyagerReceive(
- address sourceSenderAddress,
- bytes32 srcChainIdBytes,
- bytes4 selector,
- bytes memory data,
- address settlementToken,
- uint256 settlementAmount
-) external;
-```
-
-This function is called by the Voyager Execute Handler, so make sure that only the Execute Handler can call this contract by using access control or a modifier otherwise the contract can be potentially exploited. Similarly also put a check on the source sender addresses so that only your contracts on different chains can call this function.
-
-The function receives the following parameters:
-
-1. The address of the contract which initiated the request on the source chain.
-2. The identifier for the source chain.
-3. The selector to the function passed to the contract from the source chain.
-4. The data variable sent from the source chain.
-5. The address of the token received by the recipient on the destination chain.
-6. The amount of tokens received by the recipient on destination chain.
-
-Let’s implement a function on the destination chain to handle the request coming from another chain.
-
-```javascript
-address sourceContractAddress;
-address voyagerExecuteHandler;
-// user address + token address => amount staked
-mapping(address => mapping(address => uint256)) stakedBalance;
-
-function voyagerReceive(
- address sourceSenderAddress,
- bytes32 srcChainIdBytes,
- bytes4 selector,
- bytes memory data,
- address settlementToken,
- uint256 settlementAmount
-) external {
- // Checking if the sender is the voyager execute handler contract
- require(msg.sender == voyagerExecuteHandler, "only voyager execute handler");
- // Checking if the request initiated by our contract only from the source chain
- require(
- sourceContractAddress == sourceSenderAddress,
- "source sender does not match"
- );
-
- // Checking the selector that was passed from the source chain
- if (selector == stake.selector) {
- // decoding the data we sent from the source chain
- address user = abi.decode(data, (address));
- // calling the stake function
- stake(user, settlementToken, settlementAmount);
- }
-}
-
-// The handler function for the stake request
-function stake(
- address user,
- address token,
- address amount
-) internal {
- // Updating the staked balances mapping
- stakedBalance[user][token] += amount;
-}
-```
-
-In this way, you can handle cross-chain requests from the Voyager on the destination chain.
-
-- [Cross-chain Staking Dapp](../guides/crosschain-staking.md)
diff --git a/docs/develop/asset-transfer/voyager/different-workflows/_category_.json b/docs/develop/asset-transfer/voyager/different-workflows/_category_.json
deleted file mode 100644
index 95ebd46e..00000000
--- a/docs/develop/asset-transfer/voyager/different-workflows/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Different Workflows",
- "position": 2
- }
\ No newline at end of file
diff --git a/docs/develop/asset-transfer/voyager/different-workflows/cross-chain-asset-transfer.md b/docs/develop/asset-transfer/voyager/different-workflows/cross-chain-asset-transfer.md
deleted file mode 100644
index 7cd6b1e4..00000000
--- a/docs/develop/asset-transfer/voyager/different-workflows/cross-chain-asset-transfer.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Cross-chain Asset Transfer
-sidebar_position: 1
----
-
-When a user calls a function to transfer funds to another chain, the Voyager Deposit Handler contract will process the transaction, deduct the funds from user’s wallet and create a cross-chain communication request to the Router Chain endpoint. After receiving data from the source chain, our bridge contract on the Router Chain will process the request, make some necessary checks and deduct the fees required for the transaction to be processed. Once this is complete, it will fire a transaction to the destination chain to complete the cross-chain transfer request.
-
-### Edge Cases
-
-#### 1. What if liquidity is not available for a token on the destination chain?
-The user will get the Wrapped tokens for those tokens on the destination chain which can be redeemed as soon as the liquidity is available on the chain.
-
-#### 2. What if I end up getting lesser amount of tokens on the destination chain than the minimum amount promised to me?
-This would never happen. The amount of destination tokens received depends on the DEX output while swapping the tokens. Maybe the output changed between the time that elapsed between when the amount was shown to you and the actual execution. In this case, the swap may result in lesser output for the user, but at Voyager, we have a policy of no loss to the user. So we provide you stable tokens equivalent to the minimum amount displayed to you instead of the token which was the output of the DEX so that you do not suffer any loss.
\ No newline at end of file
diff --git a/docs/develop/asset-transfer/voyager/different-workflows/cross-chain-sequenced-transfer.md b/docs/develop/asset-transfer/voyager/different-workflows/cross-chain-sequenced-transfer.md
deleted file mode 100644
index 05a07f8a..00000000
--- a/docs/develop/asset-transfer/voyager/different-workflows/cross-chain-sequenced-transfer.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Cross-chain Sequenced Transfer
-sidebar_position: 2
----
-
-The flow is very similar to that of cross-chain asset transfers. The main difference here is that the user also passes an arbitrary instructions from the source chain which is executed just after the token transfer is executed on the destination chain. The Voyager Execute Handler is responsible for calling the target contract on the destination chain. The target contract on the destination chain must implement the voyagerReceive function which is the entry point for the execution of the arbitrary instruction. An example to create send arbitrary instruction from a source chain and handling it on the destination chain is mentioned [here](../different-use-cases/sequenced-transfers).
-
-### Edge Cases
-
-#### 1. What if the token transfer is successful but the arbitrary instruction execution fails?
-This would never happen as the transaction, by design, is atomic which means that either both will execute or none will execute.
-
-#### 2. What if my transaction fails on the destination chain due to some issues? What happens to my funds?
-No need to worry. We provide a replay function on our bridge contract on the Router Chain which can be called by any user to replay a failed request. You can fix the issues and call this replay function to replay your transaction on the destination chain. Your funds are safe!
-
diff --git a/docs/develop/asset-transfer/voyager/fee-model.md b/docs/develop/asset-transfer/voyager/fee-model.md
deleted file mode 100644
index 69d63016..00000000
--- a/docs/develop/asset-transfer/voyager/fee-model.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Fee Model
-sidebar_position: 6
----
-
-## For an Asset Transfer Request
-
-For an asset transfer request, Voyager's bridge contract on the Router chain calculates the bps-based fee and subtracts it from the destination token amount. For example, if a user has deposited 10000 USDC on the source chain and the fee comes out to be 10 USDC, then the bridge contract will change the destination token amount to 9990. This means that even though a contract on the Router chain calculates the fee, it is maintained on Voyager's Reserve Handler contract on the source chain.
-
-```javascript
-Fee = Min((baseFee + bps * txVolumeInUSD), maxFee)
-```
-
-:::info
-If the fee required for transaction is greater than the amount being transferred and the cost of reverting it is lesser than the amount transferred, the transaction will be reverted back on the source chain by a request from the bridge contract on the Router Chain.
-:::
-
-In this system, we need the price of the reserve tokens in USD as the fee has to be set in terms of USD. To get this price, we have two approaches:
-1. **Using Band Protocol Oracles:** For most of the reserve tokens, we will get oracles from Band Protocol.
-2. **Using Centralized Services:** If we are not able to source a reliable oracle for any reserve token, we will fetch its price from CoinGecko/CoinMarketCap.
-
-
-## For a Sequenced Request
-
-
-
-There are two fees associated with a sequenced cross-chain request - one for the asset transfer call and one for the data transfer call. The fee associated with the asset transfer call is calculated in the same way as given above. The only change is that the fee is not actually subtracted from the destination chain amount, but it is deducted from Voyager's bridge contract address along with the fee for the data transfer call, which is calculated as per the token price and gas price oracle. Voyager's bridge contract will, in turn, deduct this fee from the bridge contract address of the original application that made the sequenced request.
\ No newline at end of file
diff --git a/docs/develop/asset-transfer/voyager/guides/crosschain-staking.md b/docs/develop/asset-transfer/voyager/guides/crosschain-staking.md
deleted file mode 100644
index 03c9f5db..00000000
--- a/docs/develop/asset-transfer/voyager/guides/crosschain-staking.md
+++ /dev/null
@@ -1,597 +0,0 @@
----
-title: Cross-chain Staking dApp
-sidebar_position: 1
----
-
-In this section, we shall create a simple cross-chain staking dapp using the Voyager sequencer. We shall follow the instructions provided in the previous section to create the same. It consists of two smart contracts: **Vault** and **Stake**.
-
-**Vault** contract enables the user to first transfer his funds from chain A to chain B and then stake them on chain B.
-**Stake** contract manages the staked tokens balance on the destination side. In other words, Stake contract is the fund and state manager of the Vault contract.
-
-