Note: this proposal will be subject to an individual Snapshot vote; if it reaches a quorum of 3% of votable $ARB, it may be combined with several other maintenance-related proposals for a joint Tally vote.

Abstract

This proposal seeks to disable the legacy USDT bridge for Arbitrum One, given the activation of the new USDT0 bridge in January 2025. While the majority of crosschain volume has migrated to the new USDT0 bridge, the legacy USDT bridge is still technically enabled. This proposal seeks to disable the legacy bridge entirely, rather than continue with the current configuration which subjects depositors to a week-long delay and risks loss of funds if the depositor is a smart contract.

Motivation

Historically, the existing USDT bridge for Arbitrum One was the primary path for bridging Tether to and from Arbitrum One. The new USDT0 standard introduced a modernized alternative that has become the go-to solution. However, the legacy USDT bridge is still technically enabled, which presents several issues.

First, withdrawals from the legacy bridge to L1 are subject to a seven-day delay, which is meaningfully slower than the new USDT0 bridge which can process bridge transactions in seconds or minutes. Also, once this delay has elapsed, deposits are auto-withdrawn on L1. This inconvenience can be addressed by disabling the legacy bridge and directing users exclusively to the new USDT0 bridge.

Second, user funds could be lost if a smart contract deposits to the legacy bridge on their behalf. The legacy bridge is currently configured to auto-withdraw funds as soon as possible back to the depositor; however, this auto-withdraw configuration can cause problems for smart contracts that deposit on behalf of end users but do not have withdrawal or refund functionality. While it’s possible to recover funds in this scenario, it is certainly sub-optimal for smart contract operators and end users that delegate to them. Disabling the legacy bridge prevents smart contracts from encountering this issue and putting funds at risk. Also, once the legacy bridge is disabled, any transaction submitted to it will simply revert; this applies to third party integrations as well as direct user interactions.

Key Terms

• USDT0: Tether’s new OFT-based version of USDT; more details here

• DisableGatewayAction: A smart contract action that disables a gateway for a specified token from the L1GatewayRouter; the DisableGatewayAction source code can be found here

Specifications

Deactivate Legacy Bridge: execute the ‘perform’ function on the DisableGatewayAction contract, disabling legacy USDT on the L1GatewayRouter contract

• DisableGatewayAction: 0x8d3425f7039645223517F6F6e60Ef04C28f4188F
• L1GatewayRouter: 0x72Ce9c846789fdB6fC1f34aC4AD25Dd9ef7031ef
• Legacy USDT: 0xdAC17F958D2ee523a2206206994597C13D831ec7

Steps to Implement

1. Contract Execution: call DisableGatewayAction contract to disable legacy USDT

• An audit report for the DisableGatewayAction contract can be found here

If this proposal passes a Snapshot vote successfully, it will be combined with other maintenance-related proposals for a unified Tally vote and on-chain payload. The portion of the Tally payload that covers the actions described in this proposal will be shared as soon as each individual proposal passes a Snapshot vote.

Timeline

The following timeline outlines proposed milestones from initial discussions to full implementation. Adjustments may be made based on community feedback and DAO governance requirements.

1. June 29th: AIP forum post outlining the proposed discontinuation of the legacy USDT bridge for Arbitrum One (requisite code has already been written, tested, and audited as of 12 March 2025)
2. July 24th: Temperature check held on Snapshot
3. August: Should the temperature check pass, as specified above, it will be included in the AIP draft combining several other maintenance-related proposals for a joint Tally vote
4. On-chain Tally vote: Will commence once all other maintenance-related proposals have passed the respective temperature checks on Snapshot
5. Post-on-chain Tally vote: Should the Tally vote pass, the total waiting period will be 11 days, after which the legacy bridge will be disabled
6. Perpetuity: post-deprecation, any transaction submitted to the legacy bridge will revert