0xMiden / 0xMiden/protocol

AggLayer: Add token remapping and migration support

Aperta
#2,704 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub
agglayer
Lingua principale
Rust
Stelle
132
Fork
167
Merge medio
1g 23h
PR unite (30g)
110

Descrizione

## 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.

Guida per i contributori

Apri la guida per i contributori

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.