May 2025 - Update

We wanted to start this update by sharing an important step forward that could help us finally get past some of the long-standing issues we’ve been battling. We also adjusted our monthly updates for easier readability; with emojis, horizontal lines, etc.

One good thing that came from the increased tariffs and pressure within the Chinese tech sector is that we’ve finally been able to re-engage directly with the same PCBA factory that the original Chinese team had outsourced to build our board, and this time without the interference of the Chinese team we no longer work with.

This shift in communication has already paid off. Among the many problems we had with the original PCBA and chips, one of the biggest was that the factory had selected a large but very closed chip manufacturer to be used in our main PCBA. Because of that decision, getting the required firmware files directly from the manufacturer became nearly impossible. Even after reaching out to multiple other PCBA factories for help, none of them were able to provide the necessary files or support we needed to move forward.

Thankfully, after nearly 10 months of effort and slowly patching the relationship with the original PCBA factory, we were finally able to obtain a clean, original version of the firmware, untouched by the Chinese development team. This is gold!!! And something we’ve been trying to get for a very long time.

So, in case that’s unclear, the firmware files we had been working with were not clean. They were a version that had been altered by the PCBA factory, and as we pointed out 10 months ago, the firmware we received included over 1 million files. It has been nearly impossible to know exactly what the PCBA factory changed. Our Ukrainian team now believes this could be one of the core reasons we’ve struggled to fix the OTA system.

The good news: having this clean firmware gives us a much stronger technical foundation. It removes layers of instability that were built on top of rushed decisions and shortcuts we didn’t even know had been made. It also gives us a clearer path for debugging and stabilizing everything. Hopefully, this will be the step that finally allows us to complete the OTA system and get our software running without any lingering bugs.

The bad news: our Ukrainian team estimates it will take at least 2 months to rebuild our entire system on top of this clean firmware. That timeline does not include fixing the OTA itself, but they’re confident that once the migration is complete, the OTA will start working properly. So we’re cautiously optimistic and very grateful to have finally gotten what we needed to move forward.

Something that came to light recently is that the Chinese team we originally hired knowingly ignored multiple warnings from the outsourced PCBA factory. That factory told them that the critical chips in our PCBA were already marked as EOL (End of Life), meaning they would soon become obsolete and unavailable. We're not entirely sure why the PCBA factory continued using those chips if they knew they were EOL. Maybe they were just trying to shift blame so we would give them more business. We'll never know.

What we do know is that instead of switching the chips to newer and more reliable options, the Chinese team dismissed the warning completely and kept moving forward with the flawed design. This is exactly why we ran into supply chain issues for those chips. And now, because of that decision, once we run out of our current chip stock, we’re going to have to redesign the PCBA for future safes.

The most frustrating part is that we actually asked them multiple times, years ago, why they chose those specific chips and whether we should use something else. They told us everything would be fine. That turned out to be false.

This mistake has already cost us over a year of delays and tens of thousands of dollars in extra engineering hours, sourcing efforts, and rework. It’s the kind of setback that could have been avoided entirely if we had been given straight answers from the beginning, or if the Chinese team we hired had done their job properly. We want to acknowledge and apologize for selecting that team. When our project first started years ago, the company we hired had worked with major names like Huawei, Alibaba, Honeywell, Haier, BMW, Panasonic, HP, and Nespresso. That gave us confidence. But while the company may have had those clients on paper, it is clear now that the people assigned to our project were not the same caliber as the ones those big brands worked with. Even though we paid a premium expecting top-level engineers and expertise, we were duped.

🔒 Tamper Sensitivity and Lockdown Sync

Last month we mentioned that tamper-triggered lockdown was complete. It turned out that while we thought it was done, after deeper testing we found several issues that made the feature unreliable.

What we expected to be a quick final check ended up taking a little over two weeks. The biggest problem was that changes made from the mobile app were not consistently syncing with the safe, and vice versa. Sometimes the setting appeared to update, but it was not actually being applied in the system. Other times the safe would reflect one value, while the app showed another. It created confusion and risk of mismatch during use.

To resolve this, we ran dozens of tests across multiple firmware versions. Each test cycle required us to rebuild the firmware, flash it to the device, configure settings, and validate results. This process takes hours each time. This wasn’t something we could fix with a simple code tweak or hot patch. It required full system testing and coordination across the app, API, and Safe OS.

The good news: the sync issues have been resolved. The system now pushes and verifies tamper sensitivity updates properly in both directions, from app to safe, and from safe to app. The selected sensitivity level is stored correctly, instantly reflects on both ends, and holds steady across reboots.

📸 Camera Issues and Switching Stability

After our last update, as we continued running more tests, we discovered that something we had changed for cameras ended up having an unexpected effect on another part of the camera system that wasn’t obvious at first. When switching cameras or closing the live stream from the mobile app, it was actually turning off the camera system on the safe entirely. This wasn’t just a temporary glitch. The cameras would fully turn off and would never turn back on, even after restarting the safe. That meant no future streaming or recording was possible unless the user manually stepped in to turn on the camera physically on the safe's settings screen, which would have to be done every single time.

This was not an issue before our last update. Once we found the cause, we had to rewrite how the system manages camera state and behavior. Now, no matter how many times a user switches cameras or exits the stream, the camera does not turn off unless manually turned off by a user on the safe under camera settings. 🎉

Unfortunately though, once we fixed that, we noticed there was another issue with the camera switching itself.

Switching between the interior and exterior cameras would sometimes freeze the stream or cut it off entirely. The reason it wasn’t caught earlier is because it only showed up in specific edge cases, like when a user rapidly switched back and forth between the camera feeds. Under those conditions, the stream would occasionally stop displaying, even though the system thought it was still active.

Fixing this required repeated firmware rebuilds, flashing, and testing after each change. Since camera behavior is deeply integrated into the system, each test cycle took hours to complete. After many rounds of debugging, we traced the problem to how the system was handling internal cleanup and reinitialization during switching. In some cases, the process responsible for starting the camera wasn’t fully resetting, which caused the stream to freeze. We reworked how the system starts, stops, and verifies each camera handoff to make sure it performs as expected.

This issue took a little over three weeks to fully resolve.

The good news: the camera system is now about 90 percent stable.

The reason we say 90 percent is because there is still one known edge case. When switching back and forth between cameras very quickly, the stream may occasionally not display. This happens rarely, likely in less than 5 percent of switch attempts under rapid interaction. When it does happen, exiting the stream and reopening it resolves the issue.

Since this is not critical to safe performance, and because the cameras are fully working almost every single time, we’ve chosen not to dedicate any more resources to the camera right now. We’ll revisit it once other priority items are completed and once we bring on some outside capital.

🛠️ Hardware Testing App Improvements

In one of our previous updates, we shared that we were building an internal tool to help test and verify each safe before it ships. Since then, we’ve made major upgrades to the tool’s accuracy, reporting, and depth. It now automatically detects subtle edge cases, logs structured test results, and sends reports directly to our backend portal for better QA documentation. These changes also help us speed up factory testing and improve consistency.

Even though this app was originally designed as a factory-only tool, the backend integration now lays the foundation for future remote diagnostics that could support customers more effectively after launch.

👆🏻 Fingerprint Sensor Fixes and Optimization

This was by far our most important and impactful fix of the month.

The original fingerprint SDK had been developed by a Chinese team in 2023. As we dug deeper into its behavior over the past few weeks, we discovered it was extremely inefficient. The SDK, which stands for Software Development Kit, is what allows the hardware (like the fingerprint sensor) to communicate with the safe’s operating system. Another poor job by the Chinese team. This SDK had actually been outsourced by them, which we knew at the time and gave approval for, but the problems turned out to be worse than expected. While still workable, the SDK had many issues.

One of the most obvious signs was the heat. When you touched the fingerprint sensor, it would often feel super warm, even while idle in its ready-to-scan state. We had brought this issue up several times to the outsourced Chinese SDK developers, but they always assured us it was normal and claimed the system just used a lot of power, which is why the sensor was getting hot. We never believed that explanation, but we weren’t SDK coders ourselves, which is why we had hired them to build it in the first place. So we had to take their word for it. Touching the fingerprint sensor would feel unusually hot, something that is extremely rare around fingerprint sensors and a clear sign that something deeper was wrong.

Another issue was that once the fingerprint sensor was activated, whether a user scanned or not, it would sometimes stay on indefinitely. For example, if a user tapped their profile and successfully logged in using their fingerprint, the sensor light would turn green to show it was accepted, but then return to blue and stay on, even after the safe had already been unlocked. This means that even when the operating system explicitly told the sensor to stop listening, it ignored the command and continued drawing power.

One of the biggest problems we faced was that many times after the safe was kept on for a little while, the fingerprint sensor wouldn’t turn on at all. Even though the system was booted and running, the fingerprint module simply wouldn’t respond. This also tied into the other issue, and the main reason we had to revisit the fingerprint SDK. The only fix was to reboot the safe. This was a huge issue, especially for users with 2FA enabled, because they wouldn’t be able to log in without a working fingerprint. To help during that time, we added a manual “reboot” button inside the user interface as a temporary workaround. That issue has now been fully resolved through our interrupt signal and power state fixes. The reboot button is no longer needed for fingerprint recovery, but it turned out to be a useful tool overall, so we're keeping it.

Beyond the SDK problems, we also found low-level firmware issues that originated from how the PCBA handled communication with the fingerprint sensor. The interrupt signal that’s supposed to wake the system when a finger is detected was misbehaving. In some cases, it would flip states or reverse timing entirely during memory searches, which led to random detection failures during enrollment. This wasn’t something visible on the surface, but it was one of the main reasons fingerprint scans were unreliable for so long. In simpler terms, the sensor and the safe weren’t speaking the same language when it came to detecting fingerprints, and that caused all kinds of unpredictable behavior.

We’ve now fixed this behavior completely. We re-routed the sensor’s interrupt signal correctly to the system, stabilized the communication with how the OS communicates with the sensor, and ensured the SDK no longer leaves the sensor running when it shouldn’t be. This has eliminated the power drain and overheating issues. It also means that fingerprint login now works much faster. Previously, it would take 3 to 5 seconds to scan and process a fingerprint. Now, it’s nearly instant. Our firmware team corrected the interrupt handling so finger presence is now properly recognized and stable. On the system side, we ensured that the fingerprint module now fully respects OS commands and properly powers down after use.

Some big wins came out of this:

The sensor no longer generates heat at all.
The sensor now draws significantly less power than before.
Fingerprint enrollment and scanning is dramatically faster. What used to take up to 5 seconds now completes in around 1 second. Previously, enrolling a fingerprint could take around 30 seconds and felt slow and unresponsive. The delay between each required scan made the process frustrating for users. Scanning is great now.
The fingerprint system is fully operational, responsive, and as of now, functioning as expected across all of our testing.

This was one of the biggest wins of the month. It took nearly 4 weeks to complete, but it resolved multiple issues we had been chasing for months. We’re confident in its performance moving forward. After a lot of in-depth work across both firmware and the system layer, we’re finally seeing consistent performance across all conditions. Fingerprint recognition is fast, responsive, and stable. We’re confident that this system is finalized as far as current testing shows. The end result is a reliable, fast, and safe fingerprint experience. We’re confident it’s ready for customers.

This month only had good news! 🎉

Anything else we should be aware of? Yes, at this stage, we believe the earliest we will see a mass production run will be around September/October. We are still actively seeking outside investment to sell part of the company, which would help support mass production and offset some of the losses we’ve absorbed throughout development.

We kindly request your cooperation in refraining from sending emails requesting delivery dates and any negative messages, as we no longer plan to respond to those individual inquiries. Rest assured, we're actively working to expedite the process and will provide updates as soon as they become available. Your understanding and patience during this time is greatly appreciated.

Sorry for the delay. Thank you for your unwavering support, your understanding and patience during this time are greatly appreciated.

TLDR - SUMMARY

We finally got a clean firmware version from our original PCBA factory after 10 months of effort. This is a huge win and likely the key to finishing the OTA system. Rebuilding on top of it will take at least 2 months.
The original Chinese team ignored warnings about using EOL (end-of-life) chips, which is why we’ve had supply chain issues and will eventually need to redesign our PCBA again in the near future. This mistake cost us over a year in delays and tens of thousands of dollars.
Tamper sensitivity sync is now fully fixed. App and safe now stay perfectly in sync, with settings holding correctly across reboots.
We believe camera is now MVP ready. Camera issues are almost complete. A critical bug was found and resolved where cameras would turn off permanently. One minor issue remains in rare rapid switching, but the system is stable enough to move forward.
Factory testing app got smarter. It now logs results to our backend and is laying the groundwork for future remote diagnostics and customer support.
We rewrote parts of the firmware and SDK to stop randomly disabling fingerprint sensor, overheating, eliminate power issues, and dramatically speed up enrollment and scanning. Fingerprint system is fully fixed and finalized.
Mass production is not projected before September/October.

Next update will be sent around (not before, and possibly after): July 8, 2025.
Thanks for your support!