GDPR Compliance in Decentralized Storage: A Practical Guide
What GDPR asks of a platform built on IPFS and a public ledger, what Ekayana does about each principle, and where its guarantees stop.
The GDPR Challenge for Decentralized Systems
The General Data Protection Regulation presents particular challenges for decentralized storage systems. The right to erasure is hard to honour when data is distributed across a network, and data minimization is hard to guarantee when content addressing creates permanent links.
This guide goes through what the platform does about each principle, and where its guarantees stop.
Key GDPR Principles and Decentralized Solutions
1. Right to Erasure (Article 17)
IPFS content is addressed by its hash, and deleting the original does not remove copies that other nodes already fetched. The platform answers that with encryption and with what it keeps off the chain.
- Every upload is sealed by the service before it reaches IPFS, under a fresh AES-256-GCM key that is wrapped to the service's ML-KEM-1024 key. A copy anyone else fetched is an envelope that only the service can open.
- Deleting a file removes it from your account and unpins the platform's copy.
- Unpinning is not erasure on its own. The blocks stay on a node's disk until its garbage collector removes them, and the service can open every envelope it still holds. Erasure therefore rests on the operator's storage practice as well as on the encryption.
- Nothing personal is written to the chain. A DID's registry entry holds public keys, opaque fragments and URIs. Deactivating a DID leaves a permanent public tombstone, so deactivation retires an identifier and erases nothing.
Erasure works one file and one pass at a time.
# Remove a file from your account and unpin it
curl -X POST https://api.ekayana.io/api/delete \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{ "cid": "bafybei..." }'
# List the passes you issued, then revoke one by its token hash
curl https://api.ekayana.io/api/ucan/issued \
-H "Authorization: Bearer $TOKEN"
curl -X DELETE https://api.ekayana.io/api/share/revoke/<token_hash> \
-H "Authorization: Bearer $TOKEN"There is no bulk erase, no per user key to destroy, and no deletion log. Closing a whole account is not available through the API, so a request to erase an account goes to the operator.
2. Data Minimization (Article 5)
Content addressing means every version of a file gets a new, permanent identifier. The platform keeps what it publishes small.
- The chain holds only public keys, opaque fragments and URIs.
- Public metadata documents carry titles, keywords, licenses and the researcher names and ORCIDs the owner chose to publish, and never an email address.
- File names, sizes and types sit in the service's database rather than in the stored envelope.
Two limits are worth knowing. The platform issues no verifiable credentials and runs no zero knowledge proofs, so selective disclosure is not one of its tools. And creating a Dataverse dataset through the API sends your username and email to Dataverse as the dataset contact, because Dataverse requires one.
3. Purpose Limitation
- A pass names one file, or every file its issuer owns, together with the actions it allows among read, write and delete, and an expiry. It limits scope, and it has no field for purpose.
- The platform keeps no consent records and no access log. Purpose and consent have to be recorded by whoever controls the processing.
- Registering a paper sends its decrypted text to the BioAgents knowledge base, which every user of the agent can search, and the AI analysis routes send a file's text to the configured model provider. Use either only for text that may leave the sealed store.
Practical Implementation
Consent Management
The platform has no consent API. Record consent in the system that collected it, and keep the CIDs of the files it covers next to the record, so that a withdrawal maps onto the deletes and revocations above.
Data Subject Access Requests
There is no DSAR export. These reads cover what the platform holds for an account.
| What | Endpoint |
|---|---|
| Profile and linked wallet | GET /api/users/me |
| Files you hold | GET /api/pins |
| DIDs you created | GET /api/did |
| Passes you issued and received | GET /api/ucan/issued, GET /api/ucan/received |
| Files shared with you | GET /api/shared |
| Chain changes you planned | GET /api/workflows |
| AI conversations | GET /api/ai/conversations |
Best Practices
- Encrypt on the client anything the operator must not read. The service seals every upload, but it holds the key. A file encrypted on the client cannot be indexed by BioAgents or read by the AI routes.
- Keep your own records of processing, since the platform keeps none.
- Record consent where you collect it, and never process without it.
- Plan for deletion, and design systems with erasure in mind from the start.
- Review compliance regularly.
Read more about our Privacy Controls in the documentation.
Ready to Get Started?
Explore our documentation to learn how to integrate Ekayana into your research workflow.