The best security isn't a single wall—it's many walls, each protecting the next. Medieval castles weren't defended by one barrier; they had moats, outer walls, inner walls, towers, and a keep at the center. An attacker who breached one defense still faced many more.
Zbelthas applies this same principle to digital security. We call it defense in depth: eight independent layers of protection, each designed to stop different types of attacks. Even if an attacker somehow defeats one layer, seven more stand in their way.
This document explains each layer and why it matters for protecting your digital assets.
The majority of security vulnerabilities in software come from a single source: memory safety bugs. These are programming errors where software accidentally reads or writes to the wrong part of memory. Buffer overflows, use-after-free bugs, null pointer dereferences—these technical-sounding problems are responsible for most of the hacks you read about in the news.
These bugs exist because most software is written in programming languages (like C and C++) that don't prevent them. It's like building a house where the walls might randomly develop holes—you can try to patch them, but new ones keep appearing.
Zbelthas is written entirely in Rust, a programming language specifically designed to make memory safety bugs impossible. The Rust compiler mathematically proves that certain categories of bugs cannot exist in the code before it ever runs.
We've gone further: every component of Zbelthas explicitly forbids any code that could bypass these safety guarantees. The result is that entire categories of attacks—the ones responsible for most security breaches—simply cannot work against Zbelthas.
This isn't a claim we make lightly. It's a mathematical property of how the software is constructed.
Even with memory-safe code, we assume that any component could potentially be compromised. That's why each part of Zbelthas runs in its own isolated sandbox, using the strongest isolation mechanisms your operating system provides.
Think of it like a submarine with watertight compartments. If one compartment floods, the others remain dry. If one component of Zbelthas were somehow compromised, it couldn't access the others.
On Windows, we use AppContainer—Microsoft's strongest application sandbox. On macOS and iOS, we use Apple's App Sandbox with minimal permissions. On Android, we use isolated processes with additional restrictions. On Linux, we use Seccomp-BPF, the same technology that protects Chrome.
Each sandbox strictly limits what its component can do. The wallet component, for example, can't access the network. The browser component can't access your keys. Even if malware somehow got inside one component, it would find itself trapped in a box with no way to reach anything valuable.
In most wallets, your private key exists as a single piece of data. Steal that data, and you control everything. It's a single point of failure—one successful attack, and you lose everything.
Zbelthas splits your key into multiple pieces stored in different locations with different protections. To sign a transaction, multiple pieces must work together—but they're never combined into a complete key.
This means there's no single thing an attacker can steal. They would need to compromise multiple independent systems simultaneously. And even then, the mathematical properties of our key splitting ensure that having some pieces reveals nothing about the others.
Quantum computers will eventually break the encryption that protects most digital assets today. We don't know exactly when, but we know it's coming. Most security software hasn't even begun to address this threat.
Zbelthas uses post-quantum cryptography based on the latest NIST standards. These algorithms are designed to resist attacks from both classical and quantum computers.
We also use a hybrid approach: every cryptographic operation uses both classical and post-quantum algorithms. Even if one approach is somehow broken, the other still protects you. An attacker would need to break both simultaneously—a much harder task.
If an attacker can study how security software works, they can find weaknesses to exploit. Reverse engineering—taking apart compiled software to understand its inner workings—is a standard technique for finding vulnerabilities.
Zbelthas implements multiple techniques to make reverse engineering extremely difficult. Our security-critical code is transformed in ways that defeat automated analysis tools. The logic that protects your keys is obscured so that even with access to the compiled software, understanding how it works requires enormous effort.
This isn't security through obscurity—our cryptographic algorithms are well-known standards. But the specific implementation details that an attacker would need to exploit are protected against analysis.
Security isn't just about building walls—it's also about detecting when someone is trying to breach them. Zbelthas continuously monitors for signs of tampering or attack.
We detect debuggers—tools that attackers use to analyze running software. We detect modifications to our code. We detect timing anomalies that might indicate someone is trying to extract secrets. We detect attempts to read memory that shouldn't be accessed.
When tampering is detected, Zbelthas doesn't just log an error and continue. It immediately secures all sensitive data and terminates. There's no "continue anyway" option. If something is wrong, we stop—because continuing in a potentially compromised state is worse than stopping.
Modern software is built from hundreds of components created by different developers. If any of those components is compromised—either by a malicious developer or by an attacker who infiltrates the development process—the entire application becomes vulnerable.
This is called a supply chain attack, and it's increasingly common. You might trust the main developers of an application, but do you trust every developer of every library they use?
Zbelthas audits every dependency for security issues. We verify that the code we include matches what we expect—no hidden modifications. We sign every release with post-quantum cryptography so you can verify that the software you're running is exactly what we published.
We also support reproducible builds: anyone can compile our source code and verify that they get exactly the same result as our official releases. This proves we haven't hidden anything in the compiled software that isn't in the source code.
The final layer isn't technical—it's architectural. Because Zbelthas is non-custodial and collects no data, many attack vectors simply don't exist.
There's no server to hack because there is no server. There's no database of user information to steal because we don't collect user information. There's no way for us to freeze your assets or comply with seizure orders because we don't control your assets.
This architecture also provides regulatory clarity. We're not a custodian under financial regulations. We're not a data controller under privacy regulations. This isn't a loophole—it's a fundamental property of how Zbelthas is designed.
Software security has limits. No matter how carefully we write code, it runs on hardware—and hardware can provide security guarantees that software alone cannot.
Zbelthas integrates with the hardware security features built into modern devices:
TPM 2.0 on Windows and Linux provides hardware-backed key storage and cryptographic operations. Keys stored in the TPM can never be extracted, even by the operating system.
Secure Enclave on Apple devices provides similar capabilities with Apple's dedicated security processor.
StrongBox on Android provides hardware-backed security using dedicated security chips.
Hardware security modules can generate and store cryptographic keys in a way that makes extraction physically impossible. They can perform cryptographic operations without ever exposing the keys to software. They can verify the integrity of the software running on the device.
This is why Zbelthas achieves security comparable to dedicated hardware wallets—we leverage the same hardware security features, just integrated into the device you already own.
Throughout all eight layers, Zbelthas follows a simple rule: when something goes wrong, stop immediately.
Most software tries to be resilient—to recover from errors, to continue in a degraded mode, to give users a chance to fix problems. This is exactly wrong for security software.
If a security check fails, something is wrong. Maybe it's a bug. Maybe it's an attack. Either way, the safest response is to stop immediately and protect whatever secrets might be at risk.
In Zbelthas:
If integrity checks fail, we stop.
If tampering is detected, we stop.
If hardware security isn't available, sensitive operations are blocked.
If attestation fails, we stop.
There's no "continue anyway" option. Either everything works correctly, or nothing works at all. This might seem extreme, but it's the only way to provide real security guarantees.
We've evaluated Zbelthas against the same criteria used to assess hardware wallets and enterprise security systems. The result: a security score of 92 out of 100.
This puts Zbelthas in the same category as dedicated hardware wallets—but achieved entirely in software, running on the device you already own.
92/100 represents the maximum achievable security for a software-only, non-custodial, serverless solution. The remaining 8 points would require dedicated hardware (like an air-gapped HSM) or external security audits that are still pending.
We're transparent about what we can and cannot protect against:
We protect against: Remote attacks, malware, memory forensics, reverse engineering, supply chain attacks, timing attacks, and future quantum computers.
We cannot fully protect against: Physical access to an unlocked device, user error (like sharing recovery phrases), or a deeply compromised operating system.
Security is a partnership between the software and the user. We provide the strongest protection possible; you need to protect your device and your recovery materials.
You don't need to understand all eight layers to benefit from them. Here's what they mean in practical terms:
Your assets are protected by multiple independent defenses. An attacker would need to defeat all eight layers to compromise your security. Defeating one or two isn't enough.
Your keys are protected by hardware. Even if malware infects your device, it can't extract keys from the hardware security module.
Your software verifies itself. Zbelthas checks its own integrity and stops if anything is wrong.
Attacks are detected and stopped. We don't just build walls—we watch for attackers and respond when we see them.
The software you run is verified. You can confirm that Zbelthas hasn't been tampered with.
Your protection is future-proof. Post-quantum cryptography protects you against threats that don't exist yet.
This is defense in depth: not one wall, but eight. Not hoping attacks won't happen, but assuming they will and preparing accordingly.
This document explains the security features of Zbelthas. For more details on specific aspects:
System Architecture — How these security layers fit together
Cryptographic Foundations — The mathematics protecting your data
Wallet & Blockchain — How multi-chain support works securely
Legal & Compliance — Regulatory implications of our security architecture
Zbelthas is built by a small team committed to real security and privacy. If you believe in what we're building, you can support our development.
Traditional Methods: Visit zbelthas.com/donate for Patreon and other payment options.
Web3 / Cryptocurrency: For on-chain donations, visit our Web3 portal at rpc.zbelthas.com where you can view and interact with our donation smart contract. The contract only receives donations—no tokens are issued, no rewards are promised.
Donations do not grant any rights, tokens, equity, or promises of future benefits.
Title: Zbelthas - Security Features Version: 2.0 Date: March 2026 Status: Public Whitepaper Copyright: © 2026 Zbelthas Project. All rights reserved. Trademark: Zbelthas™ is a registered trademark.