Search for projects by name or address
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.
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.
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.
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.
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.
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 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.
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.
Transparent proving systems require no trusted setups and have no additional setup-related trust assumptions.
Discovery rerun on the same block number with only config-related changes.
Discovery rerun on the same block number with only config-related changes.
| + | Status: CREATED |
| contract OffchainResolver (eth:0x77fEF66b77d6a44AeCcCCf911f9864c7b7ca392C) [N/A] | |
| +++ description: 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. |



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.