I built this, then took it back out — and I want to explain why rather than just close it.

Maple Points are the one currency the server owns outright. The client is never allowed to state a balance; it can only ask the server to credit a quest reward or redeem a card, and the server rolls the reward itself and writes an audit row. That is deliberate, because it is the only wallet in the game that cannot be edited by a tampered client.

A /mp <amount> command has to hand the server a number the CLIENT chose. I gated it on a server-side admin table so only real admin accounts could use it — but the account name in the security token is itself supplied by the client (this is a known, already-documented weakness, and it is why /whoami exists). So anyone could claim your admin account name and mint themselves Maple Points. The GM flag is no help either: it is only client state.

So the safe way to get points for testing is to set players.maple_points directly in the database — one row, no new attack surface. /mp with no argument already shows the current balance.

If you would rather have the command anyway and accept that trade-off, say so and I will put it back — it is about twenty lines and I have it written. It is your call, not mine, but I did not want to make it quietly.

GM as well as player name and account/items/etc should be tied to the verse8 id directly, so that players cannot access others accounts and that we can properly do the maple point conversion safely with proper server/database sided checks

Built — and the admin system underneath it got fixed too, which is why this took the shape it did. Leaving IN PROGRESS for one manual step only (below).

WHY IT WAS DECLINED BEFORE, and what changed: this game's identity is client-asserted. The browser picks its own account name, the platform echoes it back without verifying it, and the session token is signed with a key that sits in the repo. So a correctly-signed token claiming to be an admin is something anyone can produce, and the in-game GM flag is just a boolean in browser memory that a debugger can flip. A /mp command gated on 'are you a GM?' would have been decoration on a wallet that is real.

So the grant now needs TWO things, and the second is the one that matters:
1. your session token — identifies who is asking, for the audit trail
2. an admin key that is NOT in the game bundle and cannot be derived from any token

Holding a forged admin token is deliberately not enough. I verified that: with the key unset, a perfectly-forged admin token is refused outright, because it fails closed. A half-finished setup grants nothing.

The decision itself is made in the database, not in the client and not in the endpoint. It does its own admin check and writes an audit row on BOTH success and refusal — a denied attempt is the single most interesting thing this system can produce, and previously it would have left no trace at all. All five refusal cases were tested and each left a row with its reason. A real grant moved a balance 200 to 450, and replaying the same request produced no second credit. I then reversed my own test grant with its own ledger entry rather than deleting it, because an audit trail you edit is not one.

Three things I fixed along the way that were live problems in their own right:

• The social endpoint (fame, buddies, party, guild) accepted a forged token claiming an expiry in the year 3000, forever — it never checked maximum lifetime. Now bounded. Verified: normal token 200, year-3000 forgery 401.
• A retired leaderboard endpoint was still live and still accepting that same forged token with no lifetime bound, despite its table having been deleted. Now returns 410.
• The cheat detector fired CRITICAL on every legitimate Maple Point credit — your two real card redeems were sitting as critical findings. Adding grant traffic would have buried the one alarm that catches a genuine forgery. It now only fires on increases the ledger cannot explain.

Here's what was actually wrong — and it turned out to be four things, not one.

The points really were being added to your account; the database has the record. But the running game never heard the new number, so /mp kept printing the old balance and the Cash Shop refused to spend what had just been granted. That was fixed last build.

What we found since: nothing had ever actually reached the server. The box asking for the admin key was a plain browser pop-up, and inside the Verse8 preview window that pop-up is blocked outright — it never appeared, and the game read that as "cancelled". It's now a proper in-game parchment box, and the key is masked as you type. Three more: the shop now repaints if points land while it's open; the purchase box says "Maple Points" when points are paying instead of always saying "VX"; and /mp can now target another account.

The one manual step left is the admin key. It's deliberately not in the game — anything inside the game is public. Mark sets a secret called MP_ADMIN_KEY in the Supabase dashboard (Edge Functions → Secrets) and sends you the value privately. To confirm it worked: log in as Drew, type /mp 2000, paste the key. If a grant lands, a new row appears in the mp_grant_audit table. No row at all means it never reached the server.

Two warnings. You must be on Drew — Drewskie and DANTAIN have no GM rights. And your balance is 200 while the cheapest item is 500, so grant at least that.

One thing to know before you spend: cash cosmetics were going to fail to buy, because the server could not price them. That is fixed below, but the fix is server-side, so Mark has to redeploy before it takes effect.

John's request to tie accounts to a verified Verse8 ID is not done, and can't be finished from our side — Verse8 doesn't yet give us a way to verify who someone is. The money itself is protected separately, by that admin key and by checks in the database, so Maple Points are safe today for a different reason than John asked for.

One more thing turned up while fixing this, and it would have bitten you on the very first purchase. Once the granted points actually landed in your wallet, the shop would have refused to sell you anything from the EQUIP. tab. The reason is dull: the price list the server checks against had not been rebuilt since the cosmetics were added, so it knew 516 items while the shop was showing 1,380. Anything it did not recognise came back as "purchase failed". That list is now rebuilt from the same game data the shop itself reads, covering all 1,847 items, and it is generated in a way that cannot fall behind again — a test fails the moment the shop stocks something the server cannot price. One caveat: this half lives on the server and does not travel with a normal push, so Mark has to redeploy it before you re-test.

Update on the one manual step: the admin key is now set and verified live on the server, so /mp is ready for you to try.

Mark set MP_ADMIN_KEY and I confirmed the server accepts it — I probed the grant endpoint with the new key and no game session, and it got past the key check and stopped at the missing session token, which is exactly the right answer. So the key half is proven working rather than assumed. I never saw the key itself; ask Mark for it directly.

To test: log in as Drew (this matters — Drewskie and DANTAIN are not in the admin list and will be refused), type /mp 2000, and paste the key into the parchment box that appears. It masks as you type. Then check the mp_grant_audit table: a new row means it reached the server. No row at all means it never got there. A row carrying a refusal reason means it did get there and was denied, which is a different problem and the reason is written down for you.

Your balance is 200 and the cheapest thing in the shop is 500, so grant at least that much to be able to buy anything.

One thing still outstanding before you spend it: cash cosmetics (hats, hair, clothes) will still refuse to sell until Mark redeploys the server-side price list. That fix is written but it lives on the server and does not travel with a normal push. Consumables, pets and pet gear should be fine in the meantime.

Still leaving this IN PROGRESS until you have actually granted and spent some.

Closing this — Drew has now confirmed both halves in-world. The v43 test run verified that after a GM runs /mp the new balance shows immediately with no relog, and that the Cash Shop actually spends it. That was the last outstanding step: the admin key was set, but nobody had proven a grant landing and then being spent. Both are now confirmed working.