# Tally: Front-end interface to force transaction inclusion during sequencer downtime **URL:** \ **Category:** Finalized AIPs\ **Created:** [February 14, 2024, 4:36pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247 "2024-02-14T16:36:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [February 14, 2024, 4:36pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/1 "2024-02-14T16:36:20Z")
## **[Non-Constitutional AIP] Front-end interface to force transaction inclusion during sequencer downtime** ### **Abstract** [WakeUp Labs](http://www.wakeuplabs.io) proposal outlines the development of a simple but effective front-end interface that enables users to force-include transactions directly on L1 when the Arbitrum Sequencer is down, aiming to increase trust among end-users navigating the Arbitrum ecosystem. Inspired by a few community discussions ([Link 1](https://x.com/Cattin0x/status/1735779772054077917?s=20) & [Link 2](https://x.com/fede_intern/status/1754226077981893052?s=20)) , and validated historical events like: [Sequencer Downtime 1](https://offchain.medium.com/todays-arbitrum-sequencer-downtime-what-happened-6382a3066fbc), [Sequener Downtime 2](https://dedaub.com/blog/arbitrum-sequencer-outage), [Historical Sequencer Status](https://status.arbitrum.io/history/3) and [L2BEAT status](https://l2beat.com/scaling/risk). This tool aims to empower users with the ability to bypass the Sequencer in situations where it is unavailable or censoring transactions, thus aligning with Arbitrum’s vision for progressive decentralization. WakeUp Labs has a proven track record of expertise in crafting blockchain tools and infrastructure. Their contributions extend to collaborating on [open-source projects for major DAOs](https://x.com/0xMilton/status/1755972182553899487?s=20), enhancing Ethereum Foundation-funded initiatives, building complex DeFi protocols, SmartContracts and offering a [developer platform](http://www.platform.wakeuplabs.io) that facilitates robust and scalable API calls for smart contract deployment without requiring Solidity programming skills. (Currently operating even on the Arbitrum blockchain). ### **Introduction** The Arbitrum Sequencer is a critical component of the network, responsible for submitting users’ transactions to L1. Under the current system, the Sequencer is a potential single point of failure; if compromised, it could delay or prevent the processing of transactions. There are ways to bypass it, but non-developer users lack that capability. This proposal seeks to mitigate such risks by providing a user-friendly alternative transaction submission pathway, thereby enhancing the network’s resilience, user autonomy, and their confidence in the Arbitrum ecosystem. For the service to be truly useful in the event of catastrophic occurrences, empowering more teams to deploy their own instances is crucial. Thus, to boost the project’s reliability and significantly enhance its value to the Arbitrum DAO, it is essential to embrace an OpenSource approach from the beginning. ### **Rationale** - **Decentralization and user empowerment:** By enabling direct L1 transaction submissions, users can circumvent Sequencer outages or censorship, maintaining their ability to transact without interruption. This capability is crucial for ensuring the network’s operational integrity and aligns with the principle of progressive decentralization. - **Enhancing trustless security:** The proposed interface would serve as a valuable tool in rare situations where the Sequencer fails to perform its duties. It ensures that the Arbitrum Rollup maintains its trustless security model, even when permissioned components of the system are not functioning correctly. ### **WakeUp Labs core team** - **[Milton Berman](https://www.linkedin.com/in/miltonberman/)**, co-founder and CEO, brings extensive experience as a CTO in a decentralized identity project supported by IDB Lab and Bitcoin NGO. He has also worked as a Product Owner at Rootstock blockchain and as a CTO in a mobile game studio company. - **[Maximiliano del Hoyo](https://www.linkedin.com/in/maximiliandh/)**, co-founder and CBDO, has a diverse background in software and finance. His previous experience at notable companies like Microsoft and Nestle provides him with the necessary knowledge and network to navigate the intersection of technology and business. - **[Gonzalo Silman](https://www.linkedin.com/in/gonzalo-silman/)**, co-founder and COO, possesses a unique blend of expertise in economics (former university professor), finance, and entrepreneurial experience in creating gaming products for LATAM communities. ### **Proposal Details** ### Technical Implementation 1. **OpenSource from Day One** : Given that the project should be 100% trustless, as clearly outlined in its ‘Rationale’ above, we believe that the entire project, including both the Back-End and Front-End, should be OpenSource from the beginning. One of our goals is for this service to be run from different instances and by different providers; therefore, it will be a top priority to ensure that this repository is well-documented and our support is readily available so that any team or community project can implement it. 2. **Transaction Monitoring:** Develop functionality to listen for user transactions on L2 that are not included by the Sequencer, with guidance from the Arbitrum SDK documentation. 3. **Manual Transaction Hash Input:** In cases where automatic detection is not feasible, provide a user interface for manually entering the transaction hash or implement manually the previous transaction in the new solution. 4. **L1 Transaction Replication:** Implement mechanisms to replicate the intended L2 transaction on L1, using “Forced Withdrawal” type transactions to push the L2 transaction from L1. 5. **Confirmation Display:** Ensure the interface provides feedback once the transaction has successfully been processed. 6. **Processing Time Consideration:** Account for the approximately 24-hour processing period to prevent errors or transaction duplication across chains. 7. **Hosting, Service & Maintenance:** WakeUp will host the service, ensuring it runs 24/7, even on IPFS. For the first three months, we will fine-tune and iterate the service. Additionally, should any problems occur, the WakeUp team is committed to identifying and resolving these issues for a minimum of the next two years. ### Development Roadmap & Budget Allocation: 1. **Technical Research, POC, Documentation and Testing (4 weeks, $ARB 9000):** Deep dive into the Delayed Inbox functionality and its integration, along with creating a PoC and validating the necessity of a new internal tool for transaction monitoring and sequencer status. We will also carefully check that our solution doesn’t disrupt the proper functioning of Arbitrum; if it does, we will enable this instance only when the official sequencer is not operating correctly. This research conducted by the WakeUp Team will be made public, and the community will be able to view it, both in a summary Twitter Thread and in an Article shared on the OSS Github repository once completed. This document will also consider the security measures that must be taken into account when carrying out the development. 2. **Endpoint Development (1.5 weeks, $ARB 3500):** Creation of endpoints to interact with the backend logic. 3. **Logic Integration and Testing (2.5 weeks, $ARB 3500):** Connecting the frontend to the endpoints and verifying the operational logic, and test heavily the MVP. 4. **Design Phase (4 weeks, $ARB 5000):** Additional time allocated for the design process, ensuring a user-friendly experience. 5. **UI Development (3 weeks, $ARB 5500):** Crafting an aesthetic and intuitive user interface inspired by existing high-quality designs. To enhance user security, we will add a banner at the top of the website to ensure the URL is correct and guard against phishing sites. 6. **Enhancing Documentation Clarity and Usability (3 weeks, $ARB 6000):** Finalizing and clearly documenting the open-source codebase. As detailed above, any team should be able to run their own instance of the service, so it’s crucial that everything is sufficiently clear. There, we will also add a list of URLs for instances set up by others that we can confirm are correctly implemented. 7. **Service & Maintenance after Launch (24 months, $ARB 10000).** We commit to hosting the site on Vercel or AWS, ensuring 24/7 operation for at least 24 months. Once a stable version has been achieved and properly tested, an instance will also be running on IPFS to ensure a 100% decentralized option. While this may not be the most performant option, it will be available for at least these 2 years. After evaluating its performance, we will attempt to provide it indefinitely. Initially, the WakeUp team will refine the website based on feedback from users and the Arbitrum community and will conduct continuous testing to ensure its reliability. Any issues, such as downtime or crashes, will be promptly addressed by the WakeUp team for at least the next two years. ### **Budget, Resources and Payment Schedule** - **Estimated Timeframe:** Approximately 4.5 months for full implementation, including design phases; followed by 3 months dedicated to post-launch iterations and 24 months of hosting, monitoring, and bug fixing to address any possible error. - **Development Team:** One full-time senior Solidity developer for the core implementation and research, in coordination with the entire WakeUp Labs engineering team, plus additional design and developer resources for the UI/UX phase. The proposal also includes a Senior Developer working part-time for post-launch maintenance. Gonzalo or Milton from the core team will also keep track of the project as PO. - **Payment Schedule & Terms:** - **Total Cost:** 42.500 $ARB ### **Conclusion** ### Developing a front-end interface to enable force-including transactions during Sequencer downtime is a crucial requirement in the Arbitrum ecosystem. This proposal aims to empower users by ensuring transaction capabilities even when the Sequencer is unavailable. By doing so, it aligns with Arbitrum’s goals of decentralization and enhancing user autonomy. For the solution to be truly useful in critical cases, we must ensure that other projects can run their own instances of this service. This is why the project is conceived as OpenSource from the very beginning, and the WakeUp Labs team will actively assist teams wanting to implement it. Furthermore, WakeUp will be responsible for maintaining the service operational and implementing minor improvements for a minimum of 2 years. #### Notes: Some changes have been made throughout the proposal; you can see the details here: > [@Tally: Front-end interface to force transaction inclusion during sequencer downtime](https://forum.arbitrum.foundation/t/proposal-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/46): > > Considering today is April 1st, and taking into account that we have been publicly working on the proposal since at least mid-February, engaging in discussions with community members in person at EthDenver, through L2 Beat’s office hours, and in Arbitrum’s public debates, I am convinced we are prepared to move forward with the final steps. The proposal will transition to its definitive version. Alongside changing the title, the notes will be removed and listed below this point to maintain a hi… ---
**Author:** ![cp0x](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/cp0x/32/5455_2.png) [@cp0x](https://forum.arbitrum.foundation/u/cp0x)\ **Post date:** [February 15, 2024, 12:04am UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/2 "2024-02-15T00:04:16Z")
Hi, As far as I understand ([The Sequencer and Censorship Resistance | Arbitrum Docs](https://docs.arbitrum.io/sequencer)), even if the sequencer is not working, it sends data: > Currently, on Arbitrum One, this delay time between submission and force inclusion is roughly 24 hours, as specified by `maxTimeVariation.delayBlocks` / `maxTimeVariation.delaySeconds` . A force inclusion from L1 would directly affect the state for any unconfirmed L2 transactions; keeping conservatively high delay value ensures it should only be used under extraordinary circumstances ---
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [February 16, 2024, 2:26pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/3 "2024-02-16T14:26:43Z")
Hi @cp0x , you’re right about the data transmission during Sequencer downtime. Arbitrum offers mechanisms for transaction inclusion, but, as you mentioned, they require a 24-hour delay and may cause transaction reordering. Additionally, these mechanisms are intended for technical users. Our proposal acknowledges these first two issues without altering them. Instead, we aim to develop a user interface that demystifies and simplifies access to these mechanisms. This interface will make the forced inclusion process more straightforward and understandable, enhancing Arbitrum’s usability during critical times and strengthening user trust. ---
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [February 16, 2024, 2:27pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/4 "2024-02-16T14:27:27Z")
On the other hand, if there’s a concern that this could disrupt the proper functioning of Arbitrum, we could enable it only in instances where the official sequencer is not operating correctly. ---
**Author:** ![cp0x](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/cp0x/32/5455_2.png) [@cp0x](https://forum.arbitrum.foundation/u/cp0x)\ **Post date:** [February 16, 2024, 3:33pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/5 "2024-02-16T15:33:29Z")
I also think another suggestion should be taken into account: [https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xbecc45a6beb55a708e25195f34db2f5ff757e0da5ff55171ca731b39428e27c3](https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xbecc45a6beb55a708e25195f34db2f5ff757e0da5ff55171ca731b39428e27c3) It introduces a “batch poster manager” role with the ability to grant/revoke batch-posting affordance. ---
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [February 19, 2024, 1:48pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/6 "2024-02-19T13:48:09Z")
From what I understand, those changes have been approved. The first one, regarding the poster manager, is already in the “Develop” branch, while the other is pending to be merged into “Main”. Thanks for sharing this with us. We should keep these changes in mind, but I believe in our case, it’s all about sending from L1 to L2, regardless of the role in the Sequencer or the MaxTime Variation. All these technical questions will be resolved when our Tech Lead starts the in-depth technical research necessary for the implementation. It would be interesting that once Milestone 1 is completed, we could also deliver a clear and consciously crafted document about the technical research conducted. I think this would contribute to the community, and we could release it in the format of an Article + Twitter Thread to ensure its documentation and attach it to the OSS GitHub once finished. ---
**Author:** ![maxlomu](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/maxlomu/32/1282_2.png) [@maxlomu](https://forum.arbitrum.foundation/u/maxlomu)\ **Post date:** [February 29, 2024, 12:38am UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/7 "2024-02-29T00:38:01Z")
Hey @Gonzacolo, thanks for posting this. I find the idea of creating a user-friendly tool to bypass the sequencer and force include transactions very valuable for decentralization, similar to what Superchain offers with [https://superbridge.app](https://superbridge.app/). The costs seem reasonable to me as well. I am interested in understanding how can we make sure that the tool is available in the future. - What happens after the initial 3 months of support? - Will the UI remain functional? Could you elaborate on the long-term options available for the DAO to ensure the tool remains operational and supported ---
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [February 29, 2024, 11:04pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/8 "2024-02-29T23:04:09Z")
> [@maxlomu](#): > > [https://superbridge.app](https://superbridge.app) @maxlomu, Indeed, SuperBridge was my point of reference. The entire project will be open source, including both front-end and back-end components. With this approach, anyone can offer a similar service if there’s a need. When crafting the proposal, I envisioned the first three months of support as a period for iterating on the project based on feedback received. But you are right; I hadn’t considered the need for long-term website operation. We could turn the last milestone into: **Website Hosting & Maintenance after Launch (24 months, $ARB 10000).** - We commit to hosting the site on Vercel or AWS, ensuring it runs 24/7 for at least 24 months. - During the initial 3 months, the WakeUp team will use feedback from users and the Arbitrum community to refine and iterate the website, continuing to test the system and guaranteeing its functionality for the future. - Should any issues arise, such as the website going down, crashes, or other malfunctions, the WakeUp team will address and resolve these issues for at least the next two years. ---
**Author:** ![Frisson](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/frisson/32/2288_2.png) [@Frisson](https://forum.arbitrum.foundation/u/Frisson)\ **Post date:** [March 4, 2024, 11:38pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/9 "2024-03-04T23:38:29Z")
I think creating a user friendly interface to force transaction inclusion during sequencer downtime is an important initiative that we should fund as a DAO. I’m in favor of this proposal. The only gap I see here is that, as far as I can tell, WakeUP Labs is new to the DAO. I would normally like to see a service provider having executed on something successfully for the DAO before being funded for an end-to-end initiative like this. With that said, the cost is relatively low and I’m probably willing to take the leap. Would love to see any examples of relevant past work to help de-risk. ---
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [March 5, 2024, 10:59pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/10 "2024-03-05T22:59:12Z")
We have engaged with the Arbitrum Stack at least, on two separate occasions, though we have not publicly disclosed these projects within the DAO: 1. Arbitrum has been integrated into our Developer Platform [Dev Environment], enabling users to deploy Smart Contracts effortlessly thanks to our APIs. 2. We created a certificate collection for attendees of the “Eth Argentina” conference, but it was never launched due to organizational reasons. [Here](https://arbiscan.io/address/0xC3f46cC1e942C32B661726aeb0D32e26bD23D5c0) you can see our Arbitrum owner wallet, and the final SC: - [NFT collection](https://arbiscan.io/address/0xd49a1174d316a8fd6748af0d1027eb27d8f0ae5e) | [Opensea](https://opensea.io/collection/certificado-de-asistencia-ethereum-argentina-2023) On the other hand, we’ve been actively collaborating with our clients to provide high-tech solutions. Our projects have included the tokenization of soccer players, the development of APIs for indexing blockchain data, and even an AAVE fork. Indeed, this project marks our first initiative in creating something specifically designed for Arbitrum. However, we’re enthusiastic about the opportunity to establish a mutually beneficial partnership. We enjoy a strong reputation within the Argentine community, and last week in Denver, I had the opportunity to meet personally with several members of the Arbitrum DAO and foundation. I hope this can help to alleviate any concerns you may have. We’re looking forward to your response and to discussing the next steps. ---
**Author:** ![Frisson](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/frisson/32/2288_2.png) [@Frisson](https://forum.arbitrum.foundation/u/Frisson)\ **Post date:** [March 8, 2024, 12:12am UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/11 "2024-03-08T00:12:24Z")
Thanks for sharing examples of past work and connection with the DAO! ---
**Author:** ![dzack23](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/dzack23/32/746_2.png) [@dzack23](https://forum.arbitrum.foundation/u/dzack23)\ **Post date:** [March 9, 2024, 3:31pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/12 "2024-03-09T15:31:02Z")
The “Batch Poster Manager” upgrade has already been approved as part of the [ArbOS 20 upgrade](https://www.tally.xyz/gov/arbitrum/proposal/46905320292877192134536823079608810426433248493109520384601548724615383601450?chart=bubble) (it’s scheduled to go live next week). The Batch Poster Manager is unrelated to what’s being proposed here; the Batch Poster Manager makes it easier for the Sequencer to rotate out its address for a new one; this doesn’t help if the Sequencer is offline or censoring. The core contracts already have a censorship resistant “force inclusion” path that doesn’t rely on the Sequencer at all; this proposal is about developing a user interface to make this functionality more accessible to users. ---
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [March 11, 2024, 6:37pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/13 "2024-03-11T18:37:22Z")
### 03/11/2024 - Notes: Some changes have been made in this proposal, thanks to the feedback provided by @cp0x, @maxlomu and @frisson. ---
**Author:** ![imatomster](https://avatars.discourse-cdn.com/v4/letter/i/f05b48/32.png) [@imatomster](https://forum.arbitrum.foundation/u/imatomster)\ **Post date:** [March 13, 2024, 4:28pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/14 "2024-03-13T16:28:15Z")
Hey! Recently led a team from UC Berkeley at Blockchain at Berkeley to build out a front-end interface to allow transaction submission and inclusion on Arbitrum One from Ethereum! You can check out the deployed app here: [Arbitrum Bypasser](https://arbitrum-bypasser.vercel.app/) Arbitrum shouted it out here: [Arbitrum Tweet](https://x.com/arbitrum/status/1765642536985805241?s=20) Just a prototype though, we used `sendL2Message` and `signL2Message` to presign a message and send it to a bridge for it to be received by the Delayed Inbox. ---
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [March 13, 2024, 6:08pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/15 "2024-03-13T18:08:13Z")
Hey @imatomster, it’s indeed an amazing prototype! I just read the full explanation and saw the website! Congratulations! My idea is to build a platform that fully aligns with the Arbitrum style and branding, and later incorporate the link to the solution here: > **[The Sequencer and Censorship Resistance | Arbitrum Docs](https://docs.arbitrum.io/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job)** > > The Sequencer is a specially designated Arbitrum full node which, under normal conditions, is responsible for submitting users’ transactions onto L1. In principle, a chain’s Sequencer can take different forms; as Arbitrum One currently stands, the... Of course, the website should also include an explanation of how it works. This idea is all about providing certainty and security to end-users. I just followed you on Twitter and sent you a message. If the proposal advances, it would be fantastic to have you on board to receive your feedback and share your experience. It would also be great to take a look at what you have built; our developers would be excited to collaborate. Having people who have already been involved in similar projects and who understand the motivation behind it, while leaving the entire project open-source and working with a super user-friendly interface, will undoubtedly lead it to success. ---
**Author:** ![juanbug](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/juanbug/32/11891_2.png) [@juanbug](https://forum.arbitrum.foundation/u/juanbug)\ **Post date:** [March 13, 2024, 9:10pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/16 "2024-03-13T21:10:32Z")
Chiming in here on behalf of the UADP: We think that overall, this is a smart and proper thing to do. The sequencer and network will likely inevitably experience downtime in the future. When this happens, there needs to be some “insurance” in place from a front end perspective to decrease pandemonium and this does exactly that. Additionally, the team has good experience and the cost is very appropriate. Consequently, we see little to no downside in this. ---
**Author:** ![JoJo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/jojo/32/2666_2.png) [@JoJo](https://forum.arbitrum.foundation/u/JoJo)\ **Post date:** [March 14, 2024, 9:05am UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/17 "2024-03-14T09:05:31Z")
> [@Gonzacolo](#): > > direct L1 transaction submissions This, provided in a way that is user friendly, is a good value add. In time of peril (aka: when everything pumps or dumps) nothing work usually, so alternative routes are needed. Voting for on this proposal. ---
**Author:** ![cp0x](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/cp0x/32/5455_2.png) [@cp0x](https://forum.arbitrum.foundation/u/cp0x)\ **Post date:** [March 14, 2024, 2:24pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/18 "2024-03-14T14:24:59Z")
Just to clarify, this development does not affect the Arbitrum code in any way - is this only front-end development for the convenience of users? ---
**Author:** ![dk3](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/dk3/32/4808_2.png) [@dk3](https://forum.arbitrum.foundation/u/dk3)\ **Post date:** [March 14, 2024, 4:27pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/19 "2024-03-14T16:27:14Z")
For something as critical as this in a SHTF scenario, I have mixed feelings about a third party hosting the front end. I am also not sure how a pinned IPFS site would function under heavy load. Wonder if there are other ways of implementing this in a scaleable and trustless manner. ---
**Author:** ![Gonzacolo](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/gonzacolo/32/6503_2.png) [@Gonzacolo](https://forum.arbitrum.foundation/u/Gonzacolo)\ **Post date:** [March 14, 2024, 4:40pm UTC](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/20 "2024-03-14T16:40:29Z")
Hi @cp0x, As previously stated by other participants in the discussion, the development will not affect the existing functionality of Arbitrum. In fact, we plan to use the tools and SDKs provided by Offchain Labs to efficiently execute the proposal. We intend to work with this repository: > > > //github.com/OffchainLabs/arbitrum-tutorials/tree/master/packages/delayedInbox-l2msg While this solution is currently available to developers, it remains inaccessible to end-users. Our proposal aims to bridge this gap, making the functionality available to them. Furthermore, as detailed in the proposal, the document for the first milestone will comprehensively cover all aspects of the technical implementation before we proceed. [Next page](https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247.md?page=2)