feat(EXSC-423): integrate Vault Wrapper V1 subsystem [LiFiVaultWrapper v1.0.0, LiFiVaultWrapperFactory v1.0.0, LiFiVaultWrapperTypes v1.0.0, ReferenceAccessGate v1.0.0, ERC4626Adapter v1.0.0, IAccessGate v1.0.0, ILiFiVaultWrapper v1.0.0, ILiFiVaultWrapperFactory v1.0.0, IYieldAdapter v1.0.0, LibVaultWrapperMath v1.0.0]

[gvladika]

Which Linear task belongs to this PR?

Ref EXSC-423 — S15, Security review & audit support (the audited slice; ticket stays open through audit engagement, so this does not auto-close it).

Why did I implement it this way?

This is the integration PR that lands the assembled LI.FI Earn Vault Wrapper V1 subsystem (src/VaultWrapper/) on main, opened as one reviewable diff ahead of the external audit rather than re-deriving it from the individual S1–S14 sub-PRs.

The Vault Wrapper is a standalone product per [CONV:ARCH-VAULTWRAPPER] — not a facet, not periphery, not called by the Diamond, with no diamondCut or shared selector/storage involvement. A factory deploys per-integrator ERC-4626 vaults as deterministic beacon proxies; each wraps a governance-curated yield source through a pluggable adapter and takes a four-type fee split between the integrator and LI.FI. It has its own governance (a dedicated 48h timelock, an emergency pauser, and an onboarding manager).

Share metadata: symbol() is lf<assetSymbol> and name() also names the yield source, e.g. LI.FI Earn USDC via sparkUSDC, so wrappers over the same asset but different underlyings are distinguishable in wallets (EXSC-1090). The via … suffix is omitted when the underlying exposes no readable symbol; the asset symbol falls back to VW.

For the full picture — architecture, contract set, roles and governance, fee model, trust assumptions, and system invariants — see the subsystem overview and the per-contract docs:

• docs/VaultWrapper/README.md — start here.
• LiFiVaultWrapper · LiFiVaultWrapperFactory · ERC4626Adapter

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 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>

[lifi-qa-agent]

Requesting changes on 3 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	Security	setIntegratorFeeReceivers missing nonReentrant — can be called from yield source hook mid-distribution
2	🟠 Medium	Deploy script	DeployLiFiVaultWrapperFactory.s.sol missing FACTORY binding assertion after deployment
3	🟢 Low	Test gap	LiFiVaultWrapper.t.sol (or fees test) — missing dust-deposit test case

1. [Medium] setIntegratorFeeReceivers missing nonReentrant

All four ERC-4626 entry/exit functions (deposit, mint, withdraw, redeem), distributeFees, and setFeeRate are correctly nonReentrant. However, setIntegratorFeeReceivers (owner-only) is not. The _deposit implementation calls super._deposit first (pull + mint), then _routeFee (fee booking), then _routeThroughAdapter (external delegatecall to yield source). If the yield source's deposit hook calls back to setIntegratorFeeReceivers — possible when the integrator uses the same EOA as both admin and fee receiver — it could redirect pending fee receivers mid-distribution before the current fee routing completes.

Requested action: Add nonReentrant to setIntegratorFeeReceivers (consistent with the existing setFeeRate NatSpec rationale). If the integrator trust model explicitly makes this acceptable, an acceptance comment explaining why is sufficient.

2. [Medium] DeployLiFiVaultWrapperFactory.s.sol — no FACTORY binding assertion

LiFiVaultWrapper binds FACTORY as an immutable in the constructor. All existing proxies enforce this correctly via the initialize factory-only check. However, when the beacon's upgradeTo deploys a new implementation, nothing mechanically verifies that the new implementation's FACTORY matches the live factory proxy address. A misconfigured implementation (wrong factory, address(0)) would silently propagate to all proxy instances.

The deploy script already performs wiring checks (via WiringMismatch-style assertions) — this is a gap in that existing check set.

Requested action: Add to the post-deploy wiring verification in DeployLiFiVaultWrapperFactory.s.sol:

require(address(impl.FACTORY()) == predictedFactoryProxyAddress, "FACTORY binding mismatch");

Or accept with an explicit comment explaining why the 48h timelock observation window is a sufficient substitute.

3. [Low] Test gap — LiFiVaultWrapper.t.sol (new case)

• Missing: explicit test for dust deposit at feeBounds.maxBps fee where invested == 0 (e.g. deposit(1 wei, receiver) at 20% fee → succeeds, 0 shares minted, depositor loses 1 wei to fee pool). The behavior is intentional per spec, but there is no test asserting it succeeds (rather than reverts) and no test documenting that previewDeposit(1 wei) correctly returns 0 in this scenario.

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

[reednaa]

The codebase is compact and consise. It is a well written defensible implementation.

I could not find any issues with the code. Total report is 1 INFO with a couple GAS.

Review session consisted of 2 sets of 2 hours. Tools used: solidity-test-overhaul, weird ERC20 tokens, and manual review.

Ideally I want to give it another 2 sets of 2 hours but I will not be able to make it in time. Apologies for being too late.

[lifi-qa-agent]

🔁 QA Re-Review — EXSC-423 — Vault Wrapper V1 (Post-Approval Commit Review)

PR: #2092 | Ticket: EXSC-423 | Reviewer: QA AI | Date: 2026-09-03

⚠️ Post-approval re-review: Commit 1de5ee67ffe9 was pushed at 10:11Z after the Round 3 approval (07:50Z), causing GitHub to auto-dismiss the approval. This review analyses only the new commit.

---

Post-Approval Commit — 1de5ee67ffe9

Commit message: perf(VaultWrapper): give the rounding remainder to the first receiver

Summary: _payIntegrators is refactored a second time, following reednaa's suggestion at 08:24Z on the PR. The loop direction is reversed: instead of looping i=0..count-2 and paying the last receiver (index lastIndex) the remainder outside the loop, the loop now runs i=1..count-1 and pays the first receiver (index 0) the remainder outside the loop.

---

Logic verification

Before (fb31b9e): Loop i=0..count-2; last receiver integratorFeeReceivers[lastIndex] gets remainder.

After (1de5ee6): Loop i=1..count-1; first receiver integratorFeeReceivers[0] gets remainder.

Function body (current HEAD):

function _payIntegrators(address _token, uint256 _integratorTotal) private returns (uint256 retained) {
    uint256 count = integratorFeeReceivers.length;
    uint256 distributed;

    // every receiver but the first gets its bps share, rounded down
    for (uint256 i = 1; i < count; ++i) {
        FeeReceiver memory receiver = integratorFeeReceivers[i];
        uint256 share = _integratorTotal.mulDiv(receiver.bps, LibVaultWrapperMath.BASIS_POINT_SCALE);
        distributed += share;
        if (share == 0) continue;
        address wallet = receiver.wallet;
        if (SafeERC20.trySafeTransfer(IERC20(_token), wallet, share)) { continue; }
        retained += share;
        emit IntegratorPayoutRetained(wallet, _token, share);
    }

    // the first receiver takes the whole remainder to avoid rounding dust
    uint256 firstShare = _integratorTotal - distributed;
    if (firstShare == 0) return retained;
    address firstWallet = integratorFeeReceivers[0].wallet;
    if (SafeERC20.trySafeTransfer(IERC20(_token), firstWallet, firstShare)) { return retained; }
    retained += firstShare;
    emit IntegratorPayoutRetained(firstWallet, _token, firstShare);
}

Case analysis:

Case	Behavior	Correct?
count = 1	Loop runs 0 times (i=1, not < 1). distributed=0. firstShare = _integratorTotal. First receiver gets everything.	✅
count > 1	Receivers i=1..count-1 get proportional mulDiv shares (rounded down). First receiver gets remainder.	✅
firstShare = 0	Early return — avoids SLOAD of integratorFeeReceivers[0].wallet.	✅
Failed transfer (receiver i>0)	retained += share, emit. Loop continues.	✅
Failed transfer (receiver 0)	retained += firstShare, emit.	✅

Underflow safety: firstShare = _integratorTotal - distributed

_setIntegratorFeeReceivers enforces sum(bps) == BASIS_POINT_SCALE (= 10000). Since mulDiv rounds down:

share_i = ⌊_integratorTotal × bps_i / 10000⌋ ≤ _integratorTotal × bps_i / 10000
distributed = Σ share_i (i=1..count-1) ≤ _integratorTotal × Σbps_i(i>0) / 10000
             ≤ _integratorTotal × (10000 - bps_0) / 10000 ≤ _integratorTotal

No underflow is possible. Solidity 0.8's checked arithmetic is a backstop, not a crutch here. ✅

Gas savings (per reednaa's analysis):

• Eliminates lastIndex = count - 1 stack variable
• integratorFeeReceivers[0].wallet uses PUSH0 vs. a stack-allocated index — saves ~1 safe-sub operation
• Equivalent to fb31b9e75883 in correctness, slightly more efficient in EVM execution

NatSpec: Updated to "the first wallet absorbing the integer-division remainder so the portion zeroes exactly" — accurate. ✅

No new findings. The change is a pure gas optimization with correct math. All prior Round 1–3 findings remain fully resolved.

---

Verdict

✅ Pass — Commit 1de5ee67ffe9 is a correct, safe gas optimization. The remainder-to-first-receiver approach is mathematically equivalent to the remainder-to-last approach (the _setIntegratorFeeReceivers bps-sum invariant guarantees no underflow). Re-approval submitted.

QA AI — SmartContract team review | EXSC-423 | PR #2092 | Post-approval re-review — 2026-09-03

[lifi-qa-agent]

🔶 QA AI Needs Work — F-01 remains open: setIntegratorFeeReceivers missing nonReentrant guard or NatSpec documentation of the reentrancy acceptance reasoning. F-02 (FACTORY assertion) ✅ and F-03 (dust deposit test) ✅ are resolved. Full re-review posted as PR comment. One documentation-only change unblocks approval.

[gvladika]

F-02 and F-03 confirmed resolved. On F-01: two corrections, then why no change is needed.

The quoted developer response isn't about this finding. "~260–400 gas at realistic receiver counts" comes from this comment on @reednaa's unchecked-in-_payIntegrators thread. F-01 had no response until now.

That figure can't apply here anyway. This contract uses OZ v5's core ReentrancyGuard on an ERC-7201 slot (LiFiVaultWrapper.sol:9 and :61). Guard entry is a cold SLOAD plus a zero→non-zero SSTORE — on the order of 24k gas, not ~300. Adding the suggested NatSpec verbatim would have put a wrong figure in the contract right before audit.

Why nonReentrant isn't needed. The stated route — a yield-source hook calling back into setIntegratorFeeReceivers — cannot pass onlyOwner. A callback arrives with msg.sender set to the source vault or the fee token, not the owner. Round 1's variant ("integrator uses the same EOA as both admin and receiver") is not reachable either: an EOA executes no callback.

If the owner were the callback contract, there is still nothing to take. _payIntegrators fans out only the integrator's own portion and never reads or writes lifiFeeAssets/lifiFeeShares, so a rotation moves the integrator's money between the integrator's own wallets — which the owner can already do by direct call at any time. And if that rotation shrinks the set mid-distributeFees, the index cached before the loop reads out of bounds and panics, reverting the whole call rather than mispaying it. Worst case is an owner-inflicted revert: no fund loss, no state corruption.

No NatSpec added, deliberately. This thread is the record for the auditor. setFeeRate carries a nonReentrant note because there the guard is load-bearing — it is the only _accrueFees caller outside the entry/exit/distributeFees guard, so a payout hook could otherwise book fees that the in-flight distributeFees then erases. That note is not a template for documenting every setter that lacks a guard it doesn't need.

Re-triggering the review.

[lifi-qa-agent]

✅ QA Pass (Round 3) — All three findings resolved: F-01 accepted with full technical justification (onlyOwner blocks all reentrancy paths); F-02 fixed (FACTORY binding assertion in PR #2296); F-03 fixed (dust-deposit test added). New commit fb31b9e (_payIntegrators loop refactoring) reviewed and safe.

[lifi-qa-agent]

✅ QA AI Approved (re-approval) — EXSC-423 post-approval commit 1de5ee6: _payIntegrators remainder-to-first-receiver refactor verified correct. bps-sum invariant prevents underflow. Round 3 pass verdict stands.

[lifi-qa-agent]

🔍 QA Review — EXSC-423

🔗 Linear Ticket · Pull Request #2092

⚠️ New commits pushed after last approval — re-analysing post-approval changes.

Review type: 🔁 Re-review (post-approval)
Baseline: QA Pass at Run #128, SHA a90554a27565 (approval 5269138237, now dismissed)
Current head: d51522f823d8
Post-approval commits: 1. d51522f823d8 (2026-09-24T12:39:56Z) feat(VaultWrapper): name the yield source in the share name (EXSC-1090). Signed and verified.

🧠 What this ticket does

EXSC-423 brings the whole Vault Wrapper V1 subsystem to main for audit. The new commit fixes a naming problem. Before it, two wrappers over the same asset but different yield sources both returned the same name() (for example "LI.FI Earn USDC"). Now name() adds the underlying vault's symbol ("LI.FI Earn USDC via sparkUSDC"). If the underlying has no readable symbol, the suffix is left off. symbol() does not change (lf<asset>, falling back to lfVW).

⚠️ Verdict: Needs Work: The contract change is correct and safe. But the PR conflicts with main, so no pull_request CI ran on the new head: no forge unit tests, audit verification or signed-commit gate. The new and changed name assertions have never been run in CI. There are also two Low items.

---

📋 Ticket Summary

S15 — Security review & audit support
This is the umbrella PR that integrates Vault Wrapper V1 for security review and audit. Acceptance criteria were assessed in earlier rounds (three prior QA passes). This re-review covers only the delta since a90554a.

Acceptance Criteria (delta scope):

1. Wrapper share metadata stays correct and non-reverting for any allowlisted underlying: ✅ Met
   • Evidence: src/VaultWrapper/LiFiVaultWrapper.sol:268-282 reads both symbols through Solady MetadataReaderLib.readSymbol, which never reverts.
2. Wrappers over the same asset with different yield sources can be told apart: ✅ Met
   • Evidence: test_NameDistinguishesYieldSourcesOverSameAsset (LiFiVaultWrapper.t.sol:351)

---

Post-Approval Commit Analysis: d51522f823d8

Share name construction (_initErc4626Metadata)

• Untrusted metadata: underlying.readSymbol() uses Solady MetadataReaderLib at the pinned submodule 678c916. That call uses a 100,000-gas stipend (GAS_STIPEND_NO_GRIEF) and cuts results at 1000 bytes (STRING_LIMIT_DEFAULT). If the call reverts, returns nothing, returns an empty string or hits an EOA, the result is "". It also handles bytes32 symbols (MKR-style). A malicious or broken symbol() therefore cannot revert initialize or burn unlimited gas. ✅
• Worst-case size: the name is at most about 11 + 1000 + 5 + 1000 bytes, roughly 64 storage slots, a one-off cost of about 1.3M gas at deploy. Underlyings must also pass the governance-owned allowedUnderlying allowlist in the factory, as the inline comment says. Acceptable. ✅
• Empty strings: an empty underlying symbol drops the suffix. An empty asset symbol falls back to VW for both name and symbol. ✅
• Ordering: _initErc4626Metadata reads underlying from storage. It is assigned at LiFiVaultWrapper.sol:219, before the call at :232. The NatSpec now documents this dependency. ✅
• Immutability: the name and symbol are written once by __ERC20_init under initializer/onlyInitializing. No setter exists. ✅
• Storage layout: unchanged. OZ ERC20 already stores the name as a string in its namespaced (ERC-7201) storage, and no new state variables were added. ✅
• Deterministic address / salt: the factory _salt(namespace, adapter, underlying, nonce) and _proxyInitCode() do not depend on the name or symbol, so CREATE2 addresses do not change. ✅
• ABI / types: no signature changes. The requires-types regeneration is not affected. ✅
• Other name assertions: BeaconUpgrade.t.sol:107 still expects "LI.FI Earn AST". That is still correct because its MockERC4626Underlying has no symbol(), so the suffix is dropped. No scripts or TS tooling assert wrapper names. ✅
• NatSpec: the initialize @dev and the _initErc4626Metadata @dev are updated and accurate. ✅

Other checks: no inline review comments since 2026-09-21T16:24Z. The only issue comment in that window is the prior QA pass. CodeRabbit review is paused.

---

🏷️ PR Naming — ✅ Pass

feat(EXSC-423): integrate Vault Wrapper V1 subsystem [LiFiVaultWrapper v1.0.0, …]

🔎 Ticket Discoverability — ✅ Pass

EXSC-423 is in the title and the branch context. The new commit cites EXSC-1090, a follow-up ticket landing on this umbrella branch. That is fine as long as EXSC-1090 is linked to EXSC-423 in Linear.

🛡️ Version & Audit State

Contract	Version	Bumped in PR	Audit log entry	PR labels
LiFiVaultWrapper	v1.0.0	n-a (new, unaudited contract; post-approval logic change stays within v1.0.0)	⏳ pending (no auditedContracts.LiFiVaultWrapper entry in audit/auditLog.json)	AuditRequired

ℹ️ The audit is still pending for LiFiVaultWrapper v1.0.0. This commit changes in-scope audit code (initialize metadata path), so the auditor's commit pin must be at or after d51522f, or this delta must be sent to the auditor explicitly. AuditRequired correctly continues to block merge.

---

✅ Ticket Coverage — High

The delta does what it says, is small and well-contained, and comes with happy-path tests plus both "no symbol" fallback tests.

---

⚠️ Issues Found (3)

#	Severity	Type	Issue
1	🟡 Medium	CI / Process	🆕 PR conflicts with main, so no forge unit tests (or other pull_request gates) ran on head d51522f
2	🟢 Low	Test gap	🆕 No test for oversized or bytes32 underlying symbols (truncation / gas-stipend path)
3	🟢 Low	Code quality	🆕 New helper _deployWrapperOver duplicates the existing _newWrapper

🟡 [Medium] 🆕 PR conflicts with main, so the new tests have never run in CI
gh pr view reports mergeable: CONFLICTING. The branch is 147 commits ahead of and 115 behind main. GitHub does not run pull_request workflows while a PR has merge conflicts. The only check runs on d51522f are CodeQL, Aikido and check-secrets. The previously approved head a90554a had run-unit-tests (gas/misc/facets/libraries/periphery), unit-tests-required, signed-commits-required, audit-verification, solc-floor-build, deploy-smoke-test and others. As a result, the three new/rewritten tests (test_NameAndSymbolFallBackWhenAssetHasNoSymbol, test_NameDistinguishesYieldSourcesOverSameAsset, test_NameOmitsYieldSourceWhenUnderlyingHasNoSymbol) and the two updated name() assertions (LiFiVaultWrapper.t.sol:178, :332) are unverified. My static reading says they should pass, but that does not replace a green run.
Suggestion: merge or rebase main into dev-vault-wrapper, resolve the conflicts, and confirm unit-tests-required and the other required checks are green on the new head. Rebasing also changes the base of stacked PR #2417 (see Downstream).

🟢 [Low] 🆕 No test for oversized or bytes32 underlying symbols
The two failure modes that matter most for a third-party string are not pinned by a test: a very long symbol() (the 1000-byte truncation and 100k gas stipend) and a bytes32-returning symbol(). Both are handled correctly today by Solady. A test would catch a future switch to a plain IERC20Metadata(underlying).symbol() call, or a change to the readSymbol overload/limits.
Suggestion: add one mock underlying whose symbol() returns a string longer than 1000 bytes (or loops and burns gas). Assert that initialize succeeds and that bytes(name()).length is bounded. Optionally add a bytes32-returning mock.

🟢 [Low] 🆕 _deployWrapperOver duplicates _newWrapper
test/solidity/VaultWrapper/LiFiVaultWrapper.t.sol:653-674 (_deployWrapperOver) is identical to the existing _newWrapper(address) at :676-695, which already has 6 call sites.
Suggestion: delete _deployWrapperOver and call _newWrapper in the three new tests.

---

🧪 Test Coverage

Layer	Score	Files reviewed
Foundry unit/integration	Good (unverified in CI; see #1)	test/solidity/VaultWrapper/LiFiVaultWrapper.t.sol, test/solidity/VaultWrapper/BeaconUpgrade.t.sol (name assertion still correct), test/solidity/VaultWrapper/mocks/MockERC4626Underlying.sol
Deploy scripts	N/A	No deploy script changes; CREATE2 salt and init code unaffected

What is covered: the suffix appears for the default fixture; the asset has no symbol (VW fallback) while the underlying has one; two different underlyings over the same asset give distinct names and the same symbol; the underlying has an empty-string symbol; the underlying has no symbol() function (the call reverts, which exercises the revert fallback).

Gaps — all are requested changes, every item must be addressed or explicitly accepted:

Foundry gaps:

• [Low] LiFiVaultWrapper._initErc4626Metadata: oversized and bytes32 underlying symbol() not tested (see Issue Prepare for next audit #2)
• [Medium] All VaultWrapper suites: not executed in CI on head d51522f (see Issue 🔧 more updates #1)

---

🔗 Downstream Impact

Blocks: Stacked PR #2417 (EXSC-1036, feat(vaultWrapper): add Base demo deploy config) targets dev-vault-wrapper. Its diff contains no name/symbol assertions or readSymbol usage, so no code changes are needed there. However, any Base demo wrapper deployed from #2417 will now show the "… via " name. Once #2092 is rebased onto main, #2417 must be rebased too.
Operational: Nothing is deployed on live networks yet, so no redeploy or migration is needed. Frontends, indexers and the Earn backend that display or match on the wrapper's name() should expect the longer name. Matching on the unchanged symbol() still works, but symbols are not unique per yield source, so integrators should key on the wrapper address. Audit sequencing: this delta is in-scope audit code, so make sure the audit commit pin includes d51522f before auditLog.json is populated.

---

QA Agent — 2026-09-24

[lifi-qa-agent]

QA Pass (post-approval re-review) — EXSC-423. Single post-approval commit validated: FactoryInitParams initialize seeding is correct (all validations shared with owner-only setters, initializer guard present, adapter code check preserved, defaultIntegratorShareBps bounded by _setDefaultSplit); deploy ordering updated correctly (adapter before proxy). AuditRequired still blocks merge.

[lifi-qa-agent]

Requesting changes on 3 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	Process / CI	PR conflicts with main, so no forge unit tests or other pull_request gates ran on head d51522f
2	🟢 Low	Test gap	test/solidity/VaultWrapper/LiFiVaultWrapper.t.sol
3	🟢 Low	Code quality	New test helper _deployWrapperOver duplicates the existing _newWrapper

1. [Medium] Conflicts with main — new tests never ran in CI
mergeable: CONFLICTING (147 ahead / 115 behind). Only CodeQL, Aikido and check-secrets ran on d51522f; unit-tests-required, signed-commits-required, audit-verification, solc-floor-build, deploy-smoke-test did not. The three new/rewritten tests (test_NameAndSymbolFallBackWhenAssetHasNoSymbol, test_NameDistinguishesYieldSourcesOverSameAsset, test_NameOmitsYieldSourceWhenUnderlyingHasNoSymbol) and the updated name() assertions (LiFiVaultWrapper.t.sol:178, :332) are unverified. Merge/rebase main, resolve conflicts, and confirm required checks are green (then rebase stacked #2417).

2. [Low] Test gap — LiFiVaultWrapper.t.sol

• Missing: underlying whose symbol() returns >1000 bytes or burns gas — assert initialize succeeds and bytes(name()).length is bounded (unit)
• Missing: underlying whose symbol() returns bytes32 (MKR-style) (unit)

3. [Low] Duplicate helper
_deployWrapperOver (LiFiVaultWrapper.t.sol:653-674) is identical to _newWrapper(address) (:676-695). Delete it and use _newWrapper in the three new tests.

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