On 2025-12-7, I looked at 4.1M accounts that have been active on Bluesky / the Atmosphere recently.
I found the following users who have strong control over their identity via rotation keys or other mechanisms:
157 users on Bluesky servers with their own rotation keys
262 users on third party multi-user servers with their own rotation keys
997 users who probably don't need additional rotation keys because they are on their own PDSes
73 users who don't need a rotation key because they are using did:web
In total, I found 1,489 recently-active users (0.036%) who have strong control over their identity.
Custom rotation keys are uncommon on Bluesky PDSes (0.0034% of users), and somewhat more common on third-party multi-user PDSes (2.38% of users)
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, 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 done, 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 have been running a service since 2025-11-19 that listens to the firehoses on the Bluesky and Blacksky relays, keeping 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.
For each of these users, I fetched the audit log for the did from https://plc.directory/. I look at the set of keys in the most recent non-nullified log entry.
Since it took me a week to fetch audit logs this way (next time I do this I will probably just mirror the PLC), when I was done I used https://plc.directory/export?after to find all the PLC entries that had changed since I started and re-fetched their audit logs. There was a post on Bluesky during this time period with significant reach that encouraged people to set up rotation keys, so I thought it important to make sure to catch anyone who added keys as a result of that post.
Overall, I looked at 4,127,472 accounts, though the denominator for most percentages is 4,105,837 for reasons explained below. 99.18% of all accounts were on Bluesky PBC's servers; with the correction explained below, 99.7% of accounts considered on are Bluesky servers.
Accounts on Bluesky PBC's servers (PDSes)
I found 157 accounts on Bluesky servers with strong ownership of their identities (0.00384% of the 4,093,781 accounts on 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 997 accounts on solo PDSes (PDSes with only one active user). This is 0.0243% of accounts I considered. Of these, 91 (2.38%) 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 10,986 accounts on multi-user PDSes (0.268% of accounts considered). Of these, 262 (2.38% 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 73 accounts using did:web (0.00178% 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 21,635 identities that fell into special cases that I excluded from the totals (0.52% 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 21 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.
Code and Data
The code used for this census can be found in the are-we-decentralized-yet git repository on tangled, codeberg, and github
CSV files with classification of:
DIDs (main file)