What actually happens when you secure an account
You paste a credential and a few seconds later the account is yours. In between, six phases run in a fixed order — and the order is most of the point.
"Autosecure" sounds like a single action. It is a pipeline. This post walks the whole thing, in the order it actually executes, because understanding the order explains most of the design decisions that look arbitrary from outside.
Four ways in, one pipeline
Accounts arrive in different states, so there are four entry methods. They converge on the same pipeline immediately — the difference is only how the first phase gets authenticated.
- MSAuth — you already hold a Microsoft token. The fastest path, because authentication is already solved.
- OTP — you control the inbox and can read a one-time code out of it. No password required.
- Recovery — you hold the Microsoft recovery code. This is the path for accounts locked out of their own email.
- Zygercode — full credentials: email, password, and a TOTP seed. The most complete starting position.
Which one you use is dictated by what you have, not by what you want. An account you hold a live token for and an account you hold only an inbox for genuinely need different front doors.
The six phases
Auth
Establish an authenticated session with Microsoft using whichever credential you supplied. Everything downstream is a mutation on a live session, so if this fails, nothing else runs — and it fails early and loudly rather than half-securing an account.
Data
Read the account's current security state before touching anything: existing two-factor status, registered devices, aliases, recovery routes, pending changes. This is the snapshot every later decision is made against.
It also matters for a subtler reason — an account that already has 2FA enabled by someone else needs a different plan from one that has none, and you cannot tell which you have without looking first.
Profile
Resolve the Minecraft identity behind the Microsoft account: the username, the profile, whether there is a Java entitlement at all, and the stats used for valuation. Profile matching rules run here, so a flow can be conditional on what the account actually turns out to be.
Gather
Collect everything that must be captured before mutations begin. Once the locks change, some of this becomes unreadable — so the order is not stylistic, it is a hard dependency.
Secure
The phase that changes things, and the one worth reading closely. It gets its own section below.
Finalize
Persist the account, render its stats card, fire notifications, and hand the record to the dashboard. Stats images render from the stored summary rather than a fresh upstream call — a card built from a failed live fetch is a flawless layout full of zeroes.
Inside the secure phase
Enabling two-factor authentication is one line in a much longer sequence, and it is not the first one.
Device removal starts first. Registered trusted devices bypass the very protection you are about to add. Removing them after enabling 2FA leaves a window — and worse, leaves a permanent bypass if the removal then fails. So the secure phase either confirms devices are already gone or waits on the removal task before it makes any security mutation at all.
Then, with the account's trusted hardware cleared:
- Alias and recovery routing.The email routes that can reset this account get moved to addresses you control. An account whose recovery still points at the previous owner's inbox is not secured; it is on loan.
- Two-factor enrolment. A TOTP secret is provisioned and confirmed, and a recovery code is captured and stored. If the recovery code cannot be obtained, the flow adjusts its info-swap strategy rather than continuing as though it had one.
- Session invalidation. Every existing sign-in is revoked. This is the step that actually evicts anyone already inside, and doing it before the new lock exists would simply let them log back in.
- Metadata. Remaining profile and security details are brought in line with the new ownership.
What happens when a step fails
Real runs fail partway. Proxies drop, Microsoft rate-limits, an account turns out to be in a state nobody has seen before.
Two rules govern this. Failures are recorded per field rather than collapsed into one boolean — an account that got 2FA and sessions but not an alias swap is a different situation from one that got nothing, and the record says which. And an attempt that never became a real account is cleaned up rather than left as debris, which is why the abandoned-flow cleanup path is a genuine hard delete while the dashboard's own delete button routes through a seven-day recycle bin.
There is also a reaper. A flow whose process dies mid-run leaves a session row marked in-flight forever; a startup sweep marks those expired instead of letting them accumulate as permanent phantoms.
Bulk runs share fairly
Securing several hundred accounts at once is normal. The naive implementation lets one large job consume all capacity while everyone else waits.
Bulk work goes through a shared scheduler with a global concurrency cap, allocated fairly per user. A thousand-account job and a three-account job run at the same time, and the small one does not sit behind the large one.
After it finishes
The account lands in your dashboard with its credentials, its recovery code, a live two-factor code, its stats and computed value, and its recovery inbox. From there it can be shared as a public page without pasting anything into a chat window, listed on the marketplace, or handed to a Discord bot to distribute.