0xMiden / 0xMiden/protocol

AggLayer: Add token remapping and migration support

Abierto
#2,704 0 comentarios 0 reacciones 0 asignados Ver en GitHub
agglayer
Lenguaje dominante
Rust
Estrellas
132
Forks
167
Merge medio
1 d 23 h
PR fusionados (30 d)
110

Descripción

## Description

The Solidity sovereign chain bridge ([`BridgeL2SovereignChain.sol`](https://github.com/agglayer/agglayer-contracts/blob/main/contracts/v2/sovereignChains/BridgeL2SovereignChain.sol)) supports updating token-to-wrapped-token mappings. The bridge manager can remap a `(originNetwork, originToken)` pair to a new sovereign token via `setMultipleSovereignTokenAddress()`, allowing token contract upgrades and migration of user balances from legacy to updated tokens via `migrateLegacyToken()`. Legacy mappings can be cleaned up with `removeLegacySovereignTokenAddress()`. Token remapping is something sovereign chains can opt into, not a hard requirement from the base bridge protocol.

The Miden bridge's [`register_faucet`](https://github.com/0xMiden/miden-base/blob/next/crates/miden-agglayer/asm/agglayer/bridge/bridge_config.masm) procedure writes to `faucet_registry_map` and `token_registry_map` but provides no explicit update or overwrite mechanism. If a faucet is registered with incorrect parameters (wrong scale, wrong metadata hash), or if the faucet contract needs to be upgraded, there is no way to update the mapping without deploying an entirely new bridge. The current `register_faucet` does silently overwrite existing entries (since `set_map_item` overwrites), but this behavior is not intentional and has no validation or event tracking.

## Impact

Token contract upgrades or parameter corrections are impossible post-registration through an intentional mechanism. Users holding bridged tokens on a deprecated faucet have no migration path.

## Recommended Action

Add an `update_faucet_mapping` procedure gated by the bridge admin that remaps a token from an old faucet to a new one, updating both the faucet and token registries. Also modify `register_faucet` to reject duplicate registrations, making the distinction between initial registration and updates explicit. Consider adding a user-facing token migration mechanism (burn old, mint new) as a follow-up.

## References

- [`bridge_config.masm`](https://github.com/0xMiden/miden-base/blob/next/crates/miden-agglayer/asm/agglayer/bridge/bridge_config.masm) (`register_faucet`)
- [`config_note.rs`](https://github.com/0xMiden/miden-base/blob/next/crates/miden-agglayer/src/config_note.rs)
- [`BridgeL2SovereignChain.sol`](https://github.com/agglayer/agglayer-contracts/blob/main/contracts/v2/sovereignChains/BridgeL2SovereignChain.sol)

## Classification

This feature is part of the sovereign chain extension (`BridgeL2SovereignChain`), not the base bridge contract. Token remapping is something sovereign chains can opt into, not a hard requirement from the base bridge protocol.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.