Allocations and adapters
An allocation is the part of a vault invested in a particular position. An adapter is the program that connects the vault to the supported investment path and reports its value. An adapter’s name alone does not describe all the risks of the underlying asset.
Targets and actual holdings
Target weights describe the intended strategy. Actual holdings can differ because of new deposits, withdrawals, market conditions, caps or unfinished actions. Idle USDC is a position in cash, not evidence that every target investment is already earning.
Compare actual allocations with targets before interpreting a portfolio-weighted rate. Concentration should be assessed against the current portfolio as well as the intended one.
Protocol positions and token legs
A protocol leg can hold a position such as a lending receipt. A token leg holds a token whose value and liquidity depend on its asset and permitted trading path. Token trades are checked within a single transaction bracket that measures the result before and after the allowed swap.
A token’s issuer redemption value can differ from a market exit price. A successful valuation does not establish that a large sale will execute at that value. NAV and liquidity should be assessed together.
Synchronous and asynchronous paths
A synchronous action completes in the transaction. An asynchronous action starts a claim that settles later. Supported pending valuation keeps the claim represented while it is in flight. It does not make it immediately redeemable cash.
A supported cancellation acknowledges the external protocol’s actual state. It cannot simply pretend a completed external action never happened.
Sources
The source registry describes the venue, originator, asset, risk driver and exit path. Its tags help identify shared exposures. Two allocations on different venues can still depend on the same borrower or issuer.
Illustrative example: a vault invests 20% in a token on one venue and 20% in a lending position ultimately backed by the same issuer. Looking only at venue names suggests diversification. Looking through the holdings reveals a 40% issuer dependency.
What deployment and approval mean
An adapter may be implemented, deployed, approved and enabled in a particular vault at different times. Each enabled mode needs appropriate verification. Local fixtures and snapshots answer narrower questions than a funded production exit.
The core binds accounts and pins adapters to a deployed version. Supported re-pinning follows governance rules. This reduces some substitution risks without making the external protocol or upgrade process risk-free.
Read due diligence and the strategy limit engine. For operational context, see the curator console.