Vault Integration

Vault Integration

The DeFindex strategy adapter lets a vault supply one asset to lending and redeem that supply later. It implements the DeFindex asset, deposit, withdraw, balance, and harvest interface through ordinary controller operations. The adapter does not borrow, swap, or create leverage.

Each vault has a separate lending position, while the underlying liquidity and supply index belong to the configured hub market. Yield and losses follow the same accounting as other suppliers. See Interest Rates for how interest accrues and Managing Positions for supply and withdrawal behavior.

One fixed market per instance

An instance is constructed with an underlying token and three initialization arguments: the controller address, hub ID, and spoke ID. It reads the hub-asset market index and resolves the pool address through the controller, then stores all five values.

The configuration cannot be changed through the adapter. A different asset, hub, spoke, or controller requires a different instance. Construction confirms that the market index can be read; it does not validate that the configured spoke permits deposits. Spoke listing, permissions, and caps are enforced when a deposit reaches the controller.

The adapter has no administrator, upgrade entry point, configuration setter, account-remapping function, or rescue/sweep function. Its fixed addresses still depend on the behavior and governance of the external controller, pool, and token contracts.

Vault authorization and custody

The from address identifies a vault's account mapping. Deposits, withdrawals, and harvests require that address's authorization. There is no vault allowlist: any address that can provide the required authorization can use the interface. Asset and balance reads are open.

The controller account is owned by the adapter contract. The adapter maps each vault address to its own controller account ID and invokes the controller as that account's owner. One vault's authorization does not select another vault's mapping. Vault share issuance, investor withdrawals, and allocation among strategies remain the vault's responsibility.

An account ID of zero means that no account is mapped. Before reusing a stored ID, the adapter asks the controller whether that account still exists:

Lookup result	Behavior
No stored ID	Balance is zero; the next deposit can open an account. Withdrawal fails for insufficient balance.
Controller confirms the account exists	Reuse the ID and renew the mapping's storage lifetime.
Controller explicitly reports no account	Treat it as absent. A deposit clears the obsolete mapping and opens a replacement; balance reports zero and withdrawal fails.
The controller lookup fails	Stop with AccountLookupFailed; do not erase or replace the mapping.

This distinction preserves the route to collateral when the controller cannot answer. Other failed external reads also propagate as failures. An unavailable balance is not converted into a successful zero-balance response.

Deposits and withdrawals

Amounts are integers in the underlying token's smallest units. Both deposit and withdrawal reject zero or negative requests and return the vault's resulting collateral balance, not the amount transferred.

Operation	Flow and result
deposit(amount, from)	Authenticate from, measure the tokens received by the adapter, resolve the vault's account, and supply the measured receipt to the configured market. Store the returned account ID and return its resulting collateral balance.
withdraw(amount, from, to)	Authenticate from, require an existing account and enough collateral, then ask the controller to pay the chosen recipient. Return the remaining collateral balance.
balance(from)	Return the current collateral claim for the mapped account and configured asset, or zero under the confirmed-absence cases above or when that account has no supply position in this asset.
asset()	Return the fixed underlying token address.

A deposit measures the adapter's token balance before and after the vault-to-adapter transfer. Only that increase is passed to lending. The controller separately measures the adapter-to-pool receipt before crediting supply. Requested amounts, token-transfer effects, and protocol rounding can therefore produce different credited amounts. A failed downstream operation reverts the transaction's transfers and account changes together.

After resolving the account, the adapter authorizes the measured asset transfer to its cached pool for that invocation and calls supply. Direct token transfers to the adapter do not create a vault claim, and its idle token balance is not included in balance(from).

For a partial withdrawal, the adapter forwards the requested amount. When the request equals the current collateral balance, it passes the controller's withdraw-all sentinel, allowing the controller and pool to settle the complete scaled position. The adapter clears the vault mapping only after that full withdrawal succeeds. The remaining collateral read then returns zero when no position remains; a later deposit can create a fresh account.

The pool pays to directly. The adapter does not measure the recipient's balance increase or return a payout receipt: its return value is the remaining lending claim. The recipient must satisfy the controller's restrictions, including exclusion of the controller and pool addresses. Sending funds to the adapter itself does not create a credited vault deposit and has no sweep path.

Balance, interest, and harvest

balance(from) reads the controller's collateral amount for the fixed hub asset. The controller converts scaled supply through the current simulated supply index using the protocol's half-up rounding convention. This includes accrued interest in the claim without requiring a harvest to distribute or reinvest tokens. It is neither a USD valuation nor a promise that the entire amount is immediately liquid.

harvest(from, data) requires from authorization and emits an event with amount = 0 and the market's current price per share. It moves no funds, issues no shares, and performs no swaps. The optional data does not change this behavior. Harvest does not require a mapped vault account; the reported index belongs to the configured market.

The price per share uses 12 decimals. It is the positive RAY supply index, which has 27 decimals, rescaled with floor rounding:

let price_per_share_12 = supply_index_ray / 1_000_000_000_000_000;

For a supply index of 1.05 × 10^27, the event reports 1.05 × 10^12. This is a market supply-index measure, not the vault's own net asset value per issued share. The adapter does not keep separate yield or fee accounting. See Accounting and Numeric Domains for scaled balances, index conversion, and rounding.

Availability and operating limits

Deposits use the controller's ordinary entry checks: the protocol must permit supply, the hub and spoke must be active, the asset must be listed and collateralizable, applicable pause/freeze flags must permit entry, and caps must have room. A successfully constructed adapter can still be unable to accept a deposit.

Withdrawals require available pool cash and must satisfy the market's utilization limit; they cannot leave zero supply backing positive debt. An asset's spoke pause blocks its ordinary withdrawal, while freezing blocks new exposure and allows exits. A global controller pause alone does not block ordinary withdrawals. Delisting does not by itself prevent exiting an existing position. The adapter provides no special liquidity reserve or alternative withdrawal route.

Positions created through this interface contain supply without debt, so their ordinary balance, deposit, and withdrawal paths do not need solvency oracle prices. Harvest reads the market index, not an asset price. External token or contract failures and storage availability can still prevent these operations. See Oracle System for the broader controller's conditional price dependencies.

The adapter cannot redirect a position, rescue directly transferred tokens, or bypass lending restrictions. Integrators must select the instance and withdrawal recipient deliberately and maintain the vault-account storage mapping needed to reach each position. No administrative recovery should be assumed.

References

• Managing Positions: account ownership and ordinary supply/withdrawal rules.
• Interest Rates: utilization, interest accrual, and supplier returns.
• Accounting and Numeric Domains: token units, scaled supply, and rounding.
• Central Pool and Security: shared liquidity and trust boundaries.
• Endpoint reference: DeFindex interface and return types.
• Architecture reference: adapter responsibilities and custody.
• Arithmetic reference: supply valuation and numeric domains.
• Error reference: strategy and downstream error identifiers.