I have voted FOR this proposal. This is the more logical things to do for users, and I trust AF to provide a clear and safe offboarding process.
We acknowledge the logic behind this proposal and understand the benefits of disabling the legacy USDT bridge, particularly in reducing UX friction and preventing edge cases involving smart contracts and delayed withdrawals. From a technical maintenance perspective, this makes sense.
However, we’re choosing to abstain from this vote in alignment with concerns raised by @Sinkas
While the migration to USDT0 has already happened and most liquidity has moved accordingly, the decision to adopt LayerZero’s OFT-based bridge was made unilaterally by Tether and Offchain Labs, without any involvement from Arbitrum DAO. As a result, the DAO no longer controls the bridging infrastructure for one of the most widely used stablecoins on Arbitrum.
This proposal may appear procedural, but in effect, it formalizes a shift toward a bridging model with new trust assumptions, around lockbox ownership, verifier networks, and protocol-level upgradability, that were never openly discussed or approved by the DAO.
We are not opposed to cleaning up unused or problematic infrastructure, but we believe it’s important to be cautious about what our votes may implicitly signal. In this case, while disabling the legacy bridge seems reasonable, fully endorsing the current USDT0 setup without broader discussion on governance, control, and risk is something we’re not yet comfortable with.
For that reason, we’re abstaining.
I voted FOR this proposal. Tether moved away from the canonical bridge and having it still working brings no benefits for the DAO.
DAOplomats voted FOR this proposal on Snapshot.
Disabling the legacy Tether bridge is the most optimal path forward, as it no longer meets current security and operational standards.
Since all known integrators have transitioned to the new USDT0 bridge, and clear public communications have been made, this is a necessary step to protect users and streamline the bridging experience.
Voting for. It’s not doing anything useful anymore, just going to confuse users… The UX of crypto is bad enough already without needing a bridge to a dead end.
Voting FOR this proposal. The feature is already dysfunctional, so removing it is the most practical solution.
Disabling the legacy bridge removes all of the negatives associated with its existence, while offering no real benefits in keeping it active. In my view, voting FOR in this case is the only reasonable choice.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’re voting ABSTAIN.
As we hinted in our original comment, we are abstaining from this vote. We offered a full breakdown of the points that led us to this decision here.
Voting to disable, easy yes
I believe it’s important to close up ‘loose ends’ as new upgrades roll out. While there realistically is little risk, no sense in leaving that open. Nor should we create a scenario where using Tether’s product is more confusing then it needs to be for user experience improvement.
Edit 9.4.2025: Editing to save forum space as my opinion has not changed since snapshot - I will be voting to approve on tally as this improves user expierence
I have voted in favour of this proposal. Having multiple bridges is confusing, liquidity gets fragmented, and users don’t understand if they are getting a different version of the token they need to use. Having USDT’s official bridge usdt0 simplifies UX. Makes sense to deprecate legacy one.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
We support the proposal to disable the legacy USDT bridge on Arbitrum One. Maintaining two bridging pathways creates unnecessary UX confusion and exposes smart contract users to risk. USDT0 is now the canonical, audited, and efficient path. This AIP is timely, technically sound, and helps future-proof the bridging infrastructure.
We echo the proposer’s suggestion that a clear communication plan accompany the change to minimize user disruption and ensure third-party integration awareness.
can we pretty please get some independent verification that the payload on the onchain proposal actually does what it says it does?
@offchainlabs @Frisson @krst @GFXlabs and so on?
ideally, before more people vote on it without verifying it.
We’ve reviewed the payload, and have verified that the payload accomplishes what the proposal text states - disabling the legacy Tether bridge. As always, we also welcome the results of others’ independent review, as applicable.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We voted FOR.
During the temp-check stage, we supported the Removal of the Cost Cap on Nova and the Update of the Upgrade Executors, and we continue to support these changes for the onchain vote. On the other hand, we abstained on the Disable Legacy Tether Bridge proposal because we were not comfortable endorsing the USDT0 setup and the liveness and safety trust assumptions associated with it (you can read our full rationale here).
In our view, this concern does not prevent us from voting in favor of the broader package, as long as we’re clear that our favorable vote in the onchain vote does not translate to an endorsement of the USDT0 setup, just like in the off-chain vote.
However, on the occasion of this vote, we’d like to point out the obvious challenge of bundling proposals together for the onchain vote. If we had been fully opposed to the proposal to disable the legacy USDT bridge, it would have made voting for this proposal impossible. We do understand that bundling proposals together saves time and makes it easier to meet quorum, but at the same time, it introduces different problems that are not necessarily outweighed.
Before casting our vote, and since it’s a technical proposal, we asked L2BEAT’s research team to review and confirm the contents of the executable payload. They confirmed that the contents matched the outlined changes, without adding anything that shouldn’t be there.
Here’s the breakdown of the changes reviewed and confirmed by our research team:
- Updating the Upgrade Executors (Ethereum / Arbitrum One / Arbitrum Nova)
-
L1 (Ethereum):
targets[0] = UpgradeExecutor 0x3ffF...c3CeDdwith payloadProxyUpgradeAction.perform(ProxyAdmin 0x5613...0678, target 0x3ffF...c3CeDd, newLogic 0x3d745b...7932)→ upgrades the L1 Upgrade Executor implementation to the new one. This address is listed in the DAO’s official deployment table. -
Arbitrum One (via L1 Inbox 0x4dbd…AB3f):
targets[1]posts to Inbox → L2 call toUpgradeExecutor 0xCF57...A827withProxyUpgradeAction.perform(ProxyAdmin 0xDB21...961e, target 0xCF57...A827, newLogic 0x3d745b...7932). Addresses match the DAO docs. -
Arbitrum Nova (via L1 Inbox 0xC444…3949):
targets[2]posts to Inbox → L2 call toUpgradeExecutor 0x86a0...7482withProxyUpgradeAction.perform(ProxyAdmin 0xF58e...C2b9, target 0x86a0...7482, newLogic 0x3d745b...7932). Addresses match the DAO docs.
- Disabling Legacy USDT0 Bridge (L1)
-
L1 action:
targets[3] = DisableGatewayAction 0x8d34...4188fwithperform([USDT 0xdAC1...1ec7], _maxGas=0, _gasPriceBid=0, _maxSubmissionCost=5e14)and the batch’s only non-zero msg.value (values[3] = 500,000,000,000,000 wei) funding the retryable ticket. This matches the “Disable Legacy Tether Bridge” spec; the router address in the spec is the canonical L1GatewayRouter 0x72Ce…31ef.
- Removing Arbitrum Nova’s amortized cost cap (L2 Arbitrum Nova)
-
L1→Nova call:
targets[4]posts to Nova Inbox → L2 call toUpgradeExecutor 0x86a0...7482usingexecuteCallto directly call the ArbOwner precompile0x000...0070withsetAmortizedCostCapBips(0), setting it to 0 is the documented way to remove/disable the cap.
Timelock details match
- Function:
sendTxToL1(L1ArbitrumTimelock 0xE684...7f49, scheduleBatch(...))is the right L1 timelock - Delay:
259,200seconds = 3 days, which matches the constitutional L1 execution delay shown in the Tally timeline
Extra checks
- Inboxes used are the correct contracts for Arb One (
0x4dbd…AB3f) and Nova (0xC444…3949) - DAO addresses (Upgrade Executors, ProxyAdmins) match the official deployment list.
you guys deserve 30 Bonus Points just for this. thank you! cc/@SEEDGov
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
We are voting FOR this proposal in the Tally voting.
The current on-chain proposal makes three sensible changes that improve sustainability, operations, and user safety. Removing the amortized cost cap on Arbitrum Nova aligns fees with real L1 posting costs after EIP-4844, ends a recurring subsidy, and fits Nova’s current role as Orbit adoption grows. Updating the DAO’s Upgrade Executors to include executeCall() reduces overhead for future upgrades while keeping execute() available, and the published Trail of Bits review on the new path gives comfort on security intent. Disabling the legacy USDT bridge and consolidating on USDT0 removes a source of confusion and edge-case risk for contracts that cannot handle the legacy auto-withdraw behavior.
We also want to acknowledge L2BEAT’s rationale and thank them for their technical review of the executable payload. Their team confirmed that the targets and params match the stated intent, that the DAO addresses and ProxyAdmin references match the deployment list, that the correct Inbox contracts are used for Arbitrum One and Nova, and that the constitutional L1 timelock and delay align with the execution timeline. We value this kind of independent payload verification. We also note their point about the tradeoffs of bundling. In principle, we prefer single-topic on-chain votes when feasible. In this case, we believe the net effect of the bundle is clearly positive and supports the DAO’s long-term interests, so we are comfortable voting FOR while recognizing that some delegates have reservations about the USDT0 trust assumptions separate from this execution.
The Nova change reduces deficits, the executor upgrade streamlines governance work, and the bridge change improves user safety. Taken together, the proposal strengthens the network’s sustainability and operational clarity. Hence, we will vote FOR.
voted For on this past offchain vote because its creating confusion right now.
voted For on this onchain vote because these are all things that I’ve voted For before on their respective offchain votes. I do feel like these proposals should not be bundled together and that delegates should be provided a way to verify that the payload of the onchain proposals actually match what the proposal says.