General Info


When it comes to investments, managing risk is of paramount importance.

An approach of invest and forget has a very high risk of ruin for the individual investor and unfortunately this area is often overlooked during the process of forming a trading or investment plan.

The traditional finance industry uses a large variety risk management tools but even the most basic versions of these tools are still missing in DeFi applications.

These include order types such as:

  • Limit Market Order
  • Stop Market Order
  • Bracket Order
  • Dollar Cost Averaging (DCA)


Limit Market Order

A Limit Market order to swap from tokenIn (eg. USDC) for another tokenOut (eg. BOO, WFTM, STG) is an order that only executes the swap when the price of the tokenOut / USDC is lower than the Limit price that the user submitted.


Stop Market Order

A Stop Market order to swap a tokenIn (eg. BOO, WFTM, STG) for tokenOut (eg. USDC) is an order that executes when the price of tokenIn / USDC is below the Stop price that the user submitted.


Bracket Order

A Bracket order is a combination of a special Limit Market and a Stop Market order. In one case the user may have exposure to an existing trade and want to swap a tokenIn (e.g. BOO, WFTM, STG) for tokenOut (eg. USDC) either when the tokenIn / USDC price is above the Limit price submitted (usually used to realise a profit) or when the tokenIn / USDC price falls below the submitted Stop Price (usually used to realise a loss). It is also possible for a user to use a Bracket Order to enter a trade to take advantage of increased volatility.


Dollar Cost Averaging (DCA)

A Dollar Cost Average swap of tokenIn (eg. USDC) for tokenOut (eg. BOO, WFTM, STG) with number of splits 3 (fully customizable) and block interval 10 (fully customizable), allows a user to split the USDC amount he wants to swap for the tokenOut (eg. BOO, WFTM, STG) into 3 equal size orders and execute the swap at a predetermined fixed number of block intervals, minimizing slippage and achieving a more average price.


With the above order types, the user can pre-plan when to maximize profits when to minimize losses.

In addition all the above do not require the user to always be in front of the screen. The order types in the project allow the trading opportunities and risk management to be fully automated.


Interconnected Contracts

Via the Interconnected Contracts technology, a user of any ecosystem e.g. Moonbeam (Polkadot ecosystem), Binance Smart Chain ecoysystem can connect to any Fantom native project.

This opens up the possibilities for app design and UX to mutliple ecosystems, in turn utlizing the powerful dynamics of each chain.

For example in our case, before this technology, if a BSC or Moonbeam user wanted to have exposure to the main Fantom Currencies (eg. BOO, WFTM, STG) they either had to use a bridge to transfer funds across or invest in a version of these tokens natively brought to their chain but being non-native to their ecosystem, resulting in tokens suffering from limited availability and high DEX slippage.

Naturally, a BSC or Moonbeam user may want exposure to these currencies without having to change chains or transfer funds to those chains in those ways.

In our project a BSC/Moonbeam user interacts with a BSC or Moonbeam deployed smart contract (AxelarBinaceSatelite / AxelarMoobeamSatelite) to submit and delete orders.

They provide the necessary ERC20 approvals to this smart contract and their instructions are carried from BSC / Moonbeam to Fantom via Axelar resulting in the submission or deletion of their orders.

It is important to note that at the stage of submitting an order the smart contract reads the user's balance, increasing their allowance to the smart contract for the token they want to swap in but no actual funds are being transferred.

Note: Incase of deleting an existing order the user's allowance to the smart contract is reduced for the tokenIn reference accordingly. This active management of scaling up and down the users allowance for a tokenIn they were to swap for other tokens ensure responsible order and asset approval management.

When an order submitted by the BSC / Moonbeam user to the Fantom based Orderbook, it is pushed to the Fantom based execution engine (ExecutionEngineFromBinance / ExecutionEngineFromMoonbeam smart contract) and instructions are sent from the Fantom based execution engine to the AxelarBinaceSatelite / AxelaMoonbeamSatelite smart contract that the user apporoved for the relevant token originally.

Once the message is received in AxelarBinaceSatelite / AxelarMoobeamSatelite smart contract then it will attempt to transfer the relevant token (axlUSDC) from the user (as originally approved), transfer it via Axelar to the Fantom based Execution Engine so it can then be swapped for the desired tokenOut (eg. BOO, WFTM, STG)

Note: If the BSC / Moonbeam based users balance is not enough because in the meantime the user has used the funds elsewhere, forgetting to cancel his working order, then the AxelarBinaceSatelite / AxelarMoobeamSatelite smart contract instructs the Fantom based execution smart contract that the order size of the order ready for execution is zero which results in instant order cancelation.

Once the BSC / Moonbeam user sees his Limit or DCA order being excuted successfully in swapping axlUSDC to BOO, WFTM, STG the respective BOO, WFTM, STG balances are kept in the Fantom based execution engine and this is the balance shown on the screen for a BSC / Moonbeam based user

In this way the BSC / Moonbeam user transfers axlUSDC only when their orders are ready for execution, benefitting from the Fantom maximum liquidity for the native tokens BOO, WFTM, STG. Their tokens are stored in the Fantom based Execution Engine, ready to be swapped back to axlUSDC and transferred via Axelar to their BSC / Moonbeam based EVM account when they use Stop or Bracket Orders.

Note: Of course the user could switch chains from BSC / Moonbeam to Fantom and ask to withdraw their tokens BOO, WFTM, STG to his EVM account on Fantom. But we followed the approach that by definition a BSC / Moonbeam user is not obliged to switch chain to get exposure to his tokens but execute all functionality natively from their BSC / Moonbeam EVM account.

Built With

Share this project:

Updates