Everything you need to protect a Roblox script and hand out access. If you can paste one line, you can ship.
Every project runs one of three modes. You can switch any time; the same encryption applies to all of them.
| Mode | Key required | Best for |
|---|---|---|
| Keyless | No | Public / free tools you still want VM-protected. |
| Free-key | Yes (free) | Whitelisting users without charging. |
| Paid-key | Yes (you sell) | Selling access with expiring, per-buyer keys. |
This is the only thing your users ever touch. Everything else, authentication, decryption, sessions and unloading, is handled for you.
loadstring(game:HttpGet("https://xauth.live/loader/<project>"))()
local KEY = "paste-key-here" loadstring(game:HttpGet("https://xauth.live/loader/<project>"))(KEY)
Keys are random and unguessable. Each key can carry:
Create, ban and delete keys from the dashboard Keys tab, or through your Discord bot.
A key binds to the first machine that uses it. If a legitimate user changes hardware, they can request a reset. Requests appear in the dashboard HWID requests tab, where you approve or deny each one. Approving clears the bound device so the key can bind again.
Every run opens a short-lived session that keeps itself alive with periodic heartbeats. If the heartbeats stop, the session expires on its own. You can also kick any active session from the dashboard, the running script unloads cleanly on its next heartbeat.
Connect a Discord bot so buyers can redeem keys themselves. When a buyer redeems a key, their Discord identity (username and avatar) is attached to that key and shown in your dashboard, so you always know who owns what.
Typical buyer commands:
At a high level, xauth never ships anything usable to disk:
The practical result: a copied file is inert, a shared key fails on the second machine, and a revoked key or kicked session stops working right away.
Most people never need the API, the dashboard and Discord bot cover day-to-day work. For automation, an authenticated management API lets you script the same actions:
Management calls require your account credentials and are rate-limited. The runtime endpoints your loader uses are handled automatically and aren't meant to be called by hand.
No. The file is encrypted and the decrypt key is never in it. Without an authenticated request to your project, it won't run.
The key binds to the first machine. The second machine fails. If they genuinely changed hardware, they request an HWID reset for your approval.
No. Environment anomalies are reported to you, not auto-enforced on the device, so a false positive never bricks a real user.
No. Failed auth returns nothing to run and the loader exits cleanly. On success it unloads itself when the session ends.