BaseAdaptor

While every adaptor will contain logic unique to its specific integration, adaptors require certain interface guarantees in order to work with Sommelier Cellars. The required interfaces are specified in BaseAdaptor.sol. It is recommended that any adaptors inherit from BaseAdaptor.

In order to work with a Cellar, an adaptor must satisfy the following interface guarantees:

• Each deployment of an adaptor must report a globally-unique bytes32 identifier when the identifier function is called. Different versions of the same adaptor should report different identifiers. If an adaptor is updated due to bug fixes or new features, a new identifier should be used.

• Each adaptor should report the "base asset" in which the holdings associated with the adaptor's positions should be priced. This base asset is reported using the assetOf function. The adaptor's asset must always be supported by the Price Router (see "Oracle Usage and Asset Pricing" for more information).

• Each adaptor should report all assets used in any adaptor-based position using the assetsUsed function. Some adaptors may report multiple assets (for instance, an adaptor for Uniswap V3 LP positions should report both assets in the relevant pool). These assets may be specified by adaptorData (see "adaptorData and configData" for more information).

• Each adaptor should accurately report its managed TVL for a given cellar, via the balanceOf function. This specified balance is always in terms of the base asset. For adaptors whose positions may manage multiple assets, the balanceOf implementation should translate balances in one asset into corresponding balances of the base asset, and return the accumulated sum.

• Every adaptor should implement a deposit function, which handles how direct deposits from users into the adaptor's managed positions should be handled. Usually, this involves depositing those user funds into the specified position. This function will be used in the case where the position managed by the adaptor is the Cellar's holding position. If there is no clear way to handle user deposits (for example, debt token adaptors which represent liabilities and not assets), deposit may revert. If deposit is set up to revert, it may not be used as a Cellar's holding position.

• Every adaptor should implement a withdrawableFrom function, which reports how many of the position's assets are withdrawable by a given cellar at the time of execution. This value is read when the position is used to service user withdrawals. If assets cannot be withdrawn from the position to service user deposits (for example, debt token adaptors which represent liabilities and not assets), withdrawableFrom may return 0. withdrawableFrom should never revert.

• Every adaptor should implement a withdraw function, which removes assets from the adaptor-managed position to be sent to a user. Any withdrawal amount which is less than or equal to the amount reported by withdrawableFrom should not revert. Any withdrawal logic should not affect the adaptor-managed position except to the extent of the amount of tokens specified in the function's parameters.

• Every adaptor should report whether it represents a debt position, by returning a boolean when isDebt is called. Debt positions represent liabilities for the Cellar, as opposed to assets (for instance, open borrows from AAVE). Please refer to "Using Adaptors" for more information on debt positions.