BA Labs Risk Framework for SummerFi DAO-Managed Fleets
Author: Block Analitica
Date: February 11, 2026
References: RFC #601, BA Initial Fleet #76, BA Baseline Criteria #567, BA Proposal #651, SIP5.19 #674, Guardian RFC #613
1. Scope & Boundaries
This framework governs ARK inclusion, categorization, and parameter setting for DAO-Managed (“Indexed”) Vaults only. It does not apply to BA risk-curated vaults, which remain under BA’s full discretionary risk process. BA’s risk-curated approach is documented in the initial fleet and ARK parameters (#76) and baseline criteria (#567), and while the models have evolved over time, they continue to operate on the same core principles of case-by-case assessment.
BA’s role under this framework is limited to:
- Designing and documenting the inclusion rules and category definitions.
- Proposing the initial set of ARK parameters to the DAO.
- Periodically updating the framework to reflect changing market conditions, subject to DAO approval for each update.
BA does not perform per-ARK collateral assessments, monitor individual ARK state changes (liquidity, configuration, timelocks), or act as Risk Manager on these vaults. That responsibility sits with the DAO, the Keepers, and the Guardians as proposed below.
2. Hard Filters (Gate-Level Exclusions)
Every yield source must pass all hard filters before category assessment begins. Failure on any single filter is an automatic exclusion. These filters are binary and onchain-verifiable where possible.
| Filter | Requirement | Rationale |
|---|---|---|
| Protocol age | Mainnet deployment ≥ 180 days | Eliminates unproven contracts with no live track record |
| Audit status | At least one completed audit by a recognised security firm (CertiK, OpenZeppelin, Halborn, ChainSecurity, Trail of Bits, OpenZeppelin, Pashov, or equivalent) within the last 12 months | Baseline security signal |
| TVL / APY screen | Must pass the dynamic TVL minimum derived from fleet APY and protocol APY (see 2.1 below) | Ensures the ARK can deliver a meaningful yield uplift relative to the risk it adds |
| Backing liquidity | ≥ 60% of backing must not be locked or subject to long lockups or vesting | Guarantees a realistic unwind path in stress scenarios |
| Transparent and verifiable backing | Backing must be verifiable via one of: (1) fully onchain verification accessible to anyone, (2) third-party solution providing continuous proof (e.g. zk-proof of reserves), or (3) monthly attestations by at least 2 independent auditors/attestors covering the last 6 months (or since deployment if younger). See 2.2 for details. | Prevents opaque or unverifiable collateral from entering the vault |
| Asset allowlist | USDT, USDC or ETH only (initial scope) | Limits operational surface area; can be extended via governance |
| Swap liquidity (if applicable) | If deposit or withdrawal into the ARK requires a token swap, the swap route must have sufficient liquidity to result in a maximum price impact of 0.05% at the expected rebalance size (max between maxRebalanceOutflow and minRebalance Outflow) | Unbound slippage and price impact on swaps erode yield and introduce unpredictable execution risk |
| Known critical dependency | No active or unresolved critical dependency flags from BA or the Guardians | Catches systemic risk vectors not captured by other filters (e.g. single oracle, single issuer) |
2.1 TVL / APY Screen (derived from BA Labs baseline criteria, post #567)
The objective of this filter is to ensure that adding an ARK produces a meaningful APY uplift for the fleet relative to the risk it introduces. A candidate passes only if depositing into it at scale would raise the fleet APY by at least 5% (this value could be set by governance).
Inputs:
- TVL_fleet: current TVL of the DAO-managed fleet
- APY_fleet: current average APY of the fleet (30-day window preferred, 7-day fallback)
- APY_protocol: APY of the candidate yield source (same averaging window)
- TVL_protocol: TVL of the candidate yield source
Pre-condition: APY_protocol > 0.9 × APY_fleet. If this does not hold, the candidate fails immediately regardless of TVL.
Minimum TVL formula (with 10% downside tolerance on fleet APY):
TVL_min = 0.05 × TVL_fleet × (APY_fleet × 0.9) / (APY_protocol − APY_fleet × 0.9)
Pass condition: TVL_protocol ≥ TVL_min
If TVL_protocol < TVL_min, the expected APY impact is too small relative to the added risk and complexity, and the candidate is excluded at the gate level.
Note on exceptions: This filter may be bypassed if there are strong diversification or capacity reasons (e.g. large money markets with bluechip collateral that reduce overall fleet risk). Any such deviation must be accompanied by a written rationale in the onboarding proposal and is subject to DAO approval.
2.2 Backing Verification Standards
ARKs must meet one of the following verification tiers:
Tier 1: Continuous verification (preferred):
- Onchain: Backing composition is fully verifiable onchain by anyone at any time, with no trusted intermediaries required (e.g. native protocol tokens, direct smart contract holdings)
- Proof: Third-party solution provides continuous cryptographic proof of backing (e.g. zk-proof of reserves, delta-neutral position proofs), verifiable and updated with a credible and publicly identifiable provider
Tier 2: Periodic attestations (minimum standard):
- Monthly attestations by at least 2 independent auditors or attestors
- Must cover the last 6 months (or since deployment if the ARK is younger)
- Attestors must be publicly named and credible (recognized audit firms or specialized attestation providers)
Sources that cannot meet Tier 2 minimum standards are excluded at the gate level.
3. Category Definitions
Sources that pass the hard filters are assigned to one of three categories. Category assignment determines the vault-level exposure cap and the maximum single rebalance flow, both enforced by Keepers in real time. A source that does not fit any category should not be onboarded.
Category A: High Confidence
| Parameter | Value |
|---|---|
| Max Cap | 70% of yield source market/vault liquidity |
| Max % of fleet TVL | 100% |
| Max rebalance outflow | min( Max Cap, Max % fleet TVL × TVL_fleet ) × 1.05 |
| Max rebalance inflow | min( fleet TVL, Max rebalance outflow / 1.05 ) |
| Leverage/Looping | Not permitted |
| Delta Neutral | Not permitted |
| Max withdrawal / exit period | Not permitted |
| Cross-chain backing | Not permitted |
| Curator age (if applicable) | ≥ 1 years for yield sources with curator-managed strategies (e.g., Morpho vaults, Euler vaults) |
Eligibility criteria (all must hold):
- Passes all hard filters.
- Protocol has been live on the target chain for ≥ 365 days.
- No active governance attack, exploit, or credible threat flagged in the last 365 days.
Exception: The DAO may approve Category A classification for a yield source that would otherwise be excluded from Category A (e.g., due to cross-chain backing, delta neutral strategies, or other restrictions) if it demonstrates exceptional TVL, Lindy effect, and industry establishment. Such exceptions require explicit DAO vote and written rationale.
Category B: Moderate Confidence
| Parameter | Value |
|---|---|
| Max Cap | 50% of yield source market/vault liquidity |
| Max % of fleet TVL | 70% |
| Max rebalance outflow | min( Max Cap, Max % fleet TVL × TVL_fleet ) × 1.05 |
| Max rebalance inflow | min( 20% of fleet TVL, Max rebalance outflow / 1.05 ) |
| Leverage/Looping | Permitted (see 3.3) |
| Delta Neutral | Permitted (see 3.3) |
| Max withdrawal / exit period | Permitted (see 3.5) |
| Cross-chain backing | Not permitted |
| Curator age (if applicable) | ≥ 6 months for yield sources with curator-managed strategies (e.g., Morpho vaults, Euler vaults) |
Eligibility criteria:
- Passes all hard filters.
- Protocol has been live on the target chain for ≥ 180 days.
- At most one of leverage/looping, or delta neutral is present. If more than one applies simultaneously, the source is automatically Category C.
- Backing is single-chain only (except delta neutral strategies where assets can be on CEXs).
- Less than 50% of the ARK’s collateral backing is allocated to leveraged positions.
Category C: Lower Confidence
| Parameter | Value |
|---|---|
| Max Cap | 25% of yield source market/vault liquidity |
| Max % of fleet TVL | 30% |
| Max rebalance outflow | min( Max Cap, Max % fleet TVL × TVL_fleet ) × 1.05 |
| Max rebalance inflow | min( 5% of fleet TVL, Max rebalance outflow / 1.05 ) |
| Leverage/Looping | Permitted (see 3.3) |
| Delta Neutral | Permitted (see 3.3) |
| Max withdrawal / exit period | Permitted (see 3.5) |
| Cross-chain backing | Permitted (see 3.4) |
| Curator age (if applicable) | Any |
Eligibility criteria:
- Passes all hard filters.
- Does not meet Category B eligibility. Automatic placement into C if any of the following applies:
- More than one of leverage/looping, or delta neutral is present simultaneously.
- Backing involves cross-chain positions.
- 50% or more of the ARK’s collateral backing is allocated to leveraged positions.
DAO Discretion: The DAO retains full authority to override this framework in edge cases or exceptional circumstances. If a yield source does not fit cleanly into any category, or if market conditions warrant deviation from these guidelines, the DAO may vote to onboard the ARK with custom parameters. All such overrides must be accompanied by a written rationale published to the forum and require explicit governance approval.
3.3 Leverage/Looping and Delta Neutral Disclosure Requirements
Leveraged and delta neutral yield sources are excluded from Category A. They may be onboarded into Category B or C, provided the following is documented and visible to the DAO before onboarding:
If the yield source involves leveraged looping:
- The percentage of the ARK’s collateral backing that is allocated to leveraged positions.
- The leverage ratio (if determinable onchain or via documentation), for transparency purposes only.
- Whether the leverage is maintained automatically or requires manual intervention to unwind.
- The expected behaviour under a sudden adverse price move (e.g. flash crash scenario).
If the yield source is a delta neutral strategy:
- The components of the delta neutral position (e.g. long/short legs, funding sources).
Sources where any of the above cannot be verified onchain or via credible third-party documentation are excluded.
3.4 Cross-Chain Backing Disclosure Requirements
Cross-chain backing is excluded from Categories A and B. It may be onboarded into Category C, provided the following is documented and visible to the DAO before onboarding:
- The chains involved and the specific bridge(s) or messaging layer(s) used to move assets between them.
- The trust assumptions of each bridge (e.g. multisig, ZK-verified, optimistic).
- The historical uptime and incident record of each bridge used.
- The estimated time and cost to fully unwind the cross-chain position under stress conditions.
- Whether the cross-chain backing is continuously monitored and by whom.
Sources where any of the above cannot be verified onchain or via credible third-party documentation are excluded.
3.5 Withdrawal Period Disclosure Requirements
Withdrawal periods, cooldowns, and redemption queues are excluded from Category A. They may be present in Category B or C sources, provided the following is documented and visible to the DAO before onboarding:
- The standard withdrawal or exit period under normal conditions.
- Whether the period is fixed or variable based on liquidity/demand.
- Any conditions under which the withdrawal period could extend beyond the standard duration.
Sources where withdrawal mechanics cannot be clearly verified are excluded.
4. Liquidity-Aware Caps (Suggested Keeper Behaviour)
The Max Cap figure in each category is intended to function as a dynamic ceiling, not a static deposit cap. It is suggested that Keepers monitor available liquidity in real time and adjust effective deposit caps accordingly:
- If market liquidity drops (e.g. other depositors withdraw), it is suggested that Keepers withdraw vault funds to maintain the vault’s share at or below the respective Max Cap level.
- If market liquidity grows, it is suggested that effective caps increase accordingly, up to the category allocation ceiling as a share of fleet TVL.
This is intended to reduce the need for the DAO to manually adjust caps in response to liquidity shifts, but remains an operational decision for the Keeper operators.
5. Fleet-Level Controls (Recommended Guidelines)
Vault-level caps alone do not prevent correlated exposure. The following guidelines are intended to inform how fleet-level risk is managed across multiple vaults. Implementation and enforcement are at the discretion of the DAO and the Keeper operators.
- Single-protocol exposure: It is recommended that when multiple DAO-managed fleets exist (e.g., USDC fleet, ETH fleet), the combined exposure across all fleets to any single protocol does not exceed 50% of total DAO-managed TVL. If onboarding an ARK would breach this limit, it is suggested the ARK be held back until existing exposure decreases.
- Correlated-asset exposure: If two or more ARKs share the same underlying collateral or yield source (e.g. two Morpho pools both backed by USDC), it is recommended their combined allocation is kept within the single-protocol guideline above.
It is suggested that Keepers check fleet-level exposure at rebalance time and reject rebalances that would breach these guidelines, but this remains an operational decision.
6. Guardian Interaction
As established in RFC #613 and SIP0.2, Guardians have narrowly scoped emergency powers over all protocol vaults, including DAO-managed vaults. These powers include:
- Vault Pause: Temporarily halt deposits, withdrawals, and rebalances on affected vaults.
- Governance Cancellation: Cancel in-flight governance proposals that pose immediate protocol risk.
For DAO-managed vaults specifically, Guardians have an additional power:
- ARK Deposit Cap to Zero: Set any ARK’s deposit cap to zero, triggering withdrawal of vault funds from that specific yield source. This allows surgical removal of a failing ARK without pausing the entire vault.
These actions are reactive only and exist for time-critical situations (active exploit, severe depeg, liquidity crisis, external dependency failure).
When a Guardian pauses a DAO-managed vault or sets an ARK deposit cap to zero, only a DAO vote can re-enable it. Guardian actions must be reported to the forum within 24 hours, with a brief justification and post-incident review.
Guardian trigger thresholds are defined in the Guardian Module (RFC #613 / SIP0.2), not in this framework. BA’s role is limited to flagging risk events that may warrant Guardian action via the critical dependency filter or ad-hoc communication to the Guardian multisig.
7. Ongoing Monitoring & Updates
BA will review the framework and iterate on it according to the market conditions and in the communication with SummerFi team to bring alignment with their Keepers. Each review covers:
- Whether the hard filter thresholds (protocol age, TVL/APY screen parameters) need adjustment given market conditions.
- Whether the category parameters (allocation ceilings, rebalance limits) remain appropriate.
Each proposed change is published as a forum post and, if substantive, promoted to a SIP. Minor corrections can be reported directly to the forum and actioned by the DAO without a full SIP, provided no delegate objects within 48 hours.
8. What This Framework Does Not Cover
The following are explicitly out of scope and are governed by other mechanisms:
| Item | Governed by |
|---|---|
| Per-ARK collateral and protocol security assessments | Not performed on DAO-managed vaults. Users accept this tradeoff explicitly. |
| Emergency pause and vault-level halts | Guardian Module (RFC #613 / SIP0.2) |
| Oracle risk assessment | Per-ARK oracle dependency evaluation is not performed by this framework due to its qualitative nature, while the framework is designed to provide quantifiable and easily verifiable criteria for the DAO. |
| Oracle risk is flagged only if it surfaces as a known critical dependency (Section 2). | |
| Per-ARK collateral quality composition assessment | Collateral quality evaluation falls outside the scope of this framework due to its qualitative nature, while the framework is designed to provide quantifiable and easily verifiable criteria for the DAO. |
| Collateral risk is flagged only if it surfaces as a known critical dependency (Section 2). | |
| Insurance or reimbursement mechanisms | Separate governance discussion |