](https://docs.mangrove.exchange/general/web-app/trade/how-to-make-an-order/minimum-volume) # Amplified Order An **Amplified Order** on Oxium is an enhanced limit order that utilizes the **Liquidity Sourcing** option. This allows you to place limit orders across multiple markets with the same funds, leveraging Oxium’s principle of unlocked liquidity for efficient capital use. When setting up a [**Limit Order**](/dapp-guide/trade/how-to-make-an-order/limit-order) on the Trade page, you can configure the **Liquidity Sourcing** options to enable an **Amplified Order**. This allows you to make the most of Oxium’s unlocked liquidity features. 1. **Choose Order Type**: Select **Limit** under the Buy or Sell tab on the right-side panel. 2. **Enter Limit Price and Amount**: Set the specific price and amount for your limit order. 3. **Configure Liquidity Sourcing**: **Send from**: This option allows you to choose the specific wallet or source from which the liquidity for the limit order will be drawn. **Receive to**: This option defines where the proceeds from the trade will go once the order is executed. For **Amplified Orders**, setting up **Liquidity Sourcing** with specific **Send from** and **Receive to** wallets enables: * **Multi-Wallet Management**: Users can choose to fund the order from one wallet and receive the output in another, adding flexibility in asset management. * **Amplified Liquidity**: By using Oxium’s unlocked liquidity, your funds in one wallet can simultaneously support multiple orders across markets, maximizing liquidity efficiency.[
](https://docs.mangrove.exchange/general/web-app/trade/how-to-track-open-orders) # More on order types This section provides an overview of the various order types available on Oxium: * Market order * Immediate or Cancel (IOC) * Good 'til time (GTT) * Fill or kill (FOK) ### Market order[](https://docs.mangrove.exchange/general/web-app/trade/more-on-order-types#market-order) A market order is an order type used to buy or sell at the current market price. * It is executed immediately, prioritizing speed over the specified price. * The execution price of a market order may vary due to market fluctuations and order book liquidity. * Unlike limit orders, market orders do not have a specific price parameter and **are subject to slippage**, where the executed price may differ from the expected price. Example You place an market order to buy 1 WETH, with a 3% slippage (i.e. you are willing to accept up to 3% of price slippage on your order). Your order could either be executed: * In full at 1,800 USDC (desired price). * In full at a price between 1,800 USDC and 1,854 USDC (with a slippage of 3%). * Partially, depending on the liquidity available on the offer on the order book. * Ex: 0.5 WETH at 1,800 USDC + 0.25 WETH at 1,818 USDC (1% slippage) + 0.25 WETH at 1,854 USDC (3% slippage) ### Immediate or Cancel (IOC)[](https://docs.mangrove.exchange/general/web-app/trade/more-on-order-types#immediate-or-cancel-ioc) While it may seem similar to a market order, there is a fundamental difference. * With an IOC order, you set a specific limit price at which you want the order to be executed. * The order will either be immediately filled at that exact price, fully or partially, or canceled entirely. It's about ensuring that your order is executed at your desired price, or not executed at all. * The IOC order **does not allow for slippage**, meaning it won't be filled at a different price than what you specified (unlike a market order). Example You place an IOC order to buy 1 WETH at a max price limit of 1,800 USDC. Your order could either be: * Fully taken immediately, i.e. you get your 1 WETH at the desired price. * Partially taken immediately, i.e. you get 0.8 WETH at the desired price, and the rest is "canceled" (there is no resting order asking for the remainder). * Canceled if there is no match on the order book. ### Good 'til time (GTT)[](https://docs.mangrove.exchange/general/web-app/trade/more-on-order-types#good-til-time-gtt) It allows you to set an expiry date for your limit order (ex: active for 3 days, then canceled if not filled). A GTT order that was created, but that has not yet been filled will always show as "Filled" in the UI - it is a normal behavior.
Let us explain: * When placing a GTT order, Oxium will attempt to fill it entirely at the desired price. * **Instant order** = the first execution of the order: * If it is a match and the fill is in full, it will be recorded in the UI as is. * If it can't be matched just yet, a fill at quantity "0" will be recorded in the UI for the instant order, and a **resting order** will be created. * More on the fill at quantity "0": * That allows you to track in the UI that the order was successfully executed, even if no actual quantity was **yet** bought or sold. * It is crucial - without this, there would be no visual trace of what happened to the order you just placed (if not taken). * Your resting order is then waiting to be filled. There could potentially be multiple fills for that same order. Typically, there will be one fill for the initial order (0 or any other amount taken), and additional fills up until the resting order is fully taken. * This mechanism ensures that even if there are partial fills or subsequent trades on the resting order, each execution is recorded separately. Example You place an GTT order to buy 1 WETH at a max price limit of 1,800 USDC, with a time limit of 3 days. Your order could be processed in several ways: * **Instant full fill**: Your order is fully taken, immediately. * That means you obtain the target 1 WETH at the desired price. * A fill of the transaction will be recorded in the UI. * **Instant partial fill + Resting Order**: * If your order is not entirely filled, a fill with the quantity that has been partially executed will be recorded in the UI. * Then, a new order will be created to capture the remaining quantity at the requested price. This order will be resting on the order book, waiting to be fully or partially taken, until the expiry date. * Each subsequent transaction that matches your resting order will be logged as a new fill until the order is fully executed or expired * **No instant fill + Resting Order**: * If there is no matching order available on the order book at the time of placement, a "resting" order is posted in the book, waiting to be taken, either fully or partially. * Each transaction will log a new fill until the order is fully taken or expired. * **Order Cancellation**: If there is no match for your order on the order book by the end of the specified time period (3 days in this case), the order will be automatically canceled. ### Fill or Kill (FOK)[](https://docs.mangrove.exchange/general/web-app/trade/more-on-order-types#fill-or-kill-fok) The KOF order is an "all or nothing" instant order. It is similar to the IOC order in the sense that it executes immediately, but it does not allow for partial filling. Example You place an FOK order to buy 1 WETH at a max price limit of 1,800 USDC. Your order could either be: * Fully taken immediately, i.e. you get your 1 WETH at the desired price. * Canceled if there is no match on the order book. # Approvals ## Infinite approval[](https://docs.mangrove.exchange/general/web-app/trade/approve-buy#infinite-approval) Before your order can succeed, you will have to approve Oxium to transfer the funds. 1. After choosing your order parameters, you will have to click the "Buy" or "Sell" button. 2. It will trigger the approval process, starting with a pop-up. Click on "Proceed" then "Approve". 3. Your wallet will open - you can leave the suggested amount for an "infinite approval". caution Clicking "Max" will give you the maximum amount available in your wallet. This means you will have to re-approve each time you make an order. 4. Click next, review the transaction and click "Approve" on your wallet. 5. Wait for the transaction to be processed, and that's it - you're ready to trade! On the following pages, you will find more details on how to execute different order types ## About Approvals[](https://docs.mangrove.exchange/general/web-app/trade/approve-buy#about-approvals) You can read some more about approvals in the FAQ section. Here are a few things you should consider when it comes to approvals: 1. An approval is valid only for a specific order type of a specific market. > 💡 For example, if you approved a BUY market order for the WSEI/USDC market, this approval is not valid for SELL market orders for that same market. You have to approve again. 2. Approvals accumulate together. > 💡 For example, if you approve buy market order for WSEI/USDC market with a 1000 USDC and perform a market order for 100 USDC, you have 900 USDC in approved balance. If you perform the same action again ("Approve & Buy"), you'll have 1800 USDC of approved balance. 3. If your pre-approved amount is used up, your order will fail. An easy way around this is to perform an infinite approval. ## Revoke token approvals[](https://docs.mangrove.exchange/general/web-app/trade/approve-buy#revoke-token-approvals) To remove a dApp access to your wallet's tokens, you can revoke approvals previously granted. An easy way to do it would be to use [Revoke](https://revoke.cash/), for example. This will however risk your orders failing if you have open orders, so be sure you don't need the approvals. # Minimum Volume Due to the density on each market, there is a minimum token value requirement when placing limit orders (except for IOC orders). You can read more about why your transactions might be failing in the FAQ. This value will change based on the market and the source of liquidity you select, so please check the volume below in the app to make sure before you place your order! # How to Track and Manage Orders Oxium’s Trade page dashboard is designed to help you efficiently manage and track all of your active, filled, and historical orders for each trading pair. Here’s a breakdown of how to monitor and interact with your orders. ## **Trades Tab** The **Trades** tab shows recent transactions for the selected trading pair. This log of recent trades helps you understand market activity and price trends. It includes: * **Size**: The amount of the asset traded. * **Price**: The price at which the trade occurred. * **Date**: The timestamp of each trade. This tab provides a quick way to gauge market trends and see how frequently trades are happening at different price points. ## **Open Orders Tab** The **Open Orders** tab is where you’ll find all your active limit orders that haven’t been filled or canceled yet. This tab is essential for tracking orders that are waiting for specific market conditions. Here’s what you’ll see: * **Market**: The trading pair associated with the order, such as WETH/USDC. * **Side**: Indicates whether it’s a Buy or Sell order. * **Type**: Specifies the type of order, typically Limit or Market. * **Filled/Amount**: Shows how much of the order has been filled versus the total order amount. * **Price**: The set price for the order to execute. * **Time in Force**: Indicates the order’s duration condition (e.g., GTC - Good Till Canceled, FOK - Fill or Kill). * **Action**: An option to cancel the order directly from this tab if needed. This tab is particularly useful for monitoring your ongoing trades and adjusting or canceling them as necessary. ## Managing Orders from the Open Orders Tab From the **Open Orders**, you can quickly manage your orders: Modify or cancel them. * **Modify**: Click **Modify** (the pen) to open the **Order Details** window, where you can adjust: * **Limit Price**: Change the price at which you want the order to execute. * **Amounts**: Adjust the amounts for **Send from Wallet** or **Receive to Wallet** to increase or decrease the funds allocated to this order. * **Cancel**: If you no longer want the order to remain open, click **Cancel** (the cross) to remove it from the Open Orders list and cancel your order. ## **Orders History Tab** The **Orders History** tab provides a comprehensive log of all your completed, expired, or canceled orders. Here, you can review past trades and actions. The fields in this tab include: * **Market**: The trading pair involved in the order. * **Side**: Shows whether it was a Buy or Sell. * **Type**: Indicates the order type, such as Market or Limit. * **Received/Sent**: Details the amounts of assets traded or received. * **Price**: The price at which the trade was executed. * **Date**: The date and time the order was filled or canceled. * **Status**: Displays the final status of the order, such as Filled, Expired, or Canceled. * **Explorer**: A link to the blockchain explorer for each transaction, enabling you to verify and track transactions on-chain. # Earn The **Earn** page on Oxium’s DApp lets you explore and manage yield-generating positions within available vaults, built on Oxium's flexible liquidity engine. These vaults leverage Oxium’s unique liquidity provisioning to offer optimized yield strategies, allowing you to earn rewards while maintaining liquidity flexibility. With Oxium’s composable infrastructure, yield opportunities are more dynamic and adaptable to market conditions, giving liquidity providers enhanced control over their earnings. You can deposit tokens to earn yields, view your active positions, and monitor key metrics for each vault. #### **Step 1: Accessing the Earn Page** In the Oxium DApp sidebar, click the **"Earn"** icon (the piggy bank icon). This will take you to the Earn page, where you can view all available vaults and your active positions.
→ 43% User Incentives (Airdrop).
— Early Supporters and users who helped bootstrap the product. 8% unlocked at TGE.
— 35% for post-TGE incentives and growth.
→ 5% Grants & Partnerships
const { ethers } = require("ethers");
// context
// outTkn: address of outbound token ERC20
// inbTkn: address of inbound token ERC20
// ERC20_abi: ERC20 abi
// MGV_address: address of Mangrove
// MGV_abi: Mangrove contract's abi
// signer: transaction signer
// loading ether.js contracts
const Mangrove = new ethers.Contract(
MGV_address,
MGV_abi,
ethers.provider
);
const InboundTkn = new ethers.Contract(
inbTkn,
ERC20_abi,
ethers.provider
);
const OutboundTkn = new ethers.Contract(
outTkn,
ERC20_abi,
ethers.provider
);
// if Mangrove is not approved yet for inbound token transfer.
await InboundTkn.connect(signer).approve(MGV_address, ethers.constant.MaxUint256);
// preparing snipes data
const outDecimals = await OutboundTkn.decimals();
const inbDecimals = await InboundTkn.decimals();
const snipe1 = [ // first snipe spec
offer1, //offer id
ethers.parseUnits("1.5",outDecimals), //takerWants from offer1
ethers.parseUnits("2.0",inbDecimals), //takerGives to offer1
100000 // 100,000 gas units to execute
];
const snipe2 = [ // second snipe spec
offer2, //offer id
ethers.parseUnits("1.5",outDecimals), //takerWants from offer1
ethers.parseUnits("2.2",inbDecimals), //takerGives to offer1
50000
];
// triggering snipes
await Mangrove.connect(signer).snipes(
outTkn,
inbTkn,
[snipe1, snipe2],
true // fillwants
);
addressoutbound_tknaddressinbound_tknuintofferIdMgvStructs.OfferPackedofferuintwantsoutbound_tkn ERC20).uintgivesinbound_tkn ERC20).MgvStructs.OfferDetailPackedofferDetailMgvStructs.GlobalPackedglobalMgvStructs.LocalPackedlocal| Type | Field | Description |
|---|---|---|
bytes32 | makerData | The returned or reverted value of makerExecute, truncated to fit a bytes32 word. |
bytes32 | mgvData | Information gathered by Mangrove concerning the offer execution. If the offer was a success it is equal to:
If the offer failed (Offer Bounty will be taken from Maker Contract), it will be equal to one the following messages:
|
**Note** : For this explanation, we are conveniently using a 1 ETH allocation for each increment. If based on our parameters, our Kandel would create a price grid of 10 points, for example, then we would use 10 ETH in total (1 ETH \* 10 price points). ### Populating Bids and Asks
The pair represents the chosen market on which a Kandel strategy is running (along with the technical tick spacing).
Example: ETH/USDC is a trading pair
| | Price range |The price range is needed to run any market-making strategy. It consists of the lowest and highest prices in the price grid at which Kandel instance posts its bids and asks.
Example of a price range:
• Lowest price = 1000 USDC per ETH
• Highest price = 1500 USDC per ETH
The current price of the base token that is used for constructing the price distribution.
Example: the price of ETH is used for the ETH/USDC pair
| | Number of offers | The number of offers to be published by the Kandel strategy within the selected price range. | | Ratio |The ratio defines the distance between price points which is derived using geometric progression.
Example:
• Ratio is 0.01 (due to ticks it will not be exact)
• Mid price is 1000
• Price point below mid price: 10000.99
• Price point above mid price: 10001.01Additionally, the ratio could be derived from price points PricePoint(i+1) / PricePoint(i) - 1.
Example: 1010 / 1000 - 1 = 0.01
It is the distance between an executed bid/ask and its dual offer.
Whenever a Kandel ask is taken at a given price point, Kandel uses the amount of quote just received to place a bid at a lower price point. With a step size of 1, it will place the bid at the price point immediately below. With a step size of 2, Kandel will repost two price points below, etc. (Technical aside: if in attempting to repost say 3 steps below Kandel hits the boundaries of its range it will transport as far below as possible). The same applies symmetrically for bids.
Using a step size ≥ 2 allows one to publish a more continuous liquidity on the books, regularising the strat’s PnL, while at the same time keeping a reasonable spread between price points. Indeed, what matters to PnL is not the distance between price points, but how far money moves along the price grid each time an offer is taken.
| | Initial inventory |The initial inventory is the amount of base tokens and quote tokens that must be deposited into the strategy. The minimum to be deposited into the strategy depends on the selected price range and density of the selected market.
Example on the ETH/USDC pair:
• Base token is ETH
• Quote token is USDC
It is the required amount of native tokens to be deposited into the strategy. A provision is required to post an offer, in order to pay a potential bounty. The bounty is only a subset, smaller in value than the provision.
The provision covers the whole price grid, hence:
• Kandel provision = Provision per offer x Number of offers
Example: if the selected pair is on the Polygon network, the bounty would be an amount of MATIC tokens.\*
| # Choosing Kandel parameters This section goal is to help you develop an intuition to choose your Kandel parameters. It should be taken as an explanation on how the various parameters can impact your Kandel, and how the market conditions (ex: volatility) could be taken into account. It is **not** a trading advice. **Note** : As a reminder, Kandel is not intended as a "set and forget" strategy, and needs ongoing maintenance and checks. We will be going through standard steps you might want a take in order to check the market and deploy a new Kandel. Essentially, that means that by using discrete AMM such as Kandel, you can fix the level of liquidity you are offering adjusted per volatility. So choosing the spread starts with answering the question - what is the volatility? If you can estimate or predict it well enough, the only thing you need to do is pick the spread (i.e. your parameters for Kandel). ### Check-in frequency First, it is good practice to know how often you aim to update your Kandel. Depending on the trading pair you chose, markets can behave very differently. **Example** : I will update my Kandel every 24h. ### Set your price range Next, you should try to anticipate how much the market/price will vary during that period you just decided on. You are kind of betting on daily volatility. **Example :** I will look at the market volatility for the past 24h, and decide on the price range for my new Kandel. ### Number of Offers / Ratio This is the number of offers / ratio of the progression used to calculate the price grid. You would logically bet on intra-day volatility (few min or hours). If the volatility is increasing, you might want to increase the grid size (space between the offers). You will find more information about its calculation in the previous table. **Note :** * High volatility: spaced out offers (less offers in the chosen range) -> higher ratio * Low volatility: narrow offers (more offers in the chosen range) -> smaller ratio ### Step size The general idea to configure your step size, is that a bigger volatility would likely lead to a bigger step size. ### Simple use case Let's say you want to have a continuous Kandel, and maybe your current paramaters allow you only 2 offers: * The solution to this is instead of having 2 offers with a step size = 1, you can configure 16 offers with a step size of 8 * That gives you continuity (more offers for a similar interval) * When your offers are taken, Kandel will be able to "grab" lower prices # Published Liquidity Kandel instances don't lock your funds into the strategy. It uses the funds on the selected source, for publishing the chosen amount of liquidity. Published liquidity is the amount of liquidity in active offers that are managed by the particular Kandel instance. # More on failing offers This section explains the reasons why some offers might fail using Kandel. ### Definition When we talk about an offer "failing", we mean that it could not execute. An offer can also fail to update itself. While we won't go into details in this part of the documentation, it is important to mention and differentiate those cases to further understand Kandel strategy's behavior. * `makerExecute()`: it is the callback function that is called when an offer is matched. Its role is to execute all offers that were posted on Oxium by a given contract. * A failure in `makerExecute()` means the trade is canceled, and the bounty is given to the Taker as a compensation. The offer is removed from the book. * `makerPosthook()`: it is the callback function that is called after the offer execution (i.e. after a successful execution of `makerExecute()`). * A failure in `makerPosthook()` means the offer cannot update or repost itself after being taken. It does not cancel the trade, since it is called after `makerExecute()`. ### Kandel and `makerExecute()` failure After launching a Kandel strategy, Bids and Asks are populated with a certain volume. Kandel strategy's contract is handling all the posting for the user, using liquidity that has been previously deposited.\ Therefore, since the user is not in charge of writing and maintaining the smart contract, failures to execute `makerExecute()` can be almost entirely ruled out, with the exception of some very specific scenarios such as: * Someone severely modifies the volume distribution/sourcing methods, creating issues when a Kandel Bid/Ask is taken (via the SDK) * Kandel runs on YEI, and the user's liquidity is not available for sourcing at the time the offer is taken. That could happen if the user's funds are suddenly borrowed entirely (on YEI) ### Kandel and `makerPosthook()` failure The main failures that Kandel could run into are linked to reposting Bids and Asks. This has little incidence for the user, nor does it affect the behavior of his Kandel strategy.\ Non-reposted liquidity will be placed into the Unallocated liquidity reserve, and the offer will be "empty" for Kandel, until the user replenishes it.**Note** : > If too many empty offers stack up, it would diminish Kandel's ability to profit from the spread, and therefore the overall generated yield. Kandel is not intended as a "set and forget" strategy, and needs ongoing maintenance and checks. Reposting offers is handled with `makerPosthook()`, and failure could happen if: * The residual of a partially taken offer is too small with regard to density: * A partially taken offer is the result of a Taker placing a Market order * If an offer is almost entirely taken, the remainder (dust) could be too small to pass the density check, leading to a failure to repost itself * Kandel runs out of gas during the execution of the `makerPosthook()` because the gas requirements suddenly changed * This is unlikely to happen, but it theoretically could (if the order book becomes very dense in offers, for example) # Potential risks Kandel strategy is subject to some risks that should be taken into consideration. By using Kandel, you acknowledge (i) having the necessary knowledge and understanding of the blockchain technology and the tokens, and (ii) comprehended the risks associated with blockchain-based software systems and tokens, as described below and in the disclaimer. ### Economical risks As a user of the Kandel strategy, you understand that using Kandel can be affected by economic risks, including but not limited to: * Partial or total loss of the tokens used; * Partial or total loss of the value of the tokens used; * Market extreme volatility; * Insolvency of a third-party platform or company; * Absence of liquidity and impossible resale on markets of the tokens. ### Impermanent Loss Kandel is a passive market-maker where profit is generated from the spread. An example of impermanent loss on an ETH/USDC pair would be as follows: 1. If the current price of ETH/USDC pair moves up, asks will be consumed. 2. If the price keeps going up and crosses the max price range value, Kandel strategy will be left only with active bid offers on the ETH/USDC market. 3. It is likely that no one would be interested in taking these bids since they would not match the current price (you would be offering too little USDC for ETH, considering the new current price). This is what we call impermanent loss - your strategy stops generating profit from the spread. ### Smart contract and technological risks You understands that even though the strategy has been implemented by an experienced team of researchers and developers, the use of Kandel can be affected by smart contract and technological risks, including but not limited to: * Security error or failure allowing and/or resulting in hacking and stealing of user, third-party platform and/or website/app data; * Stealing or loss of the user external wallet private key or his access to the third-party platform; * Risks associated with blockchains used for the strategy, including but not limited to due to successful attacks from hackers or other criminal groups or organizations or countries, including but not limited to denial of service attacks, Sybil attacks, spoofing, smurfing malware attacks, consensus-based attacks, or phishing, or other new methods that may or may not be known; * Lack of transparency in crypto asset management and markets; That being said, please note that the **Kandel strategy has been thoroughly audited** by ChainSecurity. # Deployment adresses ### Contract Addresses[](https://docs.mangrove.exchange/developers/addresses/contract-addresses#core-contract-addresses) {% tabs %} {% tab title="Base" %} #### Core contracts These contracts are the immutable base of Mangrove both holding the book and markets, as well as exposing key view functions.
| Contract | Address | Source |
|---|---|---|
| Mangrove | 0x22613524f5905Cb17cbD785b956e9238Bf725FAa | Mangrove.sol |
| MgvReader | 0xe5B118Ea1ffBC502EA7A666376d448209BFB50d3 | MgvReader.sol |
| Contract | Address | Source |
|---|---|---|
| MgvPriceOracle | 0x8Fb396e0745F0B4b1Cf12FB2e4d1662Ff7560ffD | MgvPriceOracle.sol |
| Contract | Address | Source |
|---|---|---|
| MangroveOrder | 0xA3c363Ca0EA3603faEe9FAcffD65E777122adF36 | MangroveOrder.sol |
| KandelSeeder | 0x808bC04030bC558C99E6844e877bb22D166A089A | KandelSeeder.sol |
| AaveKandelSeeder | 0x095854c8C4591Fb0a413615B9a366B4Dd69b9B1D | AaveKandelSeeder.sol |
| ERC4626KandelSeeder | 0x4778c54E6380BBC6eF9647f2A31528B0640B41fE | ERC4626KandelSeeder.sol |
| Contract | Address | Source |
|---|---|---|
| Vault Factory | 0x26A0e433f89317Ca5585945198a5F0760C1dAFA5 | MangroveVaultFactory.sol |
| ERC4626 VaultFactory | 0x92dB74A11Ec2b2acDCFC354cf55243cF33C052B8 | MangroveERC4626KandelVaultFactory.sol |
| Chainlink oracle factory | 0x656A6ac038D1686D4f80427ddaF59b352f960123 | MangroveChainlinkOracleFactoryV2.sol |
| Chainlink oracle factory (legacy) | 0x9d05c7A303efEbD215B86B57Da2Fc671039E5712 | MangroveChainlinkOracleFactory.sol |
| Dia Oracle Factory | 0x5297561cb9df1D2Ff83698C6fc51aBeF24D39560 | MangroveDiaOracleFactory.sol |
| Oracle Combiner | 0xb898C4a986a1e4Fd31b9818772F9EC16dbf3EFED | OracleCombinerFactory.sol |
| Mint helper (V1) | 0x2AE6F95F0AC61441D9eC9290000F81087567cDa1 | MintHelperV1.sol |
| Contract | Address | Source |
|---|---|---|
| Ghost Book | 0x15F02Fb9c9Bb772A3303349F88c94Fc971bd549F | MangroveGhostBook.sol |
| UniV3 module | 0xAf31bEb21d2b1f8C3BdD211eC02470265A21ea3f | UniswapV3Swapper.sol |
| Contract | Address | Source |
|---|---|---|
| Mangrove | 0x109d9CDFA4aC534354873EF634EF63C235F93f61 | Mangrove.sol |
| MgvReader | 0x7E108d7C9CADb03E026075Bf242aC2353d0D1875 | MgvReader.sol |
| Contract | Address | Source |
|---|---|---|
| MgvPriceOracle | / (Arbitrum uses static values) | / |
| Contract | Address | Source |
|---|---|---|
| MangroveOrder | 0x50793D97A0c905Ea51c1C93f37FC73aBE6D2ffCc | MangroveOrder.sol |
| KandelSeeder | 0x89139Bed90B1Bfb5501F27bE6D6f9901aE35745D | KandelSeeder.sol |
| AaveKandelSeeder | 0x55B12De431C6e355b56b79472a3632faec58FB5a | AaveKandelSeeder.sol |
| Contract | Address | Source |
|---|---|---|
| Vault Factory | 0x6B82CE8a45Ce9BeF9B20c3D65747356a5cDab41A | MangroveVaultFactory.sol |
| Chainlink oracle factory | / | MangroveChainlinkOracleFactoryV2.sol |
| Chainlink oracle factory (legacy) | 0x31c47E3F442F521E1c65b5b626aC2e978C1f2587 | MangroveChainlinkOracleFactory.sol |
| Dia Oracle Factory | / | MangroveDiaOracleFactory.sol |
| Oracle Combiner | / | OracleCombinerFactory.sol |
| Mint helper (V1) | 0xC39b5Fb38a8AcBFFB51D876f0C0DA0325b5cD440 | MintHelperV1.sol |
| Contract | Address | Source |
|---|---|---|
| Ghost Book | 0x46708Dd6E68e1f09c6f4830C2586f73659dFafEA | MangroveGhostBook.sol |
| UniV3 module | 0x22Ba67Eb361Ec40e0949ED034F3CE08Af51099fA | UniswapV3Swapper.sol |
| Contract | Address | Source |
|---|---|---|
| Mangrove | 0xBe1E54d0fC7A6044C0913013593FCd7D854C07FB | Mangrove.sol |
| MgvReader | 0xe118B2CF4e893DD8D954bB1D629e95026b5E8D5A | MgvReader.sol |
| Contract | Address | Source |
|---|---|---|
| MgvPriceOracle | / (Static values) | MgvPriceOracle.sol |
| Contract | Address | Source |
|---|---|---|
| MangroveOrder | 0xC00D2Da52195B123d3c994aaf2eb1E8DA8999d4f | MangroveOrder.sol |
| KandelSeeder | 0x1A839030107167452D69d8f1a673004B2a1b8A3A | KandelSeeder.sol |
| AaveKandelSeeder | 0xCb62cD0Ea7aD46d5B630C1068C7bED2cBd2b7E23 | AaveKandelSeeder.sol |
| Contract | Address | Source |
|---|---|---|
| Vault Factory | 0x751A2128aDA840049D0Cc1C4B7F8cF7311F568Fd | MangroveVaultFactory.sol |
| Chainlink oracle factory | / | MangroveChainlinkOracleFactoryV2.sol |
| Chainlink oracle factory (legacy) | 0xC6488ED14C0AD6763eC56d8e81F1bDE5016772dD | MangroveChainlinkOracleFactory.sol |
| Dia Oracle Factory | / | MangroveDiaOracleFactory.sol |
| Oracle Combiner | / | OracleCombinerFactory.sol |
| Mint helper (V1) | 0xC0Ba6baF6899686bB601effE73bFC42404B93670 | MintHelperV1.sol |
| Contract | Address | Source |
|---|---|---|
| Ghost Book | / | MangroveGhostBook.sol |
| UniV3 module | / | UniswapV3Swapper.sol |
| Contract | Address | Source |
|---|---|---|
| Mangrove | 0xb1a49c54192ea59b233200ea38ab56650dfb448c | Mangrove.sol |
| MgvReader | 0x26fd9643baf1f8a44b752b28f0d90aebd04ab3f8 | MgvReader.sol |
| Contract | Address | Source |
|---|---|---|
| MgvPriceOracle | / (static values) | MgvPriceOracle.sol |