GameGrid
Minecraft Economy and Item Delivery - visual guide

Minecraft Economy and Item Delivery

A currency and shop on any of the five Minecraft server types, with no mod and no plugin: namespaced item ids, RCON delivery, and delivery that is checked rather than assumed.

It needs no mod and no plugin

The whole economy on Minecraft — the shop, the item list, delivery, account linking, chat and the live map — runs on a stock Minecraft server. It uses give, clear, say and list over RCON, the chat that the server already writes into logs/latest.log, and the world files already on disk.

Nothing is installed in your server, nothing is loaded into its process, and no restart is needed to switch any of it on. That is not a coincidence: GameGrid hosts five Minecraft server types and only Paper takes Bukkit plugins, so anything needing a plugin would be a feature four customers in five could not have.

It works identically on Vanilla, Paper, Forge, Fabric and NeoForge.

The one thing that has to be configured is RCON, and GameGrid writes that into server.properties on every start. If a purchase fails because RCON is not configured yet, the server has simply never been started — one start fixes it.

General setup is in Setting Up Your Server Economy. This article covers what is specific to Minecraft.

Item ids are namespaced, and nothing else works

The id under each item name in the Shop tab is the namespaced id: minecraft:diamond_sword, minecraft:cooked_beef, or create:cogwheel for a modded item.

That form has been the only correct one since the Flattening in 1.13 and is unchanged since, so one stored id is correct on every version and every server type. The namespace is also what makes a modded item addressable at all — nothing about cogwheel on its own says which mod it belongs to.

Old numeric ids such as 276 are refused with an explanation rather than passed through to become a failed purchase somebody has already paid for.

The catalog reads display names from the server's own language file, so the names beside the ids are the names the game itself shows.

Where the item list comes from

Economy → Shop → Scan Game Items reads three sources, in order.

Your server's own jar — the item registry evidence and the display names it ships. Every id proved this way is one the game itself uses as an item.

Every mod jar in `mods/` — the mod id from its own metadata, and the items and names it declares. This is how a Forge, Fabric or NeoForge server gets its modded items into the shop with no extra step. Install a mod through the Mods tab, re-scan, and its items are sellable.

The running server, over RCON — for the handful of ids that no recipe, tag or loot table can prove: spawn eggs, barrier, bedrock, debug_stick, and most modded ids that have no recipe.

Start the server before you scan. A stopped server can be read from its jar but the third source is unavailable, so the list comes back shorter — and the platform says so rather than quietly returning less.

Paper plugins are not scanned, deliberately. A Bukkit plugin cannot add an entry to Minecraft's item registry, so it cannot add anything give accepts; its "custom items" are ordinary items carrying extra data. There is nothing in plugins/ to find, and listing ids that give would refuse would put unsellable items in your shop.

The Scan Game Items reply also tells you if something was incomplete — a jar that has not been unpacked yet (start the server once), a mod scan that ran out of time, or a probe budget that ran out. Scanning again continues from where it stopped.

Delivery is checked, not assumed

A purchase is delivered with give <player name> <item> <quantity> over RCON. Minecraft's give takes the account name, which is why a link stores the account name alongside the account's UUID.

RCON has no success or failure code — a give that worked and one that did nothing both come back as an ordinary line of text. So the platform reads what the server actually said, and where the answer is not conclusive it counts the item in the buyer's inventory before and after. Only then is the transaction marked Delivered.

If it cannot establish either, the delivery is recorded as unverified rather than as delivered, and it is flagged for a person. Check in game before refunding one of these — the item may well have arrived.

Before the give, the platform runs a harmless check that also tells it whether the item id exists on this server, whether the buyer is online, and how many they already hold. A purchase of an id the server does not have therefore fails before anything is sent.

The player has to be connected: give only reaches a player who is on the server. A purchase made while they are offline is held and delivered when they next join, for up to 24 hours.

Quantities, and enchanted or named items

Minecraft itself refuses a give of more than 100 stacks of the item, checked before anything is handed over — so an over-large quantity fails cleanly and delivers nothing. For an ordinary vanilla item that is 6,400; a modded item with a larger stack size can legitimately be more.

/buy accepts a quantity of 1 to 100 anyway, so this is only reachable through a shop item configured to hand over a large number per purchase.

An item id can carry a tail for enchantments or a custom name, and the syntax changed at 1.20.5: minecraft:diamond_sword{Enchantments:[…]} on 1.13 to 1.20.4, and minecraft:diamond_sword[minecraft:enchantments={…}] from 1.20.5 onward. The platform checks the tail against your server's real version and refuses the wrong dialect with a message naming both, rather than letting it become a parse failure after the coins are gone.

A tail on a server whose version cannot be read is refused too — start the server once so its version can be read, or sell the plain item id.

A plain namespaced id with no tail needs no version and works whatever the platform can or cannot detect.

An item id containing whitespace, a semicolon or a control character is refused outright. A shop entry is typed by a person and a console command is one line; a shop entry must not be able to become a second command.

Account linking

A player runs /link in Discord, gets a code by direct message, and types !link CODE in Minecraft chat within ten minutes.

Minecraft has no chat API. RCON can send a command but is never told anything, and it never sees a chat message; logs/latest.log is the only place chat exists, so the platform tails that file. That means the server has to have been started at least once for the log to exist — and it also means nothing is installed and no restart is needed.

The whole chat message must be !link then the code, with nothing else. Capitals do not matter.

The link stores the Mojang UUID, which is a genuinely durable identity: a Minecraft account's UUID never changes even when its name does. The account name is stored beside it because that is what give takes, so both travel together.

If a player renames their account, re-link them so the stored name is current.

Full flow and troubleshooting: Linking Discord Accounts to In-Game Players.

Auto-earn on Minecraft

All six rewards pay on Minecraft: playtime, kill bonus, death penalty, level milestone, daily login and Discord activity. Two different mechanisms sit behind them.

Playtime and deaths come from scoreboard objectives read over RCON. The platform reads the totals every minute and credits the difference. Playtime is paid per whole hour, with the remainder carried forward.

Kills and advancements come from the server log as they happen. A kill is a death whose killer is a player online at the time — a mob kill does not pay, and neither does a death with no killer.

Level milestone is paid on an advancement. Minecraft never announces an experience level to its log or its scoreboard, so an advancement is the closest thing to a milestone it reports.

Deaths are only ever paid once. The log announces every death and the scoreboard counts the same deaths; the platform deliberately lets the scoreboard counter own it, so a player who dies once is charged once, not twice.

Death penalty is entered as a positive number and deducted, and a wallet is never taken below zero.

Daily login is claimed by the player with /daily; Discord activity pays per message in your linked channel. Neither needs anything from the game.

A player's first minute pays nothing — their scoreboard totals are recorded as a starting point rather than paid out. Joins and leaves are recorded but pay nothing directly on this game, because playtime comes from the scoreboard instead.

Event participation does not pay on this game. Nothing here raises an event the platform can see, so the control is hidden and the setting is stored without paying. It pays on Valheim, where a raid ending or a boss dying is something the server is told about. Use /award for event prizes here.

Auto-earn only pays a player who has linked, and it stops for the day at the maximum daily earn cap. See Per-game economy support.

Chat bridge

/chat-link #channel mirrors in-game chat into Discord and sends the channel's messages back with say. Both directions read and write the same places the rest of this article uses — the log file and the console channel — so again, nothing to install.

A message from Discord appears in game as [Discord] <name>: <message>.

There is no chat send box in the panel for Minecraft. The bridge is how you talk to your players from outside the game.

See Discord Chat Bridge.

One economy across your Minecraft servers

All five server types share one set of item ids, so a Vanilla, a Paper, a Forge, a Fabric and a NeoForge server can all share one economy — one wallet and one shop across the lot. Set it up on the Economy Overview tab.

A Minecraft server cannot share an economy with 7 Days to Die, Palworld or Valheim; the panel does not offer those.

A shared shop can hold a modded id, which will only deliver on the servers that actually have that mod. Keep modded items priced on a group whose servers all run the mod, or expect failed deliveries on the ones that do not.

See Sharing One Economy Across Servers.