[CONSTITUTIONAL] Proposal: For Arbitrum DAO to register the Sky Custom Gateway contracts in the Router

[Tally_Support]

Voting has started for this proposal!
Vote on Tally: [CONSTITUTIONAL] Register the Sky Custom Gateway contracts in the Router

---

I am a bot. Questions? Contact support@tally.xyz

[danielM]

Voted FOR on Tally, my opinion remains the same: [CONSTITUTIONAL] Proposal: For Arbitrum DAO to register the Sky Custom Gateway contracts in the Router - #47 by danielM

[maxlomu]

Voted FOR on Tally as per my previous comment.

[Euphoria]

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.

Our reasoning remains the same as we shared during the Snapshot vote: registering Sky’s custom gateways is a practical fix that makes bridging USDS and sUSDS smoother for everyone, without adding new costs or unnecessary risks for the DAO.

One point we want to stress again is that these kinds of routine technical updates should ideally not need full governance cycles each time. Delegates end up relying on OCL and the AF for technical checks anyway. It makes sense to trust them to handle this directly for a limited period, with clear updates to keep the community in the loop.

This small change improves user experience today and can help us build a more efficient process for similar requests going forward.

[dragonawr]

I will be voting FOR on Tally due to the additional compatibility the contract’s registry will bring with no downsides, and given most security-related questions have already been properly answered.

[jameskbh]

I voted FOR on Tally. The reasoning remains the same, and I still think the DAO could benefit from something like this.

@jameskbh

A note not completely related to the proposal: A few delegates mentioned that we would benefit from a framework/standard for situations like this. I believe a template would suffice (we could pin it in the forum). That would be one of the categories we could create to make the proposals easier to interact with.

[paulofonseca]

voting Against on the current onchain vote because for some weird strange reason, we still don’t have the cancellable onchain proposals that Tally promised us more than one year ago, here at Arbitrum DAO, and all delegates still need to coordinate and vote against in an onchain proposal every time there is an onchain proposal that was published with errors in its payload.

[paulofonseca]

voting For on the current onchain vote with the ID 71020107401388505040510993373598301285550678565865201408741893567942851985019 because this will bring much more liquidity into Arbitrum.

[Griff]

Voted for on Tally. I really think we’re misusing the DAO’s time and attention here this process took way too long. These kinds of execution-level decisions are better left to an AAE like Offchain Labs, who are in the best position to handle them thoughtfully and safely.

[danielo]

in Favour, great to see this development.

I agree with Griff on the ideal being to migrate these smaller, more operational decisions to an operational unit and have the DAO able to overule or veto, but not required to vote every time.

[krst]

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 the proposal.

We have previously supported a similar proposal, and, just as we did then, we want to highlight that we need to establish a setup to perform such upgrades without requiring a full-fledged DAO vote. There have been other proposals in the past, as well as more recently, that would benefit from such a setup.

To avoid creating unnecessary overhead, we could explore an option where the OpCo assumes this responsibility, similar to how the Uniswap Accountability Committee (UAC) operates in Uniswap. However, since this isn’t a straightforward implementation, where we could assign a role to someone, but rather something that requires a custom-built solution, perhaps the Foundation, together with Offchain Labs, could take it on temporarily.

[ocandocrypto]

As in @web3citizenxyz representation, voting for. Below the rationale:

Web3 Citizen Delegate Communication Thread

Tally: Sky Custom Gateway We are voting FOR. We’re supporting this proposal for the same reasons in snapshot.

[SEEDGov]

After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Tally Vote.

Rationale

This is a no-brainer, the contracts have passed security requirements, and we still emphasize that we should remove barriers to provide a more streamlined process to the builders for them to migrate tokens to Arbitrum and use our native bridge.
There are clear frictions for teams to do this as can be noted in the post made by @Jose_StableLab:

@Jose_StableLab

Thank you @AbdullahUmar for raising awareness about the complexities around launching a custom gateway on Arbitrum.

As StableLab, we’ve been closely working with the Sky team throughout their custom gateway proposal process, and we’d like to share our perspective on the experience so far:

• The Sky proposal is still in progress. While much of the technical and procedural work has been completed, there are still critical steps required before the proposal is ready for onchain submission.
• All of the Sky-side code has been audited, as correctly noted in the proposal. The team has taken their due diligence seriously to ensure security and correctness.
• Regarding Offchain Labs’ involvement, when approached, they provided the governance action contract and the required governance documentation necessary for executing it to achieve the Router update. However, they asked Sky to conduct their own review of the governance action contract and prepare and check the governance transaction payload themselves.
• Because the governance execution itself must also be verified, the Sky team has independently engaged a separate security firm to audit and validate the governance actions. Importantly, they are covering these costs themselves.
• We’ve also reached out to the $BORING team to support their efforts as well. However, due to the differing stages of their respective processes and some technical differences between both proposals, it’s likely that the two gateway proposals will proceed onchain separately. This is necessary to prevent delays in Sky’s timeline for launching USDS on Arbitrum.

Overall, we believe the current process for deploying custom gateways on Arbitrum, while secure, is highly resource-intensive and time-consuming. This creates a significant burden for projects looking to integrate with Arbitrum, particularly those without access to deep technical or auditing resources.

We think it’s worth opening a discussion on whether this process can be streamlined in the future, without compromising on security or decentralization, to reduce the overhead for teams launching in the Arbitrum ecosystem.

[Tane]

We vote for this proposal.

Our opinion has not changed from the Snapshot vote.
No material issues emerged in review, and registering Sky’s gateway is routine operational work that shouldn’t require extensive DAO deliberation.

[BlockworksResearch]

Blockworks Advisory voted for this proposal.

Our opinion has not changed from the beginning of this proposal, and we’d like to support the Sky community on Arbitrum in anyway that we can. However, for future reference, it might be worth pushing these votes to the security/audit council rather than having them subject to a vote by the entire DAO.

[AlexLumley]

Why I’m Voting FOR
I’m voting FOR this proposal because it hands off routine, low-risk gateway registrations to a specialized operations layer, freeing the DAO to focus on strategic decisions. As Danielo Ospina and Griff said, smaller config changes—such as adding Sky’s USDS and sUSDS to the Router—shouldn’t require full governance votes each time, provided there’s an override mechanism. These contracts are already live on Base with prior audits, and Offchain Labs has co-reviewed the integration. Enabling one-click bridging for these stablecoins will drive liquidity, expand use cases, and reinforce our commitment to seamless DeFi UX, all under an established timelock and fallback path.

Analysis buckets

• Treasury impact: No direct ARB spend; leverages existing audits and dev resources.
• Alignment: Supports a delegated process and UX efficiency.
• Execution design: Joint Sky/OCL testing plan; standard timelock enables safe deployment.
• Community optics: Shows agile decision-making while upholding security norms.

Forum thread | Snapshot

[blockful]

We are voting FOR the proposal.
Integrating Sky and USDS into Arbitrum is a meaningful step for both sides. It makes it easier for Sky users to access Arbitrum and gives Arbitrum users a safer way to engage with Sky and USDS.

CallData review is part of our work for ENS DAO, and it’s also included in the service scope at anticapture.com. In case StableLab or Sky need support with this or future proposals, we’re happy to help ensure things run smoothly onchain.

[0x_ultra]

I am confirming my support on this on-chain vote, in line with my previous statement here: [CONSTITUTIONAL] Proposal: For Arbitrum DAO to register the Sky Custom Gateway contracts in the Router - #65 by 0x_ultra

[WinVerse]

DAOplomats is voting FOR on Tally.

We are maintaining our vote from the temp check.

[Tally_Support]

Onchain voting for this proposal is ending within 24 hours:
[Vote on Tally: [CONSTITUTIONAL] Register the Sky Custom Gateway contracts in the Router](https://www.tally.xyz/gov/eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9/proposal/2616193137172809132)
* * *
I am a bot. Questions? Contact support@tally.xyz