Allocation and Capacity
Proportional Allocation
When a user deposits into an OPAL vault, OpalManager distributes the incoming capital across every adapter in proportion to what each adapter already holds. Withdrawals reclaim from each adapter in the same proportions.
The allocation algorithm is deterministic: given the same portfolio state, it produces the same result every time. The sum of all per-adapter allocations equals the aggregate input exactly, with no rounding residue.
Every deposit reinforces the existing portfolio composition. Every withdrawal preserves it.
The Token Index
OPAL vaults can hold multiple asset tokens and multiple liability tokens across multiple adapters, each with its own internal token ordering. OpalManager maintains a global token index (assetTokens[] and liabilityTokens[], bounded at MAX_TOKENS = 10 each) that reconciles adapter-local views into a single coherent aggregate.
A tokensHash value (bytes32) represents the current token layout of the vault. Integrations and managed rebalance bundles can assert the expected tokensHash at runtime. If the token layout has changed since the bundle was composed, the transaction reverts.
Group-Aware Capacity
DeFi lending markets impose supply caps and borrow ceilings. Adapters that share the same underlying market declare the same groupId. When computing vault-level capacity (maxJoin / maxExit), OpalManager scales each adapter's raw capacity by the group's share of the combined total, then takes the minimum across all adapters.
This prevents a large deposit from hitting a protocol supply cap at the transaction boundary. The vault returns the correct deposit ceiling before the transaction is attempted.
Bounded Complexity
All allocation operations are bounded by MAX_ADAPTERS = 10 and MAX_TOKENS = 10, enforced at the contract level. Every vault operation has a known worst-case gas cost regardless of operational history or portfolio complexity.
Atomic Rebalances
The Bundler3 Execution Model
Managed rebalances in OPAL are executed through Origami's fork of Morpho Bundler3, an independently audited multi-step transaction engine. OpalManager functions as a permissioned Bundler that accepts a list of declarative call steps and executes them sequentially on target plugin contracts.
Every adapter enforces the withApprovedBundler modifier on all state-changing functions. Only OpalManager can move capital in or out of any adapter. External contracts, compromised wallets, and governance proposals cannot directly touch adapter positions.
Access Tiers
User deposit (join)
None
User withdrawal (exit)
None
Managed rebalance (multicall)
Elevated Access only
Add / deprecate / remove adapter
Elevated Access only
Whitelist adapter implementation
OpalAdapterFactory owner only
Approve new external plugin
Manager owner / Elevated Access
Atomicity via Flash Loans
Multi-step operations (leverage construction, PT rollovers, inter-adapter migrations) are collapsed into a single transaction using the AaveV3Flash plugin. The flash loan provides capital within the same transaction block. A post-execution balance sheet assertion (via the TbsV2 plugin) checks the result against expected ranges.
If every step succeeds and the assertion passes, the position is live. If any step fails or the assertion is off, the entire transaction reverts and the vault returns to its exact pre-operation state.
Reentry Safety
Flash loan callbacks are constrained by a predeclared hash mechanism. Before initiating a flash loan, the bundle specifies a hash of the exact nested callback steps. An unexpected callback reverts immediately.
Plugin Whitelist
All external integrations (flash loan providers, DEX routers, inter-vault operations) must be registered in OpalManager's plugin whitelist. A bundle step targeting an unregistered address reverts the entire bundle.
Last updated