Aeva Mainnet v1.1.1: aeUSD Comes to Every Wallet and App
Aeva Mainnet has completed its v1.1.1 network upgrade. It is a small release with a clear purpose: aeUSD, the dollar bridged in from Robinhood Chain, now works in every EVM wallet, contract and application on Aeva.
It was also the first upgrade on Aeva Mainnet to run fully automatically. The proposal was submitted and passed by governance, and at the scheduled block every node switched to the new software by itself. Block production paused for 2.7 seconds.
What changes for users
aeUSD is the settlement currency of Aeva. You receive it when you bridge USDG from Robinhood Chain, and it is the currency in which assets on Aeva settle and pay income.
Until now, aeUSD lived only on Aeva's native side. The chain could hold it, settle it and pay it out, but the EVM side of Aeva could not see it: MetaMask did not show it, and contracts such as the DEX could not trade it.
With v1.1.1, aeUSD has an ERC-20 interface. In practice:
It appears in MetaMask and other EVM wallets as aeUSD, with 6 decimals. It can be sent from any EVM wallet. It can be traded on Aeva's DEX, starting with an AEVA/aeUSD pool.
Any contract on Aeva can now work with it.
Nothing changes about aeUSD itself. It is still backed one to one by USDG locked in the bridge on Robinhood Chain, and it can still be bridged back at any time.
A note on naming: Aeva's testnet had an earlier native coin also called aeUSD. On mainnet it was never used and has a supply of zero. To avoid two tokens with the same name in wallets, its metadata now reads "aeUSD (legacy)".
Technical details
The rest of this post explains how the change works.
One coin, two interfaces
Aeva is built on the Cosmos SDK with an integrated EVM. Native coins live in the bank module; EVM tokens are contracts. The erc20 module connects the two through token pairs: a pair maps a bank denomination to an ERC-20 address, served by a precompile.
aeUSD on mainnet is the bank denomination minted by the bridge's usdg-rh route. v1.1.1 registers a token pair for it. The ERC-20 at the paired address is not a separate token and not a wrapper. It is a view onto the same bank balance: balanceOf returns the bank balance, totalSupply returns the bank supply, and an ERC-20 transfer moves the bank coin directly. There is exactly one aeUSD balance per account, reachable from both sides.
The address
Aeva derives the ERC-20 address of a native coin deterministically:
address = keccak256("aeva/coin/v1" || denom)[12:]
For bridged USDG this gives:
0x6F3D4d9994457e11cf88d5577A0b5ac457B2d78B
Anyone can recompute it from the denomination. The same scheme produces the existing address of native AEVA.
Why this needed an upgrade
The erc20 module's governance messages can register an existing EVM contract as a new coin, or toggle and configure pairs that already exist. None of them can give an existing bank coin an ERC-20 interface; in the upstream module, that path is reserved for coins arriving over IBC. So the registration had to be performed by the upgrade handler itself.
The handler does three things:
It registers the token pair for the coin of the usdg-rh route, and only if that route exists and is a synthetic inbound route.
It requires the coin's bank metadata to be present first, because the ERC-20's name, symbol and decimals are read from it.
It enables the pair as a plain ERC-20 precompile. aeUSD is not a gas coin, so it does not get the deposit and withdraw functions of a wrapped native token.
The legacy coin's metadata is renamed in the same handler. Its token pair, balances and supply are untouched.
What did not change
No balances, delegations, validators or bridge routes changed at the upgrade. The bridge's invariants hold as before: the USDG locked in the router on Robinhood Chain equals the supply of aeUSD on Aeva plus transfers in flight. After the upgrade, the ERC-20's totalSupply matches the bank supply of the bridged coin exactly.
How the upgrade ran
Release. v1.1.1 was built reproducibly from a tagged commit, and its checksums were signed with Aeva's release key. Binaries, checksums, signature, build provenance and the upgrade plan are published at releases.aevachain.com/v1.1.1.
Rehearsal. Before mainnet, the upgrade was rehearsed on a copy of mainnet's state, following the chain's real history, with every balance and delegation compared before and after.
Governance. The upgrade was proposed as an expedited proposal naming the plan, its height and the binary's checksum. It passed, and the plan was scheduled for block 523,629.
Automatic switch. Every Aeva node now runs under cosmovisor, the standard Cosmos process manager for upgrades. The new binary was staged in advance on every node and verified against the checksum in the approved plan. At block 523,629 the chain halted as planned, every node switched to v1.1.1 on its own, and blocks resumed 2.7 seconds later with all validators signing.
External validators upgrade their own nodes from the same signed release.
What's next
With aeUSD available on the EVM side, the first AEVA/aeUSD pool opens on Aeva's DEX, giving AEVA an on-chain dollar price on its own chain.
The next release, v1.2.0, follows the same path: a signed, rehearsed release, a governance vote and an automatic switch. It brings AE-20 bridging for tokens from Robinhood Chain, along with further protocol improvements. We'll publish its details closer to the vote.
aevachain.org · aevachain.app · releases.aevachain.com/v1.1.1
