On 2026-07-21, I looked at 5.062M accounts that have been active on Bluesky / the Atmosphere in the last 30 days.
This is an update to a similar census I did about 7 months ago.
I found the following users who have strong control over their identity via rotation keys or other mechanisms:
270 users on Bluesky servers with their own rotation keys
13,201 users on third party multi-user servers with their own rotation keys
1,293 users who probably don't need additional rotation keys because they are on their own PDSes
265 users who don't need a rotation key because they are using did:web
In total, I found 15,029 recently-active users (0.299%) who have strong control over their identity.
This is an increase of about 10x over my earlier census, in which 0.036% had such control. Most of this growth is due to accounts on multi-user third-party PDSes, and can probably be attributed to PDS migration tools helping users create rotation keys as part of migration: 96.4% of users with their own rotation keys on multi-user third-party PDSes have performed at least one migration.
What is a rotation key, and why have one?
Most accounts on Bluesky and in the Atmosphere use a standard called did:plc for identifying accounts.
Updates to did:plc identities are managed via cryptographic keys known as rotation keys. These are public/private key pairs, and the holder of the private half can use it to sign updates to the identity such as changing its handle or moving it to a different data server. All accounts will have at least rotation key, managed by their PDS server, and may optionally add other rotation keys under their own control.
User data on Bluesky and in the Atmosphere are stored in servers called PDSes. Each account is hosted on one PDS, and a PDS can host many accounts. In current practice, the vast majority of accounts are hosted on PDSes operated by the company Bluesky PBLC, though a growing number of users are on other PDSes, such as Blacksky, Eurosky, Northsky, and others. These PDSes, apps, and other services are collectively known as the Atmosphere.
atproto, which the Atmopshere is built on, supports migrating accounts between PDSes without losing data or changing your identity. This is normally done by downloading your data (in a "CAR" file) from the old PDS, uploading it to the new PDS, and asking your old PDS to use its rotation key to record that you have moved.
atproto also supports "adversarial migration" in which you are able move without the cooperation of your old PDS - perhaps because it has gone down, or because it has become hostile and does not wish to let you move.
In order to use adversarial migration, you need to have - ahead of time - a recent backup of your data and a rotation key that is controlled by you, not your PDS.
Thus, this census gives us an idea of how many users might be prepared to use adversarial migration if needed. In addition to having a rotation key, they must also have a recent CAR file, and must have securely kept track of the private half of their own rotation key.
How can I tell if I have my own rotation key?
To use a rotation key, you need to keep track of the private half of the key. So, if you are not sure, you effectively do not have one.
You can look at an account's rotation keys by looking up its handle at https://pdsls.dev/ and checking under the "identity" tab
How do I set up my own rotation key?
There are a number of web-based tools that make it easy to add a rotation key to your identity. They include:
Note that in order to be able to use your rotation key, you need to:
Keep track of the private key! Keep it safe, and treat it like a password
Regularly take backups of your repo by downloading your CAR file. This can be done using tools such as:
... and more
Methodology and additional details
I've been running a service that listens to the firehose on four different relays: It keeps track of the last time each did created any records (posted, reposted, liked, followed, unfollowed, blocked, etc.) This is the source of my 'recently active users' list: I looked at all dids that had been active in the previous 30 days.
For each of these users, I used a local replica of https://plc.directory/ to look at rotation keys and PDSes for each account.
Overall, I looked at 5,061,238 accounts, though the denominator for most percentages is 5,027,444 for reasons explained below. 94.15% of all accounts were on Bluesky PBC's servers; with the correction explained below, 94.15% of accounts considered on are Bluesky servers.
The Bluesky PDSes use the same two rotation keys for all DIDs. If you do not add a rotation key, Bluesky can theoretically prevent you from moving your account elsewhere. Some types of account takedown, for example, prevent migration.
I looked for strong ownership over identities on the Bluesky PDSes by looking for did:plc identities on those PDSes with at least one additional unique rotation key.
Accounts on solo PDSes
I found 1,293 accounts on solo PDSes (PDSes with only one active user). This is 0.0257% of accounts I considered. Of these, 186 (14.39%) have multiple rotation keys.
If a PDS hosts only one repository, we can probably assume that it is self-hosted or otherwise under the control of its sole user, and we can assume that the user will be able to keep control of their identity.
The reference PDS uses a single rotation key for all accounts. It is still useful to add another, so that if all data from the PDS is lost (including the private half of its rotation key), the user still has a way to keep control of their identity.
Accounts on multi-user PDSes
I found 260,481 accounts on multi-user PDSes (5.18% of accounts considered). Of these, 13,201 (5.07% of multi-user PDS accounts) have strong ownership of their identities
PDSes operated by entities other than Bluesky still carry potential risk, with the risk simply shifted to another party. Thus, it is still a good idea to have your own rotation key even if you are on a third-party PDS.
In most cases, most or all users on multi-user PDSes have the same rotation key, controlled by the PDS. I identified users with stronger control over their identities by looking for users on these PDSes that have additional, unique, rotation keys not shared by any other users on their PDS.
Users on third-party multi-user PDSes are currently much more likely to have custom rotation keys than those on Bluesky's PDSes. This is probably due in part to these users being more aware of the functioning of the protocol and having heightened sensitivity to issues of distributed identity. I would also attribute this to some of the PDS movers having built-in features to add personal rotation keys as part of the process, which I think is an excellent feature.
Accounts using did:web
I found 265 accounts using did:web (0.00527% of accounts considered)
did:web is an alternative way of managing your identity that uses a different method for claiming ownership - we can assume that these accounts have strong ownership over their identity.
If you are not sure whether your account uses a did:web, then it does not. It is not currently possible to migrate from a did:plc identity to a did:web (or any other type of did) identity.
Unusual cases
I found 33,794 identities that fell into special cases that I excluded from the totals (0.666% of all identities)
In particular, the Bridgy Fed PDS seems to handle rotation keys differently than most other PDSes, in that it gives all users two rotation keys, and these rotation keys are unique to the account.
On the one hand, I know of no way for Bridgy Fed users to control rotation keys (or other aspects of their accounts), so users do not have strong control of their identity. On the other hand, these are accounts bridged in from other networks, so the repos on Bridgy Fed are not the authoritative source of information for these accounts anyway. I thus exclude them from my counts.
There were 410 other DIDs that I had trouble classifying due to being on PDSes that may or may not use individualized rotation keys, but I could not tell.
In addition, 8,270 did:plc accounts did not seem to have usable rotation keys and/or PDS service records at all; they may have been deleted.