Current complex interactions with Arbitrum-native protocols are tedious, cumbersome and expensive. The Depot facilitates complex, gas-efficient interactions with other Arbitrum-native protocols in a single transaction.
Any protocol with a Pipeline to the Depot can be used via Beanstalk in a single transaction. Pipelines to the Depot can be added via Beanstalk governance.
The Pipeline Pipeline allows anyone to perform an arbitrary series of actions in the EVM in a single transaction by using 0xb1bE000644bD25996b0d9C2F7a6D6BA3954c91B0 as a sandbox for execution.
The following functions to interact with Pipeline can be called through the Pipeline Pipeline.
pipe(...)
multiPipe(...)
advancedPipe(...)
For guides on interacting with the Market through the Beanstalk UI, go here.
Pods can be bought and sold in a decentralized, trustless fashion on the Market. The Market creates liquidity for Pods through an on-chain order book.
Sellers can List Pods or Fill open Pod Orders placed by buyers.
Buyers can Order Pods or Fill open Pod Listings placed by sellers.
Pods from Beans Sown in a single transaction form a Plot. Anyone with a Plot can List a whole or partial Plot for sale in exchange for Beans. This is known as a Pod Listing. Pod Listings have the following inputs:
Pod Listing Inputs
Example
1. Plot
Place in Line: 140M, Pods: 4,000
2. Position within the Plot
2,000 to 4,000
3. Price per Pod
0.80 Beans
4. Expiration
30M Pods
1. Plot
Farmers may own multiple Plots. Plots are identified by their place in the Pod Line.
2. Position within the Plot
As Pods are Harvested on a First In, First Out (FIFO) basis, if less than a whole Plot is Listed, the seller must choose which Pods within the Plot to List. A seller can List any contiguous set of Pods within a Plot. If only a portion of a Plot is Listed, the seller must choose which subset of Pods within that Plot are for sale. In the example above, the last 2,000 Beans in the Plot are Listed, while the first 2,000 (i.e. Pods 0 - 2,000) remain in the seller’s possession.
3. Price per Pod
The sale price of each Pod, denominated in Beans.
4. Expiration
The number of Pods that can Harvest before the expiration of the Listing. Setting this input to 30M Pods would remove this Listing from the Pod Market once 30M Pods are Harvested after the creation of the Listing.
A Pod Listing can be Cancelled at any time until it is entirely Filled. Plots can only be Listed in a single Pod Listing at a time. Pod Listings are automatically Cancelled if the owner of the Plot transfers or re-Lists any Pods in the Plot.
A Pod Listing can be entirely or partially Filled at any time by a buyer. If the Pod Listing is partially Filled, the rest of the Pod Listing remains Listed.
A Pod Order is an offer to buy Pods at a given price, before a given place in the Pod Line. Any seller may Fill a Pod Order by selling Pods according to the terms of the Order.
Anyone with Beans can Order Pods by creating a Pod Order. A Pod Order has the following inputs:
Pod Order Inputs
Example
1. Maximum number of Pods to be purchased
4,000 Pods
2. Price per Pod
0.80 Beans
3. Maximum place in the Pod Line
140.0M
1. Maximum number of Pods to be purchased
Because Pod Orders can be partially or entirely Filled at any time by a seller, a Pod Order defines the maximum number of Pods the buyer would like to purchase at a given price.
2. Price per Pod
The price to be paid for each Pod, denominated in Beans.
3. Maximum place in the Pod Line
A Pod Order with a maximum place in the Pod Line of 140.0M could be Filled by any Pods with a position in the Pod Line of 140.0M or earlier. In general, Pods closer to the front of the Pod Line are more valuable, as they become Harvestable for Beans sooner due to the FIFO Harvest schedule.
A Pod Order can be Cancelled at any time until it is Filled. To facilitate instant clearance, Beans are locked in a Pod Order until it is entirely Filled or Cancelled. If the Pod Order is partially Filled, the rest of the Pod Order remains Listed.
The Toolshed offers a suite of tools for efficient use of Beanstalk and other Arbitrum-native protocols.
Tractor is currently not supported in the Beanstalk UI.
Maintaining and optimizing a position in Beanstalk requires manual intervention (Mowing, Planting, Harvesting Pods and Depositing the Beans, etc.). Smaller Farmers do not necessarily have the resources to automate the execution of their Beanstalk transactions, and existing generalized function call systems (i.e., smart contract accounts, Depot + Pipeline) only support the use of assets from the sender of the transaction.
Tractor is a peer-to-peer transaction marketplace that allows third party operators to perform Beanstalk actions on behalf of a Farmer.
Blueprints are off-chain data structures that are EIP-712 signed to verify the intent of the publishing Farmer. Blueprints allow Farmers to define arbitrary sequences of on-chain function calls, which can be executed permissionlessly by other Farmers known as Tractor Operators.
Blueprints contain the Publisher, an Advanced Farm function call containing an arbitrary sequence of internal function calls, a set of copy instructions that define how to interpret Operator calldata, expiry parameters and the EIP-712 signature from the Publisher. Any Tractor Operator can execute any Blueprint with any calldata at anytime through the tractor(...) function provided that the Blueprint does not revert.
Junctions are contracts that are contain basic operations as external functions that are used by Tractor orders. Junctions allow Farmers to define Blueprints that will fail under a predefined set of conditions, such as balance limits, price thresholds, etc.
Examples
A Farmer creates a Blueprint for an Operator to Plant on their behalf any time they have more than 100 Earned Beans and will pay the caller 1 Earned Bean.
A Farmer creates a Blueprint for an Operator to Mow on their behalf any time that P > 1 and will pay the caller 5 USDC.