I appreciate this initiative to improve UX for USDS, however, I believe that decisions around the bridge should come from Offchain Labs, and I would rather them even propose the change.
OCL is best positioned to evaluate if this causes any weird edge cases to the bridge and would ask that future initiatives get their tacit approval, before wasting your time and the community’s time with these minor, yet critical technical changes.
If OCL supports it we all will.
Hey @griff, we appreciate your concerns, please kindly note, that under the hood of this proposal both OCL and SKY were collaborating on this work, so both entities are fully aware of this situation and amount of work needs to be done to implement it.
Really excited about this proposal for integrating USDS/sUSDS into the Arbitrum Bridge. This integration stands to benefit both Arbitrum and Spark by providing users with a smoother, more efficient bridging experience—making it easier for new users to onboard and further solidifying Arbitrum’s position as a leading DeFi hub.
I also appreciate that multiple security audits have been conducted, which gives us greater confidence in the security and robustness of the implementation.
I agree with @Griff that this is essential, and it’s reassuring to know that OCL has its eyes on it. This collaboration and rigorous approach is exactly what we need to drive meaningful innovation while maintaining security across the ecosystem.
We’re approving this proposal because it’s logical and necessary, but that doesn’t mean there aren’t important questions to address.
What guarantees are there that SKY cannot arbitrarily modify gateways, such as freezing funds, without DAO approval? How does this ensure that the benefits don’t tilt more toward Spark/SKY rather than the broader Arbitrum ecosystem?
If SKY leaves the project, how is the continuity of the gateways and the USDS/sUSDS tokens ensured? Does this set a precedent for other projects requesting custom gateways? If so, is the DAO ready to handle such requests?
Lastly, while the proposal is clear and necessary, it almost feels like it cannot be rejected because there are no real alternatives for moving USDS/sUSDS. We are concerned that immediate utility might take priority over the long-term health of the ecosystem. Can we refine the DAO’s criteria for approving gateways? Will there be official guidelines for this, or is this being handled as a one-off case?
This proposal brings some solid benefits to the Arbitrum ecosystem—making it easier to bridge USDS and sUSDS, improving liquidity through Spark, and keeping DAO governance control intact, all without adding extra costs. The audits from ChainSecurity and Cantina are also reassuring. Big thanks to @spike_stablelab for the thoughtful responses so far and for laying everything out clearly.
That said, I think a few things could use more clarity to help the community feel even more confident moving forward:
Security Review & Arbitrum Foundation Involvement
Arbitrum Foundation (AF) might need to do an additional security review, either before or after the temperature check. Would Sky Ecosystem be open to that? Not because the audits so far aren’t solid, but just to add another layer of assurance.
Implementation Timeline & Execution Details
It’d be helpful to have a clearer timeline on when everything is expected to roll out. How long will the governance process take? When could we expect the update to the Router? Just having a rough roadmap would be great for setting expectations.
Transition Plan for Existing Users
Right now, users who bridged USDS/sUSDS through the default gateways will need to bridge back to Ethereum and then re-bridge through the Sky Custom Gateways. Is there a plan to communicate this clearly so users don’t get caught off guard? Also, any chance of gas rebates or incentives to help with the extra steps?
Long-Term Commitment & Maintenance
The Sky team mentioned that maintenance should be minimal since the gateways rely on Arbitrum’s native messaging layer, which is great. But just to be sure—does Sky plan to maintain and support these gateways long-term? Would be good to know if there’s a roadmap for future upgrades.
Overall, I think this proposal makes a lot of sense, and I’m excited to see it move forward. Just ironing out these last few details would make it even stronger. Looking forward to hearing more thoughts from the community!
On behalf of the UADP, We think Integrating USDS and sUSDS tokens into the Arbitrum Bridge by registering the Sky Custom Gateway contracts in the Router is a strategic move that enhances user experience and expands the stablecoin ecosystem on Arbitrum. By enabling seamless bridging through the official Arbitrum Bridge UI, users can efficiently access and utilize these tokens, fostering greater adoption and liquidity within the network. This integration not only simplifies the bridging process but also aligns with Arbitrum’s commitment to providing diverse and robust financial instruments to its community.
Overall, implementing this proposal would position Arbitrum as a more versatile platform for stablecoin transactions, benefiting both users and the broader DeFi ecosystem. We don’t see any downsides to this.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
This proposal is similar to the request that Rari proposed, where the setGateways() function was called on the L1GatewayRouter contract to register token gateways. Since most tokens that bridge to Arbitrum would need to come to the DAO with a proposal every time and ultimately, DAO delegates will have to rely on technical responses from OCL and the AF, why not allow OCL or AF to handle such requests directly for a period of 12 months?
They could submit a quarterly or bi-annual report or update in a dedicated post listing all the tokens added to the L1GatewayRouter contract. This would streamline the process and be similar to how power is delegated to elected/nominated entities for other programs like DIP, DAO Allocator Program, Stylus Sprint, and TMC.
As pointed out by most delegates, this proposal is a win-win for both Arbitrum and Sky. We welcome this initiative and hope to see a more structured process for future proposals.
I support this proposal overall—it solves a real issue and improves the user experience. But before moving forward, I’d like more clarity on security audits.
As a non-technical person, I want to understand how we can be sure there are no risks in the Sky Custom Gateway. Has this contract been audited by a reputable firm? If yes, can we see the report? If not, will SKY commit to an audit before implementation?
Security is a major concern when bridging assets, and I’d feel more comfortable if we had a clear risk assessment before making this change. If SKY can provide this assurance, I’m fully on board.
Thank you, @spike_stablelab, for this proposal.
This is a promising step forward for both Arbitrum’s ecosystem and the broader DeFi space. SKY’s pioneering work in DeFi has consistently driven innovation, and integrating their custom gateway contracts for USDS and sUSDS directly aligns with our shared vision of growing and enhancing the Arbitrum DeFi landscape. By streamlining the bridging process, we simplify user experience and expand the stablecoin ecosystem on Arbitrum, a key driver for increased adoption.
We appreciate that the code has undergone rigorous security audits by industry leaders like ChainSecurity, Cantina, and Certora, with Offchain Labs’ direct involvement. This collaborative vetting process adds a key layer of trust and integrity to the initiative.
relatively low risk (no user funds can be lost) as I understand, correct? (worst case users have to send fun backs to mainnet and then bridge again)
So in favour although I do have some concerns about how to manage things like this moving forward if the volume of requests increases (something to discuss another day)
Sky ecosystem owns the custom gateway, and the USDS, sUSDS tokens. Arbitrum DAO would not have any influence on the protocols governed by the Sky ecosystem.
There wouldn’t be a scenario where Sky Ecosystem would deprecate the custom gateways independently of the tokens, as they were deployed together as a single package and would likely be deprecated together as well.
The standard gateways do not work because both USDS and sUSDS tokens on Ethereum are upgradeable, and the only way to maintain their upgradeability on Arbitrum is through the use of custom gateways.
It appears that this matter is better addressed to Arbitrum DAO delegates.
Yes, more audits would certainly help.
The implementation timeline depends on input from multiple stakeholders across both the Sky and Arbitrum ecosystems. We are actively working with them and will share more detailed plan in the due course of events.
As one of the first steps, we have proactively collaborated with Offchain Labs, who have blocked all bridging for USDS and sUSDS from Ethereum to Arbitrum through the default gateways before the custom gateways launch to ensure users do not use the standard gateways in the first place. We’ll take more steps in the future to smooth out the process.
Sky Ecosystem has made a significant investment in developing custom gateways and is committed to maintaining and supporting these gateways over the long term.
It appears that this matter is better to be decided among DAO delegates.
We’ve had the code for the Sky custom gateways audited by ChainSecurity and Cantina. If you’d like to dive into the details, you can check out their reports here:
On top of that, we also used Certora to formally verify the code. You can explore all the formal verification specifications here:
https://github.com/makerdao/arbitrum-token-bridge/tree/master/certora
Sky Ecosystem maintains a set of general emergency response procedures to handle urgent situations like exploits. While this document isn’t gateway-specific, you can view the Sky Atlas Emergency Response System, maintained by Powerhouse, here: