A Litecoin Wallet That Remembers Nothing

Sergey Ovcharenko — Thu, 09 Apr 2026 07:58:43 +0000

In a previous article we introduced Ritual Protocol. Today we look at how it works in a real application.

Imagine: you need a new address on a blockchain network, or you want to access an existing one. You place some runes, point to London at 12:47, and tap a sequence of emojis. That's it. Cold wallet ready. No custodial nonsense, everything by the book — the way Satoshi intended. The only difference is that you don't need to remember or store a seed phrase. It's deterministically derived from your ritual.

No Storage

A typical wallet generates a key on first launch and saves it somewhere. A file, a database, an encrypted vault — doesn't matter. There's a place that needs to be protected, that can be lost, that can be stolen.

This wallet saves nothing. At all. Every time you need access — you reproduce it.

The Ritual

From a cryptographic standpoint, the protocol recommends at least 80 bits of ritual entropy. But the app doesn't restrict you. If you want a "Vatican City 12:00" address — just open it and use it.

A Regular Wallet Inside

After the ritual, a completely ordinary wallet opens. Address, balance, transaction history. You can receive and send LTC. Fees are calculated automatically, there's a MAX button, and both Litecoin address formats are supported.

The only difference is how you got here. And the fact that once you close the app — the key no longer exists anywhere.

Disclaimer

This wallet was built as a demonstration of Ritual Protocol's capabilities and a test of its viability in everyday use. All bugs found during testing have been fixed — but please use this software responsibly and for its intended purpose.

Source code on GitHub: https://github.com/runetcom2014/LTC-Wallet

Ritual Protocol: a key as an action, not an object

Sergey Ovcharenko — Sat, 28 Mar 2026 13:12:11 +0000

Every secret storage system is only as secure as the storage itself. Someone steals your password database — they steal everything. Someone compromises your keystore — they compromise everything. You can encrypt the storage, split keys, add authentication factors — but the fundamental problem remains: the key exists as an object, and objects can be stolen.

Ritual Protocol takes a different approach. The key is not stored. It is reproduced through a sequence of actions — a ritual. Same actions, same parameters — same 32 bytes out. Every time. No storage — no attack vector tied to its compromise.

How it works

A ritual is an ordered set of rites. Each rite has a type and parameters. Order matters: sequences [A, B, C] and [C, B, A] produce different keys.

Rite types

V1 defines six rite types. They can be combined in any order and repeated — each repetition increases entropy.

The rites are intentionally varied — a text string, a symbol sequence, a file slice, a star map, a city and time, runes on a grid. The idea is that every user has their own natural way to create a unique and reproducible ritual. Some will remember a symbol sequence, some will use a file and an offset, some will use a city and time combination with personal meaning.

Full description of each type with entropy formulas is in the specification.

Finalization

And that's really all there is to it. "I like it. Simple, easy to remember." — J.S.

Each rite is hashed independently through SHA256, then the hashes are folded sequentially — rite order affects the result, this is an intentional property of the protocol.

The final state is run through three KDFs:

Argon2id (64 MB, t=3, p=4) → scrypt (128 MB) → BLAKE2b-256

Three algorithms were chosen deliberately — each has a different memory access pattern. This makes it harder to build specialized hardware for brute force. Each brute force attempt costs as much memory and time as a legitimate finalization.

At 80 bits of ritual entropy, the effective security is approximately 126 bits — the difference is the computational cost of the KDF chain.

What's next

The protocol is intentionally minimal — exactly 32 bytes out and nothing more. What to do with them is the environment's concern. The reference implementation in Go compiles to .dll/.so with a simple C API, which makes it easy to plug the core into almost anything. There's a pretty decent demo in the examples.

Licensing: the author, as a responsible member of the open source community, hereby contributes this humble piece to the betterment of mankind. Personal use is free. If you're building a business on it — you know where to find us.

GitHub: https://github.com/runetcom2014/ritual-protocol
Specification: https://zenodo.org/records/19090391

Forem: Sergey Ovcharenko