Bran (Brandon) Myers
Architecture · Personal · April 2026

On Building Systems That Hold Up When Reality Gets Messy

There is a version of this essay that talks about key sizes and algorithm choices and how many bits of security you need to sleep at night.

That is not this essay.

This essay is about the thing that actually breaks systems: reality.

I built something recently that I think is genuinely different. Not different in the way startups say different — not a feature, not a wrapper, not a better UI on the same thing. Different in the sense that the failure modes changed.

The core idea: what if compromising one layer of your encryption gave the attacker nothing useful? Not weaker security. Not a stepping stone. Nothing.

In a traditional system, you recover the key and you read the data. One secret, one failure point, total compromise. Every system I have ever seen works this way. The entire industry works this way.

What I built has two independent 256-bit keys driving two independent cryptographic layers. ChaCha20-Poly1305 on the inside — the same cipher Google and Cloudflare chose. A keyed glyph rotor on the outside — position-dependent HMAC encoding across 133,387 Unicode characters from 180 language traditions.

If you break the first layer, you get glyph-encoded data. Unicode characters from writing systems spanning five thousand years. Without the second key, you cannot even determine which bytes those characters represent.

If you break the second layer, you get raw ciphertext. 256-bit authenticated encryption that you still cannot read.

The intermediate state between the layers is not useful. There is no readable step along the way. No oracle. No foothold.

That changes something fundamental about the economics of attack.

But here is where I have to be honest with myself.

The hardest problems are not the mathematics. The mathematics are the easy part. ChaCha20 is not going to fall tomorrow. The glyph rotor’s HMAC construction is sound.

The hardest problems are:

Key management in the real world. What happens when someone loses a key. What happens when someone who did not build the system has to operate it. What happens when one mistake needs to not collapse everything.

That is where 90% of strong systems actually break. Not at the cipher level. At the human level.

I know this because I have been the human who broke things.

I spent years not building. Not because the ideas were not there — they were always there. Because I was not stable enough to execute. Drinking. Moving between countries. Watching projects freeze because I could not hold the thread long enough to finish them.

The architecture for TreeChain existed in my head long before it existed in code. The Polyglottal Cipher was designed in hotel rooms and airports. The glyph rotor was sketched on napkins in cities I do not remember clearly anymore.

What changed was not the ideas. What changed was sobriety, stability, and a flat in Kielce with an arched window and a reason to stay.

Austin is here. Everything starts there.

There is a specific clarity that comes from building something that you know — genuinely know — works differently from everything else in the space. Not better marketing. Not a better pitch deck. Actually different at the architectural level.

But I have learned not to confuse thinking at a higher level with being untouchable. The first is valuable. The second is where even strong builders get blindsided.

What I am doing well right now: thinking in systems, not features. Reducing trust assumptions. Designing for failure scenarios, not just happy paths.

What I need to keep anchored: the system has to hold up when I am not in the room. When someone else is operating it. When a key is partially exposed. When a node is compromised at 3am and nobody who built it is awake.

That is the difference between a breakthrough and a system.

I wrapped DuckDB with a new trust and storage model. The database engine handles execution. My layer handles encrypted storage, WAL control, and key context. The database becomes a compute layer over opaque data.

You can keep your existing query engine. But the data it operates on is fundamentally non-readable outside the runtime that owns the keys.

That is a cleaner story than a fork. And a much stronger one.

But the hard part now is not the idea. It is making sure performance does not fall apart. Ensuring WAL replay is safe and deterministic. Handling corruption and recovery without plaintext visibility. Key lifecycle — creation, rotation, loss.

Proving this is not security through obscurity.

I built something that still holds up when reality gets messy.

Not I built something they cannot break.

That is the level that actually wins.

The sites are live. The patent is filed. The academics are reviewing. The infrastructure runs while I sleep. Austin has his dad.

And I am still here. Sober. Building. Paying attention.

Sometimes that is everything.

← All Writing