# Cloaked

Markdown version of https://l2beat.com/privacy/projects/cloaked

## Summary

- Metrics: Not tracked. Data tracking is not available for this project.
- Tracked on: Ethereum
- Attributes: Stealth addresses, Any amount

### Risks

- Trusted setup: No setup (sentiment: neutral). No setup: This project does not have a ZK system and thus no setup-related trust assumptions.
- Exit window: Infinite (sentiment: good). Under the documented key model, existing stealth balances are held in user-controlled EOAs and can be recovered with the published client-side recovery tool. The hosted service cannot spend them without obtaining client-side key material. This protocol does not pass the walkaway test: users cannot fully use it if all centralized protocol participants disappear. New payment-address generation, ENS resolution, address indexing, transaction construction, and relaying depend on the hosted Cloaked service.
- Privacy: Recipient privacy. Public observer: Recipient private (sentiment: good); Chain analyst: Recipient at risk (sentiment: warning); Network observer: Recipient at risk (sentiment: warning); Privileged insider: Recipient exposed (sentiment: bad); Future adversary: Recipient at risk (sentiment: warning).
- Reproducibility: Partially reproducible (sentiment: warning). The production web wallet is closed source and cannot be self-hosted. The published derivation code and API schema can nevertheless be used to build a local client that creates an account, derives keys, and signs and submits payments through the hosted API. The backend implementations of the API, ENS gateway, indexer, and relay service are not published, so the complete service cannot be reproduced.

### About

A wallet service with a closed-source hosted frontend that keeps spending keys client-side and gives recipients a fresh stealth address for every payment through reusable ENS names.

### Links

- Website: https://app.clkd.xyz
- Docs: https://clkd.xyz/docs, https://clkd.xyz/docs/ens-names, https://clkd.xyz/openapi.json
- Repository: https://github.com/cloakedxyz/clkd-stealth, https://github.com/cloakedxyz/clkd-recovery, https://github.com/cloakedxyz/account, https://github.com/cloakedxyz/clkd-privacy-pools
- Social: https://x.com/staycloakedxyz
- Contracts explorer (Disco): https://disco.l2beat.com/ui/p/cloaked

## Protocol description

Cloaked is a wallet service that separates incoming payments across fresh Ethereum addresses while presenting them as one account. Whether requested through an ENS name, the app, or the API, each address is controlled by a private key that the recipient can derive locally.

### Stealth address generation

Under Cloaked's published key model, the client deterministically derives separate viewing and spending keys from a passkey secret or a wallet signature combined with a PIN. It shares the viewing key and public spending key with Cloaked so the service can generate and monitor payment addresses, but keeps the private spending key locally.

For each payment nonce, the service derives an ephemeral private key, combines it with the recipient's public spending key, and returns the resulting one-time address. The client can recreate the same ephemeral key and combine its public key with the private spending key to derive the private key controlling that address. Under this model, only the client can derive the private key needed to spend from a correctly generated address.

The derivation SDK, API schema, and standalone recovery client are published. The recovery client can derive exportable stealth private keys without using the Cloaked API.

The production web wallet itself is closed source, has no published reproducible build, and cannot be self-hosted. Users who rely on it must trust the remotely served application to preserve the client-side spending-key boundary. The API, ENS gateway, indexer, and relay are also hosted and closed source, so the complete wallet service cannot be self-hosted.

The hosted frontend is not required to hold or use spending keys. A locally run client can create an account and perform payment-address, quote, local derivation and signing, and submission flows against the hosted API. In this setup, the spending key and derived stealth private keys remain local; Cloaked receives the scoped viewing capability and signed authorizations. Assuming the client verifies the data it signs, bypassing the hosted frontend removes it as a spending-key exfiltration risk.

This differs from the usual sender-driven ERC-5564 flow. The payer does not derive the address from public recipient metadata and publish an announcement. Cloaked's service performs the derivation, keeps the address-to-account mapping, and indexes the resulting balances.

When a user spends, the service selects one or more stealth addresses and prepares the transaction. The client re-derives the corresponding private keys and authorizes execution. Cloaked uses EIP-7702 account delegation for actions such as combining balances, paying fees in tokens, swaps, and bridging.

### ENS resolution

Cloaked supports both the free `username.clkd.eth` subdomain created during registration and custom `.eth` names or subnames owned by the user. Linking a custom name sets Cloaked's resolver for that name but does not transfer ownership, and the user can unlink it by changing the resolver again. Both kinds of name use the same ENS CCIP-Read flow.

A lookup is redirected to `api.clkd.xyz`, which creates a fresh payment address and returns a signed ENS answer. The onchain resolver checks the answer's expiry and signature against its configurable signer. For custom names, Cloaked stores the linked name only in encrypted form, although the name and its resolver configuration remain public on Ethereum.

The signature authenticates the answer as one accepted by Cloaked, but it is not a proof that the returned address was correctly derived for the named recipient. An external sender cannot independently verify recipient control from the ENS answer alone. The resolver owner can immediately replace both the gateway URLs and accepted signer.

### Privacy considerations

Cloaked's fresh addresses do not hide the sender, token, amount, or receiving address of an individual payment. They prevent separate receives from automatically accumulating under one reused public address. Later transactions can still link addresses when they consolidate balances, use a recognizable destination, or correlate by timing and amount.

The hosted service has the viewing capability and address index needed to link an account's stealth addresses and activity. Cloaked also integrates [Privacy Pools](https://l2beat.com/privacy/projects/privacy-pools) for an Incognito balance that can break the public onchain link between a deposit and withdrawal, but Cloaked states that its relay sees both sides. The underlying pools are tracked separately because their public transactions cannot be attributed specifically to Cloaked users.

## Privacy

**What the protocol promises:** Hides which account a receiving address belongs to. The payer knows the address it was given; sender, asset, amount and where the funds go next are public.

On public blockchains like Ethereum, all actions transparent by default. A privacy protocol can at best cut the link between addresses or offer privacy while deposited. The colour says whether a careful user can keep the link, amount or recipient private against that adversary: green yes, yellow only outside supported options or by accepting another leak, red no. Fields marked at risk stay private only under the condition in their note.

### Public observer

Recipient private (sentiment: good)

**Who:** Everyone with a block explorer and some basic tools. Sees every public onchain event, but does no correlation beyond following links. Examples: A curious counterparty, an employer, a journalist.

A fresh receiving address has no public derivation linking it to the recipient account, but its funds can be followed through later sends and change outputs. Combining addresses exposes their joint use, and EIP-7702 delegation reveals the account implementation without proving who owns the address.

**Advice:** Generate a fresh address for each receive, spend address-held balances separately with Advanced Control, and send to destinations with no public link to you.

**Sources**

- [Address derivation from server-held ephemeral material](https://github.com/cloakedxyz/clkd-stealth/blob/9eb359efdd4ea31f5504bf81e57dcfe6f966dc14/src/shared/genStealthAddress.ts#L17-L58)
- [Input selection, visible change and EIP-7702 execution](https://clkd.xyz/docs/how-it-works#sending-funds)
- [Quote API: spendableAddresses and reusable singleAddress mode](https://clkd.xyz/openapi.json)

### Chain analyst

Recipient at risk (sentiment: warning)

**Who:** Scrapes all public data and correlates it: timing, amounts, gas and wallet fingerprints, address clusters. Examples: Chain analytics firms, ZachXBT, data brokers.

Spending through shared execution infrastructure makes service use recognizable, which narrows the anonymity set to Cloaked users. No registry or announcement maps accounts to addresses, but timing, distinctive amounts, recurring counterparties and consolidation can identify or cluster recipients. A send draws from several addresses by default and leaves a change output that links them.

**Advice:** Space out related payments and check whether amounts or recurring patterns identify you. Follow your own change outputs to see what a counterparty can trace.

**Sources**

- [Documented transaction links and change handling](https://clkd.xyz/docs/how-it-works#what-is-visible-onchain)
- [Deterministic ephemeral keys stay offchain](https://github.com/cloakedxyz/clkd-stealth/blob/9eb359efdd4ea31f5504bf81e57dcfe6f966dc14/src/shared/deriveDeterministicEphemeralKey.ts#L35-L68)
- [API permits repeated use; receive-once/spend-once is not enforced](https://clkd.xyz/openapi.json)

### Network observer

Recipient at risk (sentiment: warning)

**Who:** Sits between the user and the chain and sees web2 traffic only: RPC providers, relayers and broadcasters, indexers, ISPs. Learns IP addresses, timing, browser fingerprints, ciphertext and what becomes public. Assumes Tor to send transactions and, where the client has an RPC setting, an own node to read the blockchain. Examples: Infura or Alchemy, a Tornado relayer, a wallet vendor selling telemetry, Google captcha or analytics in the dapp frontend.

Every spend from the hosted client goes to a third-party relay, Porto, with the stealth address, destination and amount, which clusters your addresses per session even over Tor. The client is closed source, so what else reaches the RPC, hosting and analytics providers named in the privacy policy cannot be verified. Only the recovery tool runs without any server.

**Advice:** Derive your address keys with the recovery tool, which makes no network calls, and spend them from a wallet on your own node over Tor. Fund gas for token transfers from a fresh wallet, since sponsored execution is only available through the hosted client.

**Sources**

- [Client sends prepareCalls with address, recipient and amount to Porto RPC](https://github.com/cloakedxyz/clkd-stealth/blob/9eb359efdd4ea31f5504bf81e57dcfe6f966dc14/README.md#architecture)
- [CCIP-Read forwards the ENS query and verifies the returned answer](https://l2beat.com/privacy/projects/cloaked#OffchainResolver)
- [Disclosed metadata, relay data and external service providers](https://clkd.xyz/docs/privacy)
- [Recovery derives address keys locally without API calls](https://github.com/cloakedxyz/clkd-recovery/blob/b432a33873e2cfa4769807f8c95ed20a67234eed/src/lib/deriveKeys.ts#L31-L68)
- [Recovered keys are spent from any wallet; token sends need gas](https://github.com/cloakedxyz/clkd-recovery/blob/b432a33873e2cfa4769807f8c95ed20a67234eed/src/components/PostRecoveryGuide.tsx#L81-L106)

### Privileged insider

Recipient exposed (sentiment: bad)

**Who:** Holds a protocol operator role or receives keys or plaintext by design: upgrade admin, sequencer, decryption or view key holder, TEE vendor, association set provider, hosted prover, note registry. Examples: A compliance backdoor key, a DAO with an upgrade key, a KMS committee, an ASP operator.

Cloaked holds the viewing key, so it can regenerate every address and tie its activity to your account. Its Incognito relay states that it retains deposit-to-withdrawal associations, and the hosted wallet code handles your spending secrets.

**Advice:** Verify address derivations and transactions with an inspected local client. This protects your spending keys but does not remove Cloaked's view.

**Sources**

- [Viewing key and public spending key shared with the server](https://github.com/cloakedxyz/clkd-stealth/blob/9eb359efdd4ea31f5504bf81e57dcfe6f966dc14/src/client/deriveServerBoundKeys.ts#L16-L53)
- [Account-scoped addresses, quotes, submissions and pool state](https://clkd.xyz/openapi.json)
- [Privacy policy: retained pool associations and account data](https://clkd.xyz/docs/privacy)
- [Signature and expiry checks do not prove recipient control](https://l2beat.com/privacy/projects/cloaked#OffchainResolver)
- [Owner can replace gateway and signer](https://l2beat.com/privacy/projects/cloaked#permissions)
- [Hosted-client trust boundary](https://l2beat.com/privacy/projects/cloaked#upgrades-and-governance)

### Future adversary

Recipient at risk (sentiment: warning)

**Who:** Harvest now, decrypt later. Holds every byte ever written onchain plus any retained logs, and future cryptanalysis such as a large quantum computer that breaks elliptic-curve key exchange and pairings, but not hashes, symmetric ciphers or lattices. Examples: First well-funded insiders, then everyone in a potential post-quantum future.

No announcement is published, so a quantum computer cannot replay address derivations from the chain alone. The viewing key held by Cloaked exposes the history regardless. Accounts created from a wallet signature reduce to that wallet's key plus a four-digit PIN. Passkey PRF secrets do not follow from breaking the passkey.

**Advice:** Create your account with the passkey PRF setup, not from a wallet signature. Treat the address history shared with Cloaked as permanently disclosed.

**Sources**

- [Stealth signing keys mix the spending key with a hashed secret](https://github.com/cloakedxyz/clkd-stealth/blob/9eb359efdd4ea31f5504bf81e57dcfe6f966dc14/src/client/genStealthPrivateKey.ts#L17-L34)
- [Four-digit PIN and wallet address determine the signed message](https://github.com/cloakedxyz/clkd-stealth/blob/9eb359efdd4ea31f5504bf81e57dcfe6f966dc14/src/client/genCloakedMessage.ts#L15-L48)
- [Signature components are hashed into the account keys](https://github.com/cloakedxyz/clkd-stealth/blob/9eb359efdd4ea31f5504bf81e57dcfe6f966dc14/src/client/genKeysFromSignature.ts#L23-L42)
- [Independent secrets, including two WebAuthn PRF outputs](https://github.com/cloakedxyz/clkd-stealth/blob/9eb359efdd4ea31f5504bf81e57dcfe6f966dc14/src/client/genKeys.ts#L7-L67)
- [FIDO hmac-secret uses a separate random credential secret](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#sctn-hmac-secret-extension)
- [Operator data and retention](https://clkd.xyz/docs/privacy)

## Risk summary

### Funds can be stolen if
1. a user relies on the hosted wallet and it is malicious or compromised and exfiltrates derived spending keys. The production wallet is closed source and has no published reproducible build, so users cannot inspect its source or verify the code being served.
2. the accepted ENS signer returns an attacker-controlled payment address for a Cloaked name. The resolver authenticates the answer but does not prove that the intended recipient controls it.

### Funds can be lost if
1. a user loses the passkey and encrypted backup, or the wallet and PIN, needed to re-derive their private spending keys.
2. the service and client derive different address data and a payment is sent to an address for which the user cannot recreate the private key.

### Privacy can be lost if
1. Cloaked, or an attacker who obtains its viewing data, uses the service's viewing capability and index to link an account's stealth addresses and onchain activity.
2. spending from several stealth addresses together, reusing destinations, or recognizable timing and amounts links otherwise separate payments onchain.
3. a user relies on the Incognito balance, because Cloaked's relay observes the association between Privacy Pools deposits and withdrawals even though it is hidden from public onchain observers.

## Upgrades & Governance

Cloaked has no public onchain governance process for its hosted wallet, API, indexer, ENS gateway, or relay. These components can change without an onchain notice period. The production wallet is closed source and has no published reproducible build, so users who rely on it cannot inspect its source, verify which client code is deployed, or determine whether an update preserves the client-side spending-key boundary. Users can bypass the hosted frontend with an inspected local client, but this does not reproduce the other hosted components or prevent them from changing.

The deployed ENS `OffchainResolver` code is immutable, but its owner can immediately replace the gateway URLs and accepted signer or transfer ownership. The accepted signer can authenticate any offchain ENS answer, including a payment address. The resolver callback verifies only the signature and expiry; it does not verify stealth-address derivation or recipient control. The resolver owner and signer are currently the same EOA.

These powers affect new address generation and ENS lookups. They do not let the owner or signer spend from an existing, correctly derived stealth address because its private spending key remains with the user. Existing balances can be recovered independently with the published recovery client, but the full Cloaked experience does not remain available if the hosted service disappears.

## Updates

Each date links the update on the HTML page, which also shows its contract diffs.

### [2026-08-21 11:41 UTC](https://l2beat.com/privacy/projects/cloaked?update=e8d7eb25) (1 change)

Initial discovery of Cloaked's ENS CCIP-Read OffchainResolver and the EOA that controls its gateway and signer.

## Permissions

Explore these contracts and permissions in Disco, L2BEAT's contract explorer: https://disco.l2beat.com/ui/p/cloaked

### Ethereum

#### Actors

##### Cloaked Resolver Owner

Addresses: [0xDFc622F06EfDD0E830d82f30679A3C9302BC7940](https://etherscan.io/address/0xDFc622F06EfDD0E830d82f30679A3C9302BC7940)

- Can interact with OffchainResolver
  - change the accepted signer and gateway URLs immediately, or transfer resolver ownership
  - sign arbitrary offchain ENS answers, including payment addresses accepted by the resolver

## Smart contracts

![A diagram of the smart contract architecture](https://l2beat.com/static/images/architecture/cloaked.a10b0974.png)

Explore these contracts and permissions in Disco, L2BEAT's contract explorer: https://disco.l2beat.com/ui/p/cloaked

### Ethereum

#### OffchainResolver

Addresses: [0x77fEF66b77d6a44AeCcCCf911f9864c7b7ca392C](https://etherscan.io/address/0x77fEF66b77d6a44AeCcCCf911f9864c7b7ca392C#code)

Immutable ENS CCIP-Read resolver used by Cloaked. Every query redirects to a configurable API gateway and accepts the returned ENS record if it is unexpired and signed by the configurable signer. It does not verify that a returned payment address was derived for the named recipient.
- Roles:
  - **owner**: Cloaked Resolver Owner
  - **signer**: Cloaked Resolver Owner