Non-Constitutional Abstract - Create another express-lane for arbitrum One execution that works with stablecoins approved by the DAO or a DAO council, which is optimized for specifically stablecoin transfers through:
a separate mempool for simple transfer transactions for most stablecoins on Arbitrum
fixed gas price that is lower than avg on mainnet arbitrum
Overview
I propose StableLane, a dedicated Arbitrum-native blockspace optimized specifically for high-volume, low-cost stablecoin payments. StableLane would provide predictable fees, reduced congestion, and potentially faster confirmation for payment flows—positioning Arbitrum as the leading L2 for stablecoin utility.
Motivation
Stablecoins are the dominant on-chain asset class, yet most L2s treat payment traffic the same as any other transaction type. Competing ecosystems are increasingly optimized for stablecoin throughput. Arbitrum needs a purpose-built payment lane to stay competitive, attract payment processors, and support mainstream merchant/payment use cases like Peanut and Yodl that are already live on Arbitrum today. A specialized lane can deliver significantly cheaper, more stable fees while offloading payment traffic from the main chain, while freeing up resources in the main lane.
Implementation
StableLane could be deployed as A virtualized lane within Arbitrum One using sequencer-level routing for stablecoin transactions.
Key features:
Limited opcode surface → lower state load & cheaper execution
Highly optimized mempool/ordering for micro-payments, may be more attractive to emerging uses of stablecoins like x402
Shared settlement & bridging with Arbitrum One, finality on Arbitrum One mainnet.
Optional fee-subsidy from the DAO treasury
Next Steps
Gather community feedback on the StableLane design and constraints.
Evaluate technical tradeoffs and financial tradeoffs.
Engage payment processors, wallets, and stablecoin issuers for demand validation.
If supported, commission a technical spec + cost model through Arbitrum DAO working groups or ask OCL for help.
Open to feedback, improvements, and alternative designs.
I agree that this is a good idea and it’s a good direction.
But why not 0 gas costs, or as close to 0 as possible?
I think we should be even more aggressive. Arbitrum needs to compete with Coinbase, Base, and USDC who practically offer gas free USDC transactions. so I think we should aim to have free stablecoin transactions on Arbitrum, by subsidizing them with the gas from all other transactions, especially now that we doubled the minimum L2 gas fee AIP: Raise the gas target, min L2 base fee, & implement improvements to the pricing algorithm
i think this would reduce sequencer revenue by a bit, but all other advantages, especially in attracting new liquidity and apps, would be huge.
Very clever idea. I suspect this would generate significant interest in adoption from Orbit chains, which should be considered as well (I could see us implementing it on ApeChain for example).
I’m interested in the criteria for eligibility for stablecoins and do have some minor concerns around the potential negative externality of creating a moat for newer or emerging stablecoins that may not be incorporated off the bat.
I agree that subsidized or near-zero fees can be a strong short-term lever to accelerate adoption and compete with other L2s.
At the same time, competing on value rather than price feels more sustainable over the long run. The longer-term opportunity might be to use StableLane not only to move stablecoins cheaply, but to add an optional layer of legitimacy and trust at execution time.
If stablecoin payments become a dedicated fast-lane for commerce, the same transaction could optionally write a minimal, privacy-preserving proof of authenticity and ownership transfer alongside the payment. This would be particularly valuable for real-world commerce, secondary markets, warranties, and anti-counterfeit use cases.
Importantly, this does not conflict with decentralization or privacy. Supporting privacy-by-default while offering optional tools to verify authenticity and ownership can help address piracy and fraud without imposing KYC or centralized control.
Curious whether others see StableLane evolving beyond price competition into a foundation for legitimacy-aware, on-chain commerce on Arbitrum.
I imagine one of the big feature requests for this will be the ability to pay the fees using the payment-stables (instead of native ETH) since this would bring the UX to parity with competing chains. I think the most feasible way to achieve this would be to launch with some Meta-Tx/Relayer infra in place (the alternative would be to allow fees to be paid “natively” in a stable-currency, but adding in an additional fee-currency to Arbitrum One seems to me to raise a lot of weird and troubling technical questions).
I’m not sure “fixed gas price” is necessary here, as opposed to simply having a very high (i.e., much higher than the main-lane Arb One) gas limit. This is functionally a “fixed gas price” (the minimum) for the common case, it just means you still get an economical congestion mechanism as when the limit is reached.
I think it’s also worth considering the alternative of launching a Stable-coin Payment L3 on Arbitrum One as a DAO-governed chain, as this seems to achieve many of the same goals (cheap stable-payments in the Arb ecosystem, offload payment traffic from Arb One, attract projects/liquidity to Arb One) without the technical complexity — i.e, it’s technically feasible today (note that this also allows for native stable payments (at least in one stable)).
(Nitpick / maybe it’s just me, but: I think “similar to Timeboost” isn’t quite the right way to frame this. Reading the title, I was expecting something less ambitious — Timeboost is really just about how tx ordering is handled on a granular, sub-1-second level. “Dedicated Blockspace” or something like that captures it better IMO.)
Thank you for the time and effort you’ve put into this proposal.
Offchain Labs is actively evaluating a couple of approaches to increase throughput for payment-oriented transaction patterns, including using payments-specific execution paths. This work is still in the research phase and is separate from any of our previous public proposals.
Once we have a formal specification that we feel confident addresses both scalability and security considerations, we will share it with the community and look forward to engaging in further public discussion about the details.
We appreciate you sharing this idea and helping to start a constructive conversation with the community.
