Proposal: For Arbitrum DAO to register the Sky Custom Gateway contracts in the Router
Constitutional
This is a draft proposal by SKY to request comments from the community, to correct and finalize this document before submitting to Snapshot for voting by Arbitrum DAO.
Abstract
SKY has launched support for USDS and sUSDS tokens on Arbitrum. This proposal requests Arbitrum DAO to register the Sky Custom Gateway contracts in the Router contracts to allow users bridging USDS and sUSDS through the official Arbitrum Bridge UI.
Motivation
SKY has formally introduced support for USDS and sUSDS tokens on the Arbitrum network, and Spark is set to soon launch Spark Liquidity Layer and Spark Savings (https://spark.fi). The Spark Liquidity Layer will deploy liquidity on Arbitrum to provide slippage-free liquidity for USDC, USDS, and sUSDS tokens natively through a Peg Stability Module (PSM). Arbitrum users will have access to this through Spark Savings (https://app.spark.fi/), enabling stablecoin holders to earn the Sky Savings Rate.
The Arbitrum Ecosystem’s Router contracts maintain a list of gateways used for bridging various L1/L2 tokens to/from Arbitrum. The Arbitrum Bridge UI relies on the routers for gateway information when bridging tokens. Currently, USDS and sUSDS tokens are routed through the default gateways rather than the Sky Custom Gateways. As a result, the Arbitrum team has disabled bridging USDS and sUSDS through the Arbitrum Bridge, creating a suboptimal UX. This means that users will have access to USDS and sUSDS on Arbitrum, and Spark will deploy liquidity there, however, they won’t be able to use the Arbitrum Bridge UI to transfer USDS and sUSDS to Arbitrum.
Rationale
This proposal seeks to update the Router configuration to utilize the Sky Custom Gateways for USDS and sUSDS tokens that are live on Arbitrum, ensuring users receive the official token versions when they use the Router contracts through the Arbitrum Bridge UI.
Sky Custom Gateway
The Sky Custom L1 Gateway on Arbitrum currently bridges USDS and sUSDS tokens from Ethereum to Arbitrum. Sky Custom Gateways are designed to enable Sky governance to extend support to new Sky ecosystem tokens in the future and also perform essential maintenance operations, such as bridge or token upgrades. Additionally, the Sky Custom L1 Gateway leverages a pre-deployed Escrow contract, which is also used by the DAI token, one of the first tokens bridged to Arbitrum.
Key terms
USDS – Stablecoin
sUSDS – Savings USDS (Stablecoin + Yield)
Specifications
Current Status
The Sky Custom Bridge, along with USDS and sUSDS tokens, is currently live on Arbitrum and available for end-user access. Additionally, Spark is set to deploy significant stablecoins liquidity (USDC, USDS and sUSDS) through the Spark Liquidity Layer and will launch Spark Savings, allowing Arbitrum stablecoin holders to access the Sky Saving Rate (available at https://app.spark.fi/) USDS address on Ethereum - https://etherscan.io/address/0xdC035D45d973E3EC169d2276DDab16f1e407384F
sUSDS address on Ethereum - https://etherscan.io/address/0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD
Sky Custom Gateway on Ethereum - https://etherscan.io/address/0x84b9700e28b23f873b82c1beb23d86c091b6079e
Sky Custom Gateway on Arbitrum - https://arbiscan.io/address/0x13f7f24ca959359a4d710d32c715d4bce273c793
Official USDS address on Arbitrum - https://arbiscan.io/token/0x6491c05a82219b8d1479057361ff1654749b876b
Official sUSDS address on Arbitrum - https://arbiscan.io/token/0xdDb46999F8891663a8F2828d25298f70416d7610
Deployment Details
We propose the execution of the setGateways method [1] on the L1GatewayRouter contract [2] on Ethereum for both USDS and sUSDS tokens. This action will register the official USDS and sUSDS tokens along with the Sky Custom Gateway contracts on the Router. Upon approval, the Sky team will collaborate with Offchain Labs to develop and submit an executable proposal for a DAO vote.
[2] https://etherscan.io/address/0x72Ce9c846789fdB6fC1f34aC4AD25Dd9ef7031ef
Overall Costs
There are no direct additional costs associated with this proposal.
Proposal: For Arbitrum DAO to register the Sky Custom Gateway contracts in the Router
Constitutional
This is a draft proposal by SKY to request comments from the community, to correct and finalize this document before submitting to Snapshot for voting by Arbitrum DAO.
Abstract
SKY has launched support for USDS and sUSDS tokens on Arbitrum. This proposal requests Arbitrum DAO to register the Sky Custom Gateway contracts in the Router contracts to allow users bridging USDS and sUSDS through the official Arbitrum Bridge UI.
Motivation
SKY has formally introduced support for USDS and sUSDS tokens on the Arbitrum network, and Spark is set to soon launch Spark Liquidity Layer and Spark Savings (https://spark.fi). The Spark Liquidity Layer will deploy liquidity on Arbitrum to provide slippage-free liquidity for USDC, USDS, and sUSDS tokens natively through a Peg Stability Module (PSM). Arbitrum users will have access to this through Spark Savings (https://app.spark.fi/), enabling stablecoin holders to earn the Sky Savings Rate.
The Arbitrum Ecosystem’s Router contracts maintain a list of gateways used for bridging various L1/L2 tokens to/from Arbitrum. The Arbitrum Bridge UI relies on the routers for gateway information when bridging tokens. Currently, USDS and sUSDS tokens are routed through the default gateways rather than the Sky Custom Gateways. As a result, the Arbitrum team has disabled bridging USDS and sUSDS through the Arbitrum Bridge, creating a suboptimal UX. This means that users will have access to USDS and sUSDS on Arbitrum, and Spark will deploy liquidity there, however, they won’t be able to use the Arbitrum Bridge UI to transfer USDS and sUSDS to Arbitrum.
Rationale
This proposal seeks to update the Router configuration to utilize the Sky Custom Gateways for USDS and sUSDS tokens that are live on Arbitrum, ensuring users receive the official token versions when they use the Router contracts through the Arbitrum Bridge UI.
Sky Custom Gateway
The Sky Custom L1 Gateway on Arbitrum currently bridges USDS and sUSDS tokens from Ethereum to Arbitrum. Sky Custom Gateways are designed to enable Sky governance to extend support to new Sky ecosystem tokens in the future and also perform essential maintenance operations, such as bridge or token upgrades. Additionally, the Sky Custom L1 Gateway leverages a pre-deployed Escrow contract, which is also used by the DAI token, one of the first tokens bridged to Arbitrum.
Key terms
USDS – Stablecoin
sUSDS – Savings USDS (Stablecoin + Yield)
Specifications
Current Status
The Sky Custom Bridge, along with USDS and sUSDS tokens, is currently live on Arbitrum and available for end-user access. Additionally, Spark is set to deploy significant stablecoins liquidity (USDC, USDS and sUSDS) through the Spark Liquidity Layer and will launch Spark Savings, allowing Arbitrum stablecoin holders to access the Sky Saving Rate (available at https://app.spark.fi/) USDS address on Ethereum - https://etherscan.io/address/0xdC035D45d973E3EC169d2276DDab16f1e407384F
sUSDS address on Ethereum - https://etherscan.io/address/0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD
Sky Custom Gateway on Ethereum - https://etherscan.io/address/0x84b9700e28b23f873b82c1beb23d86c091b6079e
Sky Custom Gateway on Arbitrum - https://arbiscan.io/address/0x13f7f24ca959359a4d710d32c715d4bce273c793
Official USDS address on Arbitrum - https://arbiscan.io/token/0x6491c05a82219b8d1479057361ff1654749b876b
Official sUSDS address on Arbitrum - https://arbiscan.io/token/0xdDb46999F8891663a8F2828d25298f70416d7610
Deployment Details
We propose the execution of the setGateways method [1] on the L1GatewayRouter contract [2] on Ethereum for both USDS and sUSDS tokens. This action will register the official USDS and sUSDS tokens along with the Sky Custom Gateway contracts on the Router. Upon approval, the Sky team will collaborate with Offchain Labs to develop and submit an executable proposal for a DAO vote.
[2] https://etherscan.io/address/0x72Ce9c846789fdB6fC1f34aC4AD25Dd9ef7031ef
Overall Costs
There are no direct additional costs associated with this proposal.
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/104?u=hawheik
The Event Horizon Community voted FOR on this Proposal (ehARB-111): EventHorizon.vote/vote/arbitrum/ehARB-111
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/104?u=hawheik
The Event Horizon Community voted FOR on this Proposal (ehARB-111): EventHorizon.vote/vote/arbitrum/ehARB-111
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/101?u=0x_ultra
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.
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/73?u=bob-rossi
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/20?u=tekr0x.eth
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/87?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/95?u=ocandocrypto
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/94
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/93
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/92?u=griff
this will bring much more liquidity into Arbitrum https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/91?u=paulofonseca
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. https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/90?u=paulofonseca
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/88?u=dragonawr
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/86?u=maxlomu
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/57?u=0xalex
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/63
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/85
Change and evolution are native parts of our ecosystem. I vote yes.
Voting against as there is an error in the submitted proposal.
https://forum.arbitrum.foundation/t/gfx-labs-delegate-communication-thread/13794
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/76?u=ocandocrypto
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/72?u=pedrob
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/75?u=tane
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/73
For - as mentioned by many if sanctioned by OCL a no brainer
The Event Horizon Community voted FOR on this proposal (ehARB-94): EventHorizon.vote/vote/arbitrum/ehARB-94
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/70?u=mcfly
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/69?u=maxlomu
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/66
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/63
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/65?u=0x_ultra
https://forum.arbitrum.foundation/t/proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/16?u=castlecapital
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/2861
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/62?u=bruce
this will help bring more liquidity into Arbitrum. https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/61?u=paulofonseca
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/35?u=tekr0x.eth
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/59?u=griff
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/57
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/57?u=0xalex
https://forum.arbitrum.foundation/t/tempetechie-eth-delegate-communication-thread/27225/6#p-68121-snapshot-proposal-constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-routerhttpssnapshotboxsarbitrumfoundationethproposal0xdb22a77942eddfea9c826790ac03c3e54a34716c0a9bde846399cffe6046d256-4
i voted for here , because no extra cost goes to the Dao and Tech work will be done by SKY and offchain team that ressaure that progress will be smooth
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/54
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/53
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/52?u=blockworksresearch
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/48?u=0xtalvo.eth_mty
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/47?u=danielm
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/46?u=ezr3al
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/101?u=0x_ultra
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.
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/73?u=bob-rossi
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/20?u=tekr0x.eth
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/87?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/95?u=ocandocrypto
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/94
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/93
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/92?u=griff
this will bring much more liquidity into Arbitrum https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/91?u=paulofonseca
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. https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/90?u=paulofonseca
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/88?u=dragonawr
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/86?u=maxlomu
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/57?u=0xalex
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/63
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/85
Change and evolution are native parts of our ecosystem. I vote yes.
Voting against as there is an error in the submitted proposal.
https://forum.arbitrum.foundation/t/gfx-labs-delegate-communication-thread/13794
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/76?u=ocandocrypto
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/72?u=pedrob
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/75?u=tane
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/73
For - as mentioned by many if sanctioned by OCL a no brainer
The Event Horizon Community voted FOR on this proposal (ehARB-94): EventHorizon.vote/vote/arbitrum/ehARB-94
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/70?u=mcfly
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/69?u=maxlomu
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/66
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/63
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/65?u=0x_ultra
https://forum.arbitrum.foundation/t/proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/16?u=castlecapital
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/2861
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/62?u=bruce
this will help bring more liquidity into Arbitrum. https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/61?u=paulofonseca
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/35?u=tekr0x.eth
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/59?u=griff
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/57
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/57?u=0xalex
https://forum.arbitrum.foundation/t/tempetechie-eth-delegate-communication-thread/27225/6#p-68121-snapshot-proposal-constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-routerhttpssnapshotboxsarbitrumfoundationethproposal0xdb22a77942eddfea9c826790ac03c3e54a34716c0a9bde846399cffe6046d256-4
i voted for here , because no extra cost goes to the Dao and Tech work will be done by SKY and offchain team that ressaure that progress will be smooth
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/54
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/53
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/52?u=blockworksresearch
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/48?u=0xtalvo.eth_mty
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/47?u=danielm
https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/46?u=ezr3al
thats awesome to be honest great idea
thats awesome to be honest great idea
Voting has ended!
===============
[[CONSTITUTIONAL] Register the Sky Custom Gateway contracts in the Router](https://www.tally.xyz/gov/eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9/proposal/2616193137172809132)
### Final Votes
| **Category** | **Result** | **Details** |
|----------------------|------------------|-----------------------------|
| **Quorum reached** | ✅ | 234.71M of 222.41M |
| **Majority Support** | ✅ | |
| **For** | | 217.67M (92.7%) |
| **Against** | | 27.23k (0.0%) |
| **Abstain** | | 17.04M (7.3%) |
* * *
I am a bot. Questions? Contact [email protected]
Voting has ended!
===============
[[CONSTITUTIONAL] Register the Sky Custom Gateway contracts in the Router](https://www.tally.xyz/gov/eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9/proposal/2616193137172809132)
### Final Votes
| **Category** | **Result** | **Details** |
|----------------------|------------------|-----------------------------|
| **Quorum reached** | ✅ | 234.71M of 222.41M |
| **Majority Support** | ✅ | |
| **For** | | 217.67M (92.7%) |
| **Against** | | 27.23k (0.0%) |
| **Abstain** | | 17.04M (7.3%) |
* * *
I am a bot. Questions? Contact [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
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.
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.
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 [email protected]
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.
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.
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.
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.
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.
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.
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.
I'm voting "For" this proposal with the understanding that the inclusion of this into the router doesn't introduce any security risks.
That doesn't necessarily mean that I consider USDS/sUSDS in itself good or bad, trustworthy or not, I see those kinds of considerations as mostly separate from the question as to whether we should enable seamless access to the infrastructure of Arbitrum for users.
I'm voting "For" this proposal with the understanding that the inclusion of this into the router doesn't introduce any security risks.
That doesn't necessarily mean that I consider USDS/sUSDS in itself good or bad, trustworthy or not, I see those kinds of considerations as mostly separate from the question as to whether we should enable seamless access to the infrastructure of Arbitrum for users.
Seconding the suggestions throughout the thread to allow one of the Arbitrum Aligned Entities to take on the task of making these decision in the future. This seems like a prime candidate for a DAO policy to be set and then applied by an AAE, with the assumption that we want to enable infra access broadly and don't want to arbitrate the advantages/disadvantages of every single token as a DAO.
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Tally Vote.
I am confirming my support on this on-chain vote, in line with my previous statement here: https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/65
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.
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.
DAOplomats is voting FOR on Tally.
We are maintaining our vote from the temp check.
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.
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.
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.
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.
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.
I'm voting "For" this proposal with the understanding that the inclusion of this into the router doesn't introduce any security risks.
That doesn't necessarily mean that I consider USDS/sUSDS in itself good or bad, trustworthy or not, I see those kinds of considerations as mostly separate from the question as to whether we should enable seamless access to the infrastructure of Arbitrum for users.
I'm voting "For" this proposal with the understanding that the inclusion of this into the router doesn't introduce any security risks.
That doesn't necessarily mean that I consider USDS/sUSDS in itself good or bad, trustworthy or not, I see those kinds of considerations as mostly separate from the question as to whether we should enable seamless access to the infrastructure of Arbitrum for users.
Seconding the suggestions throughout the thread to allow one of the Arbitrum Aligned Entities to take on the task of making these decision in the future. This seems like a prime candidate for a DAO policy to be set and then applied by an AAE, with the assumption that we want to enable infra access broadly and don't want to arbitrate the advantages/disadvantages of every single token as a DAO.
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Tally Vote.
I am confirming my support on this on-chain vote, in line with my previous statement here: https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/65
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.
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.
DAOplomats is voting FOR on Tally.
We are maintaining our vote from the temp check.
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Tally Vote.
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:
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:
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.
voting For on the current onchain vote with the ID 71020107401388505040510993373598301285550678565865201408741893567942851985019 because this will bring much more liquidity into Arbitrum.
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.
I have voted FOR in the Tally vote, for the same reasons as below:
I have voted FOR in the Tally vote, for the same reasons as below:
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 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.
As in @web3citizenxyz representation, voting for. Below the rationale:
Voted FOR on Tally, my opinion remains the same: https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/47?u=danielm
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
I voted FOR on Tally. The reasoning remains the same, and I still think the DAO could benefit from something like this.
As in @web3citizenxyz representation. Voting FOR. Below the rationale:
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.
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.
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.
A bit OT here but we are moving in a world in which we need a technical DAO solution for
Just food for thoughts
gm, voting FOR - excited to improve the UX and support for the Sky Ecosystem.
Perhaps we can figure out a solution where a trusted group, similar to Uniswap's accountability committee, can handle such adjustments.
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.
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.
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Tally Vote.
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:
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:
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.
voting For on the current onchain vote with the ID 71020107401388505040510993373598301285550678565865201408741893567942851985019 because this will bring much more liquidity into Arbitrum.
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.
I have voted FOR in the Tally vote, for the same reasons as below:
I have voted FOR in the Tally vote, for the same reasons as below:
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 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.
As in @web3citizenxyz representation, voting for. Below the rationale:
Voted FOR on Tally, my opinion remains the same: https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/47?u=danielm
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
I voted FOR on Tally. The reasoning remains the same, and I still think the DAO could benefit from something like this.
As in @web3citizenxyz representation. Voting FOR. Below the rationale:
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.
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.
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.
A bit OT here but we are moving in a world in which we need a technical DAO solution for
Just food for thoughts
gm, voting FOR - excited to improve the UX and support for the Sky Ecosystem.
Perhaps we can figure out a solution where a trusted group, similar to Uniswap's accountability committee, can handle such adjustments.
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.
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.
gm, voting FOR - excited to improve the UX and support for the Sky Ecosystem.
Perhaps we can figure out a solution where a trusted group, similar to Uniswap's accountability committee, can handle such adjustments.
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
Voted FOR on Tally as per my previous comment.
Perhaps we can figure out a solution where a trusted group, similar to Uniswap’s accountability committee, can handle such adjustments.
maybe the security council? after a successful offchain vote? I think this should be technically possible, no?
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 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.
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!
We’re voting FOR this proposal. Even though USDS will likely be supported by many bridges, adding the Sky Custom Gateway makes the user experience smoother by allowing official bridging through the Arbitrum UI. The contracts have been properly audited and verified, so we’re comfortable with the security. Overall, it’s a simple, low-risk step that brings Maker and Sky closer to the Arbitrum ecosystem.
Voting FOR!
Spark Liquidity Layer and Spark Savings Service are critical infrastructure for the growth of the Arbitrum ecosystem. The prerequisite for enabling their functionalities is to ensure users can seamlessly bridge USDS and sUSDS.
This proposal carries low technical risk, incurs zero cost, and merits strong community support.
Cross-posting here as an update on the state of the proposal:
hey @SpikeWatanabe.eth is it possible to have a public acknowledgment by @offchainlabs here in this thread, that they are indeed supporting the implementation of this proposal?
maybe the security council? after a successful offchain vote? I think this should be technically possible, no?
Voting FOR for the reasons outlined here https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/32
I vote FOR this proposal.
There are some doubts about the necessity of this step. After all, to be honest, there are many bridges that will support USDS due to its large distribution.
I vote FOR this proposal.
There are some doubts about the necessity of this step. After all, to be honest, there are many bridges that will support USDS due to its large distribution.
You have to understand that we made a bridge for RARI because they were transferring the management of their chain to Arbitrum and this was the only correct approach to such a transfer of tokens from one chain to another. In this case, there is no such need.
If you look at the big picture, then this vote is providing SKY and USDS with Arbitrum reputation.
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.
We are voting FOR this proposal in the Snapshot voting.
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.
We are voting FOR this proposal in the Snapshot voting.
As mentioned in our previous comment, we’re supporting this proposal as it improves the current bridging experience without introducing new risks or costs to the DAO.
We also believe this kind of update doesn’t always need to go through a full proposal process. A more efficient path could be explored in the DAO allowing Offchain Labs or the Foundation to handle similar requests for which they are capable for a fixed term, with clear reporting. This would reduce the governance load for the delegates while maintaining transparency.
That said, we support this proposal and believe it’s a practical, win-win step for both Arbitrum and the Sky team.
Voting 'FOR' this proposal on Snapshot.
A lot of our initial concerns seem addressed. Beyond improving the bridging experience, I see a lot of potential for USDS and sUSDS to enhance Arbitrum’s DeFi ecosystem. Picture GMX using sUSDS for yield-bearing collateral or Pendle splitting USDS for fixed yields. It would be great if Sky can look into collaborating with Arbitrum-native protocols to explore these opportunities.
Voting 'FOR' this proposal on Snapshot.
A lot of our initial concerns seem addressed. Beyond improving the bridging experience, I see a lot of potential for USDS and sUSDS to enhance Arbitrum’s DeFi ecosystem. Picture GMX using sUSDS for yield-bearing collateral or Pendle splitting USDS for fixed yields. It would be great if Sky can look into collaborating with Arbitrum-native protocols to explore these opportunities.
Additionally, given the gateway’s reliance on Arbitrum’s messaging layer, a gas cost comparison—perhaps against CCTP or similar bridges—would be great.
One last thing: I’d like to propose Sky provide a 3-month post-launch report with metrics like bridged volume and Spark adoption to quantify the impact.
This proposal offers good strategic value, and we're quite supportive.
Im voting for this proposal, its a clear win-win, thanks for clarifying my concerns @SpikeWatanabe.eth.
Blockworks is voting FOR this proposal on Snapshot.
We're happy to see an integration of Maker/Sky deployed on Arbitrum, especially as its straightforward and will contribute to the adoption of the network.
Blockworks is voting FOR this proposal on Snapshot.
We're happy to see an integration of Maker/Sky deployed on Arbitrum, especially as its straightforward and will contribute to the adoption of the network.
We believe this proposal is relatively safe so long as procedure was followed from last time: https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/3?u=blockworksresearch
voting FOR on the current offchain vote because this will help bring more liquidity into Arbitrum.
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.
LobbyFi’s rationale on the price and making the voting power available for sale for this proposal
LobbyFi sees this proposal as one that benefits the whole Arbitrum ecosystem will therefore make the auction available. We do not expect any particular actor to be incentivised to acquire the voting power instantly, and since there is no direct monetary aspect to the proposal, we will set the instant buy price arbitrarily at 10 ETH.
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.
so i vote FOR on the snapshot, my position remains the same: https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/8?u=danielm
gm, voting FOR - excited to improve the UX and support for the Sky Ecosystem.
Perhaps we can figure out a solution where a trusted group, similar to Uniswap's accountability committee, can handle such adjustments.
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
Voted FOR on Tally as per my previous comment.
Perhaps we can figure out a solution where a trusted group, similar to Uniswap’s accountability committee, can handle such adjustments.
maybe the security council? after a successful offchain vote? I think this should be technically possible, no?
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 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.
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!
We’re voting FOR this proposal. Even though USDS will likely be supported by many bridges, adding the Sky Custom Gateway makes the user experience smoother by allowing official bridging through the Arbitrum UI. The contracts have been properly audited and verified, so we’re comfortable with the security. Overall, it’s a simple, low-risk step that brings Maker and Sky closer to the Arbitrum ecosystem.
Voting FOR!
Spark Liquidity Layer and Spark Savings Service are critical infrastructure for the growth of the Arbitrum ecosystem. The prerequisite for enabling their functionalities is to ensure users can seamlessly bridge USDS and sUSDS.
This proposal carries low technical risk, incurs zero cost, and merits strong community support.
Cross-posting here as an update on the state of the proposal:
hey @SpikeWatanabe.eth is it possible to have a public acknowledgment by @offchainlabs here in this thread, that they are indeed supporting the implementation of this proposal?
maybe the security council? after a successful offchain vote? I think this should be technically possible, no?
Voting FOR for the reasons outlined here https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/32
I vote FOR this proposal.
There are some doubts about the necessity of this step. After all, to be honest, there are many bridges that will support USDS due to its large distribution.
I vote FOR this proposal.
There are some doubts about the necessity of this step. After all, to be honest, there are many bridges that will support USDS due to its large distribution.
You have to understand that we made a bridge for RARI because they were transferring the management of their chain to Arbitrum and this was the only correct approach to such a transfer of tokens from one chain to another. In this case, there is no such need.
If you look at the big picture, then this vote is providing SKY and USDS with Arbitrum reputation.
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.
We are voting FOR this proposal in the Snapshot voting.
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.
We are voting FOR this proposal in the Snapshot voting.
As mentioned in our previous comment, we’re supporting this proposal as it improves the current bridging experience without introducing new risks or costs to the DAO.
We also believe this kind of update doesn’t always need to go through a full proposal process. A more efficient path could be explored in the DAO allowing Offchain Labs or the Foundation to handle similar requests for which they are capable for a fixed term, with clear reporting. This would reduce the governance load for the delegates while maintaining transparency.
That said, we support this proposal and believe it’s a practical, win-win step for both Arbitrum and the Sky team.
Voting 'FOR' this proposal on Snapshot.
A lot of our initial concerns seem addressed. Beyond improving the bridging experience, I see a lot of potential for USDS and sUSDS to enhance Arbitrum’s DeFi ecosystem. Picture GMX using sUSDS for yield-bearing collateral or Pendle splitting USDS for fixed yields. It would be great if Sky can look into collaborating with Arbitrum-native protocols to explore these opportunities.
Voting 'FOR' this proposal on Snapshot.
A lot of our initial concerns seem addressed. Beyond improving the bridging experience, I see a lot of potential for USDS and sUSDS to enhance Arbitrum’s DeFi ecosystem. Picture GMX using sUSDS for yield-bearing collateral or Pendle splitting USDS for fixed yields. It would be great if Sky can look into collaborating with Arbitrum-native protocols to explore these opportunities.
Additionally, given the gateway’s reliance on Arbitrum’s messaging layer, a gas cost comparison—perhaps against CCTP or similar bridges—would be great.
One last thing: I’d like to propose Sky provide a 3-month post-launch report with metrics like bridged volume and Spark adoption to quantify the impact.
This proposal offers good strategic value, and we're quite supportive.
Im voting for this proposal, its a clear win-win, thanks for clarifying my concerns @SpikeWatanabe.eth.
Blockworks is voting FOR this proposal on Snapshot.
We're happy to see an integration of Maker/Sky deployed on Arbitrum, especially as its straightforward and will contribute to the adoption of the network.
Blockworks is voting FOR this proposal on Snapshot.
We're happy to see an integration of Maker/Sky deployed on Arbitrum, especially as its straightforward and will contribute to the adoption of the network.
We believe this proposal is relatively safe so long as procedure was followed from last time: https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/3?u=blockworksresearch
voting FOR on the current offchain vote because this will help bring more liquidity into Arbitrum.
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.
LobbyFi’s rationale on the price and making the voting power available for sale for this proposal
LobbyFi sees this proposal as one that benefits the whole Arbitrum ecosystem will therefore make the auction available. We do not expect any particular actor to be incentivised to acquire the voting power instantly, and since there is no direct monetary aspect to the proposal, we will set the instant buy price arbitrarily at 10 ETH.
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.
so i vote FOR on the snapshot, my position remains the same: https://forum.arbitrum.foundation/t/constitutional-proposal-for-arbitrum-dao-to-register-the-sky-custom-gateway-contracts-in-the-router/28617/8?u=danielm
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.
What I was saying is the OCL should be leading or at the very least, quickly supporting proposal’s like this,so you both could save some time and simplify this process.
That being said it's a no brainer, I'm voting for this proposal, if the OCL supports it so do I.
Supporting this proposal with a YES. The sky stablecoin is a net benefit for Arbitrum, and the technical integration does not inherit any risks.
This vote is pretty straight forward. Integrating Sky Custom Gateway contracts would enhance flexibility and interoperability on Arbitrum.
The only concerns we see/highlighting are:
This vote is pretty straight forward. Integrating Sky Custom Gateway contracts would enhance flexibility and interoperability on Arbitrum.
The only concerns we see/highlighting are:
Assuming these are in line, we think approving this would:
Overall, assuming technical security, we see no reason as to why this should be denied.
Yes, certainly, sorry for the typoo
Between Sky’s recent launch/expansion to Arbitrum and Maker’s longstanding success and reputation in the space, we believe this is a worthwhile proposal.
In light of this proposal and similar past approvals (e.g., RARI’s custom gateway integration), we’d like to suggest an enhancement to the Arbitrum Bridge UI: a DAO-Approved Token List and Verified Gateway Badge.
Between Sky’s recent launch/expansion to Arbitrum and Maker’s longstanding success and reputation in the space, we believe this is a worthwhile proposal.
In light of this proposal and similar past approvals (e.g., RARI’s custom gateway integration), we’d like to suggest an enhancement to the Arbitrum Bridge UI: a DAO-Approved Token List and Verified Gateway Badge.
Given that certain tokens require explicit governance approval for custom Router gateways, it would be beneficial to:
Create a DAO-Approved Token List that includes all tokens formally approved by the DAO for bridging, allowing users to filter for officially recognized assets. This is the current set of token lists that can be enabled on the official Arbitrum Bridge UI:
Introduce a Verified DAO Badge next to these tokens in the Arbitrum Bridge UI, linking to the governance proposal that approved them. This could look similar to the official Arbitrum token badge:
This would enhance user trust, transparency, and security while also providing projects an incentive to align with DAO-approved infrastructure. It ensures users are informed when bridging assets and helps prevent reliance on unverified bridge paths.
I voted FOR this proposal.
This is nice to have
ensuring users receive the official token versions when they use the Router contracts through the Arbitrum Bridge UI.
All audit reports were provided
I voted FOR this proposal.
This is nice to have
ensuring users receive the official token versions when they use the Router contracts through the Arbitrum Bridge UI.
All audit reports were provided
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
And OCL and Sky are aware of and ready to implement it.
It would be useful to announce somewhere in the proposal that StableLab (or the author) was proposing this on behalf of Sky. That would save some time and a few questions.
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.
I am in favor of this proposal. It seems like a win-win for Arbitrum and SKY. This partnership will strengthen the ecosystem, serving as a "simple yet crucial technical solution" to improve interoperability and the user experience on Arbitrum. I look forward to seeing the detailed implementation timeline. I trust the project and its transparency, as ChainSecurity has established an impressive track record as an auditor for high-profile blockchain projects. One of their most notable successes is the audit of the MakerDAO protocol. On the other hand, Cantina has demonstrated its expertise in auditing blockchain projects, such as its work with Aave, one of the leading decentralized lending protocols.
Thank you everyone for your comments and questions, your feedback is much appreciated, snapshot voting is now live.
Please cast your votes.
I’m voting FOR this proposal because, as several delegates have pointed out, I believe it creates a win-win partnership that will amplify Arbitrum’s network effect.
Apologies everyone, but we overlooked Thursday posting schedule. We decided to cancel the proposal and repost it on Thursday, so that everyone would have enough time to evaluate and vote.
I decided to vote "For" on Snapshot, based on the rationale outlined in my previous comment and considering that OCL has also expressed support for this initiative.
I decided to vote "For" on Snapshot, based on the rationale outlined in my previous comment and considering that OCL has also expressed support for this initiative.
Sky (Maker) has consistently demonstrated its value and capability over the years, and I believe their proposal will be a enhancement to the existing DeFi ecosystem on Arbitrum.
I'm particularly pleased to see the emergence of more yield opportunities on-chain. Expanding these yield-generating products is really key to attract more users and liquidity!!!
Hello everyone, thank you very much for your questions and feedback, it was important for us to understand community sentiment. It appeared that overall consensus was more or less positive, we'll proceed to post it on snapshot on Thursday.
Voted For: Sky/Maker has a great reputation in crypto, especially among users who have been in this space for some time. This is why it is great to see the integration of the Arbitrum chain (besides Ethereum, Base, and Gnosis). Our reputation with a combination of Sky and Spark can bring a lot more uses to Arbitrum.
I believe that the necessary upgrade in this proposal to update the router is a small effort to really increase users' experience when onboarding sUSD and USDS. There is no cost related to this proposal, only work from both the Sky and Arbitrum teams. Both teams have already confirmed they are willing to work together to implement this.
you mean @offchainlabs guidance?
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.
Sky’s proposition of registering its USDS and sUSDS tokens into the L1GatewayRouter is a move in a positive direction for further adoption of a decentralised yield-bearing stablecoins. This integration in the Arbitrum Bridge UI improves utilisation of Sky and in tandem Spark’s yield opportunities across it’s lending platform. Having already deployed $100M USDS and $100M sUSDS on Arbitrum, it further exemplifies Sky's move to distinguish itself on Arbitrum's ecosystem.
It would be helpful to better understand the potential risks surrounding changes to the Arbitrum Ecosystem Router. I assume there are significant risks and that’s why these changes go through governance (if there aren’t risks, we should come up with a more efficient process).
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)
I just cast my vote in favor on Snapshot by the reason I mention before:
I am in favor of this proposal. It seems like a win-win for Arbitrum and SKY. This partnership will strengthen the ecosystem, serving as a “simple yet crucial technical solution” to improve interoperability and the user experience on Arbitrum. I look forward to seeing the detailed implementation timeline. I trust the project and its transparency, as ChainSecurity has established an impressive track record as an auditor for high-profile blockchain projects. One of their most notable successes is the audit of the MakerDAO protocol. On the other hand, Cantina has demonstrated its expertise in auditing blockchain projects, such as its work with Aave, one of the leading decentralized lending protocols.
I'm excited about this deployment. Arbitrum's strong liquidity and DeFi ecosystem make it a natural partner for SKY.
Procedurally, shouldn't this be a constitutional proposal? It's my understanding that the onchain proposal would need to be submitted to the Core Governor.
I'm excited about this deployment. Arbitrum's strong liquidity and DeFi ecosystem make it a natural partner for SKY.
Procedurally, shouldn't this be a constitutional proposal? It's my understanding that the onchain proposal would need to be submitted to the Core Governor.
It would be helpful to better understand the potential risks surrounding changes to the Arbitrum Ecosystem Router. I assume there are significant risks and that's why these changes go through governance (if there aren't risks, we should come up with a more efficient process).
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?
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.
What I was saying is the OCL should be leading or at the very least, quickly supporting proposal’s like this,so you both could save some time and simplify this process.
That being said it's a no brainer, I'm voting for this proposal, if the OCL supports it so do I.
Supporting this proposal with a YES. The sky stablecoin is a net benefit for Arbitrum, and the technical integration does not inherit any risks.
This vote is pretty straight forward. Integrating Sky Custom Gateway contracts would enhance flexibility and interoperability on Arbitrum.
The only concerns we see/highlighting are:
This vote is pretty straight forward. Integrating Sky Custom Gateway contracts would enhance flexibility and interoperability on Arbitrum.
The only concerns we see/highlighting are:
Assuming these are in line, we think approving this would:
Overall, assuming technical security, we see no reason as to why this should be denied.
Yes, certainly, sorry for the typoo
Between Sky’s recent launch/expansion to Arbitrum and Maker’s longstanding success and reputation in the space, we believe this is a worthwhile proposal.
In light of this proposal and similar past approvals (e.g., RARI’s custom gateway integration), we’d like to suggest an enhancement to the Arbitrum Bridge UI: a DAO-Approved Token List and Verified Gateway Badge.
Between Sky’s recent launch/expansion to Arbitrum and Maker’s longstanding success and reputation in the space, we believe this is a worthwhile proposal.
In light of this proposal and similar past approvals (e.g., RARI’s custom gateway integration), we’d like to suggest an enhancement to the Arbitrum Bridge UI: a DAO-Approved Token List and Verified Gateway Badge.
Given that certain tokens require explicit governance approval for custom Router gateways, it would be beneficial to:
Create a DAO-Approved Token List that includes all tokens formally approved by the DAO for bridging, allowing users to filter for officially recognized assets. This is the current set of token lists that can be enabled on the official Arbitrum Bridge UI:
Introduce a Verified DAO Badge next to these tokens in the Arbitrum Bridge UI, linking to the governance proposal that approved them. This could look similar to the official Arbitrum token badge:
This would enhance user trust, transparency, and security while also providing projects an incentive to align with DAO-approved infrastructure. It ensures users are informed when bridging assets and helps prevent reliance on unverified bridge paths.
I voted FOR this proposal.
This is nice to have
ensuring users receive the official token versions when they use the Router contracts through the Arbitrum Bridge UI.
All audit reports were provided
I voted FOR this proposal.
This is nice to have
ensuring users receive the official token versions when they use the Router contracts through the Arbitrum Bridge UI.
All audit reports were provided
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
And OCL and Sky are aware of and ready to implement it.
It would be useful to announce somewhere in the proposal that StableLab (or the author) was proposing this on behalf of Sky. That would save some time and a few questions.
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.
I am in favor of this proposal. It seems like a win-win for Arbitrum and SKY. This partnership will strengthen the ecosystem, serving as a "simple yet crucial technical solution" to improve interoperability and the user experience on Arbitrum. I look forward to seeing the detailed implementation timeline. I trust the project and its transparency, as ChainSecurity has established an impressive track record as an auditor for high-profile blockchain projects. One of their most notable successes is the audit of the MakerDAO protocol. On the other hand, Cantina has demonstrated its expertise in auditing blockchain projects, such as its work with Aave, one of the leading decentralized lending protocols.
Thank you everyone for your comments and questions, your feedback is much appreciated, snapshot voting is now live.
Please cast your votes.
I’m voting FOR this proposal because, as several delegates have pointed out, I believe it creates a win-win partnership that will amplify Arbitrum’s network effect.
Apologies everyone, but we overlooked Thursday posting schedule. We decided to cancel the proposal and repost it on Thursday, so that everyone would have enough time to evaluate and vote.
I decided to vote "For" on Snapshot, based on the rationale outlined in my previous comment and considering that OCL has also expressed support for this initiative.
I decided to vote "For" on Snapshot, based on the rationale outlined in my previous comment and considering that OCL has also expressed support for this initiative.
Sky (Maker) has consistently demonstrated its value and capability over the years, and I believe their proposal will be a enhancement to the existing DeFi ecosystem on Arbitrum.
I'm particularly pleased to see the emergence of more yield opportunities on-chain. Expanding these yield-generating products is really key to attract more users and liquidity!!!
Hello everyone, thank you very much for your questions and feedback, it was important for us to understand community sentiment. It appeared that overall consensus was more or less positive, we'll proceed to post it on snapshot on Thursday.
Voted For: Sky/Maker has a great reputation in crypto, especially among users who have been in this space for some time. This is why it is great to see the integration of the Arbitrum chain (besides Ethereum, Base, and Gnosis). Our reputation with a combination of Sky and Spark can bring a lot more uses to Arbitrum.
I believe that the necessary upgrade in this proposal to update the router is a small effort to really increase users' experience when onboarding sUSD and USDS. There is no cost related to this proposal, only work from both the Sky and Arbitrum teams. Both teams have already confirmed they are willing to work together to implement this.
you mean @offchainlabs guidance?
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.
Sky’s proposition of registering its USDS and sUSDS tokens into the L1GatewayRouter is a move in a positive direction for further adoption of a decentralised yield-bearing stablecoins. This integration in the Arbitrum Bridge UI improves utilisation of Sky and in tandem Spark’s yield opportunities across it’s lending platform. Having already deployed $100M USDS and $100M sUSDS on Arbitrum, it further exemplifies Sky's move to distinguish itself on Arbitrum's ecosystem.
It would be helpful to better understand the potential risks surrounding changes to the Arbitrum Ecosystem Router. I assume there are significant risks and that’s why these changes go through governance (if there aren’t risks, we should come up with a more efficient process).
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)
I just cast my vote in favor on Snapshot by the reason I mention before:
I am in favor of this proposal. It seems like a win-win for Arbitrum and SKY. This partnership will strengthen the ecosystem, serving as a “simple yet crucial technical solution” to improve interoperability and the user experience on Arbitrum. I look forward to seeing the detailed implementation timeline. I trust the project and its transparency, as ChainSecurity has established an impressive track record as an auditor for high-profile blockchain projects. One of their most notable successes is the audit of the MakerDAO protocol. On the other hand, Cantina has demonstrated its expertise in auditing blockchain projects, such as its work with Aave, one of the leading decentralized lending protocols.
I'm excited about this deployment. Arbitrum's strong liquidity and DeFi ecosystem make it a natural partner for SKY.
Procedurally, shouldn't this be a constitutional proposal? It's my understanding that the onchain proposal would need to be submitted to the Core Governor.
I'm excited about this deployment. Arbitrum's strong liquidity and DeFi ecosystem make it a natural partner for SKY.
Procedurally, shouldn't this be a constitutional proposal? It's my understanding that the onchain proposal would need to be submitted to the Core Governor.
It would be helpful to better understand the potential risks surrounding changes to the Arbitrum Ecosystem Router. I assume there are significant risks and that's why these changes go through governance (if there aren't risks, we should come up with a more efficient process).
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?
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.
Sky’s proposition of registering its USDS and sUSDS tokens into the L1GatewayRouter is a move in a positive direction for further adoption of a decentralised yield-bearing stablecoins. This integration in the Arbitrum Bridge UI improves utilisation of Sky and in tandem Spark’s yield opportunities across it’s lending platform. Having already deployed $100M USDS and $100M sUSDS on Arbitrum, it further exemplifies Sky's move to distinguish itself on Arbitrum's ecosystem.
It’s evident following it’s success on Base, this move aligns with Arbitrum’s protocol, and offers existing protocols the capability to spawn new facets of DeFi including for GMX, through yield-accruing collateralised derivative positions.
Therefore we are in accordance and agree with this implementation and introduction of the Sky’s registration in the Router contracts.
It would be helpful to better understand the potential risks surrounding changes to the Arbitrum Ecosystem Router. I assume there are significant risks and that’s why these changes go through governance (if there aren’t risks, we should come up with a more efficient process).
Yes that is correct, it is a constitutional proposal, thank you for pointing this out.
In DeFi everything is risky to an extent, from our perspective it is a very straightforward change, which’s been implemented in the past by the likes of Rari. Those changes go through governance, because the Arbitrum DAO governance system owns those functions, which can make the change. On the risk assessment side, we are going to be following OFC guidance, to make sure everything is done correctly and audited.
We appreciate your opinion, it is a very interesting suggestion. As far as standardization of that process is concerned, it is out of our hands, since it is something that DAO needs to agree on collectively and implement.
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.
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?
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?
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.
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.
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
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.
Thank you everyone for your questions, I hope they will be well addressed
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
Thank you everyone for your questions, I hope they will be well addressed
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
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:
How will governance over gateway upgrades be balanced between Sky and the DAO? Delegates need assurance that the DAO retains oversight if conflicts arise.
Custom gateways are operated by Sky Ecosystem and its governance, so Arbitrum DAO doesn’t have a direct role in their operation or upgrades. However, Arbitrum DAO retains full authority to list these custom gateways—and can revert to the standard gateway on the Arbitrum Router contract at any time—without needing approval from Sky Ecosystem.
Is there any issue for existing users who already bridged via default gateways? Would they have to migrate to any other token?
Users are not going to lose any funds. If a user already bridged their Arbitrum USDS or sUSDS through the default gateways, they’ll need to send those tokens back to Ethereum first, and then bridge them again using the custom gateways.
This proposal doesn’t require any funds, but it does require technical work done by Offchain Labs and the Sky team. Are both entities aware of this proposal? Are they willing to do the work to execute on this proposal?
Yes
Is the Sky team committed to maintaining and upgrading this integration if needed? For how long? Long-term support is key to ensuring this remains a reliable and efficient solution for the Arbitrum ecosystem.
If yes, this integration seems like a solid step forward.
Sky Ecosystem has added upgradeability to both tokens and gateways to be able to add new features as needed later on. We can’t comment on the future roadmap for the Sky Ecosystem (since it’s decentralized), but these custom gateways should be maintained as long as the tokens exist on Arbitrum, since they were all deployed by Sky Ecosystem as an integrated stack. Plus, there’s very little maintenance required because the gateways rely on Arbitrum’s native messaging layer.
Just to clarify, since the Sky Custom Gateway is already live, this proposal is only about registering the contract in the Router, correct?
Correct
It’s a set of custom gateways on Ethereum and Arbitrum, but it’s built on the same foundations as the existing ones. Under the hood, it still uses Arbitrum’s native cross-chain messaging layer—just like the standard gateways. The Sky ecosystem has already deployed custom gateways for DAI in production for years, so the approach is definitely tried and tested.
wanted to also request some elaboration about the implementation timeline. And to mitigate any risks, is there any proper backup plans
We’ll be sharing more details about the implementation timeline soon. Since this has been done before in other comparable proposals, like the one for RARI, we’ll stick to previously tested approaches and also review prior discussions to incorporate any learnings.
Consider there was a case from Rari and now Sky, we could consider standardizing the process of requesting the registration of tokens as we anticipate similar questions arise from the delegates for each proposal like this.
It seems that this issue needs to be decided by Arbitrum DAO members, rather than Sky or any other third party.
If this goes live, the DAO can revoke or modify the registration if needed right? Just want to confirm there is DAO oversight over the Sky custom gateway contracts if/once it is registered.
Arbitrum DAO oversees the Router contract and can update the gateways for any L1 token—including USDS and sUSDS—at any time. Meanwhile, the custom gateways and the tokens themselves remain under the full control of the Sky Ecosystem and its governance.
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
Please see answer above for 0xDonPepe.
How important is it to use the native Arbitrum bridge, since there are many third-party bridges for these purposes? What is the advantage, since there is a 6-day delay for withdrawals?
A native bridge that relies on the native messaging layer is always good to have. Native withdrawal delays shouldn’t pose any issues for USDS or sUSDS holders, thanks to the complete setup that the Sky Ecosystem achieved with Spark! The Spark Liquidity Layer maintains USDC liquidity on Arbitrum, which can be replenished on demand. This allows USDS and sUSDS holders earning yield to easily switch to USDC at any point on Arbitrum, and then use Circle CCTP or other fast withdrawal solutions to move their USDC back to Ethereum.
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?
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?
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.
If SKY leaves the project, how is the continuity of the gateways and the USDS/sUSDS tokens ensured?
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.
Does this set a precedent for other projects requesting custom gateways? If so, is the DAO ready to handle such requests?
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.
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?
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.
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.
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:
Thank you, @SpikeWatanabe.eth, 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.
Thank you, @SpikeWatanabe.eth, 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.
Thanks for putting this up @SpikeWatanabe.eth.
If this goes live, the DAO can revoke or modify the registration if needed right? Just want to confirm there is DAO oversight over the Sky custom gateway contracts if/once it is registered.
Thanks for putting this up @SpikeWatanabe.eth.
If this goes live, the DAO can revoke or modify the registration if needed right? Just want to confirm there is DAO oversight over the Sky custom gateway contracts if/once it is registered.
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
Also, we would love an answer to this
I’ll support this proposal since I don’t see any big risks or extra costs for the DAO. I’m not super technical too, but I can see that this will make bridging USDS and sUSDS smoother for users through the official Arbitrum Bridge.
Better UX is always a win :)
Thanks for the proposal, @SpikeWatanabe.eth!
It's no brainer to execute the registrations of USDS and sUSDS tokens since Arbitrum already has registered DAI as well and the relevant parties have already been in sync. Consider there was a case from Rari and now Sky, we could consider standardizing the process of requesting the registration of tokens as we anticipate similar questions arise from the delegates for each proposal like this.
hi @SpikeWatanabe.eth
We do not see any issues with registering Sky’s Custom Gateway contracts in the Router as long as OffChain Labs and/or the Arbitrum Foundation has given the green light after reviewing and validating the contract audit reports.
Interesting proposal @SpikeWatanabe.eth. Echoing what the others have mentioned about the auditing and upgrading process that registers the Sky contracts, but wanted to also request some elaboration about the implementation timeline. And to mitigate any risks, is there any proper backup plans (as @0xDonPepe pointed out)?
I believe that decisions around the bridge should come from Offchain Labs, and I would rather them even propose the change.
Assuming this proposal passes the technical audit from the security risk manager, at this stage we plan to support this proposal.
Thanks for the proposal @SpikeWatanabe.eth
I see no reason we don’t move forward with this proposal, as there will be many benefits for users to use both products, especially the savings one. If Arbitrum believes this is safe, I am fully onboard to support the proposal.
Overall, the proposal is clear. Thank you. Considering the lack of cost, I see no reason not to do it.
However, I would be glad if you could answer a question:
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?
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.
I am not very savvy in the technical part, but if it is safe and does not carry any additional risks in itself, then why not. Arbitrum users will get an additional opportunity to earn. This is great! And it does not carry extra costs from the DAO budget. So if the contract audit is successful then of course it needs to be done.
Hey, yes there are aware of the proposal, we ran by them the final draft before posting it on forum.
Thanks for the proposal—this looks like a win-win. I want to echo the audit sentiment and ensure we don’t run into any issues.
Is the Sky team committed to maintaining and upgrading this integration if needed? For how long? Long-term support is key to ensuring this remains a reliable and efficient solution for the Arbitrum ecosystem.
If yes, this integration seems like a solid step forward.
Thanks for this proposal - it is a welcome development. Sky is one of the better products in the ecosystem. For a while now there has only been support for USDS / sUSDS tokens on Ethereum and Base or so, (at least from the Spark / Sky frontends). It will also be great to have Arbitrum in the mix.
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.
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.
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.
Sky’s proposition of registering its USDS and sUSDS tokens into the L1GatewayRouter is a move in a positive direction for further adoption of a decentralised yield-bearing stablecoins. This integration in the Arbitrum Bridge UI improves utilisation of Sky and in tandem Spark’s yield opportunities across it’s lending platform. Having already deployed $100M USDS and $100M sUSDS on Arbitrum, it further exemplifies Sky's move to distinguish itself on Arbitrum's ecosystem.
It’s evident following it’s success on Base, this move aligns with Arbitrum’s protocol, and offers existing protocols the capability to spawn new facets of DeFi including for GMX, through yield-accruing collateralised derivative positions.
Therefore we are in accordance and agree with this implementation and introduction of the Sky’s registration in the Router contracts.
It would be helpful to better understand the potential risks surrounding changes to the Arbitrum Ecosystem Router. I assume there are significant risks and that’s why these changes go through governance (if there aren’t risks, we should come up with a more efficient process).
Yes that is correct, it is a constitutional proposal, thank you for pointing this out.
In DeFi everything is risky to an extent, from our perspective it is a very straightforward change, which’s been implemented in the past by the likes of Rari. Those changes go through governance, because the Arbitrum DAO governance system owns those functions, which can make the change. On the risk assessment side, we are going to be following OFC guidance, to make sure everything is done correctly and audited.
We appreciate your opinion, it is a very interesting suggestion. As far as standardization of that process is concerned, it is out of our hands, since it is something that DAO needs to agree on collectively and implement.
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.
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?
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?
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.
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.
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
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.
Thank you everyone for your questions, I hope they will be well addressed
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
Thank you everyone for your questions, I hope they will be well addressed
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
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:
How will governance over gateway upgrades be balanced between Sky and the DAO? Delegates need assurance that the DAO retains oversight if conflicts arise.
Custom gateways are operated by Sky Ecosystem and its governance, so Arbitrum DAO doesn’t have a direct role in their operation or upgrades. However, Arbitrum DAO retains full authority to list these custom gateways—and can revert to the standard gateway on the Arbitrum Router contract at any time—without needing approval from Sky Ecosystem.
Is there any issue for existing users who already bridged via default gateways? Would they have to migrate to any other token?
Users are not going to lose any funds. If a user already bridged their Arbitrum USDS or sUSDS through the default gateways, they’ll need to send those tokens back to Ethereum first, and then bridge them again using the custom gateways.
This proposal doesn’t require any funds, but it does require technical work done by Offchain Labs and the Sky team. Are both entities aware of this proposal? Are they willing to do the work to execute on this proposal?
Yes
Is the Sky team committed to maintaining and upgrading this integration if needed? For how long? Long-term support is key to ensuring this remains a reliable and efficient solution for the Arbitrum ecosystem.
If yes, this integration seems like a solid step forward.
Sky Ecosystem has added upgradeability to both tokens and gateways to be able to add new features as needed later on. We can’t comment on the future roadmap for the Sky Ecosystem (since it’s decentralized), but these custom gateways should be maintained as long as the tokens exist on Arbitrum, since they were all deployed by Sky Ecosystem as an integrated stack. Plus, there’s very little maintenance required because the gateways rely on Arbitrum’s native messaging layer.
Just to clarify, since the Sky Custom Gateway is already live, this proposal is only about registering the contract in the Router, correct?
Correct
It’s a set of custom gateways on Ethereum and Arbitrum, but it’s built on the same foundations as the existing ones. Under the hood, it still uses Arbitrum’s native cross-chain messaging layer—just like the standard gateways. The Sky ecosystem has already deployed custom gateways for DAI in production for years, so the approach is definitely tried and tested.
wanted to also request some elaboration about the implementation timeline. And to mitigate any risks, is there any proper backup plans
We’ll be sharing more details about the implementation timeline soon. Since this has been done before in other comparable proposals, like the one for RARI, we’ll stick to previously tested approaches and also review prior discussions to incorporate any learnings.
Consider there was a case from Rari and now Sky, we could consider standardizing the process of requesting the registration of tokens as we anticipate similar questions arise from the delegates for each proposal like this.
It seems that this issue needs to be decided by Arbitrum DAO members, rather than Sky or any other third party.
If this goes live, the DAO can revoke or modify the registration if needed right? Just want to confirm there is DAO oversight over the Sky custom gateway contracts if/once it is registered.
Arbitrum DAO oversees the Router contract and can update the gateways for any L1 token—including USDS and sUSDS—at any time. Meanwhile, the custom gateways and the tokens themselves remain under the full control of the Sky Ecosystem and its governance.
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
Please see answer above for 0xDonPepe.
How important is it to use the native Arbitrum bridge, since there are many third-party bridges for these purposes? What is the advantage, since there is a 6-day delay for withdrawals?
A native bridge that relies on the native messaging layer is always good to have. Native withdrawal delays shouldn’t pose any issues for USDS or sUSDS holders, thanks to the complete setup that the Sky Ecosystem achieved with Spark! The Spark Liquidity Layer maintains USDC liquidity on Arbitrum, which can be replenished on demand. This allows USDS and sUSDS holders earning yield to easily switch to USDC at any point on Arbitrum, and then use Circle CCTP or other fast withdrawal solutions to move their USDC back to Ethereum.
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?
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?
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.
If SKY leaves the project, how is the continuity of the gateways and the USDS/sUSDS tokens ensured?
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.
Does this set a precedent for other projects requesting custom gateways? If so, is the DAO ready to handle such requests?
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.
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?
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.
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.
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:
Thank you, @SpikeWatanabe.eth, 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.
Thank you, @SpikeWatanabe.eth, 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.
Thanks for putting this up @SpikeWatanabe.eth.
If this goes live, the DAO can revoke or modify the registration if needed right? Just want to confirm there is DAO oversight over the Sky custom gateway contracts if/once it is registered.
Thanks for putting this up @SpikeWatanabe.eth.
If this goes live, the DAO can revoke or modify the registration if needed right? Just want to confirm there is DAO oversight over the Sky custom gateway contracts if/once it is registered.
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
Also, we would love an answer to this
I’ll support this proposal since I don’t see any big risks or extra costs for the DAO. I’m not super technical too, but I can see that this will make bridging USDS and sUSDS smoother for users through the official Arbitrum Bridge.
Better UX is always a win :)
Thanks for the proposal, @SpikeWatanabe.eth!
It's no brainer to execute the registrations of USDS and sUSDS tokens since Arbitrum already has registered DAI as well and the relevant parties have already been in sync. Consider there was a case from Rari and now Sky, we could consider standardizing the process of requesting the registration of tokens as we anticipate similar questions arise from the delegates for each proposal like this.
hi @SpikeWatanabe.eth
We do not see any issues with registering Sky’s Custom Gateway contracts in the Router as long as OffChain Labs and/or the Arbitrum Foundation has given the green light after reviewing and validating the contract audit reports.
Interesting proposal @SpikeWatanabe.eth. Echoing what the others have mentioned about the auditing and upgrading process that registers the Sky contracts, but wanted to also request some elaboration about the implementation timeline. And to mitigate any risks, is there any proper backup plans (as @0xDonPepe pointed out)?
I believe that decisions around the bridge should come from Offchain Labs, and I would rather them even propose the change.
Assuming this proposal passes the technical audit from the security risk manager, at this stage we plan to support this proposal.
Thanks for the proposal @SpikeWatanabe.eth
I see no reason we don’t move forward with this proposal, as there will be many benefits for users to use both products, especially the savings one. If Arbitrum believes this is safe, I am fully onboard to support the proposal.
Overall, the proposal is clear. Thank you. Considering the lack of cost, I see no reason not to do it.
However, I would be glad if you could answer a question:
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?
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.
I am not very savvy in the technical part, but if it is safe and does not carry any additional risks in itself, then why not. Arbitrum users will get an additional opportunity to earn. This is great! And it does not carry extra costs from the DAO budget. So if the contract audit is successful then of course it needs to be done.
Hey, yes there are aware of the proposal, we ran by them the final draft before posting it on forum.
Thanks for the proposal—this looks like a win-win. I want to echo the audit sentiment and ensure we don’t run into any issues.
Is the Sky team committed to maintaining and upgrading this integration if needed? For how long? Long-term support is key to ensuring this remains a reliable and efficient solution for the Arbitrum ecosystem.
If yes, this integration seems like a solid step forward.
Thanks for this proposal - it is a welcome development. Sky is one of the better products in the ecosystem. For a while now there has only been support for USDS / sUSDS tokens on Ethereum and Base or so, (at least from the Spark / Sky frontends). It will also be great to have Arbitrum in the mix.
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.
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.
I believe that decisions around the bridge should come from Offchain Labs, and I would rather them even propose the change.
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.
Hi @SpikeWatanabe.eth, Thanks for the proposal. It looks reasonable at first glance.
Just to clarify, since the Sky Custom Gateway is already live, this proposal is only about registering the contract in the Router, correct?
Is the contract being registered in the Router a standard (already used somewhere else) gateway contract, or is it a custom one?
Hey Spike, thanks for putting this proposal forward. Integrating USDS/sUSDS into the Arbitrum Bridge UI could benefit both Arbitrum and Spark by providing users with alternatives to centralized stablecoins and strengthening Arbitrum's position as a DeFi hub. I’m supportive of this direction, but I’d like to dig deeper into a few key points to ensure we’re aligning incentives and mitigating risks:
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
How will governance over gateway upgrades be balanced between Sky and the DAO? Delegates need assurance that the DAO retains oversight if conflicts arise.
Is there any issue for existing users who already bridged via default gateways? Would they have to migrate to any other token?
It seems that the news is already out. Arbitrum support is already live. :raised_hands:
Those announcements are saying that from SKY side - gateway is working as intended, now in turn Arbitrum has to make an update to their router.
We are working to address all pending question from the community.
It seems that the news is already out. Arbitrum support is already live. :raised_hands:
From our perspective, this seems like a largely harmless proposal. We’ve done something similar before with the Rari protocol in the past. There may need to be an audit conducted from the AF after/before the temperature check goes live if we follow the process established from last time
Thank you for a very straightforward proposal. I like Spark.fi dapp. I have been using it for some time and like how they brought the CeFi experience to DeFi. I would love to see support for Arbitrum chain there.
This proposal doesn't require any funds, but it does require technical work done by Offchain Labs and the Sky team. Are both entities aware of this proposal? Are they willing to do the work to execute on this proposal?
I believe that decisions around the bridge should come from Offchain Labs, and I would rather them even propose the change.
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.
Hi @SpikeWatanabe.eth, Thanks for the proposal. It looks reasonable at first glance.
Just to clarify, since the Sky Custom Gateway is already live, this proposal is only about registering the contract in the Router, correct?
Is the contract being registered in the Router a standard (already used somewhere else) gateway contract, or is it a custom one?
Hey Spike, thanks for putting this proposal forward. Integrating USDS/sUSDS into the Arbitrum Bridge UI could benefit both Arbitrum and Spark by providing users with alternatives to centralized stablecoins and strengthening Arbitrum's position as a DeFi hub. I’m supportive of this direction, but I’d like to dig deeper into a few key points to ensure we’re aligning incentives and mitigating risks:
Have Sky’s custom gateway contracts undergone third-party audits, and what contingency plans exist for emergencies (e.g., exploits)?
How will governance over gateway upgrades be balanced between Sky and the DAO? Delegates need assurance that the DAO retains oversight if conflicts arise.
Is there any issue for existing users who already bridged via default gateways? Would they have to migrate to any other token?
It seems that the news is already out. Arbitrum support is already live. :raised_hands:
Those announcements are saying that from SKY side - gateway is working as intended, now in turn Arbitrum has to make an update to their router.
We are working to address all pending question from the community.
It seems that the news is already out. Arbitrum support is already live. :raised_hands:
From our perspective, this seems like a largely harmless proposal. We’ve done something similar before with the Rari protocol in the past. There may need to be an audit conducted from the AF after/before the temperature check goes live if we follow the process established from last time
Thank you for a very straightforward proposal. I like Spark.fi dapp. I have been using it for some time and like how they brought the CeFi experience to DeFi. I would love to see support for Arbitrum chain there.
This proposal doesn't require any funds, but it does require technical work done by Offchain Labs and the Sky team. Are both entities aware of this proposal? Are they willing to do the work to execute on this proposal?