1) Sub-Roles Modifier
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 MANAGERpasses 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.
VTNet: Tenderly Dashboard
2) The missing syrupUSDC / syrupUSDT swaps
This is a legitimate catch, regenerating the updated .json to include these.
3) Empty Address
Updated to correct the forum post.