- Flexibility and Custom Trading Curves in Balancer V2
Element Finance writes about how they are utilizing Balancer V2
Element Finance talks about how they are utilizing Balancer V2
At Element Finance, we’re thrilled to be a launch partner of Balancer Protocol, utilizing what we believe to be the most innovative feature of Balancer V2. Element Finance needed to implement a custom invariant or trading curve but did not want to go through the technical overhead of forking or building our own AMM with custom logic.
We realized this route would get messy, require secure accounting logic, and generally reinvent the wheel. It would also isolate existing AMM liquidity from our protocol, limiting us from integrating or plugging into other pools or token pairs.
To avoid these issues, we chose to build on Balancer V2. Balancer V2 introduces customizable AMM logic, where developers can build different curves without having to worry about proxying through other exchanges, managing lower-level details, or security concerns.
How it Works
Unlike other AMMs, Balancer V2 keeps all the pools’ tokens in one vault. The pools themselves are decoupled from the token management and accounting logic and are just responsible for the AMM logic. There are a number of benefits for taking this approach outside the scope of this article, but the following diagram and post explain and cover some of these benefits in more depth.
When swapping, joining, or exiting a custom pool, the vault calls the custom AMM logic. It is made up of the following hooks, defined by the pool:
When a user trades or swaps, this returns the number of tokens the Pool will grant to the user (if GivenIn) or that the user will grant to the pool (if GivenOut). LP fees can be just part of this difference and accounted for in the logic.
When depositing liquidity into a pool, this defines how many tokens the user needs to deposit on each of the assets.
When exiting liquidity, this defines how many tokens the pool should give to the user.
These three functions are enough to create a new invariant or a custom trading curve. Values can of course be stored (SSTORE) or retrieved (SLOAD) in all of this.
We implemented a variation on the Yield Space curve. In simple terms, this curve deals with assets that merge in value over a fixed period of time, meaning there is a time component that affects the pricing curve. The invariant function is as follows:
Because of the Balancer V2 architecture, we only had to implement the trading or swap math for this curve along with custom logic for LP joins and exits. Balancer’s core team implemented a gas-efficient fixed point math library we were able to use to solve the invariant in various trade formats. Our testing showed this fixed math library and changes to the yield space paper’s fee structure made the implementation gas efficient. We also implemented a proportional LP entry and exit strategy easily because of the generic interfaces.
Some subtleties came up in our trading implementation. First, our trading logic needed 18 point fixed format of balances but the Vault provided token decimal format inputs and outputs. This subtly is already handled automatically by Balancer’s `BasePool` and we recommend future integrators use it instead of working directly from the interface as we did. Second, Balancer V2 expects fees to be tracked from trades and paid to Balancer V2 on LP entry/exit. In our vault, this required us to store fee collection data on trades, cutting against overall gas efficiency.
Overall, because of Balancer V2’s modular architecture, we were able to implement an AMM of nontrivial complexity with unique features quickly and efficiently.
No other AMMs gave the ability to write a custom invariant or fee structure based on the invariant.
Other Trading Assets
By plugging into Balancer, users can trade from any asset staked in Balancer’s existing V1 and V2 pools. They can plug into the existing liquidity and we did not need to write proxy contracts to trade through other exchanges.
Network Effects and Integrations
Balancer will list our user’s assets for trade on their frontend and they will be available to any other contract integrating with Balancer. Their order router plugs into our user’s pools and assets.
We just needed to audit the code around the custom logic. We didn’t need to worry about security around internal accounting, order routing, or lower-level token logic. This is all covered by Balancer’s protocol.
Forking or writing our own AMM would have been an extensive effort. There was no need to reinvent the wheel.
Gas on Arbitrage
Arbitrage against principal tokens or yield tokens of different terms and their spreads against each other could be handled efficiently via internal balances in the vault. This means trades across the different pools is managed by internal balances, making it more gas efficient.
Balancer V2 introduces an asset manager which will likely be beneficial to our users acting as LP providers in the future. It allows for LPs to gain additional APY on the liquidity they provide by staking some of it in lending protocols. They also will allow our users to use the liquidity for flash loans which we plan on using, particularly for Yield Token Compounding.
We believe in Balancer’s team and their technical prowess. As they continue to innovate and release new features, it will likely offer further improvements on what Element can do.
- Date of publication:
- Thu, 04/22/2021 - 12:14
Click on the link - it will be copied to clipboard