Xenon vs VaultCord: the alternative with no OAuth gate

VaultCord and Xenon both back up a Discord server, and the feature lists make them look like the same product at different prices. They are not. The two differ on what they need from you before they can work, and that is the comparison worth making.

Start with the thing VaultCord leads on, because it is real and Xenon does not do it.

What member recovery actually is

VaultCord restores members. Xenon does not, and no tool confined to Discord’s bot APIs can: there is no endpoint that moves an account from one server to another. Lose a server with Xenon and you get the channels, roles, permissions and settings back on a new one, then send everybody an invite.

The way VaultCord does it is worth understanding before you decide it settles the question. In its own words, member recovery works through “OAuth2 member verification”: members verify through an OAuth2 flow when they join, and the authorizations are stored. If the server is lost later, those stored authorizations are replayed and the members are added somewhere new.

Three things follow from that.

It is a gate, not a backup. Nothing about the restore reads a snapshot of your server. It reads a list of people who granted an application permission to add them to servers, possibly a year earlier. That means it only ever covers members who joined after you installed the gate and who completed it. Turning it on the week you need it recovers nobody.

The permission outlives the visit. Each member has granted a standing “add me to servers” authorization to a third party, and it stays granted until they go and revoke it. Most people will never think about it again.

And it does not cover a banned user. Discord refuses an OAuth2 join for anyone currently banned in the target server, so the members you most want back after a raid, the ones a hostile admin banned on the way out, are the ones this does not return.

None of that makes the feature worthless. It makes it a trade, and a reader deciding between the two should see the trade rather than a checkmark.

The credentials you hand over

Xenon is an application on Discord. You add it the way you add any bot. There is no developer account involved, nothing to register, no token to generate.

VaultCord’s custom bots work the other way round. You open Discord’s Developer Portal, create an application, add a bot to it, and hand the credentials over. Their own API documentation is explicit about which ones: the endpoint that creates a custom bot takes a name, an OAuth2 clientSecret and a Discord token. Their security guidance also tells you to add the bot to a team through the Developer Portal, something only possible for an application you own.

Their security guide is better than most on this point: it tells you the bot does not need Administrator, and that Manage Roles and Create Invites are the only permissions it wants.

It does not change what the credentials are. A token and a client secret are not a login to a dashboard, they are the bot, so it now exists in two places at once, your Developer Portal and someone else’s infrastructure, and rotating it after a leak is your job rather than theirs. The application is registered to your Discord account, which makes you its developer of record under Discord’s terms and puts your account in front of any enforcement action, while the service keeps running on everybody else’s applications.

The FAQ also leaves out a step. Reading message content or member data needs Discord’s privileged intents enabled on your application, by you, in the Developer Portal. VaultCord’s covers the redirect URL, the token and two Discord permissions, which are a different system entirely; intents are not mentioned. Miss it and nothing tells you. The bot connects, the backup runs, and the message content comes back empty, because the gate applies to the REST API a backup reads through and not only to the live gateway. You find out when you restore.

Past 10,000 reachable users the switch is not yours to flip. Since June 2026 you apply and Discord decides. Xenon’s two intents were applied for and approved on our application, so that review happened once, here, instead of once per customer.

The comparison page sets this out in full, with both alternatives side by side.

Their security guide is a ban-evasion guide

VaultCord’s help center has a page on securing your bot, and it states the model’s stakes in four words: “bot gone = members gone.”

Six steps follow. Two are ordinary: do not grant Administrator, and add the bot to a Developer Portal team so losing your account does not lock you out of the application. Step five is not ordinary.

It tells you to build the bot on an alt account, then how to hold that alt account: “If your main account gets terminated and you log into your alt account, Discord may flag it for ban evasion.” It recommends a different device, a VPN and an antidetect browser, the last two linked by name.

Ban evasion is VaultCord’s phrase, and Discord uses the same one. Community Guideline 19 prohibits evading permanent Discord-level enforcement by creating new or using existing accounts after removal. An antidetect browser exists to run accounts a platform has decided it does not want. So step five reads as a set of instructions for surviving the enforcement action Guideline 19 describes, and the customer carries out every one of them.

Step six is about what you tell your own members. It asks you to keep phrases like “verify in case of termination” and “verify so we can pull you if our server gets deleted” out of your verification message, and to “use clear and neutral language to avoid raising red flags.”

It is the only step that asks something of your members rather than of you, and Discord’s rules have a good deal to say about that particular message.

The feature is allowed. Their guide is what breaks it.

Pulling members back runs on guilds.join, a documented OAuth2 scope with a documented endpoint, and using it is permitted. The scope’s only stated condition is that the bot already belongs to the server it is adding people to. The mechanism is not banned, and anyone who tells you it is has not read the API docs.

The rules govern disclosure instead. Discord’s Developer Policy, in force since July 2024, opens on it. Rule one: “Do not modify a Discord user’s account without explicit permission from the Discord user. Functionality that intends to make any changes to a Discord account (e.g., adding the account to a server) must clearly and properly inform the Discord account owner of the changes and receive explicit permission to enact the changes.” Rule two: the permission prompt must be “clearly labeled and apparent, and contain an accurate description of the purpose or feature being enabled.”

Adding an account to a server is the example rule one reaches for. Both rules turn on the same thing: the member has to be told, accurately, what they are approving.

Step six is the collision. The two phrases it tells you to delete, “verify in case of termination” and “verify so we can pull you if our server gets deleted”, are accurate descriptions of the purpose of the feature being enabled. That is the language rules one and two require. The guide asks you to take it out, and says why: “to avoid raising red flags.”

So a verify gate that describes itself honestly is a compliant use of a permitted scope. Following VaultCord’s security guide converts it into a non-compliant one, on purpose, to be less visible to Discord. The feature is not the problem. The instructions shipped with it are.

And you are the one who publishes that wording, on an application registered to you, under a policy that binds you as its developer of record.

The market

The company runs a marketplace at vaultcord.com/market, linked as “Buy Members” from the footer of every page of its help center. The heading is “Buy Discord members”. Listings are priced per hundred, from a few cents to twenty dollars, sorted by seller and by the kind of community the members came from: gaming, crypto, Roblox, FiveM, and servers for game cheats.

The rules are specific here. Developer Policy rule 13: “Do not misrepresent or fraudulently manipulate engagement. This includes participating in, enabling, or promoting the inflation of server membership with bot or user accounts.” Community Guideline 15 says the same thing to everybody else: “Do not engage with our service in an inauthentic way. This includes artificially inflating server membership, manipulating engagement metrics, and selling artificial engagement services.” Guideline 16 prohibits selling or purchasing Discord assets outright.

Selling server membership by the hundred is the activity rule 13 names, and rule 13 reaches participating in it, enabling it and promoting it, which are three descriptions of hosting the market.

It is also the sharpest difference between the two products. RestoreCord forbids member selling in its own security guide and cites Discord’s terms for why. VaultCord links a market for it from its help center.

What sells there is the stored OAuth2 authorization, which is transferable by design: adding somebody to a server they have never heard of is mechanically identical to adding them back to one they left. The pulling is the product either way, and the difference between recovery and inflation is whose server the members land in.

Sellers list their own inventory, and nothing suggests a server’s members are sold out from under the operator who collected them. What the market prices is the authorization itself, at $0.08 to $20 a hundred.

Separately, its GitHub organization hosts a public repository called Discord-Token-Joiner, described in its own words as “Join tokens to a Discord Server using VaultCord OAuth2 (no CAPTCHA!)”. It was last updated on 1 August 2026.

A token joiner drives Discord user account tokens rather than a bot, and Discord is not ambiguous about that. Its own support documentation calls automating a normal user account outside the OAuth2 and bot APIs a self-bot, says it is forbidden, and says it can get the account terminated. The “no CAPTCHA” in that description refers to a check Discord puts there on purpose, and Developer Policy rule three is “Do not enable your Application to bypass or circumvent Discord’s privacy, safety, and/or security features.”

Publishing a tool is not the same as using it in your own service, and there is no evidence VaultCord does. The account that gets terminated is whoever’s token is driven through it, which will be a member of somebody’s server rather than the provider.

A market and a token joiner are two answers to the same question, which is what a provider does with access to Discord accounts. The company published both itself.

VaultCord and RestoreCord share a designer

Worth knowing if you are weighing VaultCord against RestoreCord as two independent options. VaultCord’s own documentation says its owner “formerly operated KeyAuth, a developer platform with over 190,000 users”. KeyAuth’s changelog, in July 2023, says that same founder built RestoreCord in 2020, sold it in 2022, and was starting a new Discord recovery bot. The entry a month later names vaultcord.com.

Both halves of that are the companies’ own words rather than our inference. It also explains something this page has been describing all the way down: the two products share a mechanism because they share a designer. One is the other’s founder’s second attempt at the same idea.

They are not one company today. RestoreCord was sold in 2022, trades as Axvant UG, and publishes its own comparison arguing against VaultCord.

What Xenon is actually for

Total loss, the server gone and the community scattered, is the case VaultCord is built around. It happens, and it is rare. Most servers break in duller ways: a category deleted, a permission change that locked everyone out, a 2am restructure that went wrong, a bot that ran the wrong command. No amount of member recovery helps with any of them.

What helps is having several points to fall back to and a complete, fast rebuild. Xenon keeps 15 backups on the free plan and up to 250 on Premium, of the whole structure: every channel, every role, the role order, the permission overwrites, the settings. VaultCord publishes a basic backup on its lower plans and automated backups on its top one, without stating what a backup holds.

That is the narrow claim we will make and defend: for backing up a Discord server and putting it back, Xenon is the better tool. Not best at everything. Best at that.

Where Xenon is the better answer

Xenon has been one application since 2018, and the exposure that comes with running software against Discord’s platform sits with us. It asks your members for nothing, because it needs nothing from them: it reads what an administrator can already see and writes what an administrator could already write. There is no verification gate between a new member and your server, and nothing for anyone to revoke afterwards.

It also does things VaultCord does not. Xenon has published server templates since 2018 and every submission is reviewed before it appears, which is why the catalog is smaller than galleries that publish whatever gets submitted. Sync mirrors messages, bans and role assignments between servers continuously. Chatlogs archive a single channel far deeper than a backup reaches.

On raw numbers, be careful with all of them here. VaultCord has advertised 350 messages per channel on its free tier; it does not publish a per-channel limit by plan, and RestoreCord’s comparison could not establish one either. Xenon saves up to 250 per channel on its top tier and none at all on free, which we would rather say plainly than dress up. Messages in a backup exist so a restored channel is not empty, and none of the figures anyone in this category publishes is an archive. If you want one channel kept deeply, a chatlog holds up to 1,000 messages from it. If you want a real archive, you want an export.

Where VaultCord is

If recovering your member list is the requirement, VaultCord does something Xenon does not, and no amount of argument about the mechanism changes that. Go in knowing what it asks of your members and whose Discord application you are signing up to own.

If you want anti-nuke or anti-raid enforcement, Xenon is recovery rather than prevention and has none of it.

And if you are comparing on messages per channel alone, the number is theirs.

Everything else is where we would make the case for Xenon: the structure, the templates, the sync, and not asking a single person in your server to authorize anything.

Compare the two in more detail on the comparison page, or add Xenon and see what a backup holds.

Where these numbers come from

VaultCord’s plans, limits and prices were read from its own published pages on 29 August 2026, and its setup requirements from its API documentation. Anything in this category changes; check the live pages before you decide on them.

• VaultCord’s bot security guide, for the six steps and every phrase quoted from them, and its market for the listings and prices, both read on 11 September 2026
• Discord’s Developer Policy (effective 8 July 2024) and its Community Guidelines, for rules 1, 2, 3 and 13 and guidelines 15, 16 and 19, read on 11 September 2026
• Discord’s OAuth2 documentation for the guilds.join scope and its one stated condition
• VaultCord’s GitHub organization, for the token joiner and its description, read on 30 August 2026
• RestoreCord’s bot security guide, for its rule against selling members, read on 11 September 2026
• VaultCord’s help center for its owner having run KeyAuth, and the KeyAuth changelog entries of 17 July and 26 August 2023 for the RestoreCord founding and sale
• VaultCord’s pricing and comparison pages, for its plan tiers and what it claims member recovery does
• VaultCord’s API guide, for the custom-bot endpoint taking a client secret and a Discord token, and its help center for the setup steps it lists and the privileged intents it does not
• Xenon’s own figures come from our plans, which renders the live configuration rather than a number typed into a blog post