feat(EXSC-411): S3 — fee receivers & sweep distribution

[gvladika]

Which Linear task belongs to this PR?

EXSC-411 — S3: Fee receivers & sweep distribution

Stacked on S2. The base of this PR is the S2 branch (#1993, the fee accrual engine — now including S2b's performance fee and per-fee-type split, and the S5 pause module via the merged lineage): dev-vault-wrapper ← S1 ← S2 ← S3. The diff is only the S3 distribution layer; retarget to dev-vault-wrapper once S2 lands.

Why did I implement it this way?

S2 splits every fee between LI.FI and the integrator the moment it accrues, into four per-recipient counters: lifiFeeAssets/integratorFeeAssets (idle asset, held in the wrapper, excluded from totalAssets()) and lifiFeeShares/integratorFeeShares (dilution shares minted to address(this)). S3 is the payout layer: it folds receiver configuration and a permissionless distributeFees() directly into the wrapper (S2 keeps all fee logic there, so no separate mixin), paying out exactly those tracked entitlements — nothing is re-split at distribution, so a later default-split change can never retroactively re-split already-earned fees.

• Payout in native denomination. distributeFees() first calls _accrueFees() (so pending management/performance fees crystallize even while deposits are paused — tested), then pays out each fee pool in its own token: the idle asset as the asset, the dilution shares as wrapper shares. No adapter touch, so the distribution can never be blocked by underlying illiquidity. LI.FI's booked parts go to the factory's live lifiFeeRecipient() (an integrator can never redirect it); the integrator's booked parts are fanned across its 1..N wallets (sanity-capped at 50) by their bps, with the last wallet absorbing the integer-division remainder so the pool zeroes exactly.
• Single distributeFees(), never blockable. Each integrator transfer uses OZ's non-reverting trySafeTransfer; a reverting wallet (e.g. a USDC-blacklisted address) has its share redirected to LI.FI in the same distribution instead of reverting. There is no separate LI.FI-only escape hatch — redirect makes one unnecessary. LI.FI's own transfer uses safeTransfer and is not caught (a blacklisted LI.FI recipient is LI.FI's own, factory-governed, concern).
• Receivers are mandatory. Set and validated at initialize via a typed FeeReceiver[] deploy param (1..N non-zero wallets, sanity-capped at 50, bps summing to exactly 100%); the setIntegratorFeeReceivers mutator (gated on vaultWrapperAdmin) re-validates, so an empty/unconfigured receiver set is structurally impossible — no griefing window where a permissionless distribution could divert unconfigured integrator fees.
• Storage & CEI. Receiver arrays are appended after S2's storage before a reduced __gap (uint256[46]); the subsystem is pre-release and the layout freezes before first deployment. distributeFees() zeroes all four counters before any transfer (CEI) and is nonReentrant. If a counter ever saturated (S2's uint128 clamp), the distribution pays the tracked amount — the excess stays in the wrapper rather than reverting anything.

Tests drive real accrual (deposit/withdraw + time warp through S2's engine), not seeded pools: payout equals the at-accrual tracked parts across both fee pools, 1..N-wallet fan-out with last-receiver remainder, the blacklist→redirect-to-LI.FI path, permissionless distribution, live-recipient reads, distribution-crystallizes-pending-management, distribution accrues and pays out while deposits are paused (the ticket behaviour previously deferred to S5, now in the base), zero-split books everything to LI.FI, and the init/mutator validation reverts.

/pr-ready (local CodeRabbit) findings

• Re-run against the S2 base after merging S2 (incl. S2b's per-fee-type split/performance fee and the S2 review fixes) into this branch and porting the distribution to the per-recipient counters (see the merge commit for the port details): no findings. One pre-existing lint gate crossing: the merged wrapper reaches 16 state declarations, over solhint's max-states-count — scoped disable with justification (single beacon-proxy storage host; mixins deliberately rejected).

Checklist before requesting a review

• I have performed a self-review of my code
• This pull request is as small as possible and only tackles one problem
• I have run /pr-ready (local CodeRabbit) on this branch and resolved (or explicitly documented) all findings — see .agents/commands/pr-ready.md
• I have added tests that cover the functionality / test the bug
• For new facets: I have checked all points from this list: https://www.notion.so/lifi/New-Facet-Contract-Checklist-157f0ff14ac78095a2b8f999d655622e
• I have updated any required documentation

Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)

• I have checked that any arbitrary calls to external contracts are validated and or restricted
• I have checked that any privileged calls (i.e. storage modifications) are validated and or restricted
• I have ensured that any new contracts have had AT A MINIMUM 1 preliminary audit conducted on by <company/auditor>

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: ab7126c6-4d9f-4a49-b8ba-2ea9120aa98f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Walkthrough

This PR adds configurable integrator receiver fan-out to LiFiVaultWrapper, extends initialization and factory deployment to accept receiver sets, adds permissionless sweep distribution with failure redirection, and updates the interface and tests to match the new receiver-based fee flow.

Changes

Integrator receivers and sweep distribution

Layer / File(s)	Summary
Receiver types and DeployParams src/VaultWrapper/LiFiVaultWrapperTypes.sol	Defines IntegratorReceivers and Receiver, and adds receivers to DeployParams.
Interface updates: events, errors, initialize signature src/VaultWrapper/interfaces/ILiFiVaultWrapper.sol, src/VaultWrapper/interfaces/ILiFiVaultWrapperFactory.sol	Updates VaultWrapperConfigured, adds receiver/sweep events and validation errors, changes initialize(...), and adds lifiFeeRecipient().
Wrapper initialization with receivers src/VaultWrapper/LiFiVaultWrapper.sol	Adds integratorReceivers storage, receiver-count cap, and initialization logic to store receiver splits.
setIntegratorReceivers and sweep distribution src/VaultWrapper/LiFiVaultWrapper.sol	Adds owner-only receiver updates, permissionless sweep(), and payout helpers that fan out integrator fees and redirect failed transfers.
Factory deploy wiring src/VaultWrapper/LiFiVaultWrapperFactory.sol	Passes receivers into wrapper initialization during deployment.
Shared test helpers for default receivers test/solidity/VaultWrapper/BeaconUpgrade.t.sol, test/solidity/VaultWrapper/LiFiVaultWrapper.t.sol, test/solidity/VaultWrapper/LiFiVaultWrapperFactory.t.sol, test/solidity/VaultWrapper/VaultWrapperFeeTestBase.sol, test/solidity/VaultWrapper/VaultWrapperPause.t.sol	Adds receiver helpers and wires IntegratorReceivers through existing initialize/deploy test paths.
Distribution and sweep test suite test/solidity/VaultWrapper/VaultWrapperDistribution.t.sol	Adds receiver validation, sweep splitting, fan-out, redirect-on-failure, and pause/live-recipient coverage.

Estimated code review effort: 4 (Complex) | ~60 minutes

Possibly related PRs

• lifinance/contracts#1936: Shares the LiFiVaultWrapperFactory → initialize(...) deployment wiring path that this PR extends with receivers.

Suggested labels: AuditRequired

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly names the EXSC-411 fee receiver and sweep distribution work and matches the main change.
Description check	✅ Passed	The description follows the template sections and provides the task link, implementation rationale, and review checklist with enough detail.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/exsc-411-s3-fee-receivers-sweep-distribution

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[lifi-qa-agent]

🔍 QA Review — EXSC-411 / PR #1983

Ticket: EXSC-411 — S3 Fee Receivers & Sweep Distribution
PR: #1983 feat(EXSC-411): S3 — fee receivers & sweep distribution
Branch: feature/exsc-411-s3-fee-receivers-sweep-distribution → dev-vault-wrapper
Date: 2026-07-13 | Review type: 🔁 Re-review (cycle 4 — 5 new commits since last review 2026-07-10)

ℹ️ This is cycle 4. Previous cycles: first review (2026-07-07) identified FIND-01–06; cycle 2 (2026-07-10, 06:55 UTC) identified NEW-01 and NEW-02; cycle 3 (2026-07-10, 16:58 UTC) reviewed the S2-rebase commits (FeeReceiver rename, parallel-array collapse, distributeFees rename). This cycle covers 5 new commits pushed after 2026-07-10T16:58 UTC.

---

New commits reviewed (post last QA comment 2026-07-10T16:58:47Z)

Commit	Date	Description
97481f117559	2026-07-13T06:47Z	Merge from S2 branch (LiFiVaultWrapper.sol, ILiFiVaultWrapper.sol conflicts)
59ba1cbf1e00	2026-07-13T06:51Z	Merge from dev-vault-wrapper (8-file conflict set)
00d234d96d48	2026-07-13T07:39Z	docs: NatSpec + test_SetReceiversThenDistributeUsesNewReceivers (FIND-01)
0ad36e5a6d82	2026-07-13T07:40Z	test: 50-receiver upper boundary acceptance case (FIND-02)
6888fce10a6d	2026-07-13T07:41Z	test: zero-share receiver skip coverage (FIND-03)

---

Analysis of new commits

Merge commits (97481f, 59ba1c): Two sequential base-branch merges resolved conflicts in LiFiVaultWrapper.sol, ILiFiVaultWrapper.sol, ILiFiVaultWrapperFactory.sol, and five test files. The resolved code is structurally clean — no conflict markers, consistent naming, correct import graph. The MAX_FEE_RECEIVERS constant now carries a clear NatSpec explaining it is a gas-safety cap, not a product limit (see NEW-01 below). Storage layout post-merge: 14 declared state variables + uint256[50] gap (note: PR description stated uint256[46] — this may reflect a gap recomputation during the merge; the important invariant is that the reserved pool is large enough for future extension, not the exact number).

FIND-01 commit (00d234): setIntegratorFeeReceivers now carries a @dev block that explicitly states: "Accrued-but-not-yet-distributed integrator fees are held as a single total with no per-wallet bookkeeping, so they will be paid to the NEW receiver set at the next distributeFees, not the outgoing one. Call distributeFees before rotating receivers if the outgoing wallets should receive their earned share." The accompanying test_SetReceiversThenDistributeUsesNewReceivers accrues a deposit fee, rotates receivers, calls distributeFees, and asserts the new receiver receives the full integrator part while the old receiver receives nothing. ✅ Correct implementation and test.

FIND-02 commit (0ad36e): test_SetIntegratorFeeReceiversAccepts50Wallets constructs 50 FeeReceiver entries each with 200 bps (50×200 = 10,000), calls setIntegratorFeeReceivers, and asserts slot 49 is populated and slot 50 reverts. ✅ Guards the off-by-one boundary correctly.

FIND-03 commit (6888fc): test_DistributeFeesSkipsZeroShareReceiver deploys with a 1-bps / 9999-bps receiver pair and a deposit of 200,000 wei (integrator fee ≈ 1,584 wei, confirming assertLt(integratorPart, 10_000)). The 1-bps share floors to 0 and is skipped; the 9999-bps last receiver absorbs the full integrator total. ✅ Verifies if (share == 0) continue and the remainder mechanic together.

---

Updated status of all prior findings

#	Finding	Severity	Status
FIND-01	NatSpec + test for receiver-mutation semantics	Medium	✅ Resolved
FIND-02	50-wallet boundary acceptance test	Low	✅ Resolved
FIND-03	Zero-share receiver skip test	Low	✅ Resolved
FIND-04	Confirm requires-types label triggers type-package update	Low	❌ Still open — label present, no linked PR
FIND-05	Dismiss Olympix alerts with beacon proxy rationale	Info	⚠️ Reopened — new alert at LiFiVaultWrapper.sol:123 after merge
FIND-06	_defaultReceivers() helper duplication across test files	Info	⚠️ Still open (deferred)
NEW-01	MAX_FEE_RECEIVERS = 50 product decision documentation	High (demoted)	⚠️ Partially addressed — contract NatSpec is clear; Linear ticket description not updated
NEW-02	Legal/compliance sign-off for redirect-to-LI.FI on failed transfers	Medium	❌ Still open — no sign-off documented

---

Detail on remaining open items

NEW-02 — Redirect of failed ERC-20 transfers to lifiFeeRecipient — compliance sign-off required [Medium]

File: src/VaultWrapper/LiFiVaultWrapper.sol, _payIntegrators (lines 979–1012)

When trySafeTransfer fails for an integrator wallet (e.g. a USDC-blacklisted or OFAC-sanctioned address), the failed share is accumulated in redirected and transferred to lifiFeeRecipient — LI.FI's own fee recipient:

// instead we redirect the failed transfer amount to lifi
redirected += share;
emit IntegratorPayoutRedirected(wallet, _token, share);

The developer confirmed on 2026-07-10 that this behaviour is left as-is pending explicit legal sign-off with Alessandro. No sign-off has been documented in the PR or on the Linear ticket as of this review.

Risk: LI.FI receiving funds earmarked for a potentially sanctioned/blacklisted wallet may create OFAC or similar regulatory reporting obligations depending on jurisdiction. This is a pre-deployment concern — once deployed and generating fees, this scenario can occur in production.

Required before merge: Document legal/compliance sign-off in the PR description or as a Linear ticket comment from the relevant authority (Alessandro or legal team). If sign-off is not forthcoming, the design must be changed: options are (a) escrow contract as redirect target instead of lifiFeeRecipient, or (b) silent skip (no redirect, the failed share stays unbooked). Either alternative removes the compliance exposure.

---

FIND-04 — requires-types label confirmation [Low]

The PR retains the requires-types label, indicating a dependent type-package update is expected. No linked PR or comment confirming the type-package update has been posted.

Required: Post a comment confirming the requires-types action has been tracked (e.g., link to the type-package PR or note that no off-chain consumer currently indexes VaultWrapperConfigured in the updated form). This is a non-blocking housekeeping item but should not be forgotten.

---

NEW-01 — Linear ticket description update [Low — partially addressed]

Code level: ✅ The contract now documents MAX_FEE_RECEIVERS = 50 as "only a sanity cap to bound the permissionless distributeFees fan-out loop and prevent griefing... not a product limit" — this is the audit-facing record and satisfies the core requirement.

Process level: ⚠️ The Linear ticket description (EXSC-411) still reads "1..5 receiver wallets with individual bps". Update the ticket description (or post a comment from the ticket owner) to reflect that the protocol-level cap is 50 and the 1-5 range is an integrator-onboarding convention. This prevents the discrepancy from confusing future reviewers or auditors who compare the ticket to the code.

---

FIND-05 — Reopened Olympix alert at LiFiVaultWrapper.sol:123 [Informational]

The merge commits triggered a new Olympix scanner alert on the integratorFeeReceivers dynamic array at line 123, flagged as "uninitialized state variable." The same beacon proxy justification applies as to the previously dismissed alerts: this variable is initialized write-once in initialize(), the factory deploys and initializes atomically, and _disableInitializers() in the constructor ensures the implementation is never used uninitialised directly. Dismiss with the standard CWIA/beacon proxy rationale.

---

FIND-06 — _defaultReceivers() helper duplication [Informational — deferred]

The _defaultReceivers() helper remains duplicated across LiFiVaultWrapper.t.sol, VaultWrapperPause.t.sol (×2), BeaconUpgrade.t.sol, and LiFiVaultWrapperFactory.t.sol. The shared _receivers(wallets, bps) helper in VaultWrapperDistribution.t.sol is a step in the right direction but has not been adopted by the other files. Remains deferrable to a housekeeping follow-up.

---

⚠️ Verdict: Needs Work

Significant progress this cycle: FIND-01, FIND-02, and FIND-03 are all resolved — the test coverage gaps flagged in the first review are closed. The production logic remains correct.

Remaining blockers:

1. NEW-02 (Medium): Legal/compliance sign-off for redirect-to-LI.FI of failed integrator transfers — must be documented before merge
2. FIND-04 (Low): Confirm/link the requires-types type-package update

Process items (non-blocking but should be done before merge):

• NEW-01 (Low): Update the Linear ticket description to reflect MAX_FEE_RECEIVERS = 50 cap
• FIND-05 (Info): Dismiss the reopened Olympix alert at line 123 with beacon proxy rationale

Deferred:

• FIND-06: _defaultReceivers() duplication

💡 Once you've addressed the items above, re-apply the "Agent Review Request" label to trigger an automated re-review.

---

QA re-review (cycle 4) by: QA AI Agent (lifi-qa-agent[bot]) — 2026-07-13 | Ticket: EXSC-411 | PR: #1983

[lifi-qa-agent]

Requesting changes on 5 items — each requires either a code fix or an explicit acceptance comment with justification before this review is considered complete.

#	Severity	Type	Issue / File
1	🔴 High	Design	MAX_FEE_RECEIVERS = 50 product decision must be formally documented (not just Slack)
2	🟠 Medium	Compliance	Legal/compliance sign-off required for redirect of failed ERC-20 transfers to lifiFeeRecipient
3	🟠 Medium	Test gap	test/solidity/VaultWrapper/VaultWrapperDistribution.t.sol (NatSpec + test for receiver-mutation semantics)
4	🟢 Low	Test gap	test/solidity/VaultWrapper/VaultWrapperDistribution.t.sol (50-wallet boundary acceptance test)
5	🟢 Low	Test gap	test/solidity/VaultWrapper/VaultWrapperDistribution.t.sol (zero-share receiver skip test)

1. [High] Formally document MAX_FEE_RECEIVERS = 50 product decision
The ticket specifies "1..5 receiver wallets" and a developer inline comment in the code itself asks "shouldn't this be 5 according to our requirements?". The developer confirmed via Slack that Alessandro approved N wallets — this verbal sign-off needs to be recorded formally. Required: (a) a comment on the Linear ticket from the ticket owner confirming 50 is the intended product limit, and (b) an inline @dev comment in the contract explaining the design rationale (e.g., "50 is a gas-safety cap; the product-level default is enforced by integrator onboarding, not the protocol").

2. [Medium] Legal/compliance sign-off for LI.FI receiving redirected failed transfers
When trySafeTransfer fails for an integrator wallet (e.g., USDC blacklist, OFAC-sanctioned address), the failed amount is redirected to lifiFeeRecipient — LI.FI's own fee recipient. Depending on jurisdiction, LI.FI receiving funds earmarked for a sanctioned wallet may create reporting obligations or compliance exposure. The developer has acknowledged this and is raising it with Alessandro. Before merge: legal sign-off must be documented in the PR or Linear ticket, OR the design must change (escrow contract or silent skip). No code merge without this sign-off.

**3. [Medium] Test gap — VaultWrapperDistribution.t.sol (NatSpec + test for receiver-mutation semantics)

• Missing @dev NatSpec on setIntegratorFeeReceivers stating: "Accrued but not yet distributed fees will be paid to the new receiver set. Call distributeFees() before calling this function if you want the outgoing receivers to receive already-earned fees."
• Missing: test_SetReceiversThenDistributeUsesNewReceivers — exercise the scenario: accrue fees, call setIntegratorFeeReceivers, call distributeFees(), assert fees go to the new receivers.

**4. [Low] Test gap — VaultWrapperDistribution.t.sol (50-wallet boundary acceptance)

• Missing: test_SetIntegratorFeeReceiversAccepts50Wallets — construct exactly 50 FeeReceiver entries summing to 10,000 bps and assert the call succeeds. The 51-wallet rejection is already tested; the 50-wallet acceptance must also be explicit to guard against off-by-one regression.

**5. [Low] Test gap — VaultWrapperDistribution.t.sol (zero-share receiver skip)

• Missing: test_DistributeFeesSkipsZeroShareReceiver — configure a 1-bps receiver with a fee amount so small that share == 0, confirm the receiver gets nothing, and confirm total distributed remains correct (no stranded funds).

💡 Once you've addressed the items above, re-apply the "Agent Review Request" label to trigger an automated re-review.

[gvladika]

Thanks — responses to the cycle-3 review, item by item.

1. [High] MAX_FEE_RECEIVERS = 50 — intentional.
50 is a gas-safety sanity cap on the permissionless distributeFees fan-out loop, not a product limit — this is already documented inline at LiFiVaultWrapper.sol:65-68. Alessandro approved N wallets (Slack, 2026-07-10). No code change; the product-limit decision is tracked on the Linear ticket, not enforced on-chain.

2. [Medium] Redirect of failed transfers to lifiFeeRecipient — intentional, pending legal.
The non-reverting trySafeTransfer + redirect-to-LI.FI design is deliberate: it guarantees one hostile/blacklisted integrator wallet can never block the whole distribution. We're keeping it as-is pending explicit legal/compliance sign-off; if legal isn't comfortable, the fallback is a dedicated escrow target or a silent skip. This stays open until legal responds — no code change now.

3. [Medium] Receiver-rotation semantics — done.
NatSpec added to setIntegratorFeeReceivers documenting that accrued-but-undistributed fees follow the new receiver set (single-total accounting, no per-wallet bookkeeping), plus test_SetReceiversThenDistributeUsesNewReceivers.
→ 00d234d

4. [Low] 50-wallet acceptance test — done.
test_SetIntegratorFeeReceiversAccepts50Wallets — 50 receivers summing to 10_000 bps, asserts success and exactly-50 storage.
→ 0ad36e5

5. [Low] Zero-share skip test — done.
test_DistributeFeesSkipsZeroShareReceiver — a 1-bps receiver on a tiny fee pool whose share floors to 0, asserting it's skipped and the last receiver absorbs the whole integrator total (no stranded funds).
→ 6888fce

FIND-04 (requires-types) and FIND-06 (dedup _defaultReceivers) — FIND-06 is already resolved (no local _defaultReceivers remain; all suites use the shared defaultReceivers() helper). FIND-05 (Olympix) confirmed resolved in your last pass.

Full VaultWrapper suite: 232 passing.

[lifi-qa-agent]

Requesting changes on 4 items — each requires either a code fix or an explicit acceptance comment with justification before this review is considered complete.

#	Severity	Type	Issue / File
1	🟠 Medium	Compliance	Legal/compliance sign-off required for redirect of failed ERC-20 transfers to lifiFeeRecipient (NEW-02)
2	🟢 Low	Process	Confirm requires-types label tracks a type-package update — link PR or document no-op (FIND-04)
3	🟢 Low	Process	Update Linear ticket EXSC-411 description to reflect MAX_FEE_RECEIVERS = 50 cap (not "1..5 wallets") (NEW-01)
4	🟢 Low	Process	Dismiss reopened Olympix alert on LiFiVaultWrapper.sol:123 (integratorFeeReceivers) with beacon proxy rationale (FIND-05)

1. [Medium] Legal/compliance sign-off for redirect-to-LI.FI of failed integrator transfers
When trySafeTransfer fails for an integrator wallet (blacklisted/sanctioned address), the failed share is redirected to lifiFeeRecipient — LI.FI's own fee recipient. Depending on jurisdiction, LI.FI receiving funds earmarked for a sanctioned wallet may trigger OFAC or similar reporting obligations. The developer confirmed on 2026-07-10 this is pending explicit sign-off with Alessandro. Required: document legal/compliance sign-off in the PR or Linear ticket before merge. If sign-off is not forthcoming, options are: (a) redirect to a dedicated escrow contract instead of lifiFeeRecipient, or (b) silent skip with no redirect.

2. [Low] Confirm requires-types triggers type-package update
The requires-types label remains on the PR. The VaultWrapperConfigured event signature changed (removed factory and integratorShareBps fields). Any off-chain consumer built against the previous signature will fail to decode events from S3-deployed wrappers. Post a comment confirming the type-package PR is tracked (or that no consumer currently indexes this event, making this a no-op).

3. [Low] Update Linear ticket EXSC-411 description
The ticket description states "1..5 receiver wallets" — the code implements MAX_FEE_RECEIVERS = 50 with inline NatSpec clarifying it is a gas-safety cap, not a product limit. Update the ticket description or post a comment from the ticket owner formally recording that 50 is the protocol-level cap and 1–5 is an integrator-onboarding convention. This prevents future auditor/reviewer confusion when comparing ticket to code.

4. [Low] Dismiss reopened Olympix alert at LiFiVaultWrapper.sol:123
The merge commits triggered a new Olympix scanner alert on the integratorFeeReceivers dynamic array (line 123), flagged as "uninitialized state variable." The beacon proxy justification from the previously dismissed alerts applies: the variable is initialized write-once in initialize(), the factory deploys and initializes atomically, and _disableInitializers() in the constructor prevents the implementation itself from being left uninitialized. Dismiss with the standard CWIA/beacon proxy rationale.

💡 Once you've addressed the items above, re-apply the "Agent Review Request" label to trigger an automated re-review.