Preparing a bought Telegram account

Most accounts are lost in the first hour, not the first month. A purchased account changes hands with the previous holder still knowing everything needed to take it back, and the usual reaction - log in, look around, start working - burns the two advantages you have: the ability to audit before anything moves, and the ability to walk away before you have invested in it.

What follows is an order of operations. It is worth reading before you buy rather than after, because two of the steps depend on things you must have ready in advance.

What you are actually buying

A Telegram account is not a username and password. It is a set of authorizations - long-lived keys, one per device that has ever signed in - attached to a phone number that a carrier still controls. Buying the account means buying one of those keys. It does not mean the others stopped working, and it does not mean the number is yours.

• Sessions you cannot see yet - in two different senses. Every device the seller used holds its own key, and the sale revokes none of them. And the key you were handed is itself a copy: the seller kept the original, and it does not appear as a second row in the device list - it is the same row.
• A cloud password that may already exist, set by someone else, with a recovery address pointing at their mailbox.
• A sign-in email, if one was attached - a second, separate address that receives every login code, with no SMS involved. It survives everything below unless you look for it.
• The number's real owner, who is whoever can receive its SMS - which may be the seller, an SMS-rental service, or the person the account was taken from.
• A history: chats, groups, whatever the account did before you, and whatever complaints that behaviour attracted.
• A device identity baked into the key, which is why the delivery format matters - see tdata and session formats.

The job of intake is to reduce that list to: one key, minted by you and held only by you; one password, set by you; one recovery address and one sign-in address, both in your mailbox. Anything left over is someone else's claim on the account.

Have the proxy ready before the first login

This is the step people do last and should do first. The very first connection an account makes under your control sets the network pattern for everything after it, and connecting once from your office IP or a random VPN is not undone by fixing it later.

1. Buy a static dedicated proxy in the country of the account's phone number before the account arrives. Not a rotating pool, not your own connection - see which proxies to buy.
2. Verify the exit: confirm the country and check the address against a reputation service while a refund is still possible.
3. Only then attach the proxy to the account, and let the first connection go through it.

The first session: import, do not explore

Import the account through the platform rather than signing in manually somewhere first. A tdata archive carries the device identity the account was built with, and importing it preserves that key instead of minting a new one; a fresh sign-in from an unfamiliar client announces a new device on an account that has just changed hands, which is precisely the pattern that draws attention. Preserving the key is the right move for the first hours - it is not the permanent arrangement, because the key you preserved is a copy of the seller's. The sessions section deals with that.

Then leave it alone. The temptation is to read the chats, check the username, join something. Every one of those actions is an action on an account whose ownership you have not yet secured - and if the previous holder is still watching, you have just told them the account is live and worth taking back.

Keep one driver. Two tools operating the same key at once produce the duplicate-key error and can invalidate the authorization outright - the reasoning is under one key, one driver.

Sessions: the list shows devices, not copies

This is the step that decides ownership, and the one most often skipped because the account appears to work without it. It does work - for the seller too. But “clean up the sessions” hides two different problems, and only one of them is in the list.

Other guides point here instead of repeating any of it, so the whole handover lives in this one section: what you can evict, what cannot be evicted at all, and the numbered order that ends shared access. Two things sit outside it and neither is optional - the proxy is attached before the first connection, and afterwards the account goes into quarantine rather than to work.

Other people's devices: visible, and evictable

Open the account's active sessions and terminate everything except the one you are working from. Do not try to guess which entries are harmless: a session you cannot account for is by definition not yours. If the list is long or the device names are unfamiliar, that tells you something about how the account was kept. What this settles is other people's devices and only that: the copy of the key you are holding is not in the list at all, which is what the next block is about.

A copy of your key: not in that list at all

The file you were sent is the authorization itself - tdata and session strings are the key in a wrapper - and sending such a file copies the key rather than moving it. The seller kept the original, and the original and the copy are the same key. That is why the device list shows one row while two people use the account: from the server's side there is no second sign-in to display. No code was entered, no password was asked, no key was minted, and the device count does not move. So the advice everybody repeats - terminate the sessions you did not create - is right about other people's devices and blind here: it has nothing to terminate. The only row carrying the problem is the one you are sitting on.

There is a sharper edge to this. Telegram delivers login codes into Telegram: while the account has a live session, the code arrives in the service chat, inside the app. A copy of the key is therefore not just read access to the history - it is a seat where the codes land. Whoever holds it can read the code produced by a sign-in attempt on the number without ever touching the number, and both of the doors a code opens - account deletion and password reset - are then open to them.

Replacing the key: the order that ends shared access

A copy cannot be taken back, only made worthless. Revoking an authorization kills every copy of it at once, so the order is: get a key of your own first, revoke the shared one after.

1. Evict the devices you can see, from the session you were given. That session is normally old enough to be allowed to do it; an authorization minted minutes ago is not, as the note above says. It clears other people's devices and settles nothing about ownership - the copy of the key in your hands is not in that list.
2. Make the cloud password yours first - the next section covers how. A QR sign-in on a protected account still asks for the password, so this cannot be postponed; and if a password is set and the seller will not hand it over, stop here and read when to write the account off.
3. Mint your own authorization by QR login from the session you already have. The existing session approves the new device, so no code is sent to the number or to any mailbox - there is nothing to intercept. It is the same mechanism that sits behind exporting an account: import preserves, export mints.
4. Move the work onto the new key and stop driving the one you were given - one driver per key, as always (one key, one driver).
5. Wait about a day. An authorization younger than roughly 24 hours is not allowed to terminate other sessions, and there is nothing that buys that time back.
6. Then revoke the authorization you were given. That is the moment the seller's copy stops working, because it is the same key. Nothing you did before that moment removed their access.

Yes, this adds a device to an account that has just changed hands - the pattern the first session section tells you to avoid. It is a real cost, paid once, and it buys the only thing that ends shared access. Skipping it is a choice too, and it deserves to be stated plainly: the account stays shared with whoever holds the file, for as long as it lives. If the same file was sold more than once, the consolation is that one revocation evicts all of them at once - what dies is the key, not the person.

Take the password, both addresses - and the key

Three separate claims have to end up in your hands, and taking two of the three is the usual way an account is lost. The key is the section above. The password, with the recovery address behind it, is this one. The sign-in address is the one people find last, if they find it at all. Each of the three is enough on its own to hand the account back to somebody else.

A cloud password is what stands between a stolen SMS code and a lost account, so it has to be yours rather than merely changed. The distinction is not cosmetic: changing an existing password leaves the previous owner's recovery email attached, which leaves them a path back in. Remove the password entirely, then set a new one from scratch, then attach your own recovery address by hand.

Then look for the second address, the one this step is usually named after only half-correctly. A sign-in email is not the recovery address and is not touched by anything you just did: it receives every login code directly, so a seller who kept it keeps a working way in. Worse, a login code on its own is enough to lose the account outright - the cloud password is never asked for that - so this address outranks the password you just set. Replace it, or accept that the account is borrowed.

That code opens two doors, not one, and the second is the quieter of them. The first is account deletion: the account is erased and the number goes free. The second is a password reset - the same code, no password, then a seven-day wait, at the end of which two-step verification is switched off, every session on the account is signed out - yours included - and the account is handed over whole, with its history, its channels and its warming intact. Account deletion destroys what you paid for; the password reset takes it over. That is the real reason the address receiving the codes outranks everything else on this page, and the reset is worth reading in full where it is owned: seven days the account will not mention.

The order is not free either: the password has to be yours before you can mint a key of your own, and the key has to be yours before the account is. So the sequence runs - read the current state, evict the devices you can see, replace the password, attach your recovery address, mint your key, wait the day, revoke the key you were given, replace the sign-in address. The eviction sits early because it is device hygiene rather than ownership: it removes other people's devices, never the copy of yours. The sessions section writes the handover out step by step.

The mechanics, the quarantines Telegram imposes afterwards, which of the two addresses the platform can move for you and which it cannot, and what a sign-in stalling at the password prompt means are all covered by the guide that owns this subject: the cloud password, and specifically the sign-in email.

Quarantine: the part that feels like doing nothing

With the key exclusive and the password yours, the account still should not go to work. Give it a quiet period in which it exists, connects through its proxy and does nothing else. Two things are being tested. First, whether anyone tries to take it back: a reclaim attempt usually comes early, and it is far better to meet it on an idle account than on one carrying live conversations. Second, whether the account is under a restriction the seller did not mention and you have not yet triggered.

How long is a judgement call and the market's advice on “aging” is folklore rather than method - the honest treatment is under aging is a market term. What is not a judgement call is the sequence: quarantine after taking ownership, never before, because a quiet account you do not yet control is just an account someone else can still reach.

• Watch the account's own chat list, not a mailbox. A takeover in progress announces itself exactly once and then goes quiet: when a password reset is requested Telegram says so in a service message from Telegram, inside the app - that is the only place we have ever seen it arrive - and after that the seven days simply pass, the account working exactly as before, right up to the minute the password comes off and the sessions die. If that notice appears and the request was not yours, decline the reset from a session that is still signed in; the notice carries the button. Declining removes that request. Whether the same person can arm another one, and how soon, we have not measured - so treat it as time won rather than a door closed.
• Watch for sessions reappearing - a session you did not create showing up again means the number is still delivering codes to someone else.
• Watch for a freeze or restriction landing without you doing anything, which points at history you inherited rather than behaviour you caused.
• Do not add the account to campaigns, do not send the first message, do not join anything on a schedule.

Hand it to warming, not to production

After quarantine the account still is not a working account. It is an account with an unknown behavioural baseline, a new network and a new operator, which from Telegram's point of view is close to a fresh registration regardless of its age. Treat the first weeks as warming, let the caps and windows apply, and read the action journal rather than assuming silence means health.

This is also where the economics of buying quietly collapse. The premium on an aged account is sold as skipping the ramp, but the ramp still has to happen: new device, new proxy, new behaviour. What you actually bought was the registration date, not a shortcut.

When to write the account off

Some accounts should be abandoned rather than rescued, and the cheapest moment to decide that is before you have invested weeks of warming and a live conversation history. Any of the following is enough on its own:

• Sessions you terminated come back. Someone else can still authorize, which means they can still receive codes. Nothing you do inside the account fixes that.
• A sign-in reaches the password prompt and stops. The code was obtained and used by someone who is not you; the password is all that held - and holding buys time rather than safety, because the move available to them next is the password reset. Treat it as a deadline: a sign-in stopped at the password.
• A cloud password is set and the seller will not give it to you. Then you cannot mint a key of your own - a QR sign-in asks for that password too - so you can never stop sharing the key you were handed. Sitting out the seven-day password reset is not a way around it either: a reset can be declined from any session that is still signed in, and the seller's copy of the key is one.
• The seller can still reach the recovery email or the sign-in email and will not or cannot detach it.
• The account arrives frozen or restricted, or becomes so during quarantine without any action from you - see frozen, banned, restricted.
• The number's country has no matching proxy you can actually buy.

Writing off a cheap account early is a smaller loss than discovering the same facts later with a warmed reputation and your customers' conversations inside it. That asymmetry - low price, high consequence - is the whole argument for registering your own instead.