Licenses & HWID
How keys are created, redeemed, bound to hardware, and reset — the full lifecycle of a Quark license from generation to the moment a buyer runs the script.
A license (also called a key) is the credential a buyer pastes into their executor as script_key. It is the thing the loader authenticates against every time the script runs. Licenses live in the website database — the single source of truth — so whether you create, pause, or ban a key from the software, the dashboard, or the Discord bot, the change syncs to all three instantly.
Every license belongs to exactly one key system. A key generated under one key system is meaningless to another. If you run multiple products, each has its own pool of licenses, its own bot, and its own loader URL.
Creating licenses
Open the Key System tab in the Quark software, select the key system you want to issue keys for, and use one of three creation methods depending on how you sell.
Random single key
Generate one license with a randomly-generated value. This is the fastest path when you have just made a sale and want to hand a fresh key to a single buyer. Set its status and expiry at creation, then copy it out.
Manual key
Add a key with a value you choose yourself. Use this when you want human-readable or branded keys (for example a fixed prefix per reseller), or when you are migrating keys in from a system you ran previously. The value must be unique within the key system.
Bulk generation
Generate thousands of licenses at once. This is built for reseller drops, giveaways, and marketplace stock where you need a large batch of unused keys up front. Each generated key is independent — binding, banning, or resetting one never touches the others.
Bulk-generated keys are real, live licenses the moment they exist. Treat the exported list like cash: anyone holding a value can redeem it until you pause or ban it.
Lifetime vs expiring
Quark sells at $2/month or $5 lifetime, and licenses mirror that model:
- Lifetime — a license with no expiry set never expires. It stays valid until you pause, ban, or delete it.
- Expiring — a license with an expiry date (for example a 30-day monthly key). Once that date passes the key moves to the expired status and the loader stops returning the script.
The lifetime-vs-monthly distinction also affects the Account Manager: monthly-key users are capped at 5 saved Roblox accounts, while lifetime and staff accounts are unlimited.
License statuses
Every license is always in exactly one of four states. The loader only returns the real script for an active key; the other three all block delivery.
| Status | Loader behavior | Meaning & typical use |
|---|---|---|
| active | Authenticates and returns the script | The normal working state. A valid buyer with a matching HWID gets their obfuscated script. |
| paused | Rejected — temporarily | A reversible hold. Use it for a chargeback under review, a suspected sharer you are still investigating, or a buyer between billing cycles. Flip it back to active to restore access with the HWID bind intact. |
| banned | Rejected — permanently | A punitive, permanent block for abuse, key-sharing, or fraud. The key is dead but kept on record so the value can never be reused. |
| expired | Rejected — time is up | An expiring key whose date has passed. Re-issue or extend it to bring the buyer back. |
Redeeming a key through the bot
When a buyer has a raw key value, they claim it in your Discord server with the bot. This is what ties the license to a person and gives them access to everything they are entitled to.
/redeem in your server and provides their key value.Redeeming is a link-and-unlock step, not the same thing as HWID binding. The hardware bind happens later, on the first actual execution of the script.
Buyers are always whitelisted. A valid active key is a whitelist entry — there is no separate approval queue to babysit. The bot also exposes /whitelist, /unwhitelist, and /whitelisted-users if you ever need to manage entries manually.
The loader a buyer pastes
After redeeming, the buyer's loader looks like this (their real key value replaces the placeholder, and the id is your key system's published loader id):
script_key = "THEIR-LICENSE-KEY"
loadstring(game:HttpGet("https://quarkexploits.com/raw/ID.lua"))()The loader stub reads the global script_key and aborts immediately if it is missing. It then collects the machine's HWID plus player, game, and hardware info and POSTs it all to /api/v1/loader/auth for validation. The real script source is never present in that public URL — the server only returns it after the key and HWID check out.
HWID binding on first run
HWID is a hardware identifier unique to the buyer's machine. Binding is what makes a Quark key personal rather than a password anyone can copy around.
- On the first execution of the script, the server binds the license to the HWID reported by the loader. That machine is now the key's home.
- On every later run, the server compares the incoming HWID against the bound one. A match returns the script as normal.
- A different HWID is rejected. If the buyer's friend takes the same key value and runs it on their own PC, the server refuses and never delivers the script.
This mismatch rejection is the anti key-sharing mechanism. A single key can only ever run on one machine at a time, so a leaked or resold key does not multiply into free copies of your product.
Resetting a HWID
Legitimate buyers replace hardware, reinstall Windows, or switch PCs. When that happens their key is still bound to the old machine and will reject the new one, so you clear the bind and let it re-bind on the next run.
There are two ways to reset:
- From Discord — the buyer (or you) runs the bot's
/resetcommand. This is the self-service path so you are not manually clearing binds all day. - From the dashboard — reset the HWID on the license directly in the website or software.
/reset has a cooldown. This is deliberate: without it, a sharer could reset the bind on every run and defeat the hardware lock entirely. The cooldown keeps resets to the honest new-PC use case. If a buyer is genuinely stuck inside the cooldown window, a staff member can reset from the dashboard.
What blocks the script, at a glance
The loader returns the real script only when all of the following hold. Any single failure ends in a rejection and no source is delivered:
script_keyis present in the executor's environment.- The key exists and its status is active.
- The key is not expired (or has no expiry at all).
- The reported HWID matches the bound HWID — or the key is unbound and this run is the one that binds it.
Every authentication also fires a Discord webhook server-side, so you get a log of who ran what without the webhook URL ever appearing in code the buyer can see. Combined with the HWID lock and server-gated delivery, that logging is the real security model — see the Loader & Delivery and Obfuscator pages for how the script itself is protected once it reaches the machine. To be honest about the limits: no protection running inside an executor is truly unbreakable — the point is to make sharing and dumping costly, not impossible.
Related bot commands
Several bot commands touch licenses directly. Toggle any of them in the software and the change auto-syncs to the running bot:
/redeem— link a key, grant the buyer role, return the loader./reset— clear a HWID bind (cooldown-limited)./whitelist//unwhitelist— manage whitelist entries by hand./whitelisted-users— list who currently has access./user-history— review a buyer's key and reset activity./verification— verify a member owns a valid key.
Next: read The Loader & Delivery to see exactly how /api/v1/loader/auth validates a run and streams back the obfuscated script.