Over the last week, many of you have shared honest feedback, raised concerns, and asked important questions about Qubetics, especially around the Certik audit delay for chain abstraction, dVPN experience, and RPC performance. This report is meant to walk you through everything clearly and transparently, what caused the issues, what has been improved, and what you can expect next.
CertiK Audit Delay & Chain Abstraction — What Really Happened
Let’s address the key question first: why did the CertiK audit and the Chain Abstraction launch take longer than expected?
The delay came from new findings identified by CertiK during the audit process. These findings required changes in our core architecture. As a result, the Chain Abstraction mainnet launch was pushed back. This was not a setback in direction—it was a necessary step to strengthen the system at its foundation.
In the earlier architecture, transactions were executed without epoch alignment. Users also needed to run a dedicated node to add BTC liquidity. Based on CertiK’s security concerns, and our own commitment to making the system more robust and user-friendly, we introduced key architectural upgrades. In the current architecture, we have implemented epoch-based transactions and batched transaction processing. Users can now add liquidity without running a node. These changes improve consistency, reduce friction, and align the system with long-term scalability goals.
CertiK also raised a set of pointers of security concerns. The Qubetics team has already addressed these with clear and structured improvements:
We are strengthening DKG integrity by enforcing authenticated identity binding on all inbound messages. Each message will now be cryptographically linked to its transport source. We are adding strict round validation so that stale or mismatched messages are rejected. Storage keys are now scoped by round to avoid cross-round conflicts. Shares will only be marked as received after full identity and commitment checks are complete.
For DKG parameter consensus, we are introducing a pre-DKG handshake phase. This ensures that all nodes agree on a single configuration before execution begins. The DKG schedule message will include a signed configuration block so every node can verify the same parameters. Any mismatch will now result in a hard abort instead of a warning.
In the transaction pipeline, we are making error handling explicit. If calldata encoding fails, the transaction will not proceed. Each failure will include clear context, such as function name, inputs, and request ID. We are also adding unit tests to ensure that encoding failures always stop transaction creation.
For signing round coordination, we are moving toward a globally unique round assignment model. Instead of relying on incremental counters, we are exploring deterministic round IDs derived from request data. This removes the risk of collision without needing a central coordinator. We are also isolating aggregation states so that signatures from different requests cannot mix.
All of these changes are already implemented in our latest updates and shared with CertiK. The system is stable, aligned, and moving forward as planned. At this stage, Qubetics is on track and ready from an engineering standpoint. We are now in the final phase of the audit cycle. The next step is for CertiK to complete its review and provide the final security clearance. Once we receive that go-ahead, Qubetics will proceed with the Chain Abstraction launch.
Qubetics is not delayed in direction. It is refined, secured, and prepared for launch.
dVPN Issues — What Users Faced & What We’ve Done
Over the last week, we received a small number of queries from users related to dVPN. It’s important to note that most users continue to use dVPN without any issues. The system is stable and working as expected across the majority of the network.
A few users reported cases where the VPN connected but did not work as expected. In some instances, apps like YouTube or Instagram did not load. A few users also saw unexpected locations in their plans, while others experienced inconsistent connections across certain regions, with some reports coming from iOS devices.
We want to acknowledge these cases clearly. The issues were real, and user feedback helped us identify the exact areas that needed attention. These inputs allowed us to trace patterns and improve how we handle such scenarios.
dVPN works differently from traditional VPN services. It runs on a decentralized network of node providers rather than fixed servers. Because of this, performance can vary depending on the node a user connects to. In a few cases, some nodes were not fully optimized, or there were configuration mismatches. This led to limited functionality or unstable connections for a small set of users. Most nodes, however, continue to perform well, which is why the majority of users did not face any disruption.
Some users also reported that they were unable to view the list of service providers. We want to clarify that no new feature changes were made in this area. The issue was linked to incomplete wallet connection within the Qubetics app. To resolve this, users need to log out of their account, re-enter the correct mnemonic phrase, and then access the dVPN section again. This step restores proper connection and resolves the issue. This solution has already been shared with affected users, and it has worked as expected. The issue occurred only in cases where the access steps were not followed correctly.
For users who are still facing any problems, we encourage them to report the issue so we can assist directly. When reporting, please include your Node ID, plan details, VPN provider name, and a short screen recording if possible. This helps us review the exact case and provide a precise resolution without delays.
Improving dVPN performance remains a key focus. We continue to work closely with both users and node providers to maintain stability and ensure a reliable experience across the network.
RPC Issues — What Went Wrong & How It’s Fixed
We observed a few cases where users experienced slow RPC responses, connection drops, and some instability while interacting with the network. These instances helped us review the system closely. At the same time, most users continued to use the network without major issues, and overall functionality remained intact. The root cause was linked to how traffic was being handled. Earlier, a single public RPC endpoint was responsible for all types of activity across the ecosystem. This included general user interactions, dVPN traffic, and node-level communication. As usage increased, this shared setup placed pressure on one layer, which led to inconsistent performance in certain cases.
To address this, Qubetics took a direct architectural decision to restructure the RPC layer. We introduced a dedicated RPC specifically for dVPN traffic and separated it from the main public RPC used by the rest of the ecosystem. This was a proactive step taken by the Qubetics team to improve performance, not a reactive change based on user demand. This separation ensures better load distribution, faster response times, and improved stability. In simple terms, instead of one shared path handling all requests, the network now operates with separate paths for different workloads. This reduces congestion and creates a more reliable experience across the system.
For retail users, the public RPC remains the best option. It is managed and optimized by the Qubetics team and is designed to support smooth and simple interaction with the network. For businesses, infrastructure providers, and advanced users, we recommend running a dedicated RPC. This approach removes dependency on shared infrastructure and provides full control over performance, uptime, and request handling. It is the right setup for applications, integrations, and any use case where consistency and speed are critical.
Users who want to set up their own RPC can follow the steps in the official GitBook. This allows them to operate on their own infrastructure with a fully optimized connection to the network. With this update, Qubetics has strengthened its RPC architecture. The public layer continues to serve the broader community, while dedicated RPC setups give businesses the control and performance they require.
Final Thoughts — Where Qubetics Stands Today
Over the past week, the focus has gone beyond fixing isolated issues. The Qubetics team has strengthened the system at its core, with each change aimed at improving stability, usability, and long-term scalability. This work reflects a clear and deliberate approach to building a platform that performs well under real conditions.
Today, the architecture is more refined and easier to use. Both new and existing users can interact with the platform with greater clarity and consistency. The audit is now in its final stage, with all key improvements already implemented and shared. In parallel, dVPN is being stabilized using real user feedback, and RPC performance has improved through clear infrastructure separation and better load handling.
Qubetics is moving forward with control and direction. The recent challenges have been addressed with structured solutions, and the system is now in a stronger position than before. Every decision taken during this phase has focused on reliability, system integrity, and user experience. The goal has not been speed alone, but to ensure the network performs consistently and can be trusted at scale.
With this progress in place, Qubetics is on track for its next major milestone. The Chain Abstraction launch will follow once the audit is formally completed. The foundation is ready, the system is stable, and the path ahead is clear.