Plasma Gho Launch, Remote GSM Launch #879
Conversation
Compiling 420 files with Solc 0.8.27
Solc 0.8.27 finished in 152.57s
Compiler run successful!
2025-11-05T06:17:19.908746Z ERROR cheatcodes: non-empty stderr input=["npx", "@bgd-labs/[email protected]", "diff-snapshots", "./reports/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1_before.json", "./reports/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1_after.json", "-o", "./diffs/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1_before_AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1_after.md"] stderr="npm warn exec The following package was not found and will be installed: @bgd-labs/[email protected]\n"
|
❌Test Results
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1.sol
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| function _registerOracles() internal { | ||
| AaveV3Ethereum.COLLECTOR.withdrawFromV3( |
There was a problem hiding this comment.
@efecarranza there can be 2-3 wei imprecision when withdrawing, after withdraw better to get current link balance of the executor and fund the robot accordingly
There was a problem hiding this comment.
i can withdraw + 5 wei just to make sure i have the 80, 'cause i have to fund 2 bots with specific amounts.
There was a problem hiding this comment.
Starting from the v3.5 version, all transfers are transferring at least the passed amount. For example, if Alice is transferring 5 weis aTokens to Bob (through transfer or transferFrom), then Alice's aToken balance will be decreased not less 5 weis and Bob's aToken balance will be increased not less 5 weis.
There was a problem hiding this comment.
@efecarranza you can use the returned value from the function, and to fund the first robot use the value from immutable and for the second use returnedLinkBalance - LINK_AMOUNT_ORACLE_FREEZER_KEEPER
| address public constant NEW_GSM_USDC = 0x3A3868898305f04beC7FEa77BecFf04C13444112; | ||
|
|
||
| // https://etherscan.io/address/0xc39ac061686C99b1B8B09B401e8C2f486894AD3c | ||
| address public constant USDC_ORACLE_SWAP_FREEZER = 0xc39ac061686C99b1B8B09B401e8C2f486894AD3c; |
There was a problem hiding this comment.
The addresses provider immutable on the USDC and USDT swap freezer is of the plasma network and needs to be re-deployed.
Furthermore, can you add tests for the new contracts added to validate the immutables, ownerships, misc deployment config and end some e2e tests so we don't miss anything.
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part2.sol
Outdated
Show resolved
Hide resolved
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part2.sol
Outdated
Show resolved
Hide resolved
...rRewards/AaveV3Plasma_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1.sol
Outdated
Show resolved
Hide resolved
...rRewards/AaveV3Plasma_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part2.sol
Outdated
Show resolved
Hide resolved
...rRewards/AaveV3Plasma_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part2.sol
Outdated
Show resolved
Hide resolved
...rRewards/AaveV3Plasma_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part2.sol
Outdated
Show resolved
Hide resolved
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1.sol
Outdated
Show resolved
Hide resolved
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1.sol
Outdated
Show resolved
Hide resolved
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1.sol
Outdated
Show resolved
Hide resolved
| function mint(address to, uint256 amount) external; | ||
| } | ||
|
|
||
| interface IAaveGhoCcipBridge { |
There was a problem hiding this comment.
IAaveGhoCcipBridge can be imported from aave-helpers directly
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part2.sol
Outdated
Show resolved
Hide resolved
|
|
||
| function _updateFeeStrategy() internal { | ||
| IGsm(NEW_GSM_USDC).updateFeeStrategy(FEE_STRATEGY); | ||
| IGsm(NEW_GSM_USDT).updateFeeStrategy(FEE_STRATEGY); |
There was a problem hiding this comment.
the buy fee on this FEE_STRATEGY is different from the current on-chain buy fee of the OLD GSM USDT, is it expected?
There was a problem hiding this comment.
hmm, this is the current fee strategy for both as it is on chain, but i noticed on the address book it's different so we'll need to update that when we release this PR.
There was a problem hiding this comment.
cause via stewards we keep changing the value and atm it is hardcoded on address-book
There was a problem hiding this comment.
Right now, old USDT GSM and old USDC GSM have different fee strategies. Instead of one FEE_STRATEGY, this proposal should define two separate FEE_STRATEGY_USDT and FEE_STRATEGY_USDC addresses (should have the same value as old GSMs) and install them in new GSMs.
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1.sol
Show resolved
Hide resolved
| // OwnableFacilitator Constants | ||
| address public constant OWNABLE_FACILITATOR = 0x616AEe98F73C79FE59548Cfe7631c0baDBdA3165; | ||
| string public constant OWNABLE_FACILITATOR_NAME = 'OwnableFacilitator Gho GSMs'; | ||
| uint128 public constant OWNABLE_FACILITATOR_CAPACITY = 150_000_000 ether; |
There was a problem hiding this comment.
Shouldn't it be 100M? As specified in the forum
There was a problem hiding this comment.
Will update the forum, current is 50M for USDC and 25M for USDT, with plasma 50M we're already over capacity.
...ewards/AaveV3Ethereum_LaunchGHOOnPlasmaSetACIAsEmissionsManagerForRewards_20250930_Part1.sol
Show resolved
Hide resolved
| IERC20(AaveV3EthereumAssets.USDC_STATA_TOKEN).forceApprove(NEW_GSM_USDC, balanceUsdc); | ||
| IERC20(AaveV3EthereumAssets.USDT_STATA_TOKEN).forceApprove(NEW_GSM_USDT, balanceUsdt); | ||
|
|
||
| (, uint256 amountGhoUsdc) = IGsm(NEW_GSM_USDC).sellAsset(balanceUsdc, address(this)); |
There was a problem hiding this comment.
Some leftovers can appear here, but I believe it is not a problem because it will be +-1/2 weis.
| } | ||
|
|
||
| function _registerOracles() internal { | ||
| AaveV3Ethereum.COLLECTOR.withdrawFromV3( |
There was a problem hiding this comment.
Starting from the v3.5 version, all transfers are transferring at least the passed amount. For example, if Alice is transferring 5 weis aTokens to Bob (through transfer or transferFrom), then Alice's aToken balance will be decreased not less 5 weis and Bob's aToken balance will be increased not less 5 weis.
| // AaveV3Ethereum.POOL, | ||
| // address(proposal) | ||
| // ); | ||
| // } |
There was a problem hiding this comment.
Why is this commented out?
There was a problem hiding this comment.
thanks, was a mistake! i commented it back in
| actions[0] = GovV3Helpers.buildAction(payload0); | ||
| actions[1] = GovV3Helpers.buildAction(payload1); | ||
|
|
||
| // register action at payloadsController | ||
| GovV3Helpers.createPayload(actions); |
There was a problem hiding this comment.
Automatic bots must be disabled for the execution of these proposals and it has to be done sequentially.
Execute Plasma proposal Part 1, where the inbound rate of GHO is going to be increased for 50M.
Execute Ethereum proposal where rate limits are increased for the token pool.
Execute Ethereum proposal where GHO is going to be bridged.
Execute Plasma proposal Part 2 where it will perform all the GHO related tasks and reestablish the rate back to the original one.
@efecarranza Sure the bots could be disabled, but the execution is permissionless so the sequence of payload execution across different networks cannot be guaranteed.
Also on the scripts currently we put payload0 and payload1 as two actions on a single payload, so the execution of payload0 and payload1 will always be atomic which we don't want to I think
|
|
||
| ## Motivation | ||
|
|
||
| This publicaiton presents the revised GHO parameter configuration for deploying the RemoteGSM and listing GHO on Aave Protocol. A joint collaboration program with Plasma, Maple Finance and Ethena, will be launched on Aave Protocol whilst separate and complimentary rewards programs will commence on Fluid and Balancer. |
There was a problem hiding this comment.
| This publicaiton presents the revised GHO parameter configuration for deploying the RemoteGSM and listing GHO on Aave Protocol. A joint collaboration program with Plasma, Maple Finance and Ethena, will be launched on Aave Protocol whilst separate and complimentary rewards programs will commence on Fluid and Balancer. | |
| This publication presents the revised GHO parameter configuration for deploying the RemoteGSM and listing GHO on Aave Protocol. A joint collaboration program with Plasma, Maple Finance and Ethena, will be launched on Aave Protocol whilst separate and complimentary rewards programs will commence on Fluid and Balancer. |
|
|
||
| // Plasma Bridge Constants | ||
| // https://etherscan.io/address/0x7f2f96fcdc3a29be75938d2ac3d92e7006919fe6 | ||
| address public constant CCIP_BRIDGE = 0x7F2f96fcdC3A29Be75938d2aC3D92E7006919fe6; |
There was a problem hiding this comment.
This constant is not used anywhere in this payload, it can be removed.
|
|
||
| function _updateFeeStrategy() internal { | ||
| IGsm(NEW_GSM_USDC).updateFeeStrategy(FEE_STRATEGY); | ||
| IGsm(NEW_GSM_USDT).updateFeeStrategy(FEE_STRATEGY); |
There was a problem hiding this comment.
Right now, old USDT GSM and old USDC GSM have different fee strategies. Instead of one FEE_STRATEGY, this proposal should define two separate FEE_STRATEGY_USDT and FEE_STRATEGY_USDC addresses (should have the same value as old GSMs) and install them in new GSMs.
| uint128 public constant USDC_CAPACITY = 50_000_000 ether; | ||
| uint128 public constant USDT_CAPACITY = 25_000_000 ether; |
There was a problem hiding this comment.
naming is misleading, as USDC has 6 decimals, not 18.
I d rename to USDC_GSM_RESERVE_LIMIT and USDT_GSM_RESERVE_LIMIT
| address public constant NEW_GSM_USDC = 0x3A3868898305f04beC7FEa77BecFf04C13444112; | ||
|
|
||
| // https://etherscan.io/address/0x6e51936e0ED4256f9dA4794B536B619c88Ff0047 | ||
| address public constant USDC_ORACLE_SWAP_FREEZER = 0x6e51936e0ED4256f9dA4794B536B619c88Ff0047; |
There was a problem hiding this comment.
cannot the old be reused?
There was a problem hiding this comment.
this is one is specifically ChainlinkOracleSwapFreezer instead of old just OracleSwapFreezer
| import {CCIPChainSelectors} from '../helpers/gho-launch/constants/CCIPChainSelectors.sol'; | ||
|
|
||
| /** | ||
| * @title Add GHO and deploy GSM on Plasma. Migrate to new GSM on Ethereum |
There was a problem hiding this comment.
This only migrates ethereum GSMs right, can we ammend text?
| // GHO GSM Steward | ||
| IGsm(NEW_GSM_USDC).grantRole( | ||
| IGsm(NEW_GSM_USDC).CONFIGURATOR_ROLE(), | ||
| GhoEthereum.GHO_GSM_STEWARD |
There was a problem hiding this comment.
let's grant executor too
There was a problem hiding this comment.
already granted on initialize()
5 participants
Note
Execution to be performed as follows:
Ethereum Part 1
Ethereum Part 2 (will revert until after a few seconds of part 1 being executed)
Wait for Bridge from Ethereum to go through, Plasma incoming bridge will likely fail because of the inbound rate limit, in which case it can be manually retried here: https://ccip.chain.link/
Plasma Part 1
Plasma Part 2
This proposal includes some buffer in case more GHO is bridged from Mainnet to Plasma in order for it to be included in the Merkle proof.
Changelog
Bridge GHO to Plasma.
Add new GSM on Plasma.
Add Gho to Aave on Plasma.
Test Bridging Transaction
Here