AggLayer: Add faucet deregistration #2705
Description
Description
In the Solidity sovereign chain bridge (BridgeL2SovereignChain.sol), token mappings can be updated (which effectively replaces the old mapping) and legacy mappings can be explicitly removed via removeLegacySovereignTokenAddress(). Faucet deregistration (via token mapping removal) is something sovereign chains can opt into, not a hard requirement from the base bridge protocol.
The Miden bridge has no mechanism to deregister a faucet from the faucet_registry_map or token_registry_map. Once registered via CONFIG_AGG_BRIDGE, the faucet remains registered permanently. The faucet_registry_map stores [1, 0, 0, 0] for registered faucets (keyed by [0, 0, faucet_id_suffix, faucet_id_prefix]) and the token_registry_map stores the faucet ID (keyed by hash(originTokenAddress)). There is no procedure to write [0, 0, 0, 0] to either map.
Impact
A compromised, broken, or deprecated faucet remains authorized for bridge operations. Bridge-out operations will continue to accept assets targeting the compromised faucet (since assert_faucet_registered passes), and token registry lookups will continue to resolve to it. There is no way to revoke a faucet's authorization without deploying a new bridge.
Recommended Action
Add a deregister_faucet procedure gated by the bridge admin that clears a faucet from both the faucet registry and token registry maps, asserting the faucet was previously registered. After deregistration, both bridge-out and claim operations referencing the deregistered faucet will naturally fail their existing registration checks. Note that in-flight notes targeting a deregistered faucet will fail, so users should be warned before deregistration.
References
bridge_config.masm(register_faucet,assert_faucet_registered,lookup_faucet_by_token_address)config_note.rsBridgeL2SovereignChain.sol
Classification
This feature is part of the sovereign chain extension (BridgeL2SovereignChain), not the base bridge contract. Faucet deregistration (via token mapping removal) is something sovereign chains can opt into, not a hard requirement from the base bridge protocol.