This proposal is a routine update to the Endowment Manager permissions. It expands the Endowment’s access to real-world-asset (RWA) and fixed-income positions, adds a set of curated Morpho yield vaults and the Aave v3 Horizon market, enables Maple (Syrup) swap routing, and introduces a dedicated reward-claim role. No permissions are removed.
Motivation
The update continues the diversification of the Endowment’s stable and ETH allocations into vetted yield and fixed-income venues while keeping all activity within the Investment Policy Statement (IPS). New access covers fixed-yield principal tokens via Pendle, curated lending and yield vaults on Morpho (kpk, Steakhouse, Smokehouse, and Sentora), and the RLUSD market on Aave v3 Horizon. A separate Harvest role is introduced so that protocol reward claims can be executed with payouts forced to the Endowment safe, without granting broader permissions.
All token approvals are spender-pinned to the specific protocol contract they enable. A new Harvest role is created to isolate reward-claim permissions, with all claim payouts forced to the Endowment safe.
All positions conform to the Endowment’s risk tolerance under the Investment Policy Statement (IPS). All venues in this update are permissionless; the Aave v3 Horizon RLUSD position is on the stablecoin supply side, which requires no onboarding or whitelisting, and no other position in this update carries an onboarding precondition.
Next Steps
The proposal will be introduced in the next meta-governance call. Pending review from Blockful and no revisions following discussion during the meta-governance call, this proposal will progress to an on-chain executable vote.
We reconstructed all 54 transactions of the payload and compared the reconstruction against the published payload. The two are identical. Transactions described in the specification were derived from the specification and the public contract interfaces. All new permissions are correctly restricted: deposits, withdrawals, and reward payouts can only be directed to the Endowment Safe, approvals are limited to the named protocol contracts, and the Pendle Router cannot be used to route funds through external contracts. No existing permission is removed.
1. Item 6 is implemented through a new module that the proposal text should describe. Transactions 0 through 7 deploy a second Roles instance, place the Endowment Manager permission set behind it, and transfer its ownership to kpk; we understand it will host the Harvest role, configured by kpk after execution. The claims listed under item 6 are already permitted today, with payouts restricted to the Endowment Safe, so the practical effect of item 6 is a dedicated claim operator. Our simulation confirms that payouts cannot be redirected even if the module is misconfigured. Ownership of the module, however, allows kpk to grant third parties access to the Endowment Manager permission set without a DAO vote.
Question: please describe the module in the proposal text, confirm that its use is limited to the Harvest role, and identify its intended members.
2. Item 5 is not implemented. Adding syrupUSDC and syrupUSDT to the swap token lists does not appear in any of the 54 transactions.
Question: will the payload be amended to include it?
3. The specification lists an address that does not correspond to a deployed contract. The table entry for Steakhouse High Yield USDC gives 0xbeeff7aE5E00Aae3Db302e4B0d8C883810a58100, which holds no code on mainnet. The payload correctly uses 0xbeeff2C5bF38f90e3482a8b19F12E5a6D2FCa757.
Suggestion: correct the address in the proposal text.
The payload only deploys and wires the module. It does not create the HARVESTER role or add any member. The HARVESTER role and its member will be configured afterwards by the MANAGER Safe, which becomes the owner of the Sub-Roles Modifier in the last tx.
You can see exactly what the role will contain in client configs:
Its scope is limited to reward claims (Fluid FLUID, Fluid GHO, and Merkl/Morpho incentives), with the recipient hard pinned to the endowment Safe.
As for how it works, the Sub-Roles Modifier is a nested permission layer under the main Roles Modifier. Since it’s assigned the MANAGER role on the main Roles Modifier (setDefaultRole + assignRoles), every transaction it forwards is still checked against the MANAGER policy. So the effective permissions of a Sub-Role are always the intersection of its own scope and MANAGER.
It can never authorize anything that MANAGER doesn’t already allow.
To verify, the whole setup was recreated on a mainnet fork. The 8 tx setup ran cleanly, with the module deployed deterministically at 0xa5dd28EC…, owner set to the MANAGER Safe, and target set to the main Roles Modifier.
A test HARVESTER Sub-Role and verified both cases:
A claim action already allowed by MANAGER passes end to end.
An action deliberately granted to the Sub-Role but not allowed by MANAGER (WETH.transfer) reverts at the main Roles Modifier.
So the firewall is working as expected. Even if we scope something on the Sub-Roles, the main MANAGER policy still has the final say.
A claim action already allowed by 
An action deliberately granted to the Sub-Role but not allowed by