Transfer AURA to GLC Safe
01Summary
Transfer 443,674 AURA tokens from the Aave Ethereum Treasury to the GHO Liquidity Committee (GLC) SAFE to consolidate AURA holdings. Upon locking, this will generate approximately 413,849.57 vlAURA, which the GLC will manage on behalf of the Aave DAO.
- Type
- treasury allocation
Key changes
- Transfer 443,674 AURA from Aave Mainnet Collector (Treasury) to GLC SAFE address(high)
- Consolidate AURA holdings with existing 845,090.43 vlAURA already held on GLC SAFE(high)
- Enable GLC to lock transferred AURA and generate approximately 413,849.57 additional vlAURA units(high)
Generated by Kvorum
02Description
Summary
This AIP will transfer the AURA holdings from the Ethereum Treasury to the GHO Liquidity Committee (GLC) SAFE.
Motivation
The Aave DAO holds 845,090.43 vlAURA on the GLC SAFE and also 443,674 AURA on the Treasury (Collector contract).
This AIP will transfer the AURA from the Treasury to the GLC SAFE, consolidating the vlAURA holdings. The Aave DAO is expected to receive ~413,849.57 units of vlAURA upon locking 443,674 AURA.
The GLC is tasked with locking the AURA and managing the vlAURA holdings on behalf of the Aave DAO.
Specification
This proposal encompasses the following actions:
- Transfer all AURA from the Aave Mainnet Collector to the GLC SAFE Address.
GLC SAFE Address: 0x205e795336610f5131Be52F09218AF19f0f3eC60
References
- Implementation: AaveV3Ethereum
- Tests: AaveV3Ethereum
- Snapshot
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal description states a single, clear action: move 443,674 AURA from the Aave Mainnet Collector to the GLC SAFE. The only decoded on-chain action is a call to `forwardPayloadForExecution`, which is Aave Governance V3's standard mechanism for dispatching a previously deployed payload contract (identified by id/controller address) for execution rather than embedding the transfer logic directly in this transaction. This pattern is routine for Aave AIPs and does not by itself reveal the token, amount, or recipient of the underlying transfer — that logic lives in the referenced payload contract (linked in the proposal's implementation/test files) which is outside the scope of the decoded calldata provided here. Because the calldata is an opaque dispatch call rather than the actual transfer, I cannot directly verify amounts or addresses against the prose, but there is also no evidence of any mismatch, unexpected target, or extra/missing action — the single action is consistent in kind (a governance-triggered treasury action) with what the description claims. Given the generic nature of the visible calldata, I rate confidence low, since a full verification would require inspecting the linked payload contract's bytecode, which is not available in this dataset. No discrepancies are flagged because none can be substantiated from the given data, and flagging based on the opacity of the dispatch mechanism alone would be a false alarm for a routine Aave governance execution pattern.
Generated by Kvorum
04Actions
- Target
- 0x9aee…2bc7
- Value
- 0 wei
- Function
- forwardPayloadForExecution((uint256,uint8,address,uint40))
- Arguments
{ "0": [ "1", "1", "0xdAbad81aF85554E9ae636395611C58F7eC1aAEc5", "32" ] }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.