[Temp Check] Rotate Sentinel Addresses on the DUNI-Owned Uniswap Earn Vaults

TL;DR

  • DUNI owns the three Gauntlet-curated Morpho Vaults V2 behind Uniswap Earn: uniUSDC, uniUSDT and uniETH, all on Ethereum mainnet.
  • Gauntlet has upgraded its signing infrastructure and needs to swap out some wallets configured in the Sentinel role on vault deployment.
  • setIsSentinel, the function used to adjust addresses granted the Sentinel role, is owner-gated and the Owner is Uniswap governance’s mainnet Timelock.

Background

Uniswap Labs launched Uniswap Earn in July 2026. Consistent with past Uniswap Labs-originated protocol launches, the ownership roles on the smart contracts that power Uniswap Earn were assigned to Uniswap Governance. In Earn, a user deposits USDC, USDT or ETH in the Uniswap app, the deposit flows into a Morpho Vaults V2 instance, and Gauntlet curates the allocation. In the run up to launch, Gauntlet deployed the three vaults and transferred ownership to DUNI’s Timelock address.

Morpho Vaults V2 splits control across four roles.

Role Capabilities Appointed by Held on the Earn vaults by
Owner Appoint the Curator, add and remove Sentinels, transfer ownership, set vault name and symbol. One address only. Prior Owner, via setOwner DUNI, via the mainnet Timelock
Curator Set caps and risk parameters, enable yield sources, set fees, appoint allocators. Most actions timelocked. One address only. Owner Gauntlet
Allocator Move capital between enabled yield sources, within the bounds the Curator has set. Multiple addresses allowed. Curator Gauntlet
Sentinel Lower caps, revoke pending Curator actions, pull assets out of lending markets back into the vault. Takes effect instantly. Multiple addresses allowed. Owner Gauntlet

The Owner has no claim on deposits and does not set risk parameters, allocations, or fees directly. Fee management sits with the Curator. Governance’s leverage runs through its power to appoint and replace the Curator, which is why ownership was structured this way.

Performance fee is currently zero on all three vaults.

Motivation

Gauntlet has upgraded the signing infrastructure it uses across the vaults it curates. Specific to Uniswap Earn vaults, this has resulted in new addresses for the Sentinel role.

Specification

The three vaults, all on Ethereum mainnet:

Vault Address
Uniswap USDC (uniUSDC) 0x5B453493D2328E7F747eb2e66446eFe707728be7
Uniswap USDT (uniUSDT) 0xb8274eFADB953FE9ae052D481a3FC5B6A3ceD703
Uniswap ETH (uniETH) 0x98D2b241DA14c5dd848812708Eb8A1F3c5512f9d

The Owner of all three is the Timelock at 0x1a9C8182C09F50C8318d769245beA52c32BE35BC.

We propose calling setIsSentinel(address,bool) six times: once to grant the role to each new Gauntlet address, and once to revoke it from each legacy address.

Vault New Sentinel (grant) Legacy Sentinel (revoke)
uniUSDC 0xF66b884D1906F37c1692CEa63564316FF975Cd75 0xc3FE37DB03B5720D1684bE2e0200E0Af07853Ad9
uniUSDT 0xD9b023059dfD00C2DC68C4d8d0c70BCaA30577Db 0x2745513325d4Ce5724e5B6Fb663356C427AfdeCc
uniETH 0x4Ff315B873d6e5Ad8ff7fF3e17D340862762cc2f 0xc63A00De30AeB5666a8aC3478a4D119D38058c7E

A vault can hold more than one Sentinel, so the grants and the revocations are independent actions.

For every vault, the Curator stays Gauntlet, the Owner stays the Timelock, and all parameters such as caps, adapters and fees are unchanged.

Onchain Proposal Spec

Six transactions, all sent from the Timelock, all with value = 0. Function selector 0x920ed706.

// uniUSDC vault: 0x5B453493D2328E7F747eb2e66446eFe707728be7
setIsSentinel(0xF66b884D1906F37c1692CEa63564316FF975Cd75, true);
setIsSentinel(0xc3FE37DB03B5720D1684bE2e0200E0Af07853Ad9, false);

// uniUSDT vault: 0xb8274eFADB953FE9ae052D481a3FC5B6A3ceD703
setIsSentinel(0xD9b023059dfD00C2DC68C4d8d0c70BCaA30577Db, true);
setIsSentinel(0x2745513325d4Ce5724e5B6Fb663356C427AfdeCc, false);

// uniETH vault: 0x98D2b241DA14c5dd848812708Eb8A1F3c5512f9d
setIsSentinel(0x4Ff315B873d6e5Ad8ff7fF3e17D340862762cc2f, true);
setIsSentinel(0xc63A00De30AeB5666a8aC3478a4D119D38058c7E, false);

Raw calldata:

0x920ed706000000000000000000000000f66b884d1906f37c1692cea63564316ff975cd750000000000000000000000000000000000000000000000000000000000000001
0x920ed706000000000000000000000000c3fe37db03b5720d1684be2e0200e0af07853ad90000000000000000000000000000000000000000000000000000000000000000
0x920ed706000000000000000000000000d9b023059dfd00c2dc68c4d8d0c70bcaa30577db0000000000000000000000000000000000000000000000000000000000000001
0x920ed7060000000000000000000000002745513325d4ce5724e5b6fb663356c427afdecc0000000000000000000000000000000000000000000000000000000000000000
0x920ed7060000000000000000000000004ff315b873d6e5ad8ff7ff3e17d340862762cc2f0000000000000000000000000000000000000000000000000000000000000001
0x920ed706000000000000000000000000c63a00de30aeb5666a8ac3478a4d119d38058c7e0000000000000000000000000000000000000000000000000000000000000000

A full simulation will be available via Seatbelt alongside the onchain vote.

Risks and Considerations

Sentinel authority is constraining-only. Per the deployed contracts, a Sentinel can decrease relative and absolute allocation caps, revoke a timelocked Curator action, and deallocate assets. It cannot allocate, raise caps, withdraw from the vault, or change configuration. A compromised Sentinel can constrain the vault or unwind a Curator action. It cannot drain one. Morpho’s own documentation rates the impact of a compromised Sentinel as minimal and lists a hot key as an acceptable setup for the role.

No coverage gap. The six transactions execute together, so the new addresses are live before the old ones are removed.

Precedent. While Gauntlet does not anticipate needing to swap addresses frequently, any future Sentinel rotation will run through the same process, including Gauntlet’s provision of proof that they own the addresses in question.

Next Steps

Stage Target
RFC discussion Week of September 8, 2026
Snapshot temperature check Week of September 15, 2026
Onchain vote Submitted week of September 21, 2026
Timelock execution Early October 2026

Supporting Documents

2 Likes

Could you confirm whether existing depositors need to take any action when this change goes live? A short “what this means for users” note would be helpful alongside the technical details.

Will add to main post but just for avoidance of doubt will stick it here as well - existing depositors don’t need to do anything, and the security profile of the vault does not change as a result of this proposal’s execution.

1 Like

Thanks for confirming and adding this to the main post. Knowing that existing depositors don’t need to do anything is helpful.

You can find EIP-712 signed messages for all 6 addresses along with instructions on how to validate them in this gist: https://gist.github.com/alifier/7d42cd3b0c7ec7a6ff95052c186bf79d

1 Like

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and is based on their combined research, fact-checking, and discussion.

We voted FOR.

This is a routine maintenance update that keeps the existing security setup working after Gauntlet changed its signing infrastructure. We do not see any governance concerns with the proposed rotation at this stage.

Since the proposal changes roles directly on the Uniswap Earn vault contracts, we plan to ask our Research Team to review the final executable once it reaches the on-chain vote and confirm that the changes match what was approved during the temp check.

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and is based on their combined research, fact-checking, and discussion.

We voted FOR.

We supported this change during the offchain stage because it is essentially a maintenance update to keep the existing Sentinel setup working after Gauntlet changed its signing infrastructure.

Since the proposal touches the vault contracts directly, we wanted to wait for the onchain executable before fully closing the loop. Our Research Team reviewed the final proposal and calldata, confirmed that it matches the Sentinel rotations described in the temp check, and did not find anything concerning.

Matching calldata and preserving operational continuity are different checks. The proposal says the new Sentinel addresses are live before the old ones are removed because the six calls execute together. In your executable review, did you treat that as an atomic all-or-nothing property of proposal execution, or did you separately verify an ordering invariant that prevents a partial rotation?