Wulong use cases
Julien Béranger
+ Claude Opus 5.5
Where the chest stands
Wulong is a NestJS API that runs inside a trusted execution environment (TEE) on dstack, for example on Phala Cloud. Its chest is a secret store:
- A client verifies the enclave's attestation (
GET /chest/attestation), then encrypts a secret locally with w3pk using ML-KEM-1024. 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 (SIWE), saves the ciphertext with a list of Ethereum addresses allowed to read it. It returns a random slot.GET /chest/access/:slotdecrypts inside the enclave and returns the plaintext to a listed address.DELETE /chest/:slotlets the owner remove the entry.- Every entry is MAC-sealed under an enclave-only key, and each write can be anchored on Base by the enclave's relayer wallet, so the operator can neither edit access lists nor roll the chest back (see KEY_DERIVATION.md).
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 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 membership NFT" or "≥ 100 of this ERC-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 | 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 | Bids are stored sealed and all revealed together when bidding closes. | Timelock plus a batch reveal. It gives the result of a 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, 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) 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, OpenAI, Stripe…) 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-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. | 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 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, 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
- Expiry, one-time reads, editable access list. They're small, self-contained, and make sharing useful day to day.
- Dead man's switch. It's the first feature that only a TEE can offer, and it's cheap to build on
lastSeen. - 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.
- M-of-N approval. It unlocks inheritance, break-glass access, social recovery and the treasury use cases in one go.
- On-chain triggers. They unlock markets, escrow and paid unlocks.