{
"badges": [],
"description": "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.",
"detailedDescription": "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.\n\n### Stealth address generation\n\nUnder 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.\n\nFor 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.\n\nThe derivation SDK, API schema, and standalone recovery client are published. The recovery client can derive exportable stealth private keys without using the Cloaked API.\n\nThe 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.\n\nThe 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.\n\nThis 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.\n\nWhen 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.\n\n### ENS resolution\n\nCloaked 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.\n\nA 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.\n\nThe 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.\n\n### Privacy considerations\n\nCloaked'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.\n\nThe hosted service has the viewing capability and address index needed to link an account's stealth addresses and activity. Cloaked also integrates [Privacy Pools](/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.",
"links": {
"websites": [
"https://app.clkd.xyz"
],
"documentation": [
"https://clkd.xyz/docs",
"https://clkd.xyz/docs/ens-names",
"https://clkd.xyz/openapi.json"
],
"repositories": [
"https://github.com/cloakedxyz/clkd-stealth",
"https://github.com/cloakedxyz/clkd-recovery",
"https://github.com/cloakedxyz/account",
"https://github.com/cloakedxyz/clkd-privacy-pools"
],
"socialMedia": [
"https://x.com/staycloakedxyz"
]
}
}
colors+1-0
null
ecosystemColors+1-0
null
milestones+1-0
null
chainConfig+1-0
null
escrows+1-0
null
bridgeInfo+1-0
null
bridgeRisks+1-0
null
bridgeTechnology+1-0
null
scalingInfo+1-0
null
scalingStage+1-0
null
scalingRisks+1-0
null
scalingDa+1-0
null
scalingTechnology+1-0
null
daLayer+1-0
null
daBridge+1-0
null
customDa+1-0
null
zkCatalogInfo+1-0
null
interopConfig+1-0
null
privacyInfo+40-0
{
"attributes": [
{
"id": "stealthAddresses",
"label": "Stealth addresses",
"description": "Uses fresh, one-time recipient addresses to obscure who controls the receiving address."
},
{
"id": "anyAmount",
"label": "Any amount",
"description": "Deposits and withdrawals can have any size."
}
],
"exitWindow": {
"value": "Infinite",
"sentiment": "good",
"orderHint": 9007199254740991,
"description": "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.",
"walkawayTest": {
"passed": false,
"reason": "New payment-address generation, ENS resolution, address indexing, transaction construction, and relaying depend on the hosted Cloaked service."
}
},
"privacy": {
"value": "Admin view key",
"sentiment": "bad",
"description": "Cloaked holds a private, per-account viewing capability that lets its service derive and link every stealth address for that account. Its relay also sees both sides of Privacy Pools activity. This centralized visibility does not provide spending authority, and users can keep spending keys outside the closed-source wallet by using an inspected local client."
},
"reproducibility": {
"value": "Partially reproducible",
"sentiment": "warning",
"description": "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."
},
"riskSummary": "## Funds can be stolen if\n1. 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.\n2. 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.\n \n## Funds can be lost if\n1. a user loses the passkey and encrypted backup, or the wallet and PIN, needed to re-derive their private spending keys.\n2. 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.\n \n## Privacy can be lost if\n1. 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.\n2. spending from several stealth addresses together, reusing destinations, or recognizable timing and amounts links otherwise separate payments onchain.\n3. 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.",
"summaryTrackedItemName": "address",
"tokens": [],
"upgradesAndGovernance": {
"content": "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.\n\nThe 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.\n\nThese 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."
}
}
defiInfo+1-0
null
externalDependencies+1-0
null
tvsInfo+1-0
null
tvsConfig+1-0
null
activityConfig+1-0
null
livenessInfo+1-0
null
livenessConfig+1-0
null
costsInfo+1-0
null
trackedTxsConfig+1-0
null
daTrackingConfig+1-0
null
ecosystemInfo+1-0
null
ecosystemConfig+1-0
null
permissions+24-0
{
"ethereum": {
"roles": [],
"actors": [
{
"id": "Cloaked-Resolver-Owner",
"name": "Cloaked Resolver Owner",
"accounts": [
{
"address": "eth:0xDFc622F06EfDD0E830d82f30679A3C9302BC7940",
"type": "EOA",
"isVerified": true,
"name": "0xDFc6…7940",
"url": "https://etherscan.io/address/0xDFc622F06EfDD0E830d82f30679A3C9302BC7940",
"displayName": "Cloaked Resolver Owner"
}
],
"chain": "ethereum",
"description": "* Can interact with OffchainResolver\n * change the accepted signer and gateway URLs immediately, or transfer resolver ownership \n * sign arbitrary offchain ENS answers, including payment addresses accepted by the resolver ",
"discoveryDrivenData": true
}
]
}
}
contracts+22-0
{
"addresses": {
"ethereum": [
{
"name": "OffchainResolver",
"isVerified": true,
"address": "eth:0x77fEF66b77d6a44AeCcCCf911f9864c7b7ca392C",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"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.\n* Roles:\n * **owner**: Cloaked Resolver Owner\n * **signer**: Cloaked Resolver Owner",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x77fEF66b77d6a44AeCcCCf911f9864c7b7ca392C#code"
}
]
},
"risks": []
}