The device is the trust boundary.
BitMadWall assumes the path is observed, the relay is unknown, and the handset may be taken. Keys are generated and stored on the device. Content is encrypted before it leaves it. No server holds anything that could be compelled.
Seven properties the design holds to.
End-to-end encryption
Every conversation is locked on the device before it leaves it, using the same published standards Signal is built on (X25519 key agreement, AES-256-GCM). The keys change as the conversation moves, so even a stolen key cannot unlock what came before. The phones that carry a message see sealed data and a delivery header, nothing more.
Packet signing
Every message and every payment carries its sender's unforgeable signature (Ed25519). The devices along the way check the seal without opening the contents, so a forged or damaged message is dropped at the first hop instead of passed along. Your device confirms who sent a thing before showing it.
Identity verification
Contacts are verified out of band: scan a QR code carrying the public key, or compare fingerprints in person. Incidental contacts fall back to trust on first use, and the application warns loudly if a known key ever changes. First contact is the weakest point in any such system, and it is treated as such.
Panic wipe
A gesture or code erases identity keys, session state, and message history from the device immediately. It exists for the case where the handset itself becomes the risk, not for a mislaid phone.
Traffic analysis resistance
Optional cover traffic and randomized send delays of 50 to 500 milliseconds break the correlation between an action and a radio emission. It does not change how content is encrypted, and it costs battery and bandwidth, so it stays a deliberate choice per deployment.
Key storage on the device
Identity and wallet keys live in the phone's built-in secure hardware where the device provides it, and are created there so they cannot be copied out. An app passcode and an auto-lock timer stand between an unlocked handset and an unlocked identity.
No servers holding your data
There is no BitMadWall service storing messages, contacts, or keys. No account database, no message archive, no key escrow. Nothing exists to be seized, subpoenaed, or read in silence, by us or by anyone who reaches us.
Named, standard, and unmodified.
No proprietary cryptography. Every primitive below is a published standard with existing public analysis, used as specified.
Primitive selection follows the Signal protocol design. Where our implementation departs from it, the departure is documented rather than described as an improvement.
A transaction that never needed your network.
The wallet signs on the device; the mesh carries the sealed result. Whichever phone first reaches the internet broadcasts it, and a stranger's handset serves as well as your own.
- Double-spend
- Settled by the Bitcoin network, not by us. There is no BitMadWall ledger to disagree with the chain.
- Replay
- A payment broadcast twice is still the same payment. The Bitcoin network recognises it and accepts it exactly once.
- Tamper
- A relay can delay a transaction. It cannot alter or forge one: the signature covers every byte that matters.
Questions about the threat model?
We will walk through what BitMadWall protects against, what it does not, and where the residual risk sits.
Or write directly to info@tashitech.ai.