[CONSTITUTIONAL] Register $BORING in the Arbitrum generic-custom gateway

Proposals
1

Abstract

https://superboring.xyz is about to expand to Arbitrum, thus the $BORING token shall become bridgeable to Arbitrum.

Motivation

$BORING is used to incentivize markets and can thus help drive adoption both to the Superboring protocol and the underlying chain.

Rationale

Arbitrum wants to help scale Ethereum. Allowing tokens to be bridged back and forth is key to this.

Specifications

$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 .

Steps to Implement

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.

Timeline

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.

Overall Cost

We assume the process of token registration to be well known and thus incur no or negligible cost for the DAO.

2 Likes
2

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:

  1. [Non-Constitutional] Invest in Builders & Ignite ARB Demand with q/acc
  2. DeFi Renaissance Incentive Program (DRIP)

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

4 Likes
3

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?

3 Likes
4

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.

5

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.

6

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)

7

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:

    1. Projects submit their custom gateway and L2 token contracts to OCL for a technical review to confirm compatibility with the Generic Custom Gateway Router, bridge security standards, etc. Community feedback on Sky’s proposal emphasized that delegates preferred that OCL was consulted as opposed to consulting the whole DAO, with most delegates having minimal to no key feedback on the proposal.
    1. Projects must attain an audit (like RARI was reviewed by OpenZeppelin and Sky by ChainSecurity) for their custom gateway and L2 token contracts, verifying security and compliance with Arbitrum’s bridge standards.
    1. After pre-validation by OCL and auditors, the project team can post a proposal with the stated stamps of approval so that delegates have an easier time conducting a review.

We are also curious to hear alternative means by which operations can be made more seamless.

4 Likes
8

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.

9

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.

1 Like
10

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.

3 Likes
11

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.

2 Likes
12

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.

1 Like
13

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

  • USDC,
  • USDT0,
  • WETH
  • WBTC,

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.

14

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.

2 Likes
15

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.

1 Like