RFC: https://forum.summer.fi/t/rfc-reclaim-stranded-funds-across-legacy-incidental-contracts-into-the-dao-treasury/852

---

1. Overview:

Authorize the Guardian multisig (0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4) as a Merkl operator for the DAO treasury (the Timelock, 0x447BF9…C3796), so the Guardians can claim the treasury's accrued Merkl rewards on its behalf. The claimed tokens are paid to the Timelock, not to the Guardians.

Current claimable snapshot (Base): ~762,887.1296 SUMR and ~17.4189 USDC.

This is a two-part design: the root-independent authorization goes through governance; the time-sensitive claim is executed by the Guardian multisig with fresh proofs.

---

2. Motivation:

Under the stranded-funds recovery RFC, balances attributable to the DAO should be swept into the DAO treasury as minimal, individually reviewed actions. The Merkl rewards accrued to the Timelock are exactly such a balance, and the recipient of a Merkl claim is the earning address itself, so the funds settle directly in the treasury with no intermediate wallet.

Why a plain "claim" cannot go through governance directly. A Merkl claim requires amounts and proofs that are valid against Merkl's current Merkle root. Merkl regenerates and pushes a new root on a short cycle (roughly hourly, followed by a 1–2h dispute window). A SIP, by contrast, must pass a voting period and then sit through the timelock delay before it can execute. By the time any hardcoded proof reached execution, the root would have rotated many times and the claim would revert with InvalidProof. Hardcoding the claim in the SIP is therefore guaranteed to fail.

• The authorization: granting the Guardian multisig operator status, is root-independent. It never goes stale, so it is safe to route through the full governance path.
• The claim itself (with live amounts and proofs) is executed by the Guardian multisig, which can act on a short timeline and regenerate proofs against whatever root is current at the moment of execution.

This delegation is safe by construction (verified against the deployed Distributor contract):

• When an operator claims for a user, the tokens are paid to the user's recipient, which resolves to the user itself (the Timelock) when no custom recipient is set. An operator cannot redirect them, a custom recipient passed to claimWithRecipient is honored only when msg.sender == user. So the worst a misbehaving operator can do is trigger a claim that pays the treasury, or not claim at all. It cannot divert funds.
• Merkl's own documentation explicitly recommends operator-delegated claiming when the earning address is a multisig or contract.

Claim source (Timelock's Merkl dashboard): https://app.merkl.xyz/users/0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796

---

3. Specification:

Confirmed contract behavior (Merkl Distributor.sol)

• toggleOperator(address user, address operator) - caller must be user or a Merkl governor/guardian. The Timelock must therefore make this call itself (via governance execution), so msg.sender == user == Timelock. It is a toggle: 0 → 1 authorizes, calling again 1 → 0 revokes.
• _claim(...) reverts with NotWhitelisted when msg.sender != user unless operators[user][msg.sender] == 1 (the grant below), so the operator grant is strictly required for the Guardians to claim for the Timelock - not optional.
• claim(...) recipient resolves to claimRecipient[user][token], falling back to user. A non-user caller cannot override it. → funds go to the Timelock.

3.1 Execution payload

Action 1: Governance (through the SIP / timelock path). Root-independent.

The Timelock calls toggleOperator on the Merkl Distributor, naming itself as user and the Guardian multisig as operator.

Action 2: Guardian multisig (executed off the governance path, with live data).

Once Action 1 is executed and the grant is live, the Guardians submit the claim. amounts and proofs are pulled from the Merkl API/dashboard at the moment of execution, valid against the then-current root.

Tokens are paid to the Timelock. The Guardians may also claim via the Merkl frontend's "Operator mode" on the Timelock's user dashboard, which builds this same call with live proofs automatically.

Action 3: Optional cleanup (revoke).

After the claim confirms, operator status can be revoked by calling toggleOperator(Timelock, Guardian) again (1 → 0), either as a follow-up governance action or, since the AccessControlManager governor/guardian path also permits it, per Merkl's access rules. This is low-urgency: an operator cannot redirect funds, so a lingering grant is not a fund-safety risk. Revoking is good hygiene, not a requirement.

---

4. Risk Assessment:

• Funds cannot be diverted. Verified against Distributor.sol: an operator claim pays the user's recipient, which resolves to the Timelock, and a non-user caller cannot override the recipient. The Guardians can only cause the treasury to be paid; they cannot route the SUMR/USDC anywhere else.
• No privileged governance surface is touched. This SIP grants a Merkl-scoped operator flag only. It changes no Governor or Timelock roles, and is a single self-contained external call.
• Timing/root risk is designed out. The only thing in the slow governance path is the root-independent grant. The root-dependent claim is done by the fast-moving multisig, so a rotating Merkle root can no longer cause the recovery to fail. A stale proof merely reverts without moving funds.
• Toggle semantics. toggleOperator flips state; confirm the current value is 0 so execution results in 1 (authorized). (Checklist item.)
• Recipient pre-check. Confirm the Timelock has not set a custom claimRecipient for SUMR/USDC (it defaults to the Timelock). (Checklist item.)
• Scope of the grant. Operator status lets the Guardians claim any Merkl rewards for the Timelock (not just these two tokens), always paying the Timelock. This is acceptable and, if desired, can be revoked via Action 3 after the claim.
• Economic. The SUMR is the DAO's own token returning to treasury, no market buy/sell, no price impact. The USDC (~$17) is swept in the same claim at no extra cost. The SUMR balance clears the RFC's ~$100 materiality threshold comfortably.

---

5. Voting

If YES: Authorize the Guardian multisig (0x91E4…2BA4) as a Merkl operator for the Timelock treasury (0x447BF9…C3796) on the Base Distributor, enabling the Guardians to claim the treasury's accrued Merkl rewards (~762,887.1296 SUMR and ~17.4189 USDC, or the then-current cumulative amounts) directly to the treasury, per the stranded-funds recovery RFC.

If NO: Do not grant operator status; leave the rewards unclaimed.