Overview of Wells

• The idea took shape when assessing different options for how Beanstalk could deploy liquidity throughout DeFi.
• There was a lack of customizability of existing on chain technologies.
• Uniswap V2 was inflexible regarding the pricing curve it supports, the fees, and number of tokens offered.
• Curve didn't have a good oracle solution or removed the oracle entirely and had limitations around the types of tokens that could be in a pool.
• With the goal of representing any abstracted on-chain position in some form of liquidity market, it made sense to start research into different ways to provide the best user interface to an on-chain liquidity book.
• It became clear during the replant that Beanstalk needs to maintain some exposure to ETH for decentralization and due to concerns with some of the 3CRV tokens. Full scale development started around that time.
• It has gone through many iterations and there is still much more functionality that needs to be enabled.
• The need for Wells for the Bean-ETH pool was that existing on-chain oracle solutions were no longer manipulation resistant after the merge introduced a new attack vector where a single entity could propose consecutive blocks (multi-block MEV).
• Since Beanstalk wants to experiment with zero fee options in pools, it opens the door to this type of manipulation even more by limiting the cost of changing the discrepancy in liquidity pools.
• Creating a composable and effective on-chain oracle solution became a requirement, in order to remain as fully decentralized as possible.
• Wells are the culmination of the need for a new on-chain oracle solution and a customizable decentralized exchange.
• Wells are currently under audit.
• Consists of a single on-chain representation of a liquidity position and a modular way to attach different oracles through that liquidity position.
• The primary reason to have liquidity on-chain is that it can serve as proof of its own existence, and other protocols can use that to determine prices.
• Wells architecture supports the ability for some kind of abstract pricing function as well as n-dimensionality, which seemed to be base level requirements to be fully composable and customizable. Where it lacks in terms of composability is the fact that in order to have a valid on-chain oracle, the oracle needs to be updated every time one of the dependent variables updates.
• If the pricing function is not constant the pricing function itself is a dependent variable, and currently there does not appear to be a solution on-chain that handles this case. Ideally, Beanstalk will allow the deposit of liquidity in any form for supported tokens, so this is an important problem to solve.
• The current implementation of Wells allows for Bean-ETH to start trading, but there's a question as to whether or not most orders will be placed on chain, which is where Tractor comes in.
• There's on-chain liquidity order tech stack or DEX, which generally falls under the Wells umbrella, and then there is Tractor, which is highly complementary and can use everything that exists on-chain to produce more sophisticated orders.
• Tractor requires the middleware or off-chain indexing protocol that can support placing orders on other chains or even off-chain. There's an open question as to how to index those orders.
• Another question is the actual integration with Beanstalk and how to maximize the permissionless around orders and liquidity creation for the Silo and how Beanstalk can treat liquidity.

Registries (Aqueducts and Aquifers)

• Early on there will need to be a permissioned registry which is aware of safe pricing functions. An off chain piece of indexing technology that aggregates all the orders. It will read the blockchain or some stream of order creation. It will require an understanding of the nature of every well function on chain and perform some sort of judgement about which wells should not be permitted in this particular order book.
• In the current implementation, wells are not necessarily non-malicious by default, but rather by assessing the well function, pump and aquifer that were used to deploy the well, judgements can be derived about whether it is behaving non-maliciously.
• If each well is represented in the form of a single order, some sort of aggregation needs to happen. An oracle needs to use some sort of liquidity weighted average across all the different wells that have a substantial amount of liquidity. There can be some kind of permissionless ordering process where trusted wells with the highest liquidity get added and ones with low liquidity get bumped.
• A permissionless on-chain oracle registry system could be created, but ultimately there does not seem to be a way to permissionlessly trust the individual well function/auger without also verifying that it was deployed by a valid aquifer. This creates a problem where wells are a permissionless piece of technology, but they require trust in the components that deployed them to verify they should be used for a particular thing.

Deploying Wells

• You can query the output of a well through an on-chain function, but a malicious well function creator could have ownership of the contract and front run your swap and know your slippage parameter and extract the maximum amount of MEV.
• A way around the pricing function trust problem is to have a library of audited and validated pricing functions that either maintain their own state variables or somehow take in a configuration.
• There is a lot of work to be done developing theory around the pricing functions and the oracles that are derived from them.
• Ultimately it will be up to each client or UI provider to make judgements on acceptable pricing functions, augers, and pumps.

Limit Order Example

• First thing to ask when creating any type of order is whether it belongs in a well or an off-chain order book.
• Deploying a well is a relatively expensive event
• In the case of a limit order, a contract could be deployed that is just always willing to buy Beans at some price and they can update it with what value they're willing to buy at. So if the person was intending to do some market making and update the order frequently, that might make sense.
• A user wanting to make one trade might use something like tractor, where order creation would be free and still permissionless

Root Developments

• Root has built a token factory that will facilitate the creation of on-chain tokens that settle based on arbitrary settlement logic and arbitrary oracle data.