title: [ARFC] Permissioned GSM - USAT Aave V4 Avalanche
author: @TokenLogic
created: 2026-10-15
Summary
TokenLogic proposes a Permissioned GHO Stability Module (GSM) that allows approved counterparties to exchange eligible assets for GHO and vice versa. The module would retain the existing GSM functionality while introducing participant-level access controls.
The first application would support USAT on Avalanche. Under this arrangement, USAT remains supplied to Aave V4 while the GSM holds waUSAT, the receipt token representing the supplied USAT. The proposal includes the funding and configuration needed to launch this instance.
Motivation
Existing GSMs allow users to exchange supported assets for GHO within governance-defined limits. However, some institutional arrangements require restricting access to approved counterparties, particularly when specific commercial terms or asset requirements apply.
A Permissioned GSM would support these arrangements without changing existing GSM exchange functionality.
Initial Application: USAT
USAT is a USD-backed stablecoin issued by Anchorage Digital Bank, N.A.
An approved counterparty would deposit USAT into the Aave V4 Tokenization Spoke and receive waUSAT. The counterparty would then separately exchange waUSAT for GHO through the Permissioned GSM, which would hold the waUSAT. Returning GHO would allow the counterparty to recover waUSAT. Redemption for underlying USAT would depend on the selected integration and available liquidity.
The same framework could support additional assets and counterparties. Multiple approved participants could share a GSM instance under the same configuration, while existing permissionless GSMs would remain unaffected.
Permissioned Access
Permissioning would apply to the swap originator in both directions. Approved participants could specify another recipient or use a relayer to submit a valid signed swap. Neither the recipient nor the relayer would require separate participant approval.
GHO received through the module would remain freely transferable. Revoking a participant’s approval would prevent further swaps, including exchanges intended to recover previously deposited assets.
Liquidity and Exposure Management
Each instance would operate with shared liquidity, allowing approved counterparties to exchange against the same pool under governance-defined limits. Liquidity would not be reserved for individual participants. The module would not track individual principal balances or require a participant’s swaps to match their previous deposits.
The reserve supplies the GHO needed for swaps. The Remote GSM Draw Limit caps the GSM’s use of that reserve. The Exposure Cap limits additional asset inflows through swaps. Exchange fees and any applicable accrued yield go to the configured treasury.
The exposure cap would be denominated in the configured asset, including share units where applicable. Exchanges would remain subject to sufficient available liquidity, independently of the configured limits.
Administration and Emergency Controls
Governance would assign configuration and emergency permissions.
The selected GSM implementation would retain its emergency controls, including the ability to freeze exchanges. Seizure transfers assets held by the module to the designated treasury and prevents further exchanges through the instance.
Revocation, freezing or insufficient liquidity could prevent counterparties from reversing an exchange. These restrictions would need to be reflected in the relevant counterparty agreements.
Specification
TokenLogic proposes deploying a permissioned remoteGSM on Avalanche to exchange waUSAT for GHO and vice versa.
Funding the GSM
A new GHO Reserve on Avalanche would provide GHO for the USAT GSM. We would bridge the initial allocation to the Avalanche Collector, which would then transfer the funds to the reserve. To support this transfer, we would increase the bridge limits and refill rates, then apply the ongoing settings once the transfer is complete, as we have done previously when deploying new GSMs on Plasma, Monad, and Arbitrum.
Access and Administration
The initial whitelist would include the commercial counterparty and an Aave DAO Safe, controlled by the Aave Finance Committee. Both would use the same shared liquidity and pricing, with GHO required to receive waUSAT. GHO Stewards would manage the exposure cap and swap fees within the proposed limits. The reserve limit manager would control the GSM’s GHO draw allowance through LIMIT_MANAGER_ROLE.
Only the GHO Stewards Safe (0x8513e6F37dBc52De87b166980Fa3F50639694B60) would be authorized to call the GHO GSM Steward’s parameter-update functions.
Initial USAT Configuration
| Parameter | Proposed Configuration |
|---|---|
| Network | Avalanche |
| Underlying Asset | USAT |
| Underlying Asset Address | [TBD] |
| Aave Market | Aave V4 |
| Configured GSM Asset | waUSAT |
| Receipt Token Address | [TBD] |
| GSM Implementation | Permissioned remoteGSM |
| Approved Counterparty Address | [TBD] |
| Approved Aave DAO Safe | 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa |
Liquidity and Economic Parameters
| Parameter | Proposed Configuration |
|---|---|
| GHO Reserve | New Avalanche reserve; [TBD] |
| Remote GSM Draw Limit | 25,000,000 GHO |
| Initial GHO Funding | 65,000,000 GHO |
| GHO Funding Source | 0x5ba7fd868c40c16f7aDfAe6CF87121E13FC2F7a0 |
| waUSAT Exposure Cap | 20,000,000 waUSAT |
| Buy Fee (GHO → waUSAT) | 0 |
| Sell Fee (waUSAT → GHO) | 0 |
| Pricing Strategy | TBD; address: [TBD] |
| Receipt Token Conversion | 1:1 |
| Fee and Yield Recipient | Configured treasury: 0x5ba7fd868c40c16f7aDfAe6CF87121E13FC2F7a0 |
| Fee Strategy | TBD; address: [TBD] |
| Automatic Freeze Strategy / Oracle | Selection TBD; strategy [TBD] and oracle [TBD], if selected |
| Freeze Lower Bound | $0.990 USAT/USD |
| Freeze Upper Bound | $1.010 USAT/USD |
| Unfreeze Lower Bound | $0.995 USAT/USD |
| Unfreeze Upper Bound | $1.005 USAT/USD |
Bridge Configuration
| Parameter | Proposed Configuration |
|---|---|
| Funding Route and Bridge Endpoint Source | 0x7F2f96fcdC3A29Be75938d2aC3D92E7006919fe6 (Mainnet AaveGhoCcipBridge) |
| Funding Route and Bridge Endpoint Destination | 0xaf9f841de7477f35d6339943c1e6f0c101bca621 (Avalanche AaveGhoCcipBridge) |
| Initial Inbound Capacity (GHO) | 5,000,000 (unchanged) |
| Initial Outbound Capacity (GHO) | 66,000,000 (Initial GHO funding * 110%) |
| Initial Refill Rate (GHO/s) | 65,999,999 (initial outbound capacity - 1) |
| Ongoing Inbound Capacity (GHO) | 5,000,000 (current) |
| Ongoing Outbound Capacity (GHO) | 5,000,000 (current) |
| Ongoing Refill Rate (GHO/s) | 1,000 (current) |
| Bridge Bucket Capacity (GHO) | 250,000,000 (Current + Initial GHO Funding) |
| Transition to Ongoing Settings | After the initial funding transfer |
Administration and Permissions
| Parameter | Proposed Configuration |
|---|---|
| Configuration Administrator | Governance 0x3C06dce358add17aAf230f2234bCCC4afd50d090, with delegated GHO GSM Steward 0x8513e6F37dBc52De87b166980Fa3F50639694B60 permissions as proposed below |
| Reserve Limit Manager | GHO Stewards admin 0x8513e6F37dBc52De87b166980Fa3F50639694B60; LIMIT_MANAGER_ROLE |
| Steward Exposure Cap Change Limit | ±100% |
| Steward Buy/Sell Fee Change Limit | ±0.5 percentage points for each direction |
| Freeze Authority | Governance and Oracle Swap Freezer (TBD) |
| Seizure Authority | Governance 0x3C06dce358add17aAf230f2234bCCC4afd50d090 |
| Treasury Address | 0x5ba7fd868c40c16f7aDfAe6CF87121E13FC2F7a0; same configured recipient for fees and applicable yield |
The proposed exposure-cap and fee adjustment limits allow increases and decreases, as defined in this post.
Disclaimer
TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.
TokenLogic supports and maintains an independent delegate voting platform within the Aave community.
TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.
Next Steps
Following community feedback, TokenLogic will submit the proposal to a Snapshot vote. If approved, TokenLogic will submit an AIP to implement it.
Copyright
Copyright and related rights waived via CC0.