Hey — thank you for raising this. Rahul here, CEO of Safe Labs.
First, I want to acknowledge the concern directly: recurring availability issues are not acceptable for a product that people and teams rely on to manage critical assets. Reliability is not a secondary product concern for Safe. It is part of the trust layer we are expected to provide.
This is also a very active topic inside Safe Labs.
On your DevOps / infrastructure question: yes, we have dedicated infrastructure ownership, and we have doubled our Infra team over the last year. That said, the real answer is not just about team size. Some of the challenges we are dealing with are quite bespoke to Safe because of the way the product has historically been built: open, broadly accessible, multi-network, and usable without authentication.
A few things are worth unpacking.
Safe Platform and Safe Wallet have, over the years, been free, open, and largely unrestricted to access. That openness has been important to the ecosystem, but it also created an increasingly difficult infrastructure surface. We see significant traffic from bots, scrapers, automated clients, and abusive patterns hitting unauthenticated endpoints. With the recent AI-driven increase in automated traffic across the internet, these patterns have only intensified. This creates real load on the infrastructure and also drives up infrastructure costs.
We have already made meaningful progress on this at the API layer by moving more traffic to authenticated endpoints, introducing rate limits, and adding stronger controls. That helped.
The Safe Wallet web experience is more complex. We have added several protections, including measures such as CAPTCHA, but every mitigation has tradeoffs. A non-trivial portion of Safe users use VPNs, privacy-preserving setups, or more customized environments. Privacy is a use case we care about deeply, so we have to be careful that defending against abusive traffic does not accidentally degrade the experience for legitimate users.
At the same time, more teams are relying on Safe to manage sensitive operational and offchain data. That means we also need a more robust authentication layer for Safe Wallet itself — not only for product functionality and confidentiality, but also as part of a stronger defense against abusive or DDoS-like traffic patterns. This is something we are actively working on, with a focus on making the transition as seamless as possible for users.
Another important reliability challenge is Safe’s multi-network nature. Safe supports many chains, which means the product depends on many RPC providers and network-specific services. Even short blips from RPC providers can have direct downstream effects on the end-user experience. We already have fallback and failover systems in place, but we are investing further here as well — including migration work around eRPC and evaluating Envio as a parallel / fallback indexing system to improve long-term resilience.
More broadly, when we set up Safe Labs in October 2025, one of the core reasons was to bring reliability, security, and operational maturity across Safe’s products to a much higher standard. We knew this would be a significant undertaking, especially given how many users and organizations rely on Safe for mission-critical operations. One of the biggest learnings is that the margin for error is extremely narrow. Even short degradation windows can meaningfully affect user trust.
Two of our larger goals for the year are to bring the platform to 99.9% uptime reliability and to reach SOC 2 readiness. We are making strong progress on both, but there is still work ahead.
A lot of infrastructure work is invisible when it goes well, and very visible when it does not. So I appreciate the opportunity to discuss this publicly. We are not ignoring these issues. The team is taking them seriously, and we are making long-term investments in the reliability, security, and scalability of the Safe product experience.
We also need to keep improving how we communicate during incidents and degraded service windows. Users should not have to guess whether an issue is local, RPC-related, Safe-related, or something else. That is part of the operational maturity we need to keep building.
Thanks again for raising this. The criticism is fair, and the expectation is the right one: Safe needs to meet a very high reliability bar.
