• Recordings
• Meeting Notes
• Wells
• The Aquifer
• Pumps
• Requirements for Bean-ETH Well proposal
• Middleware
• UI
• Wells and Tractor Needs
• Initial Wells Interface
• Transcript

Recordings

Meeting Notes

Wells

• There are 5 components of Wells:
• Core Well code
• Well function
• Pump
• Aquifer
• Auger
• The first implementation of a Well, the constant product Well function and the corresponding Auger are currently in the hands of Halborn
• The two pieces of code which are not are the Pump and the Aquifer

The Aquifer

• The Aquifer is the contract that's going to be called to deploy a Well, and it serves as a Well registry that can confirm whether or not it deployed a given Well and because of that also provide proof of the Pump, the Auger, and Well function that were deployed with the Well.
• Needs more discussion to iron out what the details should be.

Pumps

• Pumps require a lot of complex mathematics that require more significant testing
• Things tracked by Pumps
• Last balances number
• Max percent change per block (for multi-block MEV resistance)
• Might cause some lag, so the value should be considered.
• Geometric EMA of the balance of the pool over some variable time horizon
• Cumulative geometric SMA of the balance over time
• Both the EMA and SMA are geometric values, which is largely inspired by the Uniswap V3 oracle.
• Less general deviation in relation to outliers, helps prevent short term-manipulation
• By converting into their base logarithmic values, it allows for the values to be contracted on chain which provides gas savings
• The EMA is an instantaneous tracking value. The use case of the EMA is to report an instantaneous statistic that is a function of the balances in the pool.
• Uniswap V3 uses SMA for instantaneous balances, which works, but it is more expensive from gas perspective as it requires an on chain index of balances at every time stamp over the desired range
• Wells do use an SMA to calculate time weighted average balances, using a cumulative sum similar to Uniswap’s SMA, but only storing a running total.
• It can still allow averages over time to be calculated for things like the minting schedule, where Beanstalk wants the average over the course of the hour not the instantaneous price.
• Code is pretty much wrapped up, but there is lots of testing to be done. Ideally we'll have graphics or statistics showcasing the effects of different parameters. Ultimately the DAO will have to make some sort of decision about the A parameter on the EMA and the maximum % change in a block to prevent against manipulation resistance.
• Other than that and some general cleanup, it should be ready for audit

Requirements for Bean-ETH Well proposal

• Aquifer code needs to be finalized (well registry)
• Pump (oracle) needs to be finalized
• The Beanstalk integration which uses the Pumps, in order to determine the deltaB.
• After the budget passes, BF is interested in having an audit performed by Cyphron and set up a code arena competition around wells also. And as a matter of practice, moving forwards we're hoping to put up any undeployed code on Immunify for a couple weeks.
• Maybe 7-8 weeks away from a Bean-ETH Well BIP.

Middleware

• A lot of time recently has been devoted to ensuring contract side code goes out smoothly to both auditors.
• The subgraph is going to index everything that the well is capable of doing.
• It's going to index when wells are created in the aquifer (decentralized registry), so any time somebody deploys a well, it will get picked up
• On the individual well level, it's going to record all the events that the well emits during the process of operation: adding/removing liquidity, swaps, etc
• You'll be able to track liquidity and price over time and look at individual transactions and see what's going on as well as read the components of the well through the subgraph. The components being any pumps that are attached, the well function and the tokens that it was instantiated with.
• The initial part of that process, reading the well deployment is done. Cujo is in the process of indexing the actual trading events. This particular subgraph's comparatively simple compared to the Beanstalk side, so the core functionality should be done by the end of the week, at least in a test environment.

UI

• Several months back, we built out an initial version of the wells UI. It was basically two components in the Beanstalk UI that would interact with Wells. The first is the Silo deposit page, where you could add to the Bean-ETH Well directly from the Silo interface. And then you'd also have the same trading functionality that you have currently where you can select from a range of tokens in order to deposit liquidity into that well.
• One of the other projects we've been working on over the last couple of months is to build out the Beanstalk SDK and implement it into the UI such that it can facilitate a number of different transactions such as swapping from more tokens and to allow more liquidity to flow with less friction into the well. An example would be if you have DAI and want to deposit liquidity in the Bean-ETH well, having the SDK's swap functionality correctly embedded in the UI allows you to just do all of that in one shot. A number of routes are supported, but some work needs to be done for it to be fully generalized.
• The market page will expand to split into both the Pod market and then Wells, so you'll be able to view individual Wells and see liquidity over time, current reserves, etc. in the Beanstalk UI directly.
• Last thing on the UI front is that we're considering what it would look like to go build out an independent wells UI. It might be something like Uniswap, where it's very polished and focused.
• You can expect a bot in discord that tracks the Bean-ETH well. Exactly which events are tracked is still TBD.

Wells and Tractor Needs

• What tractor is, and what this generalized on-chain marketplace is, is just the underlying on-chain trustless secure code that executes the orders and allows for order creation to a user.
• From a user perspective, a good user interface should make it very clear what they're doing, what they're trying to buy, what they're buying it with, what type of transaction it is. Users shouldn't be creating these complex transactions that are sent to Depot or tracked or whatever. Users should just be interacting with an interface that is specific to the type of exchange or market they're working with. The goal is to minimize on-chain computation and on-chain code. That is why it makes sense to create something that's super generalized, but the end product to the user is going to be more specific.
• There is truly a lot of work that needs to be done to build out things like the Beanstalk Market where one can imagine there's a deposit marketplace, a pod marketplace, a fertilizer marketplace, an ERC-20 token order marketplace where you can buy and sell unripe assets in bulk or something. Although the tech stack on the back end is going to be sufficiently generalized, custom middleware and UI still needs to be built to allow and enable these marketplaces.
• Tractor supports the ability to spend standardized tokens (ERC-20, 1155, or 721 deposits, Beanstalk deposits and plots) on behalf of the user. With the ability to use a given user's value or assets in a transaction, Tractor can then perform any number of sequential function calls based on using those assets as an input and then any asset it supports can then be outputted to the fulfiller and/or any other specified user. No changes are required for Beanstalk in order to implement and use Tractor to its fullest potential.
• The user experience should be the same whether you're dealing with on-chain well orders or off-chain tractor orders. The only functional difference is whether you want the liquidity to be provable on chain in some capacity.
• There is some question as to what the functionality parity will be between wells and Tractor at given points in the order creation flow. Too start, Tractor will likely be more broad in terms of on-chain capacities, but then there's a middleware question. Whereas Wells functionality is limited on-chain independent of middleware until there are further upgrades made. So this discussion can't be had in a perfectly generalized sense, it must be taken in the context of feature parity. But generally speaking up until the final stage of the order creation process, the whole thing should be abstracted away from the user.
• One example of using Tractor to enhance a current product is to add the ability for users to pace orders for Pods denominated in additional assets that aren't currently available, such as deposited Beans.
• For a limited use case such as that, it could be done in one to two quarters for a team of a couple engineers. The fully generalized Tractor that can scale with lots of orders is probably years of development.

Initial Wells Interface

• Might be advantageous to have an independent interface to make it very simple to do swaps.
• We need to decide whether we are or are not building a DEX. There's a big difference between deploying a Well for Bean-ETH that's just going to sit inside the current Beanstalk interface to be used as another whitelisted token, versus building a DEX with many pools.
• The Beanstalk UI that is maintained by Beanstalk Farms should be a one-stop shop to interact with Beanstalk, and you shouldn't have to go to a separate site.
• When it comes to functionality, the Beanstalk UI already has the infrastructure to support a Bean-ETH Well. You will be able to deposit from the Silo, and adding support for that pool on the swap page is just an upgrade to the SDK.
• There is currently a design for Well info, such as liquidity and trades. It would be nested under the market page. It might not be very useful at first with just one Well, but the design does exist.
• A separate website would simplify things and focus on Wells, without all the Beanstalk stuff. It would be faster to load, easier to link, work better on mobile, and present the DEX as a discrete product. It can also serve as a place to educate about wells and even do actual deployments of Wells.
• The design of the UI is going to depend on the ways in which people want to create orders, what pricing functions are available, and their parameters.
• There are two different DEXes being built: the one encompassed by Wells, and the one encompassed by tractor. From a UX perspective, what's being delivered to users should be an aggregate of all available functionality.
• What should be in a Well versus what should be in Tractor is very much a matter of how long each will take to develop.
• It's not clear what the best way to implement limit orders. Should they be on-chain or off-chain? Should they be permissioned or permissionless?
• The nature of the tech being built is to be as generalized and composable as possible. As such, many of the design decisions have to be made independently of any particular UI being built.
• There might need to be a separate, dedicated team for building a standalone DEX, whether that is an external group or one that spins off from Beanstalk Farms.
• The existing swap page that is already live can be adapted to use the tech being built.
• The goal should be to minimize the friction around building user facing products so that it's easy to utilize the tech being built.

Transcript