thats awesome to be honest great idea
I’ve decided to vote in favor. I see no issue with registering them to the Router as it happened also with Rari. It seems like the integration has already been audited and green lighted so let’s push it live!
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas. It’s based on their combined research, fact-checking, and ideation.
We are voting FOR the proposal.
The request to register the Sky Custom Gateway contracts in the Router contracts so Arbitrum’s bridge can support USDS and sUSD seems straightforward and non-contentious. We’ve supported a similar proposal in the past (upgrading bridge configuration for RARI), and since ChainSecurity and Cantina’s audits didn’t find any issues, we don’t see a reason to vote against it.
One thing we’d like to bring up again, just as we did during the RARI vote, is that we should have a more streamlined process for making such adjustments and not require a fully-fledged constitutional vote. Perhaps we can figure out a solution where a trusted group, similar to Uniswap’s accountability committee, can handle such adjustments.
3 Likes
maybe the security council? after a successful offchain vote? I think this should be technically possible, no?
Technically it would be possible, of course, but I’m not sure if it’s a good idea to extend the scope of responsibilities of the Security Council. Definitely a good topic for a broader discussion.
3 Likes
gm, voting FOR - excited to improve the UX and support for the Sky Ecosystem.
This resonates strongly with a challenge we faced when working with Offchain Labs to add ERC7281 (crosschain token standard) support to the Arbitrum Bridge, a feature requested by multiple LRTs and other major token issuers.
The main issue: each token requires individual review to be added to the Arbitrum Ecosystem Router. We’ve been looking for ways to shift this burden and accountability from OCL to the DAO.
I’d fully support developing a governance solution for this.
Thanks
We support registering the Sky Custom Gateway contracts in the Router to enable USDS and sUSDS bridging via the Arbitrum Bridge UI. This enhances UX for users accessing SKY’s stablecoins and Spark’s upcoming liquidity and savings features, which will boost Arbitrum’s DeFi ecosystem with slippage-free stablecoin liquidity and yield opportunities. The audited Sky Custom Gateways ensure security and flexibility, aligning with Arbitrum’s growth goals at no direct cost to the DAO. We’ll vote “For” to enable this seamless integration.
A bit OT here but we are moving in a world in which we need a technical DAO solution for
- bridging related stuff like this one
- adjustment of timeboost parameters that are in the hand of the sequencer operator but should fall in the laps of the dao
- likely other things coming up.
Just food for thoughts
1 Like
I’m voting FOR this proposal on snapshot
SKY (formerly Maker) is the leading protocol issuing crypto-backed stablecoins (USDS). They have immense liquidity on the mainnet, and this UX improvement will make it easier for users to bring that liquidity to Arbitrum. It’s a no-brainer.
Voting For. Any steps we can take to reduce fractionalization is important, and at no cost to the DAO it’s really a no-brainer to approve. With Offchain willing to support, voting yes.
Edit: Edit to save forum space - I will maintain my “For” vote on Tally. I’ll only add that I agree with Griff / Dnielo / l2beat - this typ eof operational decision seems a little small in scope for the DAO, and I’ll add that any time you add a DAO vote you slow down processes in what is an otherwise fast pace, competitive space.
We support this proposal. The fact that this has no additional cost but also brings more users to Arbitrum due to the additional bridging to USDS means there is little downside, but a sizable upside that generates additional benefits for both the DAO and the average user.
- BoredApe90
We vote FOR the proposal on Snapshot.
As stated in our comment, we have no issue with the registrations of USDS and sUSDS tokens in the Router contracts. Also stated in the original comment and raised by other delegates, we would like to see a more streamlined process of requesting registrations of the tokens in the Router contracts in the future, but it’s not affecting the integrity of this proposal.
1 Like
As in @web3citizenxyz representation. Voting FOR. Below the rationale:
1 Like
I voted FOR in favour of the proposal. Sky’s launch of USDS and sUSDS on Arbitrum is a win for both Arbitrum and Sky. Adding the Sky Custom Gateways for USDS and sUSDS to the Arbitrum Bridge UI will ensure users receive the official token versions and enjoy an experience as seamless as bridging other tokens. In addition, since Sky Custom Gateways are designed to handle new tokens or upgrades in the future, it should benefit both Arbitrum and Sky long-term. With Spark’s upcoming launch of Spark Liquidity Layer and Spark Savings, this could draw more users and activity to Arbitrum. Those users may rely on the Arbitrum Bridge UI, so it would be beneficial if those users did not face any complications. There are no direct additional costs associated with the implementation, the audits by ChainSecurity and Cantina (with no issues found/only 2 informational findings), and formal verification by Certora; I do not see any reason to be against this proposal.
1 Like
DAOplomats voted FOR this proposal on Snapshot.
The proposal to register the Sky custom gateway appears straightforward, with the DAO retaining the ability to update the gateway if needed. Additionally, we recognize that the audit was conducted by reputable organizations, further reinforcing our confidence in the proposal.
Also, given that OCL is aware of this initiative, we were comfortable supporting it.
1 Like
Cross-posting here as an update on the state of the proposal:
Upon moving the proposal onchain, and before the voting period started, the Sky team noticed an error in the ETH value of the custom function that would make the proposal fail. The proposal has been Cancelled in Tally’s UI. However, it will still be active onchain and we encourage all delegates to vote against it as we prepare the corrected version to be submitted next Monday. We will work on a post-mortem, including further details to prevent this from happening in the future.
2 Likes
Post-Mortem: Sky Proposal Submission — Value Parameter Error
Summary
On June 9th, StableLab submitted an onchain governance proposal on behalf of the Sky team to deploy their custom gateway contract on Arbitrum. After submission and prior to the voting phase beginning, the Sky team identified a critical mistake in one of the transaction parameters: specifically, the value field was incorrectly set to 820,000,000,000,000 ETH instead of 0.00082 ETH as intended.
Fortunately, this error was caught before voting commenced and no funds or contracts were impacted.
This post-mortem is intended to transparently explain the cause, contributing factors, and propose improvements to avoid similar issues in future governance submissions.
Timeline
-
Preparation Phase:
The Sky team finalized the execution payload and provided all parameters to StableLab in a HackMD document, including calldata and execution details. -
Submission:
StableLab copied the parameters as provided into Tally’s proposal submission interface. At this point, no validation errors were triggered. -
Final confirmation:
The Sky team conducted a final review of the proposal payload to verify that the calldata and parameters matched the intended execution details prior to sponsorship. -
Karpatkey sponsoring:
Karpatkey submitted the proposal onchain as proposal sponsor to enter the governance voting pipeline. -
Error Discovery:
During the delay period prior to voting, the Sky team performed a final review and identified that the value parameter was misrepresented by several orders of magnitude:-
Submitted: 820000000000000 ETH
-
Intended: 0.00082 ETH
-
-
Root Issue Identified:
The confusion arose due to unit mismatches between ETH and wei units.
Root Cause
- Unit Mismatch:
The governance platform (Tally) requests the value field in ETH units (Image), while the proposal value was provided in wei units (820000000000000 wei = 0.00082 ETH). This unit specification can only be seen by the proposal author.
View of the execution payload edition by the proposal author.
- Missed verification:
The Proposal Draft raw data shows the wei value of the proposal payload. This incorrect value was missed upon onchain submission of the Proposal Draft.
View of the Proposal Draft raw data by Proposal author and external reviewers.
- Failed onchain simulation incorrectly displayed:
While Tenderly can successfully spot the difference between the correct and incorrect payload ETH value (Image), Tally UI shows in both cases a “Passed” simulation, preventing the author from noticing the failed simulation unless specifically checked.
View of the proposal draft including the incorrect payload ETH value.
View of the Proposal Draft Simulation pop-up including the incorrect payload value.
View of the Proposal Draft Simulation pop-up including the correct payload value.
Impact
-
The proposal contained an invalid execution payload that would have, if executed, resulted in an unrealistic value transfer.
-
The error was detected before voting started; no contract interaction or fund movement occurred.
-
The proposal will be voted against upon delegate coordination and re-submitted with corrected parameters.
Lessons Learned
1. Unit Clarity Is Critical:
The discrepancy between wei and ETH units remains a high-risk area in manual governance proposal submissions. While engineers and protocol teams may commonly work with wei, many governance platforms request ETH input, creating easy avenues for human error. It is essential that both proposal authors and reviewers apply extra caution when inputting and verifying value parameters.
2. Proactively verify Proposal onchain simulations:
Even when platform UI indicates simulations have passed, teams should manually check transaction simulations like Tenderly whenever available. These external verifications often provide deeper transparency into the transaction payload and can catch issues that UI layers may overlook. Establishing this manual verification step as a mandatory part of pre-submission workflows can help ensure that critical execution payloads receive full scrutiny, regardless of front-end simulation results.
3. Strengthen Simulation and Validation Workflows for Critical Parameters:
While external tools like Tenderly correctly flagged the excessive value transfer, Tally’s UI displays a “Passed” status despite the incorrect ETH transfer amount. Importantly, these simulations and validations should not be passively displayed and flagged issues must be clearly surfaced in the user interface when anomalies are detected.
Next Steps
-
StableLab will collaborate with the Sky team to resubmit the proposal with the corrected value parameter.
-
The governance community will be kept informed to ensure full transparency.
Closing Thoughts
As StableLab continues to assist teams in navigating governance submission processes, we recognize the importance of continuously improving internal controls and cross-team coordination to make Arbitrum governance stronger. We take full responsibility for the oversight and are committed to strengthening our validation procedures to prevent such incidents in the future.
We appreciate the Sky team’s diligence in catching the issue early, the Tally team for timely addressing the incident, preventing further confusion, and thank the Arbitrum community for its understanding.
Post-submission update
We submitted the corrected proposal onchain. Following the advice of Arbitrum Foundation, we switched to using manual ticket redemption in the calldata as outlined here. For this reason, the msg.value field in the tally proposal was set to 0.
5 Likes
Since the core governor on Arbitrum One (L2) isn’t expected to hold funds, we suggested to the proposal author that in order to reduce complexity, they should set the ETH value field to 0 and let the timelock executor on Ethereum (L1) pay the ETH when the call is executed. The proposal author accepted this suggestion and modified the proposal accordingly.
1 Like
The constitutional action registers a custom token bridging gateway contract (0x84b9700E28B23F873b82c1BEb23d86C091b6079E) for the USDS (0xdC035D45d973E3EC169d2276DDab16f1e407384F) and sUSDS (0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD) tokens to the Arb1 token bridge gateway router contract (0x72Ce9c846789fdB6fC1f34aC4AD25Dd9ef7031ef).
As a reminder, custom gateways are a key part of the bridging process and fully trusted with user balances of the specific tokens routed through them so this is a sensitive role. They can be used to enable customizations as to how bridging is done as is the case with this proposal.
1 Like