Risks of using Beets
Last updated: October 6, 2026
Using the Beets Protocol on Sonic involves risks for liquidity providers, swappers, and other users. This page summarizes risks to help you evaluate your use of the protocol. It is important to note that this list is not exhaustive, and there may be additional risks not explicitly mentioned here. As the risk environment is fluid, we expect to periodically update this summary.
Risks for liquidity providers (LPs)
General risks
Smart contract risk
Smart contract risk is a general risk when using DeFi protocols, including Beets. Smart contracts are self-executing pieces of code that run on certain blockchains, like Sonic. Although they are designed to be secure, they can be vulnerable to bugs and exploits.
If there is a flaw in the smart contract code, it can be exploited by attackers to steal funds from the protocol. This can result in the loss of funds for liquidity providers and swappers who are using the protocol. Smart contract risk is a major risk for all DeFi users, and it is important to carefully evaluate the security of the protocols before using them.
The Balancer Vault
Beets uses Balancer-based vault architecture on Sonic. Vaults hold and account for pool assets, while individual pools define their AMM logic. The contracts and features involved depend on the pool and protocol version.
A vulnerability in a shared vault can put assets in multiple pools at risk. Audits and prior operation do not guarantee that a vault, pool, or related contract is free of vulnerabilities.
How can this risk be reduced?
- Development teams have engaged with top-tier smart contract auditing firms to identify and fix bugs before deployment.
- Contract permissions and upgrade mechanisms vary across pools and their related contracts. LPs should review which components are immutable and which can be changed by an authorized party.
How can LPs mitigate this risk?
- LPs should carefully research and use DeFi protocols that are battle-tested with a history of functioning as intended, while securing large amounts of assets.
- To diversify risk, LPs may consider not placing all their tokens into a single protocol.
Mechanism/economic risk
A mechanism or economic exploit of a DeFi protocol occurs when an attacker is able to manipulate the economic incentives of the protocol to their advantage, resulting in a loss of funds for other participants. This can happen even when there are no smart contract bugs or other unintended logic errors.
For example, an attacker could take advantage of a liquidity pool's pricing mechanism to intentionally cause the price of an asset to deviate from its true value, allowing them to buy or sell that asset at a profit.
In addition, the composable nature of DeFi means that a pool on Beets may contain tokens that may be manipulated by an attacker on a third-party protocol, which further increases risk.
These types of economic exploits are difficult to detect and prevent.
How can LPs mitigate this risk?
- LPs should carefully research and use DeFi platforms that are battle-tested with a history of functioning as intended, while securing large amounts of assets.
Toxic pool token risk
A liquidity pool is only as good as its weakest token. This is because liquidity pools typically sell the winners (tokens moving up in price) and accumulate the losers (tokens moving down in price). If a pool contains a toxic token, the value of the BPT (LP tokens) of the liquidity pool could go to zero. This is the case even if the other pool tokens remain good and would otherwise not be affected.
A toxic token could be seeded into a liquidity pool by a malicious pool creator or an otherwise good token could become toxic (similar to Terra’s stablecoin UST).
Tokens that could become problematic for LPs:
- Unsupported tokens on Balancer Protocol, including:
- Rebasing tokens
- Tokens with transfer fees
- Proxy tokens with double entry points
- Tokens with more than 18 decimal points
- Rebasing tokens
- Tokens that become toxic, including:
- Tokens that are infinitely minted
- Tokens that become frozen or exploited in any other way
- Stablecoins that lose their peg
Rebasing tokens
Rebasing tokens are a type of cryptocurrency that adjusts the supply of the token based on a predetermined formula. This formula is usually designed to keep the price of the token stable relative to some external metric, such as the price of a particular asset or a specific index. When the external metric changes, the token supply is adjusted, which in turn affects the price of the token.
For example, if a rebasing token is designed to maintain a price of $1 per token and the price of the external asset goes up by 10%, the token supply would decrease by 10% to maintain the $1 price point. Similarly, if the external asset price goes down by 10%, the token supply would increase by 10%.
Rebasing tokens can adjust holders’ token balances to reflect changes in supply.
Unfortunately, rebasing tokens generally don’t work well in liquidity pools since LPs may suffer losses when rebasing occurs.
How can these risks be reduced?
- Since the Balancer Protocol is permissionless, anyone can create a liquidity pool composed of any ERC-20 token. This makes this type of risk difficult to mitigate.
- The Beets UI may be updated to exclude blacklisted tokens and pools but LPs should not rely on this.
- Instead of including tokens that rebase, pools may use non-rebasing tokens that accrue staking yield. For example,
stSaccrues Sonic staking rewards through an increasing exchange rate againstS, rather than changes to holders’ token balances. - Where supported, recovery mode allows LPs to exit a pool proportionally. Beets multisigs handle the relevant administrative controls on Sonic. Available actions and restrictions depend on the pool and protocol version.
How can LPs mitigate these risks?
- LPs should carefully check each pool constituent token and understand its specific risks.
- LPs should review all pool tokens before providing liquidity to ensure no constituent pool tokens are unsupported by the Balancer Protocol (e.g. rebasing tokens).
- LPs should carefully check the pool creator address to verify it’s from a reliable actor.
DeFi composability risks
DeFi composability refers to the ability of different DeFi protocols and applications to work together seamlessly in endless combinations, allowing developers to create more complex financial transactions and applications. This is sometimes referred to as DeFi lego building blocks, since they can be combined and connected to create interesting new structures and applications.
While composability offers many benefits, layering on protocols and applications on top of each other comes with additional risks. For example, risks get compounded when multiple protocols are composed together, as a vulnerability in one contract could impact others. The interconnectivity of DeFi protocols can amplify risks, turning isolated incidents into systemic threats. For example, if a major protocol fails or suffers from an exploit, it could lead to a domino effect, impacting other protocols and users in the ecosystem.
Other risks could cascade if a protocol within a composability stack has a liquidity crisis, an unfavorable governance decision or regulatory outcome.
Flash Loans risk
A Flash Loan is a type of loan where a user borrows assets with no upfront collateral and returns the borrowed assets within the same blockchain transaction. Flash Loans use smart contracts which requires that a borrower repays the loan before the transaction ends. They are typically used for arbitrage opportunities, collateral swaps and to lower transaction fees, across potentially multiple protocols. It’s a powerful new financial primitive, native to DeFi.
Flash Loans may be used on Beets and interact with the Vault.
While Flash Loans offer many benefits, they also come with certain risks. Flash Loans have also been used for multiple DeFi exploits resulting in losses worth millions of dollars. Flash Loan exploits are relatively new with the full range of attack surfaces still being discovered.
How can this risk be reduced?
- The Vault is non-reentrant, which blocks most Flash Loan attacks.
Mutable pool attributes
Beets is a flexible AMM that allows people to create different types of liquidity pools, including those with immutable and/or mutable pool attributes.
For pools with immutable attributes, LPs can be assured that the rules are designed so they cannot change once they have provided liquidity since no pool attribute should be changed by anyone at any time.
For pools with mutable attributes, LPs should understand:
- Which attributes can change
- Certain attributes being mutable are riskier than others. For example, changing the swap fee percentage is generally viewed as less risky than the ability to change the constituent tokens of a pool, since a malicious editor could introduce a toxic pool token.
- Who can change each attribute
- LPs should review the addresses and permissions that can change each attribute. Beets multisigs handle protocol-level administrative controls for the Sonic deployment; pool-specific permissions may also apply.
How can this risk be reduced?
- The Beets UI displays pool information, but LPs should also verify editable attributes and the addresses authorized to change them in the relevant contracts.
How can LPs mitigate this risk?
- LPs should check to see the editability of pool attributes and understand who can authorize any changes.
Loss of funds on join/exit of a pool
Due to high price impact
When joining a pool, LPs should be aware of the price impact from adding tokens to the pool. In general, adding liquidity in proportional amounts to the token weights of the pool incur low price impact. Adding custom token amounts (non-proportionally) causes the internal prices of the pool to change, as if you were swapping tokens. The higher the price impact the more you'll spend in swap fees.
Due to slippage
LPs should also consider the effect of slippage when adding liquidity to a pool. Slippage occurs when market conditions change between the time your order is submitted and the time it gets executed on Sonic. Slippage tolerance is the maximum change in price you are willing to accept.
Slippage tolerance is a setting in both the Add/Remove liquidity flows on the Beets UI. Setting a low slippage tolerance protects you from front-running bots and maximal extractable value (MEV).
Due to high gas fees
Gas on the Sonic network refers to the unit that measures the amount of computational effort required to execute specific operations. Gas fees on Sonic are the transaction costs users pay to have their transactions processed and validated by the network's validators. Gas fees vary depending on network congestion, transaction complexity, and the amount of gas a user is willing to pay.
Gas fees can be particularly high during periods of network congestion. As a result, LPs might face increased costs when adding or removing liquidity, making adjustments to their positions, or claiming liquidity mining incentives. If the gas fees are higher than the returns they get from providing liquidity, LPs may end up with a net loss.
How can this risk be reduced?
- The Smart Order router is used to route liquidity efficiently via pools to minimize price impact.
- The Beets UI gives LPs control over their slippage settings.
- The Beets UI displays price-impact warnings and requires risk acknowledgment for certain high or unknown price-impact transactions. Acknowledging a warning does not protect users against losses.
How LPs can mitigate this risk:
- Users should review their slippage settings and potential price impact before adding or removing liquidity.
- Users should also review gas prices and the potential gas fee before any transaction. This information is usually provided by their wallet provider.
Impermanent loss
Impermanent loss is a risk that liquidity providers (LPs) face when providing liquidity to an automated market maker (AMM) like Beets. It is the difference between the value of holding assets in a pool versus holding them outside of the pool.
If the price of the assets in the pool changes, LPs may experience a loss compared to holding the assets outside of the pool. This can happen because the AMM algorithm rebalances the pool to maintain a constant ratio of the assets in the pool. If the price of one asset increases, the algorithm will sell some of that asset and buy more of the other asset to maintain the ratio. This means that LPs will sell the asset that is increasing in price and buy the asset that is decreasing in price, resulting in a loss.
This risk is particularly relevant for pools with volatile assets where token prices are likely to diverge over time.
How can this risk be reduced?
- All AMMs either have impermanent loss or reduced yield to LPs. Beets aims to make its pools as capital efficient as possible so that the yield LPs make is more likely to exceed any impermanent loss.
- The Balancer Protocol supports unbalanced pools which LPs can use to reduce impermanent loss. For example, there is lower impermanent loss in an 80/20 pool (or any other unbalanced pools) versus a 50/50 pool with the same underlying tokens.
How can LPs mitigate this risk?
- LPs should consider the risk of impermanent loss carefully before providing liquidity to a pool.
- The longer an LP holds their position, the more likely it is that their yield from swap fees offset and exceed any impermanent loss, assuming the price divergence of the token prices isn’t extreme.
- LPs may consider providing liquidity into pools with less likelihood of token price divergence. For example, stable pools or boosted pools.
- LPs should consider providing liquidity in unbalanced pools, like 80/20 pools which result in less impermanent loss versus a 50/50 pool with the same underlying tokens.
Hooks
Hooks introduce complex logic into pools, and changes in their parameters can significantly impact the risk profile of a pool. This complexity increases the potential for unforeseen errors or vulnerabilities in hook code that may, for example, amplify impermanent loss, introduce new sources of volatility, or impose restrictions on pool interactions like joins and exits.
- Hook specific risk: Hooks introduce unique functionalities to pools, and while they offer exciting possibilities, they also present specific risks that users should be aware of.
- Hook Interactions: Hooks can interact with each other and with the pool contracts in unexpected ways. These interactions may lead to unintended and yet unknown consequences or exploits.
- Hook Updates: Hooks may be updated or modified over time. These updates could introduce new risks or alter the functionality of the pool in ways that may negatively impact your assets.
User interface (UI) risk
DeFi users, including liquidity providers and swappers, typically interact with front-end user interfaces to interact with a protocol’s smart contracts. An example is the beets.fi UI, which interacts with Beets smart contracts on Sonic built on Balancer technology.
A few risks of using front-ends to manage liquidity positions in DeFi:
- UIs may not always display timely, accurate data. This may be due to the use of third-party data services experiencing periods of downtime or network congestion.
- UIs could be maliciously updated or exploited by rogue developers.
- UIs may be updated and remove certain feature sets.
- UIs may block certain wallet addresses or users in certain jurisdictions to comply with their regulations.
- UIs may experience periods of downtime or potentially be discontinued. UIs may also be shut down or have access denied to users in certain jurisdictions.
How can this risk be reduced?
- Since the smart contracts can be interacted with by any front-end UI, there is less reliance on any one single UI. The Beets UI code is open source with an MIT License which allows other third-party developers to fork the code, make improvements and compete for users.
- Users or third-party developers can keep track of changes and review the open-source repository on GitHub for potential malicious code.
- The developers of the Beets UI have provided instructions on how to clone and run local environments of the app. This allows people to have the ability to keep deprecated features or modify the code to add new features that they prefer.
How can LPs mitigate this risk?
- LPs can learn how to interact with the smart contracts directly on SonicScan.
- To mitigate the risks of downtime or lack of access, users can fork the open source code and run their own local instance.
Regulatory risk
The regulatory frameworks applicable to blockchain transactions in connection with tokens and stablecoins are still developing and evolving. In addition, the increasing complexity of DeFi applications and their interactions can make it difficult to assess and regulate them effectively. This could potentially lead to increased regulatory scrutiny or even a regulatory crackdown, which could have negative consequences for participants, our efforts to mitigate risks and the entire DeFi ecosystem.
It's also possible that the Beets UI may be wholly or partially suspended or terminated for any or no reason, which may limit your access to your tokens via this website. In this scenario, you may be able to recover funds by running your own local instance or by using a third-party website, like SonicScan.
Pool type risks
Balancer Protocol is designed to be infinitely extendible to allow for any conceivable pool type with custom curves, logic and parameters, and more. The general risks of the most popular pool types are listed below.
Weighted Pools
Weighted Pools use Weighted math, which makes them great for general cases, including tokens that don't necessarily have any price correlation (ex. USDC/wS). Unlike weighted pools in other AMMs that only provide 50/50 weightings, Weighted Pools enable users to build pools with more than two tokens and custom weightings, such as pools with 80/20 or 60/20/20 weightings. Some risks of weighted pools include:
- Impermanent loss on volatile non-correlated assets
- See above for details of impermanent loss risks.
- Toxic token risk
- Weighted pools are not limited to just having two tokens. The more tokens in a pool, the more risk that one of these could become toxic.
Stable Pools
Stable Pools are designed for assets that are either expected to consistently trade at near parity, or at a known exchange rate. Stable Pools use Stable Math (based on StableSwap, popularized by Curve) which allows for trades of significant size before encountering substantial price impact, vastly increasing capital efficiency for like-kind and correlated-kind swaps. They are ideal for:
- Pegged Tokens: Tokens that trade near 1:1, such as stablecoins denominated in the same currency
- Correlated Tokens: Tokens that trade near each other with some slowly changing exchange rate, like derivatives (e.g., stS, wS)
Loss of stablecoin peg
Stablecoins are tokens whose value is intended to be pegged or tied to that of another asset, which could be a currency, commodity or financial instrument. There are many types of stablecoins, some are riskier than others depending on product design including evidence of reserves to support the peg in times of stress. Some example types of stablecoins include:
- Peg is secured by real world reserves
- e.g. USDC secured by USD reserves
- Peg is secured by other crypto assets
- e.g. a stablecoin backed by an over-collateralized basket of crypto assets
- Peg is secured by smart contract algorithms
- e.g. UST which aimed to be secured by algorithmic rebalances to reflect the peg.
Depegging occurs when a stablecoin loses its peg to the target asset. In stable pools, if a stablecoin depegs, LPs may incur losses. This is because liquidity pools typically sell the winners (tokens moving up in price) and accumulate the losers (tokens moving down in price). In the case of a USD-pegged stable pool, if an asset permanently loses its peg to $1 and goes down in value, the pool will sell any pegged assets and accumulate the asset which has lost its peg, leading to an overall loss of funds for LPs.
Rate provider risk
Rate Providers are contracts that provide an exchange rate between two assets. These exchange rates can come from any on-chain source, whether that may be an oracle, a ratio of queryable balances, or another calculation.
This introduces risks around the rate provider being able to supply accurate and timely exchange rates between pool tokens.
Oracle risk
Oracles are data providers which supply external information to smart contracts. Oracles, like Chainlink, may be used to source exchange rates between pool tokens for a rate provider in Stable Pools. The risks of using Oracles to supply exchange rates include:
- Data accuracy: Oracles must provide accurate data for DeFi applications to function correctly. Inaccurate data can cause significant issues, such as incorrect pricing or faulty execution of smart contracts.
- Data availability: If an oracle experiences downtime or fails to update its data feed, the DeFi applications relying on it might not function correctly or become temporarily unusable, leading to potential losses for users.
- Latency: The time it takes for an oracle to fetch, process, and transmit data to a smart contract can impact the performance and efficiency of DeFi applications. High latency could lead to outdated data or missed opportunities.
- Oracle manipulation: Bad actors might attempt to manipulate an oracle's data feed to influence the outcome of a smart contract or profit from price discrepancies. This can lead to unintended consequences, such as liquidations, loss of funds, or arbitrage opportunities for attackers.
- Centralization risk: If an oracle relies on a centralized data source or a small number of data providers, it becomes a single point of failure. This centralization goes against the core principles of decentralization in the DeFi ecosystem and exposes the system to potential manipulation or downtime.
- Exploitation of vulnerabilities: Oracles themselves can have security vulnerabilities, which, if exploited, can compromise the entire DeFi system relying on them.
Rate provider cross-chain bridge risk
Pools may use rate providers that are bridged between blockchain networks.
Boosted Pools
Typically, only 10% or less of the liquidity deposited into an AMM pool is being utilized by traders because the trade sizes are much smaller than the available liquidity. Boosted Pools allow the remaining portion of liquidity to be sent to lending protocols where the liquidity can earn additional yield for accepting inherent risks.
- Boosted Pools are designed to allow for greater capital efficiency, deeper liquidity, and increased yield for Liquidity Providers.
- For traders, Boosted Pools are a cheaper entry/exit into underlying yield protocols.
- Boosted Pools increase the opportunity for LPs to gain exposure to a wide variety of yield increases from multiple yield protocols.
Third-party platform risk exposure (DeFi composability risk)
Since boosted pools deposit excess liquidity into third-party yield protocols to generate yield, LPs must fully understand the risks of the underlying protocol since a portion of their funds will be exposed to the risks of that protocol. Some of the risks of the underlying protocol may include smart contract bugs, economic attack vulnerabilities and counterparty risk from the protocol’s borrowers. Underlying protocols may also use Oracles which face additional risks (described above).
Also note, some boosted pools may use strategies that utilize multiple yield protocols in order to maximize yield. Since these strategies may change exposure to the underlying yield protocols at any time, LPs must accept the risk that the protocol utilizing these strategies carefully vets all third-party protocols to reduce composability risks.
If the underlying protocol were to get hacked, LPs in a boosted pool that deposits liquidity in that protocol could lose funds.
Depegging risk
Individual stablecoin tokens within Boosted Pools are subject to depegging risks, as described above.
StableSurge Hook
If a pool is pushed beyond its threshold balance, a surge is initiated, resulting in an increasing tax on sellers who negatively impact the peg of the asset by continuing to push the pool out of balance. On the other hand, the liquidity providers who maintain the risk of being in the pool, earn an increased fee, resulting in higher returns on their position during times of volatility.
The directional fee nature of the StableSurge hooks only charges the increased fee on those sellers who are driving the peg further from equilibrium, while those who are buying the underperforming asset are only charged the base fee. This aligns the incentives of the liquidity providers and the project entity, which inherently wants its token to stay as close to the peg as possible.
StableSurge hooks introduce dynamic swap fees designed to protect the peg, but may also impact the risk profile of a pool. Please also refer to the Hooks risk section and other General risks.
- Dynamic fee volatility: these fees are not fixed and can change significantly based on several factors, including but not limited to: pool imbalances, market volatility, and the specific configuration of the StableSurge parameters. You may encounter unexpectedly high fees, especially during periods of market stress or when the pool is significantly off-target. While the hook can lead to lower fees, there is no guarantee of consistency, and fees can rapidly increase.
- Parameter Sensitivity: The performance of the StableSurge hook is highly dependent on the correct configuration of its parameters. Incorrectly configured parameters could lead to unintended consequences, such as excessively high fees, ineffective rebalancing, or even instability in the pool. Changes to these parameters can also significantly alter the pool's behavior.
- Rate provider risk: inaccurate or manipulated oracle data could lead to unexpected fee adjustments and potential losses. Rate provider failures or manipulation are inherent risks in decentralized finance. Learn more about rate provider and oracle risks in the Stable Pools risk section.
Concentrated Liquidity Pools
Gyroscope’s ‘Concentrated Liquidity Pools’ (CLPs) are a class of AMMs that price the exchange of assets within a defined range. As such, any CLP only provides liquidity for trading activity restricted to this specific region. The goal is to use the pool’s capital efficiently. There are a few different types of CLPs:
- 3-CLPs: Pools with three assets, known as Cubic-CLPs or 3-CLPs, provide concentrated liquidity for three assets. Learn more about 3-CLPs and their risks.
- E-CLPs: Also known as ‘Elliptic-CLPs’ support asymmetric concentrated liquidity for two assets. They provide a new type of concentrated liquidity that allows highly flexible and asymmetric liquidity profiles in a single pool position. Learn more about E-CLPs and their risks.
- Dynamic E-CLPs: These pools use a dynamic rate provider to adjust their price range when the pool moves out of range. They add oracle, keeper, and strategy risks to the underlying E-CLP risks. Liquidity updates can lock in losses, even if prices later return to their initial level; delayed keeper updates can leave a pool out of range for longer. Learn more about Dynamic CLPs and their risks.
Other risks:
- The Beets UI allows people to manage their liquidity in certain Gyroscope pools. This is not an endorsement of their products or the safety of their smart contracts. Review the audit reports for the contracts you intend to use; audits do not guarantee safety. You can review Gyroscope's audit reports here.
AutoRange pools
AutoRange (Readjusting Concentrated Liquidity AMM) is a novel pool type built on Balancer, designed to offer concentrated liquidity with self-readjusting price ranges and fungible liquidity. While they aim to reduce the active management burden for LPs, higher swap fees and better capital efficiency when in range, they introduce specific risk.
- Impermanent Loss and Parametrization Risk: AutoRange pools' self-adjusting ranges aim to keep liquidity active, but impermanent loss remains a core risk that in this case can be potentially exacerbated by suboptimal range, margin and “daily price shift exponent” adjustments. The efficacy of the parameters in the mechanism which replaces manual LP intervention, introduces risks, including (but not limited to): potential for miscalculation, inefficient capital utilization, or exploitability if rebalancing patterns are predictable.
- Path Dependency Risk: Unlike traditional CFMM (Constant Function Market Makers) where “impermanent” loss can revert by the return of the asset to its original ratio, path-dependent pools are affected by the sequence of price change, meaning the losses incurred to the asset in one side of the pool during certain price fluctuations can become “permanent”.
- Low liquidity and price manipulation: AutoRange pools are not suitable for great volatility and assets with low liquidity that can be easily exploitable, for the reasons and risks detailed above, where the pool can easily fall out of range and losses can become permanent.
- Admin Parametrization: By changing the sensitivity and behavior of the pool after deployment, the price range can be narrowed or widened, even if the price range can’t be set directly. The pool admin can: 1) change the centeredness margin (the threshold for updates); 2) change the daily price shift exponent (the speed of updates); and 3) initiate an update to the price interval (i.e., the distance, or ratio, between the minimum and maximum price bounds), or simply stop an ongoing update. All of these changes will update the virtual balances and potentially slightly change the price.
Blockchain Traded Funds
Blockchain Traded Funds (or Temporal Function Market Making - TFMM) tackles impermanent loss in traditional AMMs by continuously adjusting weights within the pool, rather than relying on token allocations. This dynamic rebalancing process allows the protocol to respond more effectively to market conditions, thereby mitigating IL risk associated with market price fluctuations. These rules are programmed to respond to specific market conditions, allowing for real-time adjustments without requiring manual intervention, by analyzing market data and applying the appropriate parameters for capital allocation within the fund, thus enabling effective risk management and optimization of returns.
The Beets UI allows users to manage liquidity in certain QuantAMM pools (TFMM). This is not an endorsement of their products or the safety of their smart contracts. Users interacting with TFMM pools should be aware of the risks below. Please also refer to the General risks section.
- Market volatility: BTFs run directional strategies. These are not market neutral. The dynamic nature of the TFMM may not always respond adequately to extreme market volatility or adverse conditions, potentially leading to losses if market prices deviate significantly from expected trends.
- MEV - Change weights is equivalent to changing the price offered for swaps by the pool. This mechanism to expose a rebalance opportunity has been studied however there is an inherent multiblock MEV opportunity. This is mitigated by design choices (see mitigation section)
- Strategy Automation - Strategies require periodic triggering, if this triggering is not performed the strategy will not update weight trajectories
- Strategy Parameterization - It is expected behaviour that a periodic update will not occur if a variable in the strategy calculation means that the strategy is not mathematically possible to run. E.g. a divide by 0 situation.
- Oracle risks: reliance on oracles for price feeds introduces risk in terms of potential inaccuracies in data, which could adversely impact the rebalancing processes and overall fund performance. Additionally, infrastructure issues such as high gas costs could affect the efficiency of operations within the protocol. See more on oracle risks on the rate provider subsection.
- Sub-optimal arbitrage TFMM changes the weights within the TFMM pricing formula. At any one block TFMM is a standard CFMM pool. For actual NAV/Market value to be rebalanced to the target weights arbitrageurs have to take the immediate small arbitrage profit so that the holdings of the pool are inline with the weights. If there are no arbitrageurs, holdings will not be rebalanced. The more aggressive the arbitrage the more efficient the rebalancing.
How QuantAMM mitigates these risks:
- Market Volatility - Given that BTFs are not reliant on trade volumes, back test simulations are provided to give visibility on simulated behaviour under different market conditions. Given the BTF strategies rely on “historical memory” of price changes, historical performance and simulations are not indicative of future performance.
- Pool Tuning - Strategy parameters are fixed on creation mitigating the possibility of parameter manipulation.
- Strategy automation - Chainlink automation is used to trigger
- Future updates to TFMM may include increased monitoring of performance metrics, enhanced simulation testing, or improved user interfaces to minimize the chance of errors in parameter settings.
- Chainlink oracles are primarily used to mitigate oracle risk and any additional pool creation requires approval from the protocol team.
- Implement necessary fixes once identified, updating smart contracts, adjusting parameters or improving risk disclosures.
- Sub-optimal arbitrage - This is a relatively small risk given at any one block arbitrageurs are faced with a standard pool so they can price and take the arbitrage opportunity without any additional new invariant prediction work. Beets has also integrated BTFs in the smart order router also increasing the likelihood of being exposed to traders. Work has already begun on DEX aggregator integration and when there is a minimal amount of TVL in the pool aggregators will expose the pool for further volumes.
Before interacting with any QuantAMM Blockchain Traded Funds, users must read and accept QuantAMM’s Terms of Service.
Navigating these challenges calls for active engagement and open communication within the community. Sharing insights, feedback, or concerns can contribute to building a safer and more inclusive environment for all. Please feel free to reach out with any questions or suggestions, or to propose changes for this page directly via the GitHub.