Nova/Supernova Parallelization In Nova we have a folding property that given two instances of a relaxed rank one constraint system that we can combine them into a single instance of a relaxed rank one constraint system. In order to do so for a linear execution of a function $n$ times we first prove each instance of the $i$th proof. In the construction of the paper we use the folding property to prove them in a chain: [ instance 0] -> [folded instance] -> [folded instance] -> ... [instance 1] |||||||[instance 2]|||||||||||||| [instance 3] In this case while we can compute the proofs which have not been folded in parallel this is not true of the folded proofs. In order to fold in parallel we first compute the proofs of the base layer proofs along with their index of execution. Then we fold even and odd indices together, in this folding step we keep the start index of the first proof and the end index of the new proof. After the folding step we will have a proof that the function executed on steps between (left start index, right end index) was valid. In the final step we will have a nova proof that (0, n) were executed properly.

When an LP withdraws we calculate their currently committed capital to longs and shorts [via open longs times price avg rations, like the lp open]. The LP gets tokens for the sum of those values. When a short or a long closes the as much of the LP's committed capital as possible is added to a recovered capital pool and to ensure withdraws at the right ratio the theoretical max recovered capital is recorded as well. The recovered capital pool cannot be more than the max capital recovered.That final check prevents the bug class noticed by Will In addition to the recovered capital pool we also track any excess recovered in a interest pool: either for the short the difference between long open and close or for longs the variable interest earned by the position. When the LP withdraws capital from the pool they get (1) the face value of their committed capital tokens times the recovered amount divided by the max recovered amount. In addition they get the percent of the interest pool which currently exists that they are entitled too. Note: This strategy simplifies the code but creates distortions when longs or shorts are systematically out of balance. If for example in the pathological case where an LP only LPs a long then withdraws then an LP only LPs a short then withdraws LP A gets a lot of the interest [or loss] of LP B. However, they are both receiving the average rate of interest [or loss] associated with holding capital in the pool. Considering that (1) LPs are withdrawing and care about just getting money out and (2) most real world cases have LPs with balanced portfolios, I believe this is acceptable.

At Element Finance, we're thrilled to be a launch partner of Balancer, utilizing what we believe to be the most innovative feature of Balancer V2. We 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: onSwap

The goal of this doc is to surface some ideas for gas reduction and protocol simplification if you have an idea please add it and make sure to include an estimate of benefits, implementation costs, and feature set downside. MintTo and withdrawTo pattern We should make our default interface for methods that change token balances one which includes an output location. So instead of default minting to the msg.sender in ELF, FYT, and Tranche we mint to a provided address. Benefit: This means that on mints we don't have to do token transfers. For example the user proxy could indicate that it wants the output FYT and YC directly added to user balance. The exact gas cost benefit is hard to measure because it depends heavily on zero writing and erasing costs, but it will save at least 6500 per avoided transfer and likely more. Cost: This is a pure per transaction cost savings and fairly easy to implement.