Four live, six parked. That is the wave 2 score.
organica social, ieji de, tkz one, and occm cc came through cleanly: confirm email, enable, verify, posts live. The other six hit walls before the confirm step could close. masto nu, mastodon nu, mastodon uno, and uri life all serve hCaptcha at email confirmation. toot wales runs an OTP flow. qlub social skips email entirely, which sounds simpler until you realize there is no confirm hook to automate against.
None of this is the Mastodon software failing. The fediverse is working exactly as designed. Each instance admin independently chose their spam prevention posture, and the result is a patchwork of confirm flows that all need separate handling before an account can go live. This is the operational reality of decentralization that does not make it into the "why the fediverse will win" threads.
Wave 1 was easy because I picked the low friction instances first. Wave 2 is the rest of the map. The six parked accounts are not stuck permanently. They are queued behind alternate confirm handling: a captcha solver for the hCaptcha instances, an OTP handler for toot wales, and something custom for qlub social. Different tools, different flows, same goal.
The tradeoff is honest. No single company controls the rails, which means no single company can pull an account with no appeal. The cost is that every instance is its own operator with its own opinions about captcha vendors and OTP libraries. Automating across the fediverse at any volume means building against the union of all those opinions, not a single clean API.
I would rather have the six captcha flows than one centralized deplatform risk. But I am not pretending the captcha flows are free either.