Understand the control surface
Review who can act, what they can change and how your integration responds.
An institutional integration needs a precise answer to three questions: who authorizes customer transactions, who changes the vault's configuration, and who can interrupt an action. Review those separately for the deployment you plan to use.
Customer authorization
A vault position is represented by shares. Deposits, withdrawals and redemptions interact with the vault contract and its underlying asset. Your application must use the correct chain, token, receiver and authorization flow. A successful Partner API request does not authorize a wallet transaction.
Keep administrative service credentials separate from wallet signing. Attribution and reporting belong in your backend; the customer transaction flow requires its own integration review.
Contract roles
The current optimized-rebalancer-contracts source exposes the following controls in Rebalancer.sol. This is a source-level description; the deployment checklist establishes the actual role holders and configuration.
| Control | Source authorization | Integration implication |
|---|---|---|
| Rebalance between providers | Executor role | Monitor executed transactions and resulting allocation |
| Change the provider set | Configured timelock | Track scheduled and executed configuration changes |
| Change the entry provider | Admin role | New deposits can use a different entry provider |
| Pause or resume an action | Admin role | Deposits and withdrawals have separate pause checks |
| Set treasury, fees or minimum assets | Admin role | Refresh terms and amount validation when configuration changes |
| Replace the timelock address | Configured timelock | Track the governance configuration itself |
Withdrawal validation checks the withdrawal pause state. A universal promise that an administrator can never pause a redemption does not describe this source. Your customer experience must support temporary unavailability and explain the current action state.
Operational controls
Use separate credentials per service, verify webhook signatures and deduplicate processed events. Reconcile indexed activity against the relevant onchain records. A status response and a successful webhook are useful signals, but neither proves that a specific customer transaction settled.
Agree on the incident contact, customer messaging owner and recovery procedure before launch. See monitoring and launch readiness.
Review evidence
Use the audit report, exact source revision and deployment configuration together. An audit of one revision should not be presented as coverage of every later contract or integration component.