Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
A vertex encapsulates the rehypothecation earnings of a token. Every token in the protocol (because the earnings for the protocol itself) are kept in a Vertex which then fowards those token deposits into either one or two vaults through a Vault Proxy.
Each vertex is identified by a VertexId which is a product type on an array index and the one-hot encoding of that array index. The bottom 8 bits are the array index which is used extensively throughout the protocol. The top 16 bits is the one hot encoding which we use to interact with the ClosureId. The ClosureId is simply the bitwise union of the one-hot of all the vertices for all the tokens in its subset.
An omni-pool is built to enable swaps and LPs for multiple assets pegged to a single token. The is accomplished with a smart contract that has...
The Diamond Pattern (EIP-2535) and Diamond Storage (Store.sol).
A Simplex
An Asset Book
Multiple Vertices
Multiple Closures
And "Value" Accounting
The Simplex is the overall protocol manager and holds any high-level parameterizations.
The AssetBook simply stores the value owned by each depositor.
Further details are available for Value, Closures, and Vertices.
The Reserve is a use case of the Vertex. Normally all depositors into a vertex are closures, but the Reserve is like an empty closure which is just used to hold balances of tokens that protocol depositors can claim when withdrawing.
Closures deposit their fee earnings into the Reserve to allow them to continue to grow until their depositor decides to withdraw/collect.
A Vault proxy gives a uniform interface for Vertices to interact with vaults. Right now only ERC4626 vaults handled by vault proxies but we can foresee more complicated vault setups that do more to guarantee available liquidity for swaps.
A vault proxy secretly handles two vaults, one active vault and one backup vault. The backup is used to slowly transition from one vault to another in production without halting the protocol.
The tent is rising. The spotlight is warming up. The ring awaits. A grand spectacle of liquidity, strategy and yield. Pick your act, take your first steps into the arena and make your mark.
Be the first to hear the drums roll. Alpha leaks, surprise drops, real time alerts, the show starts here. First to hear, first to act. 🎟️ Join the Telegram:
The Burve Circus HQ. Find your crew, prepare your acts and stay tuned to every twist and turn behind the scenes. This is your backstage pass to the Burve experience. 🎟️ Enter the Discord:
Get ready to complete quests, earn points and climb the leaderboard. Your early steps will be remembered when the real show begins. 🎭 In the circus of DeFi, every act matters.
Previous versions of Burve have been audited by the Pashov team.
The latest version of Burve is currently undergoing a Sherlock Audit contest.
No Fee-On-Transfer tokens.
No tokens that revert on zero-value approvals.
Owners and vetoers are trusted individuals (that will be decentralized over time).
Owners are expected to set values appropriately. This means:
The Omni-pool is our version of a multi-pool and it's composed of 3 independent pieces:
The pool itself, which is a Diamond (EIP-2535), handles multi-swap behavior for a base token.
An Adjustor which normalizes denominations.
A Closure handles deposits/withdrawals and swaps for a particular set of tokens and can be thought of as an Multi-swap AMM in and of itself. Each closure is identified by a ClosureId which specifies exactly which tokens are in the set.
They track a target balance for each of the tokens in its set, and what the actual balance is. The combination of the two with parameters from Simplex tell us the amount of "value" held in each token in this Closure. The total sum of the value will always be equal to where N is the number of tokens in the closure and target the is the target balance.
Closures allow users to add value into the pool (deposit liquidity) by adding all the tokens in equal proportion or a single token (by specifying the value desired or the tokens deposited).
Closures also allow traders to exchange one token for another in its set as long as the "value" exchange is equal.
We use value accounting instead of constant product math. It's effectively a bonding curve that ascribes a value to a token based on its current balance, a target balance, and an efficiency factor. Closures maintain a certain amount of value in them which grows on deposits, shrinks on withdraws, and remains constant across swaps.
As a balance deviates from its target balance, the value of the token also deviates to reflect slippage. Excess balance causes the token to be worth less than one unit of value and a deficit of tokens causes the token to be more valuable.
Given x, which is the balance of the token in question, t (the target balance) and e (the efficiency factor) this gives us the value of the balance. You can see that when x is equal to t, v is also equal to t. That is the equilibrium state in a closure, where all tokens are at the target balance.
We take the derivative of this with respect to x to get the price of v in terms of x.
Vertex vaults have acceptable risk tolerances and are expected to not lose token amounts. Currently they can only be ERC4626s.
The adjustors and station proxies are properly configured.
The bgtExchanges are properly configured and are almost always funded with BGT.
New bgtExchange configurations use the previous one as a backup.
The deMinimus in searchParams is smaller than 1e6.
esX128 for any token is less than 2^24 << 128.
Uses can remove their value from a closure without removing their assets by unstaking and this awards them value tokens which can be redeemed for value in any closure in the overall pool.
The Closure tracks the overall value staked in the pool, as well as the bgtValue staked in the pool. A portion of the overall value is bgt value which are units of value that want to exchange their fee earnings for BGT instead.
The balances of each token for a closure are tracked internally and deposited into Vertices which then forwards those deposits into a vault and helps the balance grow over token.
After the balance grows, the surplus of tokens cannot be compounded back into the pool without growing the target. So instead of compounding into the LP, the surplus is left in the vault (but moved into the Reserve allocation) and attributed as fee earnings to depositors.
There are safety guidelines for the token balances that prevent a balance from getting too close to 0, and that prevent the closure from accumulating too much of one token. If a token balance has grown to twice the target balance, future deposits are no longer accepted for that token.
Earnings come from the surplus growth in our token balances from Vertices, from Swap fees, and from deposit/withdrawal fees for users opting to use single sided actions (which are effectively swaps).
Earnings for non-bgt accumulating value units are kept in the original token but deposited into their respective Vertex to continue to grow. Thus their earnings are tracked as shares in the Reserve which they can redeem upon withdrawal.
BGT accumulating value units have their fees immediately exchanged for a liquid wrapper on BGT through the BGTExchanger. Any unspent fees (because there is no exchange rate available or the exchanger has run out of the liquid BGT) are then deposited into the Reserve to grow and can be redeemed by bgt value units in the future.
Right now, for simplicity's sake, if there is unstaked value then the excess earnings from that unstaked value are split among all staked value. But in the future, this will be properly moved out to give yield for value token holders.
This is the workhorse of the protocol, and contains multiple mini-pools called Closures within in as well as vault-wrappers for each token in the multi-swap called Vertices. Each Multi-Pool is designed around one base token (e.g. USDC, BGT, ETH, BTC, BERA, SOL, etc.).
For one base token, the multi-pool can register up to 16 tokens (including the base token itself) that are closely pegged in price. For any combination of these tokens, there is one Closure (a mini-pool). When depositing liquidity, users pick which Closure to use which allows them to LP for just that token combination, and avoid the risks of any unwanted tokens out of those 16. Closures operate as a classic AMM by itself, allowing users to provide/remove liquidity and traders to swap between two tokens in its token combination. The Closures are linked together through a value staking system (explained later).
Each token registered within the Pool is registered with a vault and gets an associated Vertex. The Vertex is a proxy for that vault (which can be hot-swapped) and tokens are always deposited in their respective vault, continually earning.
Finally, all user positions and fees earned by tracked by the Asset Book.
The adjustor simply converts a token balance into a new balance that should match 1-to-1 with the base token's balance. For example, USDC has 6 decimals but MIM, another stable has 18 decimals. So we adjust the USDC balance by multiplying it with 1e12 so that it can be traded one to one with MIM. After the trade we divide out the 1e12 to get back the real USDC balance.
This is especially useful for LSTs which are pegged with a conversion ratio to the base token (e.g. stETH to ETH). So since 1 stETH might be worth 1.05 ETH, we multiply the stETH balance by 1.05 to get an artificial balance we can swap 1 to 1 against ETH with, and then we divide to recover the real balance in stETH. Furthermore, this helps prevent IL from moving pegs. Normally when the peg moves on a regular AMM, someone gets to arbitrage the pool when moving the price accordingly. Because it happens automatically with Adjustors on Burve, the "arbitrage value" is instead kept by the depositors. We use a combination of different adjustors (through the MixedAdjustor) to get the right adjustment on a per token basis.
Because users can deposit into different Closures, , we can't issue a single ERC20 LP token for all depositors in the Multi-Pool since each closure earns fees at a different rate and should thus earn different amounts of BGT. There are also a lot of closures (256 for 8 tokens, >64,000 for 16 tokens) so it's impossible to register and maintain all those BGT-earning LP tokens.
Instead, the Pool itself handles earning BGT for users, circumventing the LP Reward Vault. When users deposit into the protocol, which decide what percent of their fee earnings they wish to exchange for BGT instead. Now a user can opt to convert 100% of their fee earnings into BGT, or 0%, or somewhere in between. This happens through the "value" system described later in Closure Details. In short, a portion of the fee earnings of the pool are sent to the BGTExchanger contract which stores exchange rates for a liquid BGT wrapper which it then gives to the pool in return for those fees.
This has the desirable property of being at 1 when x is at the target, and since we limit x from zero (or near zero) to , the price has a range of to . For example, if e is 10, then the full range of x would allow for prices to go from $0.84 to $1.21. Therefore the liquidity is effectively concentrated around the price of one and we can adjust the level of concentration simply by updating e.
Compare this to the price function implied by the classic constant product setup for a concentrated position.
We can see how they are effectively the same form, but we don't need to deal in square roots. Our efficiency factor also lends itself to a more human-readable interpretation which is that each unit of x acts like e units of x in a regular constant product AMM.
We use that value function, its inverse, and Newton's method to ensure all changes to the pool's value are accurate and all balances changes leave the pool's value constant.
Any implicit swap from adding/removing a single token from the pool needs to be taxed just like a swap would or else people could synthetically swap for free by adding in one token and removing liquidity in another.
These units of value can roughly be interpreted as one unit in the base token and are thus uniform across pools. Therefore it allows users to exchange units of value between pools without cost. This is because aside from exchanging value they would still have to add and remove liq to get their desired tokens which would charge a fee similar to a swap.
.
Whenever using an AMM, there are always two risks:
Contract Risk - Is the smart contract written securely? Has it gone through audits? And yes we have! See .
Impermanent Loss / Depeg Risk - Impermanent Loss is a general term for value lost in your deposit as the price moves away from the original price at the time of your deposit. For stable swaps that market make between pegged assets, we generally call this depeg risk. This is because stable swaps mostly think about depeg events because for the most part, tokens either stay pegged in which case there is no Impermanent Loss, or a token totally depegs and there will be very significant Impermanent Loss if there are not other mitigating factors. There are cases of moving pegs which we will discuss later.
Depegs are rare but catastrophic events in DeFi and previous stableswaps have exposed users to the full loss of a depeg. For example, if you LP into the DAI-USDC-USDT pool on Curve, and USDT goes to zero then:
DeFi would be going crazy if USDT is zero. It might be the end.
Your LP position would end up holding entirely USDT and be worth nothing.
If USDT doesn't go to zero, but partially depegs to say 50 cents, that's still pretty bad and your LP deposit would have lost a little less than 50 percent of its value. The greater the depeg, the closer you LP's losses matches the depeg's losses.
Unlike other stable swaps, depeg events don't send our LPs to zero. And we ensure that with two separate approaches:
Active Intervention - One of our monitoring systems indicate a depeg and governance has allowed us to take prompt action.
Passive Intervention - The protocol itself has safe guards that mitigate depeg risk and no third-party intervention is required.
You can simulate depegs on our multipool yourself here.
We have security firms that monitor asset prices and transaction activity to readily report any potential depegs to us. If one looks sufficiently risky to the Burve team, and governance has previously agreed to allow us to intervene under the given conditions, then we will lock a vertex which prevents users for adding more of the risky token into our pool. This completely stops our LPs from accumulating any more losses.
The contract itself also limits the amount of one token it can accept. When all tokens are in balance, we call that balance the target balance. Burve's Multi-pool contract cannot accept more than twice the target balance for any token (currently twice but this can be adjusted by governance).
This means an multi-LP can at most lose roughly 2 / N of the original LP value due to the depeg where N is the number of tokens in your multi-LP. For example, if you're only LPing two tokens, then the effects of a depeg would match existing stable swaps like Curve. But if you're LPing for 8 tokens, then you'll only lose ~1/4th of the LP value instead of all of it.
We have a more precise simulator coming soon!
Effectively, once a token's price goes off peg too far, the contract simply stops accepting more of it. If the price recovers then the contract will naturally start selling it again and collect fees as if nothing has happened.
A very fair criticsm of Burve's Multi-Pool is that if a token depegs, then once it is out of Burve's accepted range Burve no longer helps with price discovery (the process of finding a fair price for the token). That's true and that's intended! Price discovery is not an easily profitable process and these days DeFi has enough professional market makers that we should really just leave it up to them! Our LPers don't have a moral obligation to always help with price discovery, especially when it gets too risky, so our simple solution is to simply not do it.
Liquid staking tokens (LSTs) are pegged to their base token but their wrapped version usually accumulates value and their peg grows over time.
In a normal AMM, in order to reflect that change, a trader comes into the pool and swaps the tokens until the price reflects the new peg. In the process, the trader extracts value through this arbitrage and LPers lose a little to impermanent loss. Over time, this IL can add up to a significant amount!
So Burve says, "why don't we just capture that IL ourselves and give it back to our LPers?" Since that peg is reported on-chain at all times by the LST's vault, the Burve contract always checks with that reported peg before every swap to adjust the swap value accordingly. This completely eliminates any IL from moving pegs.
At Burve, we've built a Rehypothecating Stable Multi-Swap AMM. That's quite a mouthful, but simply put, it's a way for users to reliably earn fees from multiple stable coins.
On this page, we'll explain exactly where the earnings come from and what are the risks of providing stableswap liquidity. For a guide on how to deposit, see quickstart.
A multi-swap pool means the underlying liquidity is made up of multiple tokens instead of just two like a normal AMM. In a multi-swap, any token can be traded for any other token in the pool. The more tokens there are, the more capital efficient it is for liquidity providers in the pool.
Burve can handle up to 16 tokens in one pool.
This gives 15x the capital efficiency of other AMMs.
You can LP for as many or as few of the 16 tokens as you'd like.
You only face Impermanent Loss for the tokens you choose to LP for.
Curve did a great job in popularizing stable swaps with their stable equation, but now they under-earn compared to LPs on modern AMMs offering concentrated positions despite having similar risk profiles. This is because concentrated positions also maintain a peg with minimal slippage but can be adjusted as the market evolves. For example, as a stablecoin matures, the peg should be be tightened to earn optimally.
That's why we opted for using a concentrated position more similar to Uniswap V3 than a traditional stable curve. The level of concentration can be adjusted through governance and is specific to each token. This means if a token becomes less risky over time we can tighten its concentration for higher yields which automatically tightens its peg with all other tokens in the multi-pool. And vice versa, if we want to mitigate risk and loosen the peg we can as well.
Concentrated liquidity and stable swaps face similar IL, but concentrated liquidity typically earns more due to its ability to quickly and flexible adjust ranges in an evolving market.
Burve uses a more concentrated liquidity approach but employs multiple circuit breakers, depeg oracles, and other risk mitigation strategies to limit IL risk.
Burve also handles moving pegs natively to prevent depositors from perpetually losing IL due to a slowly moving LST peg.
Tokens in an AMM are typically left on the smart contract waiting to be used in a swap. But the vast majority of those tokens are rarely touched. So instead, Burve puts those tokens into other yields source so they can earn while they wait which results in a constant passive yield for liquidity providers even when swap volume is low. Most of the time, we put those tokens in Money Markets to remain relatively liquid, even when earning yield. Even so there are a few important considerations.
The AMM's tokens are actually stored on money markets to constantly earn additional passive yield for LPs.
Money Markets are used as a backup depeg oracle to mitigate depeg risk and IL.
Any BGT validator emissions from money markets are automatically compounded back into the pool to further boost earning.
The BGT emissions themselves can be directed to different pools based on governance.
You can conveniently LP into any subset with just a single token and you can withdraw into just one token as well while still earning from your entire subset.
The primary risk of providing liquidity to stableswaps is the risk of a token de-pegging. This means a token that was meant to be worth 1 USD is now worth less (and on occasion more).
Almost all protocols don't have special handling for depegs, this means those protocols continue to accept more of the depegging token as it goes to zero, eventually reducing the value of your position to zero.
On Burve however, the moment a token goes out of an "acceptable" range (set by governance), the protocol stops accepting more of it until the price goes back into the "acceptable" range. This happens automatically to guarantee users a value floor (see for a visual guide). There are also manual controls in place to pre-emptively block accepting tokens if the depeg is obvious.
Automatic protections limit the trading range of a token to a narrow band and stop accepting more of a token if it depegs.
Manual protections block the protocol from accepting more of a token if the depeg is clear or for any other reason deemed too risky for our users.
Coming soon!
All of these features contribute to giving our users some of the highest yields found anywhere for stables.
We also have a backup depeg oracle from on-chain sources like money markets which we'll discuss more in the rehypothecation section.
Subset LPing! This is a great way for users to completely avoid the risks of depegs in any tokens they consider risky.
Overall, by using depeg-oracles we can minimize the impact of any depegs. We'll lean on the side of being safe, which means we'll be willing to miss out on trading fees if it means we can avoid depeg losses.
Any IL caused by depegs is minimized through market halts triggered by depeg oracles.
At Burve we do both. If a depeged token will decimate an LP position anyways we might as well earn as much as possible when facing that risk. And at the same time, also employ circuit breakers, depeg oracles, and built-in safety measures to mitigate the losses in the event of a depeg.
The LP token itself will eventually be available for BGT staking. That is a separate utility and should not be confused with the BGT emissions earned from rehypothecation.
We only use trusted and audited sources of rehypothecation yield.
No
Yes
Uniswap V4
No
No
Yes
No
Yes
🎪 Burve 🎪
Yes
Yes
Yes
Yes
Yes
Curve
Fixed by protocol
Low
Static
Uniswap V3/V4
Adjusted by User
High + Adjustable
Adjustable
Burve
Adjusted by Governance
High + Adjustable
Curve
Yes
No
No
No
No
Uniswap V3
No
No
Multi-Swap
Users can LP for up to 16 tokens in one pool to increase their capital efficiency and yields by up to 15x without any leverage.
Dynamic Concentrated Yield
Earn higher yields than other stable swaps with a concentrated position that adjusts with the market.
Rehypothecation
All tokens in the AMM earn money market yields by default, thus boosting returns without additional IL risk.
Single-Sided Deposits & Withdraws
You can deposit into any LP with just one token and remove with just one token while still earning from your whole selection.
Depeg Protection
Built-in protections automatically kick in during depegs, and additional manual safeguards keep users safe.
Automatic BGT Conversion
You can choose what percent of your fee earnings are used to farm BGT for boosted earnings.
Adjustable
No