---
title: Wulong use cases
description: What Wulong's attested secret chest could be used for: sharing, conditional release, and secrets a TEE acts on without revealing.
date: 2026-09-30
lang: en-US
author: Julien Béranger
model: Claude Opus 5.5
source: https://julienberanger.com/wulong-use-cases
---

# Wulong use cases

## Where the chest stands

Wulong is a [NestJS](https://nestjs.com/) API that runs inside a [trusted execution environment](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) on [dstack](https://github.com/Dstack-TEE/dstack), for example on [Phala Cloud](https://phala.network/). Its chest is a secret store:

- A client verifies the enclave's attestation (`GET /chest/attestation`), then encrypts a secret locally with [w3pk](https://github.com/w3hc/w3pk) using [ML-KEM-1024](https://csrc.nist.gov/pubs/fips/203/final). The recipients always include the server's key, and usually the client's own key too.
- `POST /chest/store`, authenticated with [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) (SIWE), saves the ciphertext with a list of Ethereum addresses allowed to read it. It returns a random slot.
- `GET /chest/access/:slot` decrypts inside the enclave and returns the plaintext to a listed address. `DELETE /chest/:slot` lets the owner remove the entry.
- Every entry is MAC-sealed under an enclave-only key, and each write can be anchored on [Base](https://www.base.org/) by the enclave's relayer wallet, so the operator can neither edit access lists nor roll the chest back (see [KEY_DERIVATION.md](https://github.com/w3hc/wulong/blob/main/docs/KEY_DERIVATION.md#anchoring-the-chest)).

Today, all you can do with a secret is read it back. The use cases below are about what else you could do with it.

The building blocks already in place: an attested store, identity based on Ethereum addresses, keys derived inside the enclave, a relayer wallet with on-chain reads and writes, and [timelocked governance](https://github.com/w3hc/wulong/blob/main/docs/GOVERNANCE.md) over upgrades.

Effort is rough: **S** fits in one PR, **M** takes a few PRs, **L** is a new subsystem.

## 1. Sharing

Sharing needs no new trust assumptions, only a richer version of the current access model.

| Use case | Scenario | Needs | Effort |
| --- | --- | --- | --- |
| Editable access list | Alice shares a Wi-Fi password with her flatmates and later removes one who moved out, without changing the slot. | `PATCH /chest/:slot` restricted to the owner. The server re-seals the entry. Removed readers who were also ML-KEM recipients can still decrypt their old copy offline. | S |
| Expiring secrets | A contractor gets a staging credential that stops working on Friday. | An `expiresAt` field covered by the MAC. Access past that date returns 404, and a sweep removes expired entries. | S |
| One-time reads | A password handed over once, then burnt, like a self-destructing note. | A read counter covered by the MAC, anchored like any other write so a rollback can't reset it. | S |
| Access log | The owner sees who read the secret and when. | An append-only log per slot, visible only to the owner, and optionally anchored. | M |
| Token-gated access | "Anyone holding this [ERC-721](https://eips.ethereum.org/EIPS/eip-721) membership NFT" or "≥ 100 of this [ERC-20](https://eips.ethereum.org/EIPS/eip-20)" can read a community's shared credentials. | Access rules checked against chain state at read time, through the relayer's RPC. | M |
| Team vaults | A startup keeps its shared credentials in named vaults with roles (admin, reader), like a password manager but not operated by any company. | Groups of addresses, with slots attached to groups rather than to fixed lists. | M |

## 2. Conditional release

In these use cases the enclave decides when a secret becomes readable. This is where a TEE does better than both a server and a smart contract: the rule is enforced and the secret stays private until it fires.

| Use case | Scenario | Needs | Effort |
| --- | --- | --- | --- |
| [Dead man's switch](https://en.wikipedia.org/wiki/Dead_man%27s_switch) | If Bob doesn't sign in for 90 days, his partner can read his account list. | A `lastSeen` value for the owner, a check-in endpoint, and a release rule tested on access. | S |
| Crypto inheritance and encrypted wills | Heirs receive a wallet seed phrase or a letter after an inactivity period, with an optional notary co-signature. | The dead man's switch plus M-of-N approval (below). | M |
| Timelock and embargo | A press release, exam paper or research result that nobody can read before a set time, not even the author. | `notBefore` covered by the MAC, with time taken from a trusted source rather than the host clock alone, for example the latest Base block timestamp. | M |
| [Sealed-bid auctions](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) | Bids are stored sealed and all revealed together when bidding closes. | Timelock plus a batch reveal. It gives the result of a [commitment scheme](https://en.wikipedia.org/wiki/Commitment_scheme) without a reveal step that bidders could refuse to take. | M |
| Private voting | Votes stay secret until the poll closes. The enclave publishes the tally, and ballots can optionally be revealed afterwards. | Timelock plus a tally endpoint. The result is posted on chain by the relayer. | M |
| On-chain trigger | Release when an escrow contract is paid, a governance vote passes or an oracle reports an event. | The relayer watches for a contract event, and a matching condition type is added to the entry. | M |
| M-of-N approval | A treasury recovery key is readable only once 3 of 5 signers approve within 48 hours. | Approvals collected per slot through SIWE, and release once the threshold is met. | M |
| Break-glass credentials | During an incident, on-call engineers get root credentials after approval, and every use is logged. | M-of-N approval plus the access log plus expiry. | M |
| Whistleblower drop | A source leaves documents for a journalist, to be published automatically if the source goes silent. It follows the model of [SecureDrop](https://securedrop.org/), without an operator who could be compelled to hand them over. | Dead man's switch, plus storage for large payloads outside the chest. | L |

## 3. Using a secret without revealing it

This is the missing step after storage. The secret never leaves the enclave, and callers get the *result* of using it, under a policy.

| Use case | Scenario | Needs | Effort |
| --- | --- | --- | --- |
| Policy-bound signing key | Store an Ethereum private key. The enclave signs transactions only within a daily cap, to allowlisted contracts, at a limited rate. | A signing endpoint, a policy attached to the entry, and a spend ledger that is anchored so it can't be rolled back. | M |
| Agent session keys | An LLM agent (for example [rukh](https://github.com/w3hc/rukh)) gets scoped signing rights instead of a raw private key, so a prompt injection can't drain the wallet. | Policy-bound signing plus a short-lived capability token given to the agent. | M |
| API key proxy | Share access to a paid API ([Anthropic](https://www.anthropic.com/), [OpenAI](https://openai.com/), [Stripe](https://stripe.com/)…) without sharing the key. Callers go *through* the enclave, which injects the key and enforces quotas. | An outbound HTTP proxy with a host allowlist per entry, and usage metering. Because the enclave terminates TLS itself, responses can be trusted. | M |
| Confidential AI prompts | A company's system prompt or fine-tuning data is used by the enclave for each request but never exposed to users or the operator. | The API proxy plus prompt templating inside the enclave. | M |
| CI/CD secret injection | A deploy pipeline gets production secrets only if it can prove its identity, for example with a signed attestation of the build. | An endpoint that verifies the caller's attestation or [OpenID](https://en.wikipedia.org/wiki/OpenID)-style token before releasing the secret. | L |
| Private comparisons | Two parties learn only whether their secrets match (salary bands, a shared contact, a known password), or the intersection of their lists, as in [private set intersection](https://en.wikipedia.org/wiki/Private_set_intersection). | A compute endpoint over two or more slots that returns a boolean or an intersection. | M |
| Selective disclosure | Prove "over 18" or "resident of the EU" from stored identity documents without revealing them, a lighter alternative to full [KYC](https://en.wikipedia.org/wiki/Know_your_customer) data sharing. | Predicates evaluated in the enclave, and a statement signed by the enclave's identity key that relying parties can verify against the attestation. | L |

## 4. Markets and escrow

| Use case | Scenario | Needs | Effort |
| --- | --- | --- | --- |
| Paid unlock | A researcher sells a dataset. Buyers pay on chain and the enclave adds them as readers automatically. | The on-chain trigger plus an editable access list. | M |
| Bug-bounty escrow | A researcher deposits an exploit write-up. The project sees a summary signed by the enclave, pays the bounty into escrow, and the full report is then released to the project. | Paid unlock plus a summary step that the enclave signs. | L |
| Fair exchange | Two parties swap secrets, for example a license key for a payment receipt, and each is released only if both have been deposited. | Two slots linked by an atomic release. | M |

## 5. Custody and recovery

| Use case | Scenario | Needs | Effort |
| --- | --- | --- | --- |
| Seed-phrase backup | A user backs up a wallet seed phrase that only their passkey address can read, with w3pk as the client. | Works today. What's missing is a client flow and UX. | S |
| Social recovery | If a user loses their device, 3 of 5 guardians together can re-release the backup to a new address. It's a simpler alternative to splitting the seed with [Shamir's secret sharing](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing), because the enclave enforces the threshold. | M-of-N approval plus re-sealing to a new owner. | M |
| Chest migration | Move secrets to a new version of the Wulong app without the operator ever seeing them, approved through the timelocked governance. | Export sealed to the next measured app, verified against its attestation. | L |

## 6. Developer surface

These aren't use cases in themselves, but they make every item above usable.

- **Client SDK and CLI:** `wulong store`, `wulong get`, `wulong share`, with attestation verification built in, so integrators can't skip that check.
- **Webhooks:** notify the owner when their secret is read, a condition fires or an approval arrives.
- **Large payloads:** encrypted blobs kept in external storage, with the chest holding only the key and a hash. This lifts the 1 MiB quota for documents.
- **Multi-replica:** the write lock is per process, so running more than one replica needs a shared lock or a single writer.

## Suggested order

1. **Expiry, one-time reads, editable access list.** They're small, self-contained, and make sharing useful day to day.
2. **Dead man's switch.** It's the first feature that only a TEE can offer, and it's cheap to build on `lastSeen`.
3. **Policy-bound signing key or API key proxy.** Either one turns the chest from a vault into a service that acts on secrets. They reuse the derived keys, the relayer and the enclave-terminated TLS.
4. **M-of-N approval.** It unlocks inheritance, break-glass access, social recovery and the treasury use cases in one go.
5. **On-chain triggers.** They unlock markets, escrow and paid unlocks.

## Further reading

- [Wulong on GitHub](https://github.com/w3hc/wulong)
- [dstack](https://github.com/Dstack-TEE/dstack) and [Phala Network](https://phala.network/)
- [FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final)
- [EIP-4361: Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361)
- [w3pk](https://github.com/w3hc/w3pk)