# \[BIP-885\] Permissions Update Request #7 **URL:** \ **Category:** Karpatkey Updates\ **Created:** [September 24, 2025, 9:33pm UTC](https://forum.balancer.fi/t/bip-885-permissions-update-request-7/6841 "2025-09-24T21:33:07Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![kpk](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/kpk/32/3793_2.png) [@kpk](https://forum.balancer.fi/u/kpk)\ **Post date:** [September 24, 2025, 9:33pm UTC](https://forum.balancer.fi/t/bip-885-permissions-update-request-7/6841/1 "2025-09-24T21:33:07Z")
### PR with payloads > > > previous PR: https://github.com/BalancerMaxis/multisig-ops/pull/2428 > > > \--- > … > > Mainnet simulation: https://dashboard.tenderly.co/public/safe/safe-apps/simulator/996a569e-a7c9-4596-9946-df52c45c2b83/logs > > Arbitrum1 simulation: https://dashboard.tenderly.co/public/safe/safe-apps/simulator/9ff31dc4-498c-4589-83bf-cb450fe3ffe8 ## Abstract This proposal seeks BalancerDAO’s approval to add permissions required for: - Disassembling deprecated positions and reallocating assets in line with [[BIP-850](https://forum.balancer.fi/t/bip-850-dao-treasury-assets-migration/6489)] - Staking and delegating POL to the Balancer Foundation, as outlined in [[BIP-851](https://forum.balancer.fi/t/bip-851-staking-pol-tokens-and-delegating-to-balancers-governance-profile/6593)] - Deploying sub-roles and enabling the Main Roles Modifier on Arbitrum, as defined in [[BIP-842](https://forum.balancer.fi/t/bip-842-deploy-kpk-sub-roles-architecture/6473)] ## Motivation In line with the mandates defined in the IPS and the [categorization of positions for migration](https://forum.balancer.fi/t/bip-850-dao-treasury-assets-migration/6489/5#p-15896-categorisation-of-positions-2), the DAO’s treasury management requires permissions to: - Disassemble positions considered deprecated or classified as dust - Reallocate assets into strategic positions and stable reserves - Enable POL staking and delegation to Danko, who will act on behalf of the Balancer Foundation - Deploy and configure sub-roles on Arbitrum, ensuring modularity, better risk isolation, and alignment with the cross-chain architecture introduced in [BIP-842] These permissions are temporary in nature and can be discarded once the migration, delegation, and sub-role configuration are complete. ## Changes to the Permissions Policy The following modifications are proposed for the **Manager Role** on each chain, in alignment with the post-migration plan and recent BIPs: ### Ethereum Mainnet - vFJO: withdraw from Sablier and swap to USDC - sBAL on Silo: withdraw - MTA: swap to USDC - GTC: swap to USDC - POL: staking permissions - POL: delegate POL to Danko (acting on behalf of the Balancer Foundation) ### Arbitrum One - USDC.e: swap to USDC on CoWswap and bridge to Ethereum Mainnet through CCTP - Zodiac Roles Modifier deployment: - Create the MANAGER role with the requested permissions - Configure the Sub Roles - Enable the Main Roles Modifier to point to the Avatar Safe ## Zodiac Roles Modifier Permissions Policy **Ethereum Mainnet** - Permissions diff page: [https://roles.gnosisguild.org/eth:0x13c61a25DB73e7a94a244bD2205aDba8b4a60F4a/roles/MANAGER/diff/8YaP3Ku7mUUugZkxS0tUx6sfeIVe3gSR1QkQeS830?annotations=false](https://roles.gnosisguild.org/eth:0x13c61a25DB73e7a94a244bD2205aDba8b4a60F4a/roles/MANAGER/diff/8YaP3Ku7mUUugZkxS0tUx6sfeIVe3gSR1QkQeS830?annotations=false) **Arbitrum One** - Permissions page: [https://roles.gnosisguild.org/arb1:0x13c61a25db73e7a94a244bd2205adba8b4a60f4a/roles/MANAGER?annotations=false](https://roles.gnosisguild.org/arb1:0x13c61a25db73e7a94a244bd2205adba8b4a60f4a/roles/MANAGER?annotations=false) ## References - [BIP-842: Deploy kpk Sub-Roles Architecture](https://forum.balancer.fi/t/bip-842-deploy-kpk-sub-roles-architecture/6473) - [BIP-850: DAO Treasury Assets Migration](https://forum.balancer.fi/t/bip-850-dao-treasury-assets-migration/6489) - [BIP-851: POL Delegation to Balancer Foundation](https://forum.balancer.fi/t/bip-851-staking-pol-tokens-and-delegating-to-balancers-governance-profile/6593) ---
**Author:** ![gosuto](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/gosuto/32/2014_2.png) [@gosuto](https://forum.balancer.fi/u/gosuto)\ **Post date:** [October 16, 2025, 5:22pm UTC](https://forum.balancer.fi/t/bip-885-permissions-update-request-7/6841/2 "2025-10-16T17:22:35Z")
## Ethereum ### POL Delegation allow staking of $pol NOTE: i would suggest to _not_ limit the delegates `bytes32` in `setDelegation`; it should be possible to choose any - `POL.approve(StakeManager, *)` - `ValidatorShare.buyVoucherPOL(*, *)` - `DelegateRegistry.setDelegation(“polygongovernancehub.eth”, [delegate, ratio], *)` - `DelegateRegistry.clearDelegation(“polygongovernancehub.eth”)` ### USDS Migration xDAI Bridge ([Gnosis Chain](https://docs.gnosischain.com/bridges/About%20Token%20Bridges/usds-xdaibridge-migration)) - `SparkPSMLite`: withdraw, redeem and deposit: receiver is limited to AVATAR - `GnosisBridgeRouter.executeSignatures` with masks - `UsdsPsmWrapper` buy and sell, user is limited to AVATAR - `sUSDC.deposit(*, AVATAR, *)`: allow for deposit with third referral arg - `SparkUSDC.approve(PsmUsdcSusds)` - `DAI.approve(GnosisBridgeRouter)` - `sDAI.approve`: SparkPSMLite, AAVE\_V3, BalancerVaultV2, COW\_SWAP - `USDC.approve`: SparkPSMLite, UsdsPsmWrapper, PsmUsdcSusds - `USDS.approve`: UsdsPsmWrapper - REMOVE `sUSDC.deposit(*, AVATAR)` - REMOVE `DAI.approve(XDaiForeignBridge)` - REMOVE `XDaiForeignBridge.relayTokens` (old) ### CoW Swap sell FJO/MTA/GTC for USDC via `signOrder` ### Fjord withdraw fjo from sablier and swap it - `FJO.approve(COWSWAP, *)` - `Sablier.withdraw(*, AVATAR)` ### mStable - `MTA.approve(COWSWAP, *)` ### Silo not sure why this needs to be through the router, we can just call `Silo(0x92E7E77163FFed918421E3CB6e0A22F2Fe8B37FA).withdraw(0xba100000625a3754423978a60c9317c58a424e3D, 115792089237316195423570985008687907853269984665640564039457584007913129639935, 0)` instead - `SiloRouter.execute(withdraw, siloBAL, AVATAR, *, *)` ### Gitcoin - `GTC.approve(COWSWAP, *)` ### CCTP - `CircleMessageTransmitterV2.receiveMessage` with masks ### Aave - `AaveRewardsController.claimRewards([*], *, AVATAR)` ### Lido - REMOVE withdrawal queue’s `requestWithdrawalsWstETHWithPermit` and `requestWithdrawalsWithPermit` ---
**Author:** ![kpk](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/kpk/32/3793_2.png) [@kpk](https://forum.balancer.fi/u/kpk)\ **Post date:** [October 22, 2025, 8:18am UTC](https://forum.balancer.fi/t/bip-885-permissions-update-request-7/6841/3 "2025-10-22T08:18:21Z")
Thanks for your detailed input! Below is a summary of the final adjustments following your suggestions and our internal review: **POL Delegation** **We’ll proceed with POL staking under the following scope:** - `POL.approve(StakeManager, *)` → This permission in the policy is scoped as `POL.approve(StakeManager, PoS Staking Contract)` with **PoS Staking Contract = 0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908**. This can’t be changed since the PoS Staking Contract is the required entry point for staking POL. Besides, we can’t leave the `_spender` unscoped, as that would represent a serious security risk. - `ValidatorShare.buyVoucherPOL(*, *)` → Already included in the policy and valid as proposed. - `DelegateRegistry.setDelegation("polygongovernancehub.eth", [delegate, ratio], *)` → We don’t recommend leaving the delegation structure unscoped, as it poses a clear security risk. The safest approach would be to provide a list of possible delegates to scope the `delegate` field within the `DelegationStruct`. However, if you prefer to keep it unscoped, we can technically support that setup. - `DelegateRegistry.clearDelegation("polygongovernancehub.eth")` → Already included and OK as proposed. **Silo Router** We’ve decided to keep the `Silo Router v2` call whitelisted, since without it we wouldn’t be able to use the **Pilot extension** — the router is the contract called directly from the UI. Whitelisting it also aligns with our standard guardrails and allows safe batching, since the `execute()` function is strictly scoped to call Silo(0x92E7E77163FFed918421E3CB6e0A22F2Fe8B37FA).withdraw(). That said, if you prefer to directly whitelist the `Silo.withdraw()` call, we can do it — though it would add a bit of overhead on our side. **Next Steps** Once you confirm: 1. The **list of possible delegate addresses** to scope within the `DelegationStruct`. 2. Whether to proceed with the **router whitelisting** or switch to the direct `Silo.withdraw()` call. We’ll update the permission policy accordingly, regenerate the diff page, and publish the **final payload.** ---
**Author:** ![gosuto](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/gosuto/32/2014_2.png) [@gosuto](https://forum.balancer.fi/u/gosuto)\ **Post date:** [October 30, 2025, 11:40am UTC](https://forum.balancer.fi/t/bip-885-permissions-update-request-7/6841/4 "2025-10-30T11:40:33Z")
# Ethereum > [@kpk](#): > > `POL.approve(StakeManager, *)` → This permission in the policy is scoped as `POL.approve(StakeManager, PoS Staking Contract)` with **PoS Staking Contract = 0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908**. This can’t be changed since the PoS Staking Contract is the required entry point for staking POL. Besides, we can’t leave the `_spender` unscoped, as that would represent a serious security risk. i think this is just a misunderstanding? the `approve` signature only allows for a `spender` (first arg) and `amount` (second arg). in your request the spender is the stake manager, and the amount is unscoped (`*`). no need for changes there imo; lgtm > [@kpk](#): > > `DelegateRegistry.setDelegation("polygongovernancehub.eth", [delegate, ratio], *)` → We don’t recommend leaving the delegation structure unscoped, as it poses a clear security risk. The safest approach would be to provide a list of possible delegates to scope the `delegate` field within the `DelegationStruct`. However, if you prefer to keep it unscoped, we can technically support that setup. this is quite minor and not worth the adjustment at this time imo; lgtm > [@kpk](#): > > We’ve decided to keep the `Silo Router v2` call whitelisted, since without it we wouldn’t be able to use the **Pilot extension** — the router is the contract called directly from the UI. Whitelisting it also aligns with our standard guardrails and allows safe batching, since the `execute()` function is strictly scoped to call Silo(0x92E7E77163FFed918421E3CB6e0A22F2Fe8B37FA).withdraw(). > That said, if you prefer to directly whitelist the `Silo.withdraw()` call, we can do it — though it would add a bit of overhead on our side. ok this is just a technical limitation then. indeed no security risk, just a minor inefficiency (evm wise, i understand for your ops using the router is more efficient). no need for changes then imo; lgtm # Arbitrum swap usdce to usdc and bridge to ethereum. lgtm ### CoW Swap - sell USDC.e for USDC via `signOrder` - `unsignOrder(*)` ### USDC.e - `USDCe.approve(COWSWAP, *)` ### USDC - `USDC.approve(CCTP, *)` ### CCTP - `CCTP.burnToken(*, ETHEREUM, AVATAR, USDC)` ---
**Author:** ![Xeonus](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/xeonus/32/3621_2.png) [@Xeonus](https://forum.balancer.fi/u/Xeonus)\ **Post date:** [October 31, 2025, 10:04am UTC](https://forum.balancer.fi/t/bip-885-permissions-update-request-7/6841/5 "2025-10-31T10:04:14Z")
[https://snapshot.box/#/s:balancer.eth/proposal/0x38db2412adce23237ff462a22faa2be0618a8b446937d56f33f2438edf83896f](https://snapshot.box/#/s:balancer.eth/proposal/0x38db2412adce23237ff462a22faa2be0618a8b446937d56f33f2438edf83896f)