Should your personal data live on the chain itself?
For a public social graph, there is a real argument that it should, and somebody built a chain for exactly that. For private personal data the answer is no, and the reason is not squeamishness about blockchains. It is that you cannot delete from one.
Nothing on this surface is anchored on-chain.
The case for putting it there, made properly
One layer-one chain stores posts, profiles and follows directly on-chain. Every application reads and writes the same graph, so a user's followers are not locked inside whichever client they signed up with. Its own material describes the design as powering storage-heavy applications by making content storage cheap.
That is a real technical achievement and it solves a problem a pod does not attempt. Three other projects answer the same question three other ways, and none of them made storage itself the shared layer.
For data that is meant to be public, permanent and readable by every application at once, on-chain storage is a coherent answer rather than a category error.
Why private data is different
Three properties that make a chain good at the first job make it bad at the second.
It is permanent. That is the feature. It is also why a right to erasure collides with it, and why perpetual storage has the same collision. Personal data that a person can require you to delete should not go somewhere deletion is structurally impossible.
It is public. Encrypting first is possible, and then you have moved the problem to key management, with ciphertext that stays readable forever to anyone who later obtains the key. A private key compromise in 2031 exposes data written in 2026.
It is replicated. Every full node holds a copy. There is no operator who can be compelled to remove one, which is the same sentence as durability read from the other side.
What pod does instead, precisely
Content lives in the Solid server, in an ordinary filesystem and database. Personal data is off the chain entirely.
What the chain holds is identifier material: keys, timestamps, a version identifier, a recovery policy. We resolved a real record and listed its fields, and there are no personal fields in it. Checked on one record rather than established as systematic, which is the honest form.
Access rules are enforced by the server, per resource and per agent. Not anchored on a chain, which is a claim this surface may never make and a separate page exists to keep it from creeping back.
The part where the comparison beats us
Derived keys with spending limits are the mechanism we identified as missing.
A pod grant cannot express delegation with bounds. It names an agent and a mode, and it carries no purpose, no scope and no expiry, so an audit cannot tell the principal's action from a helper's. A temporary credential scoped to posting, with a limit attached, is exactly the shape of the thing our access-control layer has no vocabulary for.
Somebody shipped it. We wrote a page saying it was an open question. Both of those are true and the order matters.
The split that actually works
Identifiers, commitments and revocation state on the chain, where permanence is a feature and nothing personal is written. Personal data off it, where a delete is a delete.
That is not our idea and this page is not claiming it. It is what the field converged on, for the reason above, and the design work is deciding which bytes go where before any are written.