← back to blog

how to run multiple Nostr accounts safely in 2026

how to run multiple Nostr accounts safely in 2026

running multiple Nostr accounts looks deceptively simple because Nostr identity is just a keypair. you generate a new private key, you publish from it, and on paper you have a new identity. no signup, no email, no centralized account graph that links you to your other identities.

in practice, multi-account on Nostr is more complicated than that because the relay layer and the client layer add detection signals on top of the bare protocol. relay operators see your IP. clients send fingerprint data. zaps (Lightning Network tips) carry routing patterns that can correlate identities. this guide covers what actually links Nostr accounts despite the keypair model and the cloud phone workflow that holds up.

what is and is not linked at the protocol layer

at the pure Nostr protocol layer, two pubkeys are unrelated. the network does not know they belong to the same person.

what is linked above the protocol:

relay-level visibility. the relays you publish to see the IP you publish from. if multiple pubkeys publish from the same IP to the same relay, the relay operator can correlate them. some relays log this; some do not.

client-level fingerprint. Nostr clients (Damus, Amethyst, Primal, web clients like iris.to or snort.social) send device fingerprints to backend services. if you use the same client to access multiple identities, those backends may correlate.

posting style and content. humans reading your posts can correlate identities by writing style, topic, time of posting, and reference patterns. NLP-based attribution is not science fiction.

zap routing. Lightning Network zaps reveal payment routing information. if multiple Nostr identities receive zaps to addresses connected to the same Lightning node or LSP, they get correlated.

follower graph overlap. if your Nostr identities mostly follow the same people and are followed by the same people, the graph correlates them.

why common shortcuts fail

generating a new key in the same client. the new key is unrelated cryptographically, but the client and the IP linked to it are the same. correlation happens above the protocol.

using a VPN. changes IP at the relay layer but does not address client fingerprint or follower graph.

switching keys in the same browser tab. the browser fingerprint stays the same. clients that store metadata locally can leak identity correlation when keys are switched.

zapping yourself across identities. Lightning Network routing can reveal common nodes or LSPs. self-zapping creates a routing trail.

the right approach: one cloud phone per Nostr identity

the setup that addresses the relay, client, and behavioral layers:

1. one dedicated cloud phone per Nostr identity
2. each cloud phone on a real mobile carrier IP, fresh per identity
3. distinct Nostr client per identity (Damus on one phone, Amethyst on another, etc.) or at minimum fresh installs per identity
4. distinct Lightning wallet per identity, ideally on different LSPs
5. distinct posting style and follower graph
6. zero cross-engagement (no zapping, replying to, or following yourself)

cloud phones solve the device, IP, and client-fingerprint layer in a way that switching keys in one app cannot.

for a deeper comparison of cloud phone tools, see cloudf.one vs Geelark.

step-by-step: setting up multiple Nostr identities

step 1: provision one cloud phone per identity

real mobile SIM per phone.

step 2: install your chosen Nostr client fresh on each phone

if you want to use Damus across all of them, install fresh on each phone. ideally vary the client across identities (Damus on one, Amethyst on another) to add another layer of separation.

step 3: generate keys on each phone separately

generate the keypair on the device that will host that identity. do not generate keys on one machine and import them across many phones; that creates a paper trail.

step 4: connect a distinct Lightning wallet per identity

each identity should have its own NWC connection or self-custody wallet. shared LSPs across identities create routing-level correlation.

step 5: build follower graphs independently

follow people who match each identity’s interests. avoid following the same set of people across all your identities. real Nostr users have differentiated follow patterns.

step 6: do not cross-engage

your identities should not zap each other, reply to each other, or follow each other. cross-engagement is the cleanest correlation signal in the entire stack.

the relay choice question

different relays have different operator philosophies. some are public, well-resourced, and minimally logged. others are private, paid, and more selective. for multi-account work, varying which relays each identity publishes to adds resistance to operator-side correlation.

a few practical guidelines:

• do not publish from all your identities to the same small set of relays
• include some larger public relays in each identity’s relay list
• if using paid relays for one identity, use different paid relays for others
• avoid publishing the same content to the same relays from multiple identities back to back

behavioral hygiene

what signals separate real Nostr users:

• different posting styles
• different topic interests
• different active hours that match the device’s time zone
• different follow graphs
• different zap patterns

what signals an operator:

• identical posting style across identities
• same topics and same opinions
• same time-of-day posting bursts
• 80%+ overlap in follows
• frequent zapping of self across identities

try a cloud phone for Nostr multi-identity

if you want multiple Nostr identities that survive both protocol-level and meta-level correlation, real device and real mobile carrier IP isolation per identity is the foundation.

cloudf.one provides cloud phones with real SIMs accessible through a browser dashboard. each phone is a real device, on a real mobile carrier IP, permanently assigned to one Nostr identity. you can start a free trial and confirm the setup before scaling.

we cover the broader multi-account framework in how to run multiple TikTok accounts from Singapore, which applies the same isolation principles.

frequently asked questions

isn’t Nostr meant to be uncensorable, so why does multi-account hygiene matter?

uncensorable at the protocol layer, yes. but relays can refuse to host you, clients can apply spam filters, and humans can ban your pubkey from their feeds. multi-account hygiene matters because operators who run sloppy multi-identity setups get filtered out at every layer above the protocol.

can a relay actually link my Nostr identities?

if multiple pubkeys publish to the same relay from the same IP, the relay operator can correlate them by reading their own logs. whether they choose to is up to them. for serious multi-account work, do not assume relay operators will not.

does using a different client really matter?

different clients have different fingerprints and connect to different backend metadata services. using the same client across all identities creates one more correlation channel. varying clients adds another layer of separation.

what about using a single Lightning node for all my identities?

if you receive zaps to the same node, routing patterns can correlate the identities. for low-stakes anonymity, one node is fine. for serious operational separation, separate wallets and ideally separate LSPs per identity.

is Nostr stricter than other federated platforms on multi-account?

stricter at the protocol layer, no, the protocol is permissive. stricter at the social layer, yes, because Nostr’s culture values authentic single-identity participation more than most platforms. operators who get noticed running many identities lose social credibility quickly.