This proposal is one of several similar maintenance proposals that have been put forward recently and require a constitutional vote. Back in September last year, we indicated that such updates should be handled differently, but no such initiative has been proposed so far. We have been asked to support this proposal, which we are doing through this vote. Separately, we will request a dedicated discussion to address these issues in future. However, such a discussion should not delay this proposal or any others of a similar nature in the meantime.
https://superboring.xyz is about to expand to Arbitrum, thus the $BORING token shall become bridgeable to Arbitrum.
$BORING is used to incentivize markets and can thus help drive adoption both to the Superboring protocol and the underlying chain.
Arbitrum wants to help scale Ethereum. Allowing tokens to be bridged back and forth is key to this.
$BORING on Ethereum is a simple, non-upgradable ERC20 contract, deployed to 0x0Bc4dF77353ae96f31bC82bC2536bb23B2009919.
$BORING on Arbitrum is a Super Token - essentially an ERC20 token with advanced capabilities like streaming and scalable distribution. It’s deployed by the same deployer account, to the same address: 0x0Bc4dF77353ae96f31bC82bC2536bb23B2009919 .
According to the Arbitrum bridge docs, bridging to an Arbitrum token with custom logic requires registration in the Arbitrum generic-custom gateway, which can be done either by the L1 token contract itself or by the Arbitrum DAO. Since the L1 token contract was deployed in the past without knowing this requirement, and is not upgradable, the latter option is needed.
Superboring on Arbitrum is expected to go live in a couple of weeks. $BORING availability is not blocking, but would help make this deployment more attractive.
We assume the process of token registration to be well known and thus incur no or negligible cost for the DAO.
This proposal is one of several similar maintenance proposals that have been put forward recently and require a constitutional vote. Back in September last year, we indicated that such updates should be handled differently, but no such initiative has been proposed so far. We have been asked to support this proposal, which we are doing through this vote. Separately, we will request a dedicated discussion to address these issues in future. However, such a discussion should not delay this proposal or any others of a similar nature in the meantime.
https://superboring.xyz is about to expand to Arbitrum, thus the $BORING token shall become bridgeable to Arbitrum.
$BORING is used to incentivize markets and can thus help drive adoption both to the Superboring protocol and the underlying chain.
Arbitrum wants to help scale Ethereum. Allowing tokens to be bridged back and forth is key to this.
$BORING on Ethereum is a simple, non-upgradable ERC20 contract, deployed to 0x0Bc4dF77353ae96f31bC82bC2536bb23B2009919.
$BORING on Arbitrum is a Super Token - essentially an ERC20 token with advanced capabilities like streaming and scalable distribution. It’s deployed by the same deployer account, to the same address: 0x0Bc4dF77353ae96f31bC82bC2536bb23B2009919 .
According to the Arbitrum bridge docs, bridging to an Arbitrum token with custom logic requires registration in the Arbitrum generic-custom gateway, which can be done either by the L1 token contract itself or by the Arbitrum DAO. Since the L1 token contract was deployed in the past without knowing this requirement, and is not upgradable, the latter option is needed.
Superboring on Arbitrum is expected to go live in a couple of weeks. $BORING availability is not blocking, but would help make this deployment more attractive.
We assume the process of token registration to be well known and thus incur no or negligible cost for the DAO.
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/31?u=bob-rossi
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/31?u=bob-rossi
The Event Horizon Community voted FOR on this Proposal (ehARB-125): EventHorizon.vote/vote/arbitrum/ehARB-125
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/42
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/40?u=ocandocrypto
Would like to see this longer term admined in a fashion that doesn't require full dao voting (delegated or optimistic approval) but support the actual underlying
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/39?u=blockful
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/4?u=castlecapital
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/23
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/38?u=euphoria
https://forum.arbitrum.foundation/t/gfx-labs-delegate-communication-thread/13794
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/21?u=tekr0x.eth
this should have been done much earlier.
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/31
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/33
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/32?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/30?u=danielm
The Event Horizon Community voted on this proposal (ehARB-120): EventHorizon.vote/vote/arbitrum/ehARB-120
For, This proposal streamlines Superboring adoption on Arbitrum by bridging tokens and facilitates broader accessibility and supports transparent governance.
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/20
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/26?u=griff
https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x586de5bf366820c4369c041b0bbad2254d78fafe1dcc1528c1ed661bb4dfb671
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/23
https://forum.arbitrum.foundation/t/gfx-labs-delegate-communication-thread/13794
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/17?u=hawheik
we need a simpler process for this kind of thing
The Event Horizon Community voted FOR on this Proposal (ehARB-125): EventHorizon.vote/vote/arbitrum/ehARB-125
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/42
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/40?u=ocandocrypto
Would like to see this longer term admined in a fashion that doesn't require full dao voting (delegated or optimistic approval) but support the actual underlying
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/39?u=blockful
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/4?u=castlecapital
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/23
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/38?u=euphoria
https://forum.arbitrum.foundation/t/gfx-labs-delegate-communication-thread/13794
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/21?u=tekr0x.eth
this should have been done much earlier.
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/31
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/33
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/32?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/30?u=danielm
The Event Horizon Community voted on this proposal (ehARB-120): EventHorizon.vote/vote/arbitrum/ehARB-120
For, This proposal streamlines Superboring adoption on Arbitrum by bridging tokens and facilitates broader accessibility and supports transparent governance.
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/20
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/26?u=griff
https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x586de5bf366820c4369c041b0bbad2254d78fafe1dcc1528c1ed661bb4dfb671
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/23
https://forum.arbitrum.foundation/t/gfx-labs-delegate-communication-thread/13794
https://forum.arbitrum.foundation/t/constitutional-register-boring-in-the-arbitrum-generic-custom-gateway/29206/17?u=hawheik
we need a simpler process for this kind of thing
FOR — Today a constitutional AIP needs 10 % of total ARB to reach quorum; recent votes have scraped by with 6–7 %. Dropping the quorum to 5 % keeps a meaningful safety-barrier while ending the grid-lock risk that makes treasuries nervous about parking votes here. The change doesn’t weaken the ⅔-super-majority rule, so hostile take-overs remain impossible, but it does let genuine upgrades clear when delegate turnout is 40-50 %. A leaner quorum means smoother governance and a more attractive home for large, long-horizon delegators—exactly the stability I want to signal.
FOR — Today a constitutional AIP needs 10 % of total ARB to reach quorum; recent votes have scraped by with 6–7 %. Dropping the quorum to 5 % keeps a meaningful safety-barrier while ending the grid-lock risk that makes treasuries nervous about parking votes here. The change doesn’t weaken the ⅔-super-majority rule, so hostile take-overs remain impossible, but it does let genuine upgrades clear when delegate turnout is 40-50 %. A leaner quorum means smoother governance and a more attractive home for large, long-horizon delegators—exactly the stability I want to signal.
what Super Tokens enable for users or developers within Arbitrum
what Super Tokens enable for users or developers within Arbitrum
I'm happy to expand on this! While this particular vote doesn't simplify anything for bridging other Super Tokens to Arbitrum unfortunately, Superfluid and Super Tokens are already alive and kicking on Arbitrum.
Fundamentally, Superfluid and by extension Super Tokens unlock fully onchain recurring payments and cashflows for a variety of use cases from Payroll, grants, vesting and funding through to consumer use cases in DeFi, SocialFi and subscriptions. My own team is building several new DeFi propositions on top of Superfluid that aren't possible using any other tech stack (recurring buys, sells and withdrawals, settlement every second of DCA, yield and incentives)
For non-custom ERC-20s this step is permissionless
It's my understanding that in principle it's permissionless even for custom ERC20s - if the L1 token is deployed with the necessary code to self-register with the generic-custom gateway.
We are in fact considering the fallback option (in case this DAO proposal gets stuck or takes too long) of deploying a new L1 token which can wrap the existing L1 $BORING, and pair that one with the custom L2 $BORING token. But that would degrade the UX of bridging to and from Arbitrum.
Thank you for commenting. I also got the impression that this operation requires way too much attention of too many participants, given that the same could be achieved in a self-service way if the L1 token were deployed with the requirement in mind.
For context: we did the same on OP-stack chains. In that case, the L1 bridge contract doesn't require any persistent pairing information at all. Instead, the L2 token address is provided by the user with the bridging request tx. The curation is done offchain: in order to have the token show up in the canonical bridge UI, a pull request with the pairing information needs to be made.
Given that this registration involves use of the custom gateway
My understanding is that this request does not involve the custom gateway, but the generic-custom gateway. The use of which is permissionless if the L1 token was deployed with logic for making a specific call to that gateway. Since the L2 token was deployed by the same EOA as the L1 token, there shouldn't be any doubts about the request coming from the same entity either.
what Super Tokens enable for users or developers within Arbitrum
what Super Tokens enable for users or developers within Arbitrum
I'm happy to expand on this! While this particular vote doesn't simplify anything for bridging other Super Tokens to Arbitrum unfortunately, Superfluid and Super Tokens are already alive and kicking on Arbitrum.
Fundamentally, Superfluid and by extension Super Tokens unlock fully onchain recurring payments and cashflows for a variety of use cases from Payroll, grants, vesting and funding through to consumer use cases in DeFi, SocialFi and subscriptions. My own team is building several new DeFi propositions on top of Superfluid that aren't possible using any other tech stack (recurring buys, sells and withdrawals, settlement every second of DCA, yield and incentives)
For non-custom ERC-20s this step is permissionless
It's my understanding that in principle it's permissionless even for custom ERC20s - if the L1 token is deployed with the necessary code to self-register with the generic-custom gateway.
We are in fact considering the fallback option (in case this DAO proposal gets stuck or takes too long) of deploying a new L1 token which can wrap the existing L1 $BORING, and pair that one with the custom L2 $BORING token. But that would degrade the UX of bridging to and from Arbitrum.
Thank you for commenting. I also got the impression that this operation requires way too much attention of too many participants, given that the same could be achieved in a self-service way if the L1 token were deployed with the requirement in mind.
For context: we did the same on OP-stack chains. In that case, the L1 bridge contract doesn't require any persistent pairing information at all. Instead, the L2 token address is provided by the user with the bridging request tx. The curation is done offchain: in order to have the token show up in the canonical bridge UI, a pull request with the pairing information needs to be made.
Given that this registration involves use of the custom gateway
My understanding is that this request does not involve the custom gateway, but the generic-custom gateway. The use of which is permissionless if the L1 token was deployed with logic for making a specific call to that gateway. Since the L2 token was deployed by the same EOA as the L1 token, there shouldn't be any doubts about the request coming from the same entity either.
Hi all,
I am one of the advisors from Superfluid Foundation, and also co-founded the Superfluid. And I am also primarily responsible for SuperBoring's smart contract.
A bit of background, on Base mainnet, we have processed over $4M in volume to date with 1000 active users per day (dune dashboard), and we expect an even higher volume on Arbitrum considering its DeFi friendliness.
Hi all,
I am one of the advisors from Superfluid Foundation, and also co-founded the Superfluid. And I am also primarily responsible for SuperBoring's smart contract.
A bit of background, on Base mainnet, we have processed over $4M in volume to date with 1000 active users per day (dune dashboard), and we expect an even higher volume on Arbitrum considering its DeFi friendliness.
However, maybe there is a misunderstanding here since it's a bit surprising that it seems that using Arbitrum's bridge is a privilege instead of a public good, as we hoped for.
To be clear, BORING is SuperBoring's token on the mainnet, and we would like it to be bridged to Arbitrum unambiguously so that our users won't be mistaken for other counterfeit "BORING" that might harm our users. For example, we have achieved it on Base mainnet "SB_TOKEN_ADDRESS=0x2112b92A4f6496B7b2f10850857FfA270464d054"
We consider such a function a public good and expect a low barrier to entry. Without such a service, we cannot deploy our service on Arbitrum because users cannot tell which Boring is canonical. This, our estimation, is a lose-lose situation for both arbitrum and SuperBoring as a product.
We appreciate Arbitrum's DAO's commitment to community alignment and ecosystem projects' engagement; we may need need to assess the cost of such a requirement and plan differently. However, I want to clarify first: What is the minimum requirement for us to have a "canonical bridged" token for our product token?
Voting has ended!
===============
[[CONSTITUTIONAL] Register $BORING in the Arbitrum generic-custom gateway](https://www.tally.xyz/gov/eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9/proposal/2646816212452902696)
### Final Votes
| **Category** | **Result** | **Details** |
|----------------------|------------------|-----------------------------|
| **Quorum reached** | ✅ | 213.04M of 204.86M |
| **Majority Support** | ✅ | |
| **For** | | 212.95M (99.9%) |
| **Against** | | 42.11k (0.0%) |
| **Abstain** | | 89.48k (0.0%) |
* * *
I am a bot. Questions? Contact [email protected]
Onchain voting for this proposal is ending within 24 hours:
[Vote on Tally: [CONSTITUTIONAL] Register $BORING in the Arbitrum generic-custom gateway](https://www.tally.xyz/gov/eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9/proposal/2646816212452902696)
* * *
I am a bot. Questions? Contact [email protected]
Voting has started for this proposal! Vote on Tally: [CONSTITUTIONAL] Register $BORING in the Arbitrum generic-custom gateway
I am a bot. Questions? Contact [email protected]
The Offchain Labs team has confirmed that the current Tally proposal payload matches with the specification of the proposal
Hi all,
I am one of the advisors from Superfluid Foundation, and also co-founded the Superfluid. And I am also primarily responsible for SuperBoring's smart contract.
A bit of background, on Base mainnet, we have processed over $4M in volume to date with 1000 active users per day (dune dashboard), and we expect an even higher volume on Arbitrum considering its DeFi friendliness.
Hi all,
I am one of the advisors from Superfluid Foundation, and also co-founded the Superfluid. And I am also primarily responsible for SuperBoring's smart contract.
A bit of background, on Base mainnet, we have processed over $4M in volume to date with 1000 active users per day (dune dashboard), and we expect an even higher volume on Arbitrum considering its DeFi friendliness.
However, maybe there is a misunderstanding here since it's a bit surprising that it seems that using Arbitrum's bridge is a privilege instead of a public good, as we hoped for.
To be clear, BORING is SuperBoring's token on the mainnet, and we would like it to be bridged to Arbitrum unambiguously so that our users won't be mistaken for other counterfeit "BORING" that might harm our users. For example, we have achieved it on Base mainnet "SB_TOKEN_ADDRESS=0x2112b92A4f6496B7b2f10850857FfA270464d054"
We consider such a function a public good and expect a low barrier to entry. Without such a service, we cannot deploy our service on Arbitrum because users cannot tell which Boring is canonical. This, our estimation, is a lose-lose situation for both arbitrum and SuperBoring as a product.
We appreciate Arbitrum's DAO's commitment to community alignment and ecosystem projects' engagement; we may need need to assess the cost of such a requirement and plan differently. However, I want to clarify first: What is the minimum requirement for us to have a "canonical bridged" token for our product token?
Voting has ended!
===============
[[CONSTITUTIONAL] Register $BORING in the Arbitrum generic-custom gateway](https://www.tally.xyz/gov/eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9/proposal/2646816212452902696)
### Final Votes
| **Category** | **Result** | **Details** |
|----------------------|------------------|-----------------------------|
| **Quorum reached** | ✅ | 213.04M of 204.86M |
| **Majority Support** | ✅ | |
| **For** | | 212.95M (99.9%) |
| **Against** | | 42.11k (0.0%) |
| **Abstain** | | 89.48k (0.0%) |
* * *
I am a bot. Questions? Contact [email protected]
Onchain voting for this proposal is ending within 24 hours:
[Vote on Tally: [CONSTITUTIONAL] Register $BORING in the Arbitrum generic-custom gateway](https://www.tally.xyz/gov/eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9/proposal/2646816212452902696)
* * *
I am a bot. Questions? Contact [email protected]
Voting has started for this proposal! Vote on Tally: [CONSTITUTIONAL] Register $BORING in the Arbitrum generic-custom gateway
I am a bot. Questions? Contact [email protected]
The Offchain Labs team has confirmed that the current Tally proposal payload matches with the specification of the proposal
voted For on this onchain vote because this should have been done much earlier.
voted For on this onchain vote because this should have been done much earlier.
voted For on this past offchain vote because we need a simpler process for this kind of thing.
I voted FOR, and the reasoning remains the same.
gm, VOTED in favor as per previous rationale.
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 are voting 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 are voting FOR the proposal.
We previously supported the proposal during the temp-check, and we are extending our support to the onchain vote as well. The most important part of this vote, as we also stated previously, is to figure out how to handle these registrations. To that end, we’ve created a working group that aims to address the situation.
Thank you for the proposal. I always write this, and I always mean it.
This proposal follows in line with previous similar decisions made by the DAO and contributes to expanding the operational capabilities of the DAO as a whole. These are two key reasons why I view this proposal positively.
Thank you for the proposal. I always write this, and I always mean it.
This proposal follows in line with previous similar decisions made by the DAO and contributes to expanding the operational capabilities of the DAO as a whole. These are two key reasons why I view this proposal positively.
I also believe that collaborating with a reliable and trustworthy additional organization/protocol/entity strengthens the broader team, which helps attract more attention, and with that, increases the potential for revenue generation. As I’ve mentioned multiple times, for me, revenue growth is one of the most important — if not the most important — factors for the DAO’s long-term success.
Lastly, the insightful comment by vijaym1 served as the cherry on top to vote FOR.
As in @web3citizenxyz representation, voting for. Below the rationale:
We are voting FOR the proposal.
This is a technically simple proposal, but one that could cause friction for other projects to do the same. L2beat has brought up discussions about ways to improve this process without the need for a Constitutional Proposal—and we support this type of initiative.
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.
We see this vote as a straightforward step to let $BORING integrate with Arbitrum using the generic-custom gateway. This helps Superboring grow and lets users confidently interact with the correct token, reducing confusion or risk of imitations. From a technical perspective, this is simply aligning two contracts for safe bridging, without introducing any new risk to existing systems or the DAO treasury.
As we’ve said before, requiring a formal DAO vote for each technical mapping like this is not the most efficient use of community effort. Projects like Superboring want to ship real adoption and volume; waiting for a governance cycle makes the experience harder for builders and does not make the network safer. We agree with other delegates that technical reviews and audits, not repeated DAO-wide votes, should set the bar for routine gateway actions.
We also appreciate recent steps to address this, like the launch of the Maintenance Upgrades Working Group led by @krst. We hope this initiative results in a smoother and more predictable path for operational upgrades or routine actions like token registration, so that governance is focused on the highest value issues while technical experts keep our infrastructure safe.
This update is positive for the Arbitrum ecosystem, poses low risk, and supports a well-established project.
I have voted in Favour. We have supported similar proposals in the past, and did not see any reason to reject it.
I already did this in private channels, but to keep things official will also post here. As this vote passed the temperature check on Snapshot and the DAO almost unanimously showed support for it, I'd like to request support from @Arbitrum Foundation with followup steps - esp with due dilligence and preparing payload for the onchain transaction. As this is an onchain change with consequences to the ecosystem, we feel that it should not be a responsibility of a single delegate and it needs to be validated by the Arbitrum Foundation anyway. Once the payload is prepare and greenlighted by the Foundation we'll be happy to help with putting the vote onchain.
I would also like to mention that we have proposed forming a working group to discuss how to handle such changes in the future so they are less troublesome and take less than a few months to complete.
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 are voting 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 are voting FOR the proposal.
We recently also voted in favor of the proposal to register the Sky Custom Gateway contracts in the router, and we are also supportive of registering $BORING, similar to how we had also done for $RARI. As we noted in the proposal for Sky, though, we need to figure out a frictionless way to handle these registrations and to avoid having a fully-fledged vote for each of them.
DAOplomats is voting FOR this proposal on Snapshot.
We have approved similar proposals in the past so we didn't have any issue supporting this.
Voting “For”
I agree with everyone else, this doesn’t really seem to be a DAO item. I understand that due to lack of other options, this is the most efficient way to get it done, so voting For as not to hinder progress of the Arb ecosystem.
Voting “For”
I agree with everyone else, this doesn’t really seem to be a DAO item. I understand that due to lack of other options, this is the most efficient way to get it done, so voting For as not to hinder progress of the Arb ecosystem.
Look, I’m not a technical user so if there is an overarching issue that I’m not understanding so be it… but there has to be abetter way to do this. either decentralized Or atleast without a DAO vote. I can’t imagine there isn’t a better way to handle this that doesn’t rely on the DAO process, as it has to be off putting to projects to have to delay there launches due to admistrative burden.
Edit: Editing to save forum space, my opinion has not changed since my snapshot vote and I am voting for on Tally as well
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 Snapshot 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 Snapshot voting.
As mentioned in our earlier feedback, we see this as a routine technical update to allow $BORING to bridge properly to Arbitrum, rather than as an endorsement of the token itself.
While we fully support Superboring’s expansion and recognize the value of Super Tokens for on-chain payments, the need for a full DAO vote on these custom token registrations adds unnecessary overhead and slows down onboarding for growing projects. We align with others who’ve said that technical review and audits should become the main requirements, with only exceptional cases going to governance. We urge the DAO to streamline such processes for the future, and we support this request as a positive, low-risk step for Arbitrum.
I’m voting yes because allowing $BORING to work on Arbitrum will help more people use the Superboring app and bring more activity to the chain. It’s a small change but useful, and it doesn’t cost the DAO anything. Seem like a good move.
voted For on this past offchain vote because we need a simpler process for this kind of thing.
I voted FOR, and the reasoning remains the same.
gm, VOTED in favor as per previous rationale.
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 are voting 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 are voting FOR the proposal.
We previously supported the proposal during the temp-check, and we are extending our support to the onchain vote as well. The most important part of this vote, as we also stated previously, is to figure out how to handle these registrations. To that end, we’ve created a working group that aims to address the situation.
Thank you for the proposal. I always write this, and I always mean it.
This proposal follows in line with previous similar decisions made by the DAO and contributes to expanding the operational capabilities of the DAO as a whole. These are two key reasons why I view this proposal positively.
Thank you for the proposal. I always write this, and I always mean it.
This proposal follows in line with previous similar decisions made by the DAO and contributes to expanding the operational capabilities of the DAO as a whole. These are two key reasons why I view this proposal positively.
I also believe that collaborating with a reliable and trustworthy additional organization/protocol/entity strengthens the broader team, which helps attract more attention, and with that, increases the potential for revenue generation. As I’ve mentioned multiple times, for me, revenue growth is one of the most important — if not the most important — factors for the DAO’s long-term success.
Lastly, the insightful comment by vijaym1 served as the cherry on top to vote FOR.
As in @web3citizenxyz representation, voting for. Below the rationale:
We are voting FOR the proposal.
This is a technically simple proposal, but one that could cause friction for other projects to do the same. L2beat has brought up discussions about ways to improve this process without the need for a Constitutional Proposal—and we support this type of initiative.
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.
We see this vote as a straightforward step to let $BORING integrate with Arbitrum using the generic-custom gateway. This helps Superboring grow and lets users confidently interact with the correct token, reducing confusion or risk of imitations. From a technical perspective, this is simply aligning two contracts for safe bridging, without introducing any new risk to existing systems or the DAO treasury.
As we’ve said before, requiring a formal DAO vote for each technical mapping like this is not the most efficient use of community effort. Projects like Superboring want to ship real adoption and volume; waiting for a governance cycle makes the experience harder for builders and does not make the network safer. We agree with other delegates that technical reviews and audits, not repeated DAO-wide votes, should set the bar for routine gateway actions.
We also appreciate recent steps to address this, like the launch of the Maintenance Upgrades Working Group led by @krst. We hope this initiative results in a smoother and more predictable path for operational upgrades or routine actions like token registration, so that governance is focused on the highest value issues while technical experts keep our infrastructure safe.
This update is positive for the Arbitrum ecosystem, poses low risk, and supports a well-established project.
I have voted in Favour. We have supported similar proposals in the past, and did not see any reason to reject it.
I already did this in private channels, but to keep things official will also post here. As this vote passed the temperature check on Snapshot and the DAO almost unanimously showed support for it, I'd like to request support from @Arbitrum Foundation with followup steps - esp with due dilligence and preparing payload for the onchain transaction. As this is an onchain change with consequences to the ecosystem, we feel that it should not be a responsibility of a single delegate and it needs to be validated by the Arbitrum Foundation anyway. Once the payload is prepare and greenlighted by the Foundation we'll be happy to help with putting the vote onchain.
I would also like to mention that we have proposed forming a working group to discuss how to handle such changes in the future so they are less troublesome and take less than a few months to complete.
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 are voting 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 are voting FOR the proposal.
We recently also voted in favor of the proposal to register the Sky Custom Gateway contracts in the router, and we are also supportive of registering $BORING, similar to how we had also done for $RARI. As we noted in the proposal for Sky, though, we need to figure out a frictionless way to handle these registrations and to avoid having a fully-fledged vote for each of them.
DAOplomats is voting FOR this proposal on Snapshot.
We have approved similar proposals in the past so we didn't have any issue supporting this.
Voting “For”
I agree with everyone else, this doesn’t really seem to be a DAO item. I understand that due to lack of other options, this is the most efficient way to get it done, so voting For as not to hinder progress of the Arb ecosystem.
Voting “For”
I agree with everyone else, this doesn’t really seem to be a DAO item. I understand that due to lack of other options, this is the most efficient way to get it done, so voting For as not to hinder progress of the Arb ecosystem.
Look, I’m not a technical user so if there is an overarching issue that I’m not understanding so be it… but there has to be abetter way to do this. either decentralized Or atleast without a DAO vote. I can’t imagine there isn’t a better way to handle this that doesn’t rely on the DAO process, as it has to be off putting to projects to have to delay there launches due to admistrative burden.
Edit: Editing to save forum space, my opinion has not changed since my snapshot vote and I am voting for on Tally as well
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 Snapshot 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 Snapshot voting.
As mentioned in our earlier feedback, we see this as a routine technical update to allow $BORING to bridge properly to Arbitrum, rather than as an endorsement of the token itself.
While we fully support Superboring’s expansion and recognize the value of Super Tokens for on-chain payments, the need for a full DAO vote on these custom token registrations adds unnecessary overhead and slows down onboarding for growing projects. We align with others who’ve said that technical review and audits should become the main requirements, with only exceptional cases going to governance. We urge the DAO to streamline such processes for the future, and we support this request as a positive, low-risk step for Arbitrum.
I’m voting yes because allowing $BORING to work on Arbitrum will help more people use the Superboring app and bring more activity to the chain. It’s a small change but useful, and it doesn’t cost the DAO anything. Seem like a good move.
We vote in favor of this proposal.
This proposal addresses an operational requirement that ideally should be permissionless and not necessitate direct DAO approval. Registering $BORING poses minimal risk or potential harm to the DAO's interests, as it simply enables the token’s bridging capability essential for Superboring’s growth on Arbitrum, benefiting the ecosystem. However, it's clear from this process that the DAO should work towards streamlining and automating such procedures in the future, minimizing governance overhead and allowing smoother onboarding of similar tokens.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
We appreciate the solid effort Didi from Super Boring's participation into Arbitrum ecosystem. Great discussion surrounding the adoption of custom gateways across chains. We agree with sentiment @vijaym1 there's significant traction built and given the development is headed by the team for Superfluid this integration could be fruitful for Arbitrum's ecosystem. As this will require no negligible cost and enhances protocol development within the chain, we are in support of this proposal.
I support the proposal. BORING is a well-established protocol and this is a straightforward technical update to enable bridging.
gm, voted FOR. Welcome $Boring to Arbitrum. Also in support of a simplified process:
gm, voted FOR. Welcome $Boring to Arbitrum. Also in support of a simplified process:
The current frictions are evident. In this thread, @Jose_StableLab clearly pointed out that builders need more support and a simplified process. This would not only benefit builders, but also delegates, who currently must vote on every single token that seeks to be added to the official bridge.
I voted FOR in this proposal. The protocol is expanding to Arbitrum and will bring new use cases to the chain.
We support this proposal as it enables $BORING to be bridged to Arbitrum, supporting Superboring’s expansion and incentivized adoption on the network. Since the token is non-upgradable and requires DAO intervention to register with the custom gateway, this is a simple, low-cost action that enhances ecosystem composability without introducing risk.
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.
One of the things we’ve observed across ecosystems is that governance and infrastructure should not be tightly coupled for operational actions like token registry, especially when security concerns can be managed off-chain through audits and pre-validation.
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.
One of the things we’ve observed across ecosystems is that governance and infrastructure should not be tightly coupled for operational actions like token registry, especially when security concerns can be managed off-chain through audits and pre-validation.
We align with comments from @AranaDigital and @AbdullahUmar that requiring a full constitutional vote for a relatively straightforward L1–L2 token mapping creates unnecessary governance overhead. When multiple such requests begin to accumulate, this adds DAO fatigue and dilutes delegate's attention due to other higher-impact proposals.
Additionally, not all delegates have the technical depth to meaningfully evaluate low-level operations like custom token mappings. Requiring DAO-wide consensus for these proposals puts an extra burden on delegates, some of whom rely on expert input or standardized procedures to assess technical details. In most cases, such proposals either become black boxes or rubber stamps. A predictable, audit-backed track would improve both the clarity of decisions and the security of the process.
As mentioned in the previous comment in the Sky token proposal, this kind of update should not always need to go through a full constitutional proposal. A more efficient path could be explored within the DAO, where OCL or the AF could be temporarily delegated the ability to review and approve standard token registry requests. This delegation could be time-bound and include clear reporting requirements, keeping the process transparent while reducing the load on delegates.
On this specific proposal, we support the BORING token registration, given the team’s multi-chain presence and early traction on Base, as mentioned by @hellwolf.
That said, we believe the proposal could benefit from a clearer explanation of what Super Tokens enable for users or developers within Arbitrum. The concept is promising, but it’s not yet fully clear how streaming functionality will be used across existing DeFi use cases or integrated into the broader ecosystem.
We appreciate the team’s effort to follow the current process and bring this to the DAO, but we believe now is a good time for the DAO to streamline and reduce the operational friction around this category of proposals.
I voted FOR this proposal
https://forum.arbitrum.foundation/t/cp0x-delegate-communication-thread/22217/201?u=cp0x
Appreciate you jumping in with that context, @vijaym1. This helps connect the dots.
The examples you shared make it much clearer how Super Tokens are already being used on Arbitrum. The recurring payment flows and on-chain DCA mechanics you mentioned are exciting; it feels like something that can open up a whole new layer of native utility here.
Thanks again for laying it out.
I am voting "For" this proposal, with the understanding that adding a token to the router introduces no additional risk to the gateway or other tokens registered with the gateway.
This isn't intended as an endorsement of $BORING or the team behind it, it is simply approving of a basic infrastructure operation, in my mind.
I am voting "For" this proposal, with the understanding that adding a token to the router introduces no additional risk to the gateway or other tokens registered with the gateway.
This isn't intended as an endorsement of $BORING or the team behind it, it is simply approving of a basic infrastructure operation, in my mind.
As has been mentioned by others in this and other similar proposals, I also think that a streamlined process for these kinds of operation, perhaps through an AAE, would be a good idea.
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Snapshot Vote.
Rationale
As we previously stated in the case of Sky, a simpler and more streamlined process must be established to support builders seeking to migrate or bridge their tokens into the Arbitrum ecosystem.
In general, I am supporting this proposal and will be voting for if/when it comes to it — it’s clear that enabling $BORING on Arbitrum brings value, and I appreciate the team’s effort to follow the current process.
As a non-technical voter, I may be missing some of the finer details, but, based on feedback and discussion here, it looks like requiring a full constitutional vote for this kind of technical mapping creates unnecessary friction — especially for less funded teams trying to build.
In general, I am supporting this proposal and will be voting for if/when it comes to it — it’s clear that enabling $BORING on Arbitrum brings value, and I appreciate the team’s effort to follow the current process.
As a non-technical voter, I may be missing some of the finer details, but, based on feedback and discussion here, it looks like requiring a full constitutional vote for this kind of technical mapping creates unnecessary friction — especially for less funded teams trying to build.
I’m interested in supporting efforts to improve this process. A well-defined, streamlined path — with the right technical checks but less overhead — would make it easier for builders and clearer for voters like me. I’m looking forward to participating in that discussion.
I'm not sure that this would degrade the UX of bridging to and from Arbitrum At the moment, there are many tokens in various chains that are not bridged through the main chain bridge. Judging by the statistics on the number of tokens that were transferred to Arbitrum, the majority are
Thank you @AbdullahUmar for raising awareness about the complexities around launching a custom gateway on Arbitrum.
As StableLab, we've been closely working with the Sky team throughout their custom gateway proposal process, and we’d like to share our perspective on the experience so far:
Thank you @AbdullahUmar for raising awareness about the complexities around launching a custom gateway on Arbitrum.
As StableLab, we've been closely working with the Sky team throughout their custom gateway proposal process, and we’d like to share our perspective on the experience so far:
The Sky proposal is still in progress. While much of the technical and procedural work has been completed, there are still critical steps required before the proposal is ready for onchain submission.
All of the Sky-side code has been audited, as correctly noted in the proposal. The team has taken their due diligence seriously to ensure security and correctness.
Regarding Offchain Labs’ involvement, when approached, they provided the governance action contract and the required governance documentation necessary for executing it to achieve the Router update. However, they asked Sky to conduct their own review of the governance action contract and prepare and check the governance transaction payload themselves.
Because the governance execution itself must also be verified, the Sky team has independently engaged a separate security firm to audit and validate the governance actions. Importantly, they are covering these costs themselves.
We've also reached out to the $BORING team to support their efforts as well. However, due to the differing stages of their respective processes and some technical differences between both proposals, it’s likely that the two gateway proposals will proceed onchain separately. This is necessary to prevent delays in Sky’s timeline for launching USDS on Arbitrum.
Overall, we believe the current process for deploying custom gateways on Arbitrum, while secure, is highly resource-intensive and time-consuming. This creates a significant burden for projects looking to integrate with Arbitrum, particularly those without access to deep technical or auditing resources.
We think it’s worth opening a discussion on whether this process can be streamlined in the future, without compromising on security or decentralization, to reduce the overhead for teams launching in the Arbitrum ecosystem.
We support registering $BORING in the custom gateway but question the need for a full constitutional vote. The change is a routine mapping of L1 and L2 addresses but triggers the DAO’s heaviest process. For non-custom ERC-20s this step is permissionless, and requiring an AIP here creates avoidable governance fatigue and risks failure through low quorum. A more efficient path would be something like:
Example 1: RARI Example 2: USDS and sUSDS (Sky tokens)
Below are the opinions of the UADP:
The following points are more relevant to the DAO as opposed to the Superboring team.
From what I can recall, this is the third instance of a proposal like this being proposed. The last two examples passed successfully through the Snapshot phase.
Example 1: RARI — passed both onchain and Snapshot Example 2: USDS and sUSDS (Sky tokens) — passed Snapshot
I would appreciate adding language to the proposal about this not being an endorsement by ArbitrumDAO (unless that's the request) but simply about operating a process that ideally should be permisionless (if indeed that's the case)
Thanks for sharing this proposal.
Before proceeding with a formal DAO proposal, we recommend that the SuperBoring team first engage directly with the Arbitrum Foundation and Offchain Labs regarding the request to register the $BORING token with the Arbitrum bridge.
Thanks for sharing this proposal.
Before proceeding with a formal DAO proposal, we recommend that the SuperBoring team first engage directly with the Arbitrum Foundation and Offchain Labs regarding the request to register the $BORING token with the Arbitrum bridge.
Given that this registration involves use of the custom gateway which typically requires coordination with core infrastructure teams, it’s important to align on technical feasibility and implementation details in advance.
We also suggest referring to this prior proposal as a useful precedent:
Constitutional Proposal to Register SKY Custom Gateway Contracts
That process may offer insight into both the necessary steps and considerations that should be addressed before bringing a similar request to the DAO.
Looking forward to seeing this move forward with the appropriate coordination.
Hello @didi welcome to the forum. I have deep respect for builders entering the ecosystem and expanding their product. I see this post has sat without response for quite a while. That said, I don't want the initial lack of engagement to discourage you from building here, and I believe that improvements can be made such that you get the amount of response you'd like, and the community can benefit from your contributions as a member. That said, I wanted to see if I may be able to help you better integrate into the community.
My initial proposal feedback is that the current proposal instance is rather sparse, and that is likely why it hasn't garnered much attention. As a delegate myself, I can imagine that the others would like to see a more robust piece of content. You note that $BORING is a token, but don't deeply explain what the product is. In addition to a product summary, I'd be curious to see metrics around superboring (tvl, volume, revenue, user metrics). It would benefit your proposal to also align these details with the value add created for the Arbitrum ecosystem. I also noticed you have SuperFluid in your name, an introduction to yourself and explanation of the relationship between SuperBoring, SuperFluid and yourself would be beneficial as well.
We vote in favor of this proposal.
This proposal addresses an operational requirement that ideally should be permissionless and not necessitate direct DAO approval. Registering $BORING poses minimal risk or potential harm to the DAO's interests, as it simply enables the token’s bridging capability essential for Superboring’s growth on Arbitrum, benefiting the ecosystem. However, it's clear from this process that the DAO should work towards streamlining and automating such procedures in the future, minimizing governance overhead and allowing smoother onboarding of similar tokens.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
We appreciate the solid effort Didi from Super Boring's participation into Arbitrum ecosystem. Great discussion surrounding the adoption of custom gateways across chains. We agree with sentiment @vijaym1 there's significant traction built and given the development is headed by the team for Superfluid this integration could be fruitful for Arbitrum's ecosystem. As this will require no negligible cost and enhances protocol development within the chain, we are in support of this proposal.
I support the proposal. BORING is a well-established protocol and this is a straightforward technical update to enable bridging.
gm, voted FOR. Welcome $Boring to Arbitrum. Also in support of a simplified process:
gm, voted FOR. Welcome $Boring to Arbitrum. Also in support of a simplified process:
The current frictions are evident. In this thread, @Jose_StableLab clearly pointed out that builders need more support and a simplified process. This would not only benefit builders, but also delegates, who currently must vote on every single token that seeks to be added to the official bridge.
I voted FOR in this proposal. The protocol is expanding to Arbitrum and will bring new use cases to the chain.
We support this proposal as it enables $BORING to be bridged to Arbitrum, supporting Superboring’s expansion and incentivized adoption on the network. Since the token is non-upgradable and requires DAO intervention to register with the custom gateway, this is a simple, low-cost action that enhances ecosystem composability without introducing risk.
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.
One of the things we’ve observed across ecosystems is that governance and infrastructure should not be tightly coupled for operational actions like token registry, especially when security concerns can be managed off-chain through audits and pre-validation.
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.
One of the things we’ve observed across ecosystems is that governance and infrastructure should not be tightly coupled for operational actions like token registry, especially when security concerns can be managed off-chain through audits and pre-validation.
We align with comments from @AranaDigital and @AbdullahUmar that requiring a full constitutional vote for a relatively straightforward L1–L2 token mapping creates unnecessary governance overhead. When multiple such requests begin to accumulate, this adds DAO fatigue and dilutes delegate's attention due to other higher-impact proposals.
Additionally, not all delegates have the technical depth to meaningfully evaluate low-level operations like custom token mappings. Requiring DAO-wide consensus for these proposals puts an extra burden on delegates, some of whom rely on expert input or standardized procedures to assess technical details. In most cases, such proposals either become black boxes or rubber stamps. A predictable, audit-backed track would improve both the clarity of decisions and the security of the process.
As mentioned in the previous comment in the Sky token proposal, this kind of update should not always need to go through a full constitutional proposal. A more efficient path could be explored within the DAO, where OCL or the AF could be temporarily delegated the ability to review and approve standard token registry requests. This delegation could be time-bound and include clear reporting requirements, keeping the process transparent while reducing the load on delegates.
On this specific proposal, we support the BORING token registration, given the team’s multi-chain presence and early traction on Base, as mentioned by @hellwolf.
That said, we believe the proposal could benefit from a clearer explanation of what Super Tokens enable for users or developers within Arbitrum. The concept is promising, but it’s not yet fully clear how streaming functionality will be used across existing DeFi use cases or integrated into the broader ecosystem.
We appreciate the team’s effort to follow the current process and bring this to the DAO, but we believe now is a good time for the DAO to streamline and reduce the operational friction around this category of proposals.
I voted FOR this proposal
https://forum.arbitrum.foundation/t/cp0x-delegate-communication-thread/22217/201?u=cp0x
Appreciate you jumping in with that context, @vijaym1. This helps connect the dots.
The examples you shared make it much clearer how Super Tokens are already being used on Arbitrum. The recurring payment flows and on-chain DCA mechanics you mentioned are exciting; it feels like something that can open up a whole new layer of native utility here.
Thanks again for laying it out.
I am voting "For" this proposal, with the understanding that adding a token to the router introduces no additional risk to the gateway or other tokens registered with the gateway.
This isn't intended as an endorsement of $BORING or the team behind it, it is simply approving of a basic infrastructure operation, in my mind.
I am voting "For" this proposal, with the understanding that adding a token to the router introduces no additional risk to the gateway or other tokens registered with the gateway.
This isn't intended as an endorsement of $BORING or the team behind it, it is simply approving of a basic infrastructure operation, in my mind.
As has been mentioned by others in this and other similar proposals, I also think that a streamlined process for these kinds of operation, perhaps through an AAE, would be a good idea.
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Snapshot Vote.
Rationale
As we previously stated in the case of Sky, a simpler and more streamlined process must be established to support builders seeking to migrate or bridge their tokens into the Arbitrum ecosystem.
In general, I am supporting this proposal and will be voting for if/when it comes to it — it’s clear that enabling $BORING on Arbitrum brings value, and I appreciate the team’s effort to follow the current process.
As a non-technical voter, I may be missing some of the finer details, but, based on feedback and discussion here, it looks like requiring a full constitutional vote for this kind of technical mapping creates unnecessary friction — especially for less funded teams trying to build.
In general, I am supporting this proposal and will be voting for if/when it comes to it — it’s clear that enabling $BORING on Arbitrum brings value, and I appreciate the team’s effort to follow the current process.
As a non-technical voter, I may be missing some of the finer details, but, based on feedback and discussion here, it looks like requiring a full constitutional vote for this kind of technical mapping creates unnecessary friction — especially for less funded teams trying to build.
I’m interested in supporting efforts to improve this process. A well-defined, streamlined path — with the right technical checks but less overhead — would make it easier for builders and clearer for voters like me. I’m looking forward to participating in that discussion.
I'm not sure that this would degrade the UX of bridging to and from Arbitrum At the moment, there are many tokens in various chains that are not bridged through the main chain bridge. Judging by the statistics on the number of tokens that were transferred to Arbitrum, the majority are
Thank you @AbdullahUmar for raising awareness about the complexities around launching a custom gateway on Arbitrum.
As StableLab, we've been closely working with the Sky team throughout their custom gateway proposal process, and we’d like to share our perspective on the experience so far:
Thank you @AbdullahUmar for raising awareness about the complexities around launching a custom gateway on Arbitrum.
As StableLab, we've been closely working with the Sky team throughout their custom gateway proposal process, and we’d like to share our perspective on the experience so far:
The Sky proposal is still in progress. While much of the technical and procedural work has been completed, there are still critical steps required before the proposal is ready for onchain submission.
All of the Sky-side code has been audited, as correctly noted in the proposal. The team has taken their due diligence seriously to ensure security and correctness.
Regarding Offchain Labs’ involvement, when approached, they provided the governance action contract and the required governance documentation necessary for executing it to achieve the Router update. However, they asked Sky to conduct their own review of the governance action contract and prepare and check the governance transaction payload themselves.
Because the governance execution itself must also be verified, the Sky team has independently engaged a separate security firm to audit and validate the governance actions. Importantly, they are covering these costs themselves.
We've also reached out to the $BORING team to support their efforts as well. However, due to the differing stages of their respective processes and some technical differences between both proposals, it’s likely that the two gateway proposals will proceed onchain separately. This is necessary to prevent delays in Sky’s timeline for launching USDS on Arbitrum.
Overall, we believe the current process for deploying custom gateways on Arbitrum, while secure, is highly resource-intensive and time-consuming. This creates a significant burden for projects looking to integrate with Arbitrum, particularly those without access to deep technical or auditing resources.
We think it’s worth opening a discussion on whether this process can be streamlined in the future, without compromising on security or decentralization, to reduce the overhead for teams launching in the Arbitrum ecosystem.
We support registering $BORING in the custom gateway but question the need for a full constitutional vote. The change is a routine mapping of L1 and L2 addresses but triggers the DAO’s heaviest process. For non-custom ERC-20s this step is permissionless, and requiring an AIP here creates avoidable governance fatigue and risks failure through low quorum. A more efficient path would be something like:
Example 1: RARI Example 2: USDS and sUSDS (Sky tokens)
Below are the opinions of the UADP:
The following points are more relevant to the DAO as opposed to the Superboring team.
From what I can recall, this is the third instance of a proposal like this being proposed. The last two examples passed successfully through the Snapshot phase.
Example 1: RARI — passed both onchain and Snapshot Example 2: USDS and sUSDS (Sky tokens) — passed Snapshot
I would appreciate adding language to the proposal about this not being an endorsement by ArbitrumDAO (unless that's the request) but simply about operating a process that ideally should be permisionless (if indeed that's the case)
Thanks for sharing this proposal.
Before proceeding with a formal DAO proposal, we recommend that the SuperBoring team first engage directly with the Arbitrum Foundation and Offchain Labs regarding the request to register the $BORING token with the Arbitrum bridge.
Thanks for sharing this proposal.
Before proceeding with a formal DAO proposal, we recommend that the SuperBoring team first engage directly with the Arbitrum Foundation and Offchain Labs regarding the request to register the $BORING token with the Arbitrum bridge.
Given that this registration involves use of the custom gateway which typically requires coordination with core infrastructure teams, it’s important to align on technical feasibility and implementation details in advance.
We also suggest referring to this prior proposal as a useful precedent:
Constitutional Proposal to Register SKY Custom Gateway Contracts
That process may offer insight into both the necessary steps and considerations that should be addressed before bringing a similar request to the DAO.
Looking forward to seeing this move forward with the appropriate coordination.
Hello @didi welcome to the forum. I have deep respect for builders entering the ecosystem and expanding their product. I see this post has sat without response for quite a while. That said, I don't want the initial lack of engagement to discourage you from building here, and I believe that improvements can be made such that you get the amount of response you'd like, and the community can benefit from your contributions as a member. That said, I wanted to see if I may be able to help you better integrate into the community.
My initial proposal feedback is that the current proposal instance is rather sparse, and that is likely why it hasn't garnered much attention. As a delegate myself, I can imagine that the others would like to see a more robust piece of content. You note that $BORING is a token, but don't deeply explain what the product is. In addition to a product summary, I'd be curious to see metrics around superboring (tvl, volume, revenue, user metrics). It would benefit your proposal to also align these details with the value add created for the Arbitrum ecosystem. I also noticed you have SuperFluid in your name, an introduction to yourself and explanation of the relationship between SuperBoring, SuperFluid and yourself would be beneficial as well.
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Snapshot Vote.
Rationale
As we previously stated in the case of Sky, a simpler and more streamlined process must be established to support builders seeking to migrate or bridge their tokens into the Arbitrum ecosystem.
The current frictions are evident. In this thread, @Jose_StableLab clearly pointed out that builders need more support and a simplified process. This would not only benefit builders, but also delegates, who currently must vote on every single token that seeks to be added to the official bridge.
I'm not sure that this would degrade the UX of bridging to and from Arbitrum At the moment, there are many tokens in various chains that are not bridged through the main chain bridge. Judging by the statistics on the number of tokens that were transferred to Arbitrum, the majority are
of which only WETH is in the official bridge, which means that the majority use third-party bridges. Therefore, I believe that the UX will not suffer from this.
We support registering $BORING in the custom gateway but question the need for a full constitutional vote. The change is a routine mapping of L1 and L2 addresses but triggers the DAO’s heaviest process. For non-custom ERC-20s this step is permissionless, and requiring an AIP here creates avoidable governance fatigue and risks failure through low quorum. A more efficient path would be something like:
This keeps security and transparency intact while freeing delegates to focus on matters that genuinely need broad deliberation. We will vote FOR if the proposal proceeds, but urge us to amend our procedures so future custom-gateway listings can be approved swiftly under a lightweight, defined rubric.
Example 1: RARI Example 2: USDS and sUSDS (Sky tokens)
Just a small correction that the USDS and sUSDS proposal only passed offchain snapshot vote, not an onchain constitutional vote, as it can be seen here.
The only one that passed an onchain constitutional vote was the RARI one, as can be seen here.
Below are the opinions of the UADP:
The following points are more relevant to the DAO as opposed to the Superboring team.
From what I can recall, this is the third instance of a proposal like this being proposed. The last two examples passed successfully through the Snapshot phase.
Example 1: RARI — passed both onchain and Snapshot Example 2: USDS and sUSDS (Sky tokens) — passed Snapshot
The Generic Custom Gateway Router is owned by the Arbitrum DAO, and only the DAO can approve new custom gateway registrations through a constitutional AIP. This involves calling setGateways on the Router, which maps the L1 token to its custom L2 contract, ensuring a canonical address to avoid multiple L2 representations of the same token, which would probably confuse users and developers.
Many “random” tokens are bridgeable without a governance vote because they use the permissionless standard ERC-20 gateway, which supports basic ERC-20 functionality without needing DAO approval. But projects like Sky and RARI require governance because they use the Generic Custom Gateway for tokens with non-standard features (including governance, interest accrual, etc.), which involves modifying the DAO-controlled Router.
In our opinion, the process behind these proposals has been unnecessarily arduous. Delegates ideally shouldn't be tasked with facilitating such proposals through the governance process, especially considering that this is a constitutional AIP. We are having enough trouble hitting quorum onchain, and with a proposal like this, delegates are tasked with overhead that can otherwise be mitigated. There should be an effort to integrate a more seamless operational mechanism for these initiatives. We do understand that proposals like this are classified as constitutional AIPs because they modify core protocol components, namely the bridge. So, to prevent trust issues around core changes from being altered too drastically, we propose a more streamlined process for instituting these proposals:
We are also curious to hear alternative means by which operations can be made more seamless.
Hello @didi welcome to the forum. I have deep respect for builders entering the ecosystem and expanding their product. I see this post has sat without response for quite a while. That said, I don't want the initial lack of engagement to discourage you from building here, and I believe that improvements can be made such that you get the amount of response you'd like, and the community can benefit from your contributions as a member. That said, I wanted to see if I may be able to help you better integrate into the community.
My initial proposal feedback is that the current proposal instance is rather sparse, and that is likely why it hasn't garnered much attention. As a delegate myself, I can imagine that the others would like to see a more robust piece of content. You note that $BORING is a token, but don't deeply explain what the product is. In addition to a product summary, I'd be curious to see metrics around superboring (tvl, volume, revenue, user metrics). It would benefit your proposal to also align these details with the value add created for the Arbitrum ecosystem. I also noticed you have SuperFluid in your name, an introduction to yourself and explanation of the relationship between SuperBoring, SuperFluid and yourself would be beneficial as well.
For reference, to the scope and typical structure of successful proposals, feel free to check out a couple I personally find well created:
My suggestions to you as you enter the community: I would strongly suggest attending the calls and getting to know both the ecosystem and delegates. Once you're a bit more familiar it would also benefit you to share your product and ideas on one of these calls.
-- Community Calendar: https://calendar.google.com/calendar/u/0?cid=Y180MTU3OTg1ZDI0NTJkZmQ4YTkxYjZhMzZiY2NhYjM3ZGViOWJmZmU5MDUzYTRiOWJjYzRlOWZmZjllZjAyOTI0QGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Snapshot Vote.
Rationale
As we previously stated in the case of Sky, a simpler and more streamlined process must be established to support builders seeking to migrate or bridge their tokens into the Arbitrum ecosystem.
The current frictions are evident. In this thread, @Jose_StableLab clearly pointed out that builders need more support and a simplified process. This would not only benefit builders, but also delegates, who currently must vote on every single token that seeks to be added to the official bridge.
I'm not sure that this would degrade the UX of bridging to and from Arbitrum At the moment, there are many tokens in various chains that are not bridged through the main chain bridge. Judging by the statistics on the number of tokens that were transferred to Arbitrum, the majority are
of which only WETH is in the official bridge, which means that the majority use third-party bridges. Therefore, I believe that the UX will not suffer from this.
We support registering $BORING in the custom gateway but question the need for a full constitutional vote. The change is a routine mapping of L1 and L2 addresses but triggers the DAO’s heaviest process. For non-custom ERC-20s this step is permissionless, and requiring an AIP here creates avoidable governance fatigue and risks failure through low quorum. A more efficient path would be something like:
This keeps security and transparency intact while freeing delegates to focus on matters that genuinely need broad deliberation. We will vote FOR if the proposal proceeds, but urge us to amend our procedures so future custom-gateway listings can be approved swiftly under a lightweight, defined rubric.
Example 1: RARI Example 2: USDS and sUSDS (Sky tokens)
Just a small correction that the USDS and sUSDS proposal only passed offchain snapshot vote, not an onchain constitutional vote, as it can be seen here.
The only one that passed an onchain constitutional vote was the RARI one, as can be seen here.
Below are the opinions of the UADP:
The following points are more relevant to the DAO as opposed to the Superboring team.
From what I can recall, this is the third instance of a proposal like this being proposed. The last two examples passed successfully through the Snapshot phase.
Example 1: RARI — passed both onchain and Snapshot Example 2: USDS and sUSDS (Sky tokens) — passed Snapshot
The Generic Custom Gateway Router is owned by the Arbitrum DAO, and only the DAO can approve new custom gateway registrations through a constitutional AIP. This involves calling setGateways on the Router, which maps the L1 token to its custom L2 contract, ensuring a canonical address to avoid multiple L2 representations of the same token, which would probably confuse users and developers.
Many “random” tokens are bridgeable without a governance vote because they use the permissionless standard ERC-20 gateway, which supports basic ERC-20 functionality without needing DAO approval. But projects like Sky and RARI require governance because they use the Generic Custom Gateway for tokens with non-standard features (including governance, interest accrual, etc.), which involves modifying the DAO-controlled Router.
In our opinion, the process behind these proposals has been unnecessarily arduous. Delegates ideally shouldn't be tasked with facilitating such proposals through the governance process, especially considering that this is a constitutional AIP. We are having enough trouble hitting quorum onchain, and with a proposal like this, delegates are tasked with overhead that can otherwise be mitigated. There should be an effort to integrate a more seamless operational mechanism for these initiatives. We do understand that proposals like this are classified as constitutional AIPs because they modify core protocol components, namely the bridge. So, to prevent trust issues around core changes from being altered too drastically, we propose a more streamlined process for instituting these proposals:
We are also curious to hear alternative means by which operations can be made more seamless.
Hello @didi welcome to the forum. I have deep respect for builders entering the ecosystem and expanding their product. I see this post has sat without response for quite a while. That said, I don't want the initial lack of engagement to discourage you from building here, and I believe that improvements can be made such that you get the amount of response you'd like, and the community can benefit from your contributions as a member. That said, I wanted to see if I may be able to help you better integrate into the community.
My initial proposal feedback is that the current proposal instance is rather sparse, and that is likely why it hasn't garnered much attention. As a delegate myself, I can imagine that the others would like to see a more robust piece of content. You note that $BORING is a token, but don't deeply explain what the product is. In addition to a product summary, I'd be curious to see metrics around superboring (tvl, volume, revenue, user metrics). It would benefit your proposal to also align these details with the value add created for the Arbitrum ecosystem. I also noticed you have SuperFluid in your name, an introduction to yourself and explanation of the relationship between SuperBoring, SuperFluid and yourself would be beneficial as well.
For reference, to the scope and typical structure of successful proposals, feel free to check out a couple I personally find well created:
My suggestions to you as you enter the community: I would strongly suggest attending the calls and getting to know both the ecosystem and delegates. Once you're a bit more familiar it would also benefit you to share your product and ideas on one of these calls.
-- Community Calendar: https://calendar.google.com/calendar/u/0?cid=Y180MTU3OTg1ZDI0NTJkZmQ4YTkxYjZhMzZiY2NhYjM3ZGViOWJmZmU5MDUzYTRiOWJjYzRlOWZmZjllZjAyOTI0QGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20