Building SecretShare🔐with Storacha & UCANs

This guest post was originally published by two talented builders, Neha Kumari and Akash Jana, from the Protocol Labs Dev Build program who’ve been exploring new ways to integrate secure delegation into developer workflows. We’re excited to syndicate their write-up on SecretShare — a project that combines UCANs, Lit Protocol, and Storacha to enable safe, time-limited access to sensitive data. Read the original post here.

Sharing secrets like API keys or credentials is a necessary evil in dev workflows but it’s also risky. Ever dropped an API key in Slack and immediately regretted it? Or shared sensitive tokens over email, only to worry if they’re still floating around?

What if you could share them once, securely, with total control?

Answer is SecretShare — a secure delegation mechanism built using UCANs, Storacha and Lit Protocol to allow time-limited or usage-limited access to sensitive information. A Web3-native way to share secrets with limited access: one-time, time-bound, and revocable.

What is SecretShare?

SecretShare Home page

SecretShare is a secure way to delegate time-limited or usage-limited access to sensitive credentials, secrets, or API tokens without revealing them outright. It is like sharing 1-time access to an API key or password vault item without giving away full control.

Think of it as “One-time vault links for devs and teams.”

With SecretShare, you can:
🔄 Share secrets like API keys once or for a short duration.
🕓 Limit access by time or usage count.
🧾 Delegate access without transferring full ownership.
📁 Store secrets securely via Storacha.
🪪 Leverage UCANs for secure, verifiable delegation.
🔐 Encrypt data using Lit Protocol.

How It Works

1. The issuer (you) uploads the secret to Storacha.
   This secret can be any text like an API key, token, or note.
2. Encryption is performed using the Lit Protocol before uploading on Storacha.
3. Storacha stores the encrypted secret and returns a unique content ID (CID).
   This CID represents the encrypted version of the secret stored securely.
4. You create a UCAN (a signed access token) that delegates permission.
   In this UCAN, you specify:
   > Who can access the secret (Recipient’s DID)
   > How long the access is valid (e.g. 10 minutes)
   > How many times it can be used (e.g. only once)
5. This UCAN is digitally signed with your space DID key.
   This proves you authorized the delegation
6. A shareable link is created using this UCAN.
   Something like: https://w3s.link/ipfs/${cid}
7. The recipient access the link.
   Recipients gets the users secrets/credentials through IPFS link.
8. If everything checks out, the Lit Protocol decrypts and shows the secret.
   It verifies:
   > Is the signature valid?
   > Is the UCAN within the allowed time?
   > Has it already been used?
9. If the UCAN is expired or already used, access is denied.
   The recipient sees a message like: “Access Denied : UCAN expired or invalid.”
10. The user (issuer) retains full control and can revoke the delegation by referencing the secret’s CID and invalidating the associated UCAN proof.

Why UCANs + Storacha?

Traditional Access Control: All or Nothing
In most systems today, access is binary. You’re either in (you get full access) or you’re out (no access at all)

For example:
Share an API key via Slack? The person can now do anything with it. Add someone to a vault? They get all the secrets in that vault.

Share an API key via Slack → full access.
Add someone to a vault → access to everything.

There’s no way to say: “Here’s this one thing, and you can use it once, for just few minutes.” That’s where UCANs and Storacha come in.

Lit Protocol: For Encryption🛡️

To protect secrets from unauthorized access, SecretShare uses Lit Protocolfor encryption. Lit is a decentralized key management network that enables attribute-based encryption, meaning decryption is only possible if certainprogrammable conditions are met such as time, identity, or signature requirements.
Before your secret ever touches Storacha, Lit encrypts it client-side. This ensures that only recipients who fulfill the UCAN-defined conditions can decrypt it without relying on centralized services. It’s trustless, composable, and censorship resistant, aligning perfectly with SecretShare’s goals.

UCANs: Delegation, Not Just Access

UCAN stands for User Controlled Authorization Network.
It’s a fancy name for a very smart idea:

Instead of granting access, you delegate capabilities what someone can do, for how long, and on what resource.

UCAN is like a cryptographic permission slip signed by you. Here in secretshare example the permission slip includes scope, time limit, usage, recipient, etc. UCANs are cryptographically signed, auditable, and verifiable the recipient can’t modify them making it tamper-proof.

So instead of saying: “Here’s the key.”
You’re saying: “You can use this key to unlock just this drawer, only once, and only within the next 10 minutes and I’m cryptographically signing this agreement.”

🐔 Storacha : Hot Decentralized Storage

Imagine needing to share a sensitive piece of information like an API key or a confidential note with someone. You want to ensure it’s secure, accessible only to the intended recipient, and doesn’t linger around longer than necessary. This is where Storacha comes into play.

Storacha is a decentralized, hot storage network built on top of Filecoin and IPFS. It allows you to store encrypted data securely and retrieve it swiftly when needed. Here’s how it works:

1. Client-Side Encryption (via Lit) before upload: Before anything leaves your device, Lit encrypts your data locally. This means your secrets are protected right from the start.
2. Content Addressing with CIDs: Once encrypted, your data is uploaded to Storacha, which assigns it a unique Content Identifier (CID). This CID is a cryptographic hash of your content, ensuring that:
   The content is immutable; any change would result in a different CIDThe data is verifiable; anyone retrieving it can confirm its integrity.The storage is location-independent; the CID doesn’t point to a specific server but to the content itself, retrievable from any node in the network.
3. Integration with UCANs: Storacha leverages User Controlled Authorization Networks (UCANs) to manage access permissions. This means you can delegate specific access rights to others without exposing your credentials or compromising security.

By combining these features, Storacha provides a robust solution for securely sharing and storing sensitive information in a decentralized manner.

Putting it All Together: SecretShare’s Model

1. You encrypt and upload a secret → get a CID
2. You create a UCAN that says:
   Bob can read secret with CID ”bafy...”, once, within the next 10 minutes
3. You share a link: https://w3s.link/ipfs/${cid}
4. When Bob opens it:
   > UCAN is validated (issuer, scope, expiry, usage)
   > If valid, the Lit decrypts the secret
   > Once revoked (or if the usage limit is reached), the share link becomes inaccessible.

Why this is powerful

> You never share secrets directly
> Access is scoped, temporary, and verifiable
> It’s developer-friendly (link-based UX) yet secure by design
> Fits seamlessly in developer workflows

Demo & Resources

1. Live: secret-share-lilac.vercel.app
2. Watch the Demo: Video
3. Source code: Github (Nkovaturient)
4. Storacha UCANs: storacha/ucanto
5. Storacha Docs: docs.storacha.network
6. Lit Protocol: litprotocol.com

SecretShare was built to solve a real pain: how to share secrets safely and temporarily in collaborative dev environments.

By combining
> UCANs for fine-grained access
> Storacha for decentralized storage, and
> Lit Protocol for secure encryption
SecretShare offers a next-gen solution to an age-old problem.

No more leaking secrets. Just safe, shareable access.

Give it a try, and feel free to fork or contribute!
From mild to wild, Storacha scales with your needs. Stay spicy!🌶️🔥

Glossary

1. UCAN — A cryptographically signed token to delegate limited access.
2. CID (Content Identifier) — A unique hash that identifies and verifies content in IPFS.
3. DID (Decentralized identifier) — A decentralized, self-owned digital identity.
4. Lit Protocol — Enables programmable, condition-based encryption.
5. Storacha — Decentralized, hot storage built on IPFS + Filecoin.
6. IPFS — A peer-to-peer system for storing and sharing files via CIDs.
7. Delegation — Granting someone limited access rights to a resource.
8. Revocation — Invalidating a previously granted access token.