WakeUp Labs - Update Thread: Front-end Interface to Force Transaction Inclusion During Sequencer Downtime

TL;DR

The goal of this thread is to keep you updated on the front-end interface project for Arbitrum that we at WakeUp Labs are developing.

Lately, we proposed creating an interface that allows users to push transactions through even when the Arbitrum sequencer is offline. After posting our proposal on Tally, we were chosen to develop it with support from the Arbitrum community for WakeUp Labs to take on this project.

What’s the project about?

This project aims to strengthen the Arbitrum ecosystem by developing an interface that allows users to submit transactions directly to Layer 1 (L1) even if the Arbitrum sequencer, responsible for handling transaction submissions, experiences downtime or issues. The main objective is to address the risk of dependency on a single point of failure presented by the sequencer.

The proposal focuses on decentralization and empowering users through an open-source approach, enabling other teams to deploy their own versions of the interface. This initiative not only enhances the network’s resilience but also provides users with greater control and confidence in the Arbitrum ecosystem. By enabling direct transaction submission to L1, users can bypass potential issues with the sequencer or any attempts at censorship, thereby ensuring uninterrupted transaction capabilities. This approach also upholds Arbitrum’s trustless security model, reinforcing the integrity of its Rollup technology even during operational challenges.

Arbitrum’s Forum

Last February, we submitted a proposal to the Arbitrum Foundation Forum. It garnered considerable attention, with numerous exchanges and suggestions from community members that helped us improve our proposal with their feedback. This was done to assess the sentiment related to our proposal and to enhance it based on community feedback.

You can check the full proposal here :point_down:

We’ve also held an open call to discuss and share all the insights of our proposal to Arbitrum in a meeting :point_down:

Later on, we conducted a successful snapshot sentiment check that you can check here.

With over 99M votes in favor and less than 1% against.

The Tally formal proposal

To move forward, we posted our proposal on the Tally platform. After giving Arbitrum members time to vote on its value to the community, we were selected to develop the interface.

Development Roadmap

Technical Research, POC, Documentation and Testing

We’ll take a deep dive into the Delayed Inbox functionality and its integration, as well as create a proof of concept (PoC). The WakeUp Team’s research will be made public, with a summary shared in an X (Twitter) thread and a detailed article posted in the OSS GitHub repository once it’s completed. This document will also outline the necessary security measures for the development process.

Endpoint Development

Creation of endpoints to interact with the backend logic.

Logic Integration and Testing

Connecting the frontend to the endpoints and verifying the operational logic, and test heavily the MVP.

Design Phase

Additional time allocated for the design process, ensuring a user-friendly experience.

UI Development

We’ll craft an aesthetic and intuitive user interface inspired by existing high-quality designs. To enhance user security, we’ll add a banner at the top of the website to verify the URL and guard against phishing sites.

Enhancing Documentation Clarity and Usability

We will finalize and clearly document the open-source codebase. As mentioned above, any team should be able to run their own instance of the service, so it’s crucial that everything is clearly explained. We’ll also include a list of URLs for instances set up by others that we have verified as correctly implemented.

Service & Maintenance after Launch

We are committed to hosting the site on either Vercel or AWS, ensuring continuous operation 24/7 for a minimum of 24 months. Once we achieve a stable version that has been thoroughly tested, we will also deploy an instance on IPFS to offer a fully decentralized option. While this may not be the most performant choice initially, it will be available for at least these 2 years, with plans to extend indefinitely after evaluating its performance.
At WakeUp Labs we will initially refine the website based on user and Arbitrum community feedback, conducting ongoing testing to maintain reliability. Any issues such as downtime or crashes will be promptly addressed by our team for at least the next two years.

Estimated Timeframe

Approximately 4.5 months for full implementation, including design phases, followed by 3 months dedicated to post-launch iterations. We will then commit to hosting, monitoring, and addressing any possible errors for 24 months after launch.

Conclusions.

Developing a front-end interface to facilitate force-including transactions during Sequencer downtime is a crucial initiative within the Arbitrum ecosystem. This proposal aims to empower users by ensuring they can execute transactions even when the Sequencer is unavailable. This effort aligns closely with Arbitrum’s objectives of decentralization and bolstering user autonomy.

To ensure the solution is effective during critical scenarios, it’s essential that other projects can independently deploy their own instances of this service. This is why the project is conceived as open-source from inception, and we are committed to actively supporting teams interested in adopting it.

What’s Next?

As we embark on the first phase — Technical Research, POC, Documentation, and Testing — we will keep you updated with all the progress!

Also, you can check out our general communications thread on this forum to learn more about us and what we’re building on Arbitrum!

4 Likes

Sequencer Misbehavior Avoider [Update]

TL;DR

In this entry, we share some details, updates and recommendations based on the first steps that are being done regarding the development of the Front-end interface to force transaction inclusion during sequencer malfunction.

*Please note that the name used in the presentation, and henceforth to refer to the issue, is different from our original proposal in the ARB forum. This is a minor detail, but we believe it better aligns with what it actually does.

Developing an user-friendly app

We’ve identified two main issues. First, non-technical users can’t transact on Arbitrum when the sequencer isn’t working correctly, which leads to delays and disrupts their activities and access to funds. Second, users have limited visibility of solutions during sequencer problems, like downtimes. There are no alerts on the main page, docs page, status page, or any other relevant sites.

How are we going to address this?

We think creating an easy-to-use app that allows seamless asset withdrawals from Arbitrum to Ethereum, regardless of sequencer downtime or issues, will help solve the main problem we’ve identified.

Before we begin high-fidelity designs, we are sharing wireframes of the ideal use-case scenario to gather feedback from the community.

If you’d like to check out the prototype we’re building, feel free to message us on social media or reply to this thread.

We focus only on withdrawals

From the feedback we gathered at EthCC Brussels, a few key points stood out:

  1. Withdrawals are simple and essential transactions with a lower risk of failure.
  2. Complex transactions, like swaps or adding and withdrawing liquidity from pools, are more likely to fail because of price fluctuations and changing parameters.
  3. Transactions such as swaps and adding or withdrawing liquidity from pools are more susceptible to failure and can be exploited for MEV.
  4. Withdrawals stay practical and reliable even during sequencer downtime or censorship.

This approach guarantees a stable, secure, and user-friendly transaction experience.

Where can you find information about the sequencer status?

Additionally, there’s a secondary issue: users have limited visibility of solutions during sequencer problems, such as downtimes. No alerts are displayed on the main page, documentation page, status page, or other relevant websites.


When it comes to Arbitrum’s main page and the Arbitrum’s Status main page, users currently need to proactively search for documentation. We believe improving user visibility on the main site is key, including adding messages or alerts to enhance usability and reduce user anxiety.

Other steps, like searching through Arbitrum’s documentation, can be challenging since the tutorial is highly technical and the “more information” link is broken. Adding a link to our simple force transaction solution in this section and fixing the broken link could help users.

Users can receive notification updates informing them that the sequencer is not available, including solutions and documentation links in these downtime messages.

Additionally, the sequencer downtime solution might be visible on other websites currently used by Arbitrum’s community. Including this feature there could also improve the user experience.

Next Steps


Our next steps involve developing and rigorously testing to ensure a well-developed product. We’ll be setting up the main components and creating high-fidelity designs. Additionally, we’ll continue to refine design use cases, including worst-case scenarios, and actively gather feedback from the community.

Spotting Opportunities for Future Ideas (Draft)

3 Likes

Sequencer Misbehavior Avoider [Update from the ARB open call on 7-31-24]

TL;DR

We’re pleased to share a segment from the Arbitrum call on July 31, 2024, where @Gonzacolo discusses the progress on developing the front-end interface to avoid Sequencer Misbehavior. We’ve also included the Figma design and a link to the presentation used during the call.

Here, you can find the presentation used:
https://bit.ly/ARB_Presentation

Also, we are including the prototype:
https://bit.ly/ARB_Prototype

Conclusion

If you have any questions about the prototype or the development process, feel free to reach out to us here or on our social media channels.

Twitter

https://x.com/wakeuplabs

Linkedin

https://www.linkedin.com/company/wakeuplabs

Research, Doc and Testing: Web App for Bypassing the Arbitrum Sequencer and Facilitating Cross-Chain Withdrawals

TL;DR

In this entry, we share details on the Research, Doc and Testing for the web app that enables users to withdraw funds from the Arbitrum network (Layer 2) to Ethereum (Layer 1) without relying on the Arbitrum sequencer. This app bypasses the sequencer, enhancing decentralization and usability for non-technical users. Next steps involve refining the UI, extensive testing, and deploying the app to mainnets. Security measures include secure communication, minimal data storage, and robust code practices. Additionally, we’ve contributed improvements to the Arbitrum SDK for better transaction signing.

Achievements So Far

UI Model:

  • Milestone 1: Technical Research, POC, Documentation and Testing Completed.
  • Developed a user-friendly interface that allows users to initiate and monitor these specialized withdrawals.
  • The UI provides clear instructions and feedback, ensuring users understand each step of this unique withdrawal process.

PoC Development:

  • Successfully demonstrated the core functionality of performing uncommon withdrawals from Arbitrum to Ethereum while bypassing the sequencer.
  • Implemented interaction with smart contracts to handle these specialized fund transfers between L2 and L1 without relying on the sequencer.
    The proof of concept has been successfully completed. You can now check out the open-source repository, and in the next few weeks, we’ll be launching the final version of the Dapp on the testnet.

Open source-repository:

You can find more details about the PoC here:

We’re looking forward to your feedback!

Implementation Details

System Overview

We developed a system that leverages Arbitrum’s design to bypass the sequencer. Utilizing the Arbitrum SDK, we directly place user transactions into the delayed inbox on Layer 1 (L1). Once a transaction is submitted, we must wait for the sequencer’s required 24-hour window to gracefully include the transaction. If the sequencer fails to do so within this timeframe, we use the SDK to force the inclusion of the transaction.

Mechanism Explanation

This approach aligns with the mechanism envisioned by the Arbitrum team, which you can read more about here:

Our contribution focuses on enhancing the user experience, making the process accessible to non-technical users by removing the technical complexities associated with these operations.

Development and Testing

All development and testing have been conducted on test chains. In these environments, the time from transaction inclusion to withdrawal is approximately 30 minutes. However, this duration may be longer on the mainnet.

By simplifying the user interaction and automating complex backend processes, our system aims to provide a seamless and intuitive experience for users, particularly for those who may not have a technical background.

Next Steps for Completing the Web App Development

To transition from a PoC to a fully functional web app, the following steps need to be undertaken:

1. Refine the User Interface

  • Enhance User Experience (UX): Continuously improve the UI based on user feedback and usability testing.
  • Add Detailed Transaction Information: Provide users with detailed information about their transactions, including status updates and historical data.

2. Testing and Quality Assurance

  • Comprehensive Testing: Conduct extensive testing, including integration tests, and end-to-end tests, to ensure the web app functions correctly.
  • Beta Testing: Release a beta version of the app to a select group of users for real-world testing and feedback.

3. Documentation

  • Develop User Documentation: Create detailed documentation and tutorials to help users understand how to use the web app.

4. Deploy and Monitor

  • Deploy Productive Environment: Once testing is complete and the app is stable, we’ll either deploy it to a production environment or set up the current environment to work smoothly with both the testnet and mainnet.
  • Monitor Performance and Security: Continuously monitor the app’s performance and security, addressing any issues that arise promptly.

By following these steps, we aim to transition our PoC into a robust and reliable web app, providing users with a secure and efficient way to withdraw funds from the Arbitrum network to the Ethereum network.

Arbitrum SDK

We have been utilizing the Arbitrum SDK for our development needs. However, during our integration process, we encountered a limitation: the SDK supports only signing transactions but doesn’t inherently provide functionality for both signing and sending them. This is a key feature for wallets like MetaMask, which require the ability to both sign and send transactions, rather than just signing alone. To address this gap, we contributed to the SDK by submitting a pull request that introduces the capability to sign and send transactions altogether. This enhancement ensures that the SDK can fully support our requirements, enabling us to securely and efficiently manage transaction signing within our application.

Also, we have encountered some issues with the InboxTools class in the SDK, which is essential for our workflow. Specifically, the methods getForceIncludableEvent and signChildTx have not been functioning as expected. We are actively working to contribute fixes to address these issues and improve the reliability of the SDK.

Conclusion

In summary, our research, documentation, and testing efforts have laid a solid foundation for a web app that effectively bypasses the Arbitrum sequencer and facilitates cross-chain withdrawals between Arbitrum and Ethereum. The achievements to date, including the development of a user-friendly UI and a successful proof of concept, demonstrate the viability of our approach.

With the next steps focused on refining the user interface, conducting thorough testing, and deploying the app to mainnets, we are committed to ensuring a seamless and intuitive experience for all users. Our contributions to the Arbitrum SDK further enhance the capabilities of our application by improving transaction signing functionality and addressing existing issues.

We are excited to move forward with these plans and look forward to delivering a robust, reliable, and user-friendly solution. Your feedback will be invaluable in finalizing the app.

Stay tuned for the upcoming testnet launch and further updates on our progress!

2 Likes

Closer to Mainnet: WakeUp Front-End Interface for Forcing Transaction Inclusions has been deployed on Testnet!

TL;DR

The WakeUp Front-End Interface has been deployed on Tesnet.

Today, we’re excited to announce that we have deployed the WakeUp Front-End interface on the testnet, and we’ll be moving it to the mainnet soon. After wrapping up the technical research, PoC, documentation, and testing, we took a deep dive into the Delayed Inbox functionality and its integration.

On top of that, we developed the necessary backend endpoints, connected the front end, and made sure everything was working smoothly. We’ve done extensive testing on the MVP to ensure everything is solid.

We also dedicated time to design, making sure the user experience is as seamless as possible. For the UI, we created a clean, intuitive interface inspired by innovative designs.

Take a look at the demo here!

And if you want to try it yourself, head over here :point_down:
https://staging-transaction-enforcer.wakeuplabs.link/

We’d love to hear your feedback! Feel free to share your comments and suggestions with us.

Next

We’re working on getting this on Mainnet soon! We’re also focused on improving the clarity and usability of our documentation.

Keep an eye out for the upcoming Mainnet launch and stay tuned for more updates on our progress!

3 Likes

Milestone #6 Completed: Documentation Improved for Clarity and Usability

TLDR;

we’ve completed Milestone #6 of the WakeUp Front-End Interface for Forcing Transaction Inclusions development. This milestone focused on updating our documentation to make it clearer and more user-friendly for everyone.

Explore the improved Documentation

We’ve updated our documentation to improve clarity and usability, and you can check it out on our GitHub repository :point_down:

The documentation provides a comprehensive guide for understanding and using the WakeUp Front-End Interface for Forcing Transaction Inclusions.

Test the Interface

We invite you to try out the interface currently deployed on the Arbitrum Sepolia testnet. Your feedback is invaluable as we continue refining and improving the experience.

You can try it here :point_down:
https://staging-transaction-enforcer.wakeuplabs.link/

If you need funds to get started, feel free to use one of the Sepolia faucets, such as this one :point_down:

How to Provide Feedback

If you encounter any issues or have suggestions, please don’t hesitate to share them here or reach out through this form.

Your input will help us improve the interface even further!

Next.

We’re almost ready to launch on Mainnet! Once we’ve gathered the final feedback, we’ll move forward with the deployment. We believe this development plays a key role in further decentralizing Arbitrum.

Stay tuned for our Mainnet launch—it’s coming soon!

3 Likes

Running on mainnet!

TL;DR:

We have deployed Arbitrum Connect: the front-end interface on mainnet, designed to empower users to enforce transaction inclusion during sequencer downtime.

WakeUp Labs is excited to announce Arbitrum Connect a significant milestone in our collaboration with Arbitrum! The front-end interface designed to enforce transaction inclusion is now live on mainnet.

This marks a pivotal step toward enhancing network reliability and transparency.

This development introduces a front-end interface, now live on mainnet, designed to empower users to force transaction inclusion during sequencer downtime, reinforcing trust and accessibility in decentralized systems.

Explore the live version on mainnet here! :point_right: https://arbitrumconnect.wakeuplabs.io/

We’re eager to see this update in action and invite you to explore its features in the Arbitrum mainnet environment!

3 Likes