There seems to be a misconfiguration of the new Remote GSM on Arbitrum. The Arbitrum remoteGSM pairs GHO with bridged USDC.e, not native USDC. USDC.e is one of the assets on Arbitrum that’s going to be deprecated so this seems off.
The USDC GSM at 0x53E0cE250d06043414070100458546AaF4e284eD has underlying asset set to the StataToken 0xE6D5923281c89DC989D00817387292387552d5C1 that wraps the bridged USDC.e 0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8 instead of native USDC 0xaf88d065e77c8cC2239327C5EDb3A432268e5831
The remote GSM proposal for Arbitrum has taken some time to develop, vote and execute; the gears were in motion before the deprecation notice. Setting it up this way put no funds at risk, though native USDC has gained considerably more traction than the bridged version, so we expect limited usage in the current setup.
We’ve started working on a small proposal to wire up a new GSM using native USDC to the existing GHO reserve in Arbitrum (which is already funded), and deprecate the existing one.
The catch here is narrower than a misconfiguration and worth naming precisely: the GSM’s underlying is the stata wrapper over USDC.e, and USDC.e is already on the Low Adoption Asset Deprecation list, so a live GHO mint path on Arbitrum now points at an asset the DAO has separately voted to wind down. Given the reply that a native USDC GSM will be wired to the existing funded GHO reserve, the open question is sequencing, and there are three ways to run it.
Ship the native USDC GSM first and leave the USDC.e one live with mint capacity set to zero until inventory drains, which avoids any forced unwind but leaves two GSMs against one GHO reserve and a second accounting surface for anyone reading GHO backing on Arbitrum. Bundle the wire-up and the deprecation into one AIP with the USDC.e inventory unwound in the same payload, which is a heavier review but produces one atomic state change and no window where a deprecated wrapper is still a mint path. Leave it as is on the expectation of limited usage, which costs nothing today and costs the next person auditing GHO backing an hour of re-deriving why the deprecated leg exists.
Path two, because the exposure is a bookkeeping problem rather than a solvency one and bookkeeping problems are cheapest to close while the reserve balance is still small.
The more durable fix is upstream. This proposal was developed, voted and executed while USDC.e was already scheduled for deprecation, which means the deprecation list is not currently a check anywhere in the AIP pipeline. Making it one, so that any payload naming an asset on the active deprecation list has to restate the pairing before execution, is a smaller change than the GSM redeploy and prevents the next instance of exactly this.