The original research question: could a Solid pod safely hold a cryptocurrency wallet?

Mostly no, and that answer contradicts our own earliest sketch, which is why it is worth publishing. Nothing like it is built: pod's code contains no user key material at all.

What was actually proposed, in 2025

The sketch predates any shipped Solidus code. It laid out a pod layout like this:

/solidus/
├── profile.ttl
├── wallet/
│   ├── keys.ttl          ← encrypted private keys
│   ├── addresses.ttl
│   ├── transactions/
│   └── preferences.ttl
└── contacts/

with the flow: encrypt the private key, store it as a pod resource, retrieve and decrypt it to sign, append the transaction to a history file.

It is a clean sketch and the instinct behind it is good, a wallet whose data lives in your own storage moves with you instead of being locked inside one application. That property is real and it is why the question deserves an answer rather than a dismissal.

Why the key part of it is the wrong shape

Encrypting a private key and putting it in a networked store means the ciphertext is reachable.

Access control becomes the only thing standing between an attacker and an offline attack on your passphrase. Once someone has the bytes, they have unlimited time and no rate limit. The whole security of the wallet collapses into the strength of one passphrase and the correctness of one access rule.

Three concrete aggravations, all of them ours:

• A fresh pod grants the public every permission mode, including control, measured this session. Keys placed in a default pod would be world-readable.
• A pod hosted by us means we hold the ciphertext. We are in the processing path already; adding key material to that is a much larger promise than we are in a position to make.
• The append mode that the history file needs cannot be granted through our interface, two of four modes.

The direction the rest of the field went is the opposite one: the private key never leaves the device, held in hardware where possible, and nothing about a portable-storage model changes that calculus.

What the sketch got right, and it is most of the layout

Everything that is not the private key is a good fit.

• Addresses, public by nature.
• Transaction history, yours, portable, and useful to carry between applications.
• Preferences and trusted contacts, exactly the kind of small structured data a pod is for.

So the honest verdict is not "no". It is "no for the key, plausibly yes for the rest", which is a more useful answer than either extreme, and it is the one we would have missed by defending the original sketch.

What actually exists today

Nothing of this. Pod's code has no wallet container, no seed, no mnemonic and no user private key: the only private key present is the server's own session-signing key. The same search matches 43 files for something genuinely implemented.

The containers pod seeds are storage and credentials. What lives in the credentials one is a different subject.

A separate wallet surface exists in this estate. It is self-labelled beta, it is not pod, and it is not this design, and naming it here without those three qualifications would be precisely the borrowing this estate keeps catching.

Why publish a research question we answered against ourselves

Because the sketch is in our archive and someone will find it. A document proposing keys in a pod, with no note saying we changed our minds, is worse than the change of mind itself.

And because the reasoning transfers. "Encrypt it and put it somewhere convenient" is the most common bad idea in this field, and it is more persuasive coming from people who once wrote it down.