← Back to Blog

Wallet Security: A Retrospective

Published: July 2026 | Category: Cybersecurity & DevOps

Status: the wallet these defences were built for, CloudVoid, is decommissioned. This is kept as a retrospective on the hardening work rather than a page for a live product.

CloudVoid at cloudvoid.online — the onboarding flow that is still served, kept as an archive.

In modern financial and wallet applications, server security cannot rely on traditional perimeter defenses alone. Today's hackers frequently target user vulnerabilities and exploit internal entry points. To truly protect financial systems, we must assume that breaches could happen and engineer resilient, self-healing architectures that neutralize threats instantly.

While architecting the backend for CloudVoid — a non-custodial multi-chain wallet I have since retired — I implemented a custom, highly hardened Linux security protocol. Here is a breakdown of that defense-in-depth approach, and which parts I still use today.

1. The Edge: Cloudflare Bot Mitigation

The first line of defense is Cloudflare. By routing all traffic through Cloudflare, we enforce strict firewall rules to instantly block malicious IPs, mitigate DDoS attacks, and severely limit bot traffic. This ensures that the only traffic reaching the origin server is legitimate user activity or authenticated application API calls.

2. Server Hardening & Access Control

A secure server should be virtually invisible to the open internet. Our Oracle Cloud backend server is hardened so that:

Even if an attacker discovers the server IP, the lack of open vectors forces them to target the development team directly.

3. Intrusion Response: Automated PM2 Lockdown

What happens if a developer's machine is compromised? We built an automated intrusion response system directly into the backend using Linux inotifywait and PM2 event listeners.

If the system detects unauthorized file movement, unusual data egress (such as an attempt to download user databases or export codebase files), or code tampering, it instantly triggers an Automated Lockdown.

# Conceptual PM2 Lockdown Trigger
if [ "$UNAUTHORIZED_EGRESS" = true ]; then
  pm2 stop all
  pkill -kill -u compromised_user
  # Isolate backend completely
fi
        

This immediately halts the backend application, isolates the compromised SSH user, and prevents any sensitive data from leaving the server environment.

4. Self-Healing Codebase Restoration

The most critical feature of this architecture is its ability to self-heal. If malware or a virus alters the application codebase, shutting down the server is only half the battle. You must safely restore the application state without allowing the malicious code to persist across restarts.

We designed an admin protocol that, upon lockdown, initiates a strict repository reset:

git fetch origin
git reset --hard origin/main
git clean -fd
        

This sequence wipes out any alien files, reverse-engineers any unauthorized code injections, and restores the entire application strictly to the verified origin state on GitHub. Once the environment is sanitized, the PM2 instances are restarted, ensuring the issue does not persist.

Conclusion

Security is no longer just about building walls; it is about building traps and automated countermeasures. By combining Cloudflare's edge protection with rigorous server hardening, instant PM2 automated lockdowns, and a self-healing codebase, we can engineer applications that actively fight back against intrusions.

CloudVoid is no longer operated, but the pattern outlived it: the same edge protection, hardened ports and return-to-source routine now run behind the systems I maintain in production.


Author: Agu Chiedozie | Cloud & AI Systems Engineer