The Loader & Delivery

How the tiny script your buyer pastes turns into a validated, HWID-locked, server-gated delivery of your real obfuscated code — and why the real source never lives at a URL anyone can open.

The one-liner your buyer pastes

Every buyer runs the same small stub inside their Roblox executor. It is only two meaningful lines: a script key and a loadstring. Here is exactly what a buyer pastes, with their own license key filled in:

script_key = "THEIR-LICENSE-KEY"
loadstring(game:HttpGet("https://quarkexploits.com/raw/YOUR-ID.lua"))()

The first line sets a global named script_key. The second line downloads the loader stub from your raw URL and executes it immediately. That stub is not your real script — it is a small, published bootstrapper whose only job is to authenticate the buyer, prove their machine, and (only if everything checks out) pull down the real, obfuscated payload.

Why script_key is required

The loader stub reads the global script_key before it does anything else. If that global is missing, empty, or was never set, the stub aborts on the spot — it does not phone home, it does not collect anything, and it definitely does not deliver code. There is no anonymous path through the loader.

This matters for two reasons. First, it means the key is the entry ticket: no valid license, no execution. Second, it keeps the raw URL useless on its own. Someone can read the stub all day, but without a real, active key bound to their machine, the stub has nothing to give them.

The /api/v1/loader/auth handshake

Once the stub confirms a key is present, it collects a small bundle of identifying information about the machine and session, then POSTs it to the server endpoint /api/v1/loader/auth. This is the single gate that decides whether real code is ever returned.

The server does the following, in order:

1. Validates the key. It looks up the license the buyer supplied and checks that it exists and is in an active state — not paused, banned, or expired. A key with no expiry is a lifetime key and passes the expiry check.
2. Validates the HWID. On the very first successful run, the server binds the machine’s hardware ID to that license. On every run after that, it compares the incoming HWID to the bound one. A match proceeds; a different HWID is rejected. This is the anti key-sharing mechanism — one key follows one machine until it is reset.
3. Returns the obfuscated real script. Only when the key and HWID both pass does the server respond with your actual protected payload for the executor to run.
4. Fires a Discord webhook, server-side. The server posts an execution notice to your configured webhook so you get a log of who ran what and when.

If any check fails — bad key, wrong status, or a mismatched HWID — the server does not return your script. The buyer’s executor gets a rejection instead of code.

HWID binding and telemetry

Alongside the key, the stub gathers a hardware ID plus contextual telemetry about the run: player and game information and hardware details available in the executor environment. The HWID is what makes a license machine-bound; the surrounding telemetry is what makes your logs useful.

The HWID lifecycle is simple:

• First execution binds it. The first time a valid key runs, its HWID is recorded and locked to that license.
• Later executions must match. The same key from a different machine is refused — that is the point.
• Resets clear the binding. When a buyer legitimately changes hardware, the bot’s /reset command (which carries a cooldown to stop abuse) or a reset from the dashboard clears the bound HWID so the next run re-binds to the new machine.

Server-side webhook logging

When an execution is authorized, the server — not the buyer’s machine — sends the Discord webhook. You supply the webhook URL once, when you create the key system, and it is stored server-side.

This design is deliberate, and it is more secure than logging from the client would be:

• The webhook URL is never in code the buyer can see. Because the stub never holds the webhook URL and the server sends the notice itself, there is nothing in the delivered code for a buyer to extract, spam, or delete.
• The log is trustworthy. A client-fired webhook can be blocked, faked, or stripped out by whoever controls the machine. A server-fired webhook reflects what the server actually authorized, so your execution log is authoritative rather than something the buyer could tamper with.

Because the website is the single source of truth, these logs and the license state behind them stay consistent across the desktop software, the API, and the Discord bot — a reset or a ban you apply in one place is reflected everywhere.

Why the real source is never in a public URL

The raw URL only ever serves the loader stub, and even that stub is not your real script. Your actual code is only returned as the authenticated response from /api/v1/loader/auth, and only after a valid key and a matching HWID clear the gate. There is no address where your real source sits waiting to be fetched.

On top of that gating, the payload the server returns is obfuscated with the tier you chose when publishing (Hyper or Quantum). So even the authorized response is not plain, readable Luau.

The “content restricted” page vs. the executor

A natural question: if the raw URL is public, what happens when someone just opens it in a browser? The two contexts are treated differently.

• A browser sees a content-restricted page. Opening the raw URL in a normal web browser does not hand over runnable code; a browser is not an authenticated executor request carrying a valid key and HWID, so it gets a restricted response, not your script.
• The executor gets the loader, then the gated payload. When the executor fetches the URL as part of the loadstring flow, it receives the loader stub, which then runs the authenticated handshake described above and pulls the real obfuscated payload only if the key and HWID pass.

So opening the link by hand reveals nothing worth having, while a legitimate, licensed execution flows straight through. The public-looking URL and the real code delivery are two different things.

End-to-end flow at a glance

1. Buyer pastes the two-line loader with their key into their executor.
2. The stub checks for script_key; if missing, it aborts immediately.
3. The stub collects HWID plus player, game, and hardware telemetry.
4. It POSTs to /api/v1/loader/auth.
5. The server validates the key status and the HWID (binding on first run).
6. On success, the server returns the obfuscated real script and fires the webhook itself.
7. On failure — bad key or mismatched HWID — no code is returned.

Related

Your loader URL, obfuscation tier, and webhook are all configured when you create and publish a key system in the software’s Key System tab. HWID resets are handled by the bot’s /reset command or from the dashboard. If you run into loader problems, the two most common causes are a missing script_key line and a key whose HWID is bound to a different machine. Questions? The community Discord is at https://discord.gg/AvfJCzRgUz.