Minecraft anarchy server: exploits and limits

An anarchy server has no in-game rules - no claims, no bans for griefing or hacked clients, no rollbacks - but it still needs an operator, because the players who enjoy anarchy are exactly the players who will try to crash it. Run Paper, keep it updated, and leave its exploit protections switched on: the packet limiter, the book and item size limits, and the protections against piston and bedrock exploits. Limit how fast players can generate new terrain, decide in advance what you will do when the world fills the disk, and expect attacks. "No rules" is a promise about gameplay. It is not a promise to leave the server defenceless, and the servers that last treat the two as completely separate.

What anarchy means for the operator#

The genre's archetype is 2b2t, running since 2010 on one world that has never been reset, with no rules, no bans for in-game behaviour and a map that has grown to an enormous size. Smaller anarchy servers copy the format: a vanilla-like survival world, no protection, hacked clients allowed, and history that accumulates.

From the operator's side, the job splits cleanly in two:

Everything in the left column is the game. Everything in the right column ends the game for everyone, and most anarchy communities expect it to be handled. A player who crashes the server repeatedly is not playing anarchy; they are stopping anyone else from playing it.

One more line belongs above both columns: your host's terms and the law still apply. Illegal content, doxxing and attacks on other services are not gameplay, and "it's an anarchy server" is not a defence anyone else will accept.

Server software and base settings#

Run Paper. Its patches against crash exploits, dupes and packet abuse are the reason anarchy servers can exist at all on modest hardware, and it is the first project to fix a newly discovered exploit. Vanilla and Fabric have far fewer of these protections, and the forks of Paper receive Paper's fixes later. Update promptly: on an anarchy server, a published crash exploit will be tried on you within days.

The relevant server.properties settings:

online-mode=truespawn-protection=0white-list=falsemax-players=100view-distance=8simulation-distance=6max-world-size=29999984rate-limit=0max-chained-neighbor-updates=1000000network-compression-threshold=256enforce-secure-profile=true

What each of those is doing:

• `online-mode=true` is not optional. An offline-mode anarchy server lets anyone log in as anyone, including you.
• `spawn-protection=0` removes the vanilla ring around spawn that only operators can edit. Anarchy spawns are meant to be destroyed.
• `max-world-size` is the world's hard edge, defaulting to 29999984. Lower it if you want a finite world; more on that below.
• `rate-limit` is a vanilla per-connection packet limit, 0 meaning off. Paper's packet limiter is more precise, so leave this at 0 and configure Paper's instead.
• `max-chained-neighbor-updates` caps how many block updates one chain can trigger, which limits some lag-machine designs. The default is 1000000.

Your operator account should not play. If it does, it will be the target of every social-engineering attempt on the server, and an operator session hijacked by a malicious client is the worst outcome on the list.

Packet limits and spam limits#

Many crash and lag exploits come down to sending the server more of something than it expects: thousands of packets per second, oversized data, or requests that are expensive to answer. Paper's global config has dedicated sections for this in config/paper-global.yml. Key names and defaults move between Paper versions, so treat the following as a map of what to look for in your generated file rather than as values to paste:

packet-limiter:  all-packets:    action: KICK    interval: 7.0    max-packet-rate: 500.0  overrides:    ServerboundPlaceRecipePacket:      action: DROP      interval: 4.0      max-packet-rate: 5.0spam-limiter:  incoming-packet-threshold: 300  recipe-spam-limit: 20  tab-spam-limit: 500

The packet limiter counts packets per player over a rolling interval. If the rate crosses max-packet-rate, the player is kicked or the excess packets are dropped. all-packets is the overall limit; overrides sets tighter limits for specific packet types that are known to be expensive. The recipe-book packet override in the default config exists because spamming it was a real lag exploit.

Do not lower the global limit aggressively. Legitimate players on poor connections send bursts of packets when their connection recovers, and an anarchy server is full of players running clients that send more than vanilla does. Start with the defaults and tighten specific packet types when you see them abused.

The spam limiter covers chat, tab-completion and recipe spam. Tab completion is worth knowing about: asking the server to complete a long command string is expensive, and repeated tab-completion requests were a classic way to lag a server.

Books, item data and chunk bans#

The most famous family of anarchy exploits is the "chunk ban", historically done with written books. Fill a chest with books carrying the maximum amount of text, place enough of them in one chunk, and the chunk becomes so large that the packet to send it to a player exceeds what the client accepts. Anyone who walks into that chunk is disconnected, and if it is at someone's base, they can never log in there again.

Paper limits the size of book and item data so that this cannot be done with ordinary items:

item-validation:  book:    author: 8192    page: 16384    title: 8192  book-size:    page-max: 2560    total-multiplier: 0.98  display-name: 8192  lore-line: 8192  resolve-selectors-in-books: false

book-size.page-max caps the bytes on one page, and total-multiplier makes each additional page allowed slightly less, so a full book is bounded. resolve-selectors-in-books: false stops books from resolving selectors and scoreboard components, which used to be a way to make the server do expensive work. Leave these at their defaults unless you have a reason; loosening them is how the exploit comes back.

Variants of the chunk ban have used other kinds of data - shulker boxes full of items with long names, maps, banners, signs - and the defence is the same: keep Paper current, keep its limits on, and if a player reports that a specific chunk disconnects them, treat it as a server problem. MCA Selector can open the world offline and delete or inspect the chunk; world backup and restore covers finding the right region file.

Lag machines, entities and redstone#

A lag machine is a contraption built to make the tick take as long as possible: redstone clocks that update thousands of blocks, piles of entities that collide with each other, falling-block and item spam, hopper arrays. On a normal server you would ban the builder. On an anarchy server you cap what any contraption can do.

The settings that matter most, in config/paper-world-defaults.yml:

collisions:  max-entity-collisions: 8chunks:  entity-per-chunk-save-limit:    arrow: 16    experience_orb: 16    snowball: 8    ender_pearl: 8misc:  redstone-implementation: ALTERNATE_CURRENT

What those three settings do:

• `max-entity-collisions` caps how many collisions one entity processes per tick. Entity cramming machines rely on huge numbers of collisions.
• `entity-per-chunk-save-limit` caps how many of each listed entity type are saved in a chunk. Projectile and orb spam that would otherwise persist forever is trimmed when the chunk saves. The defaults are -1 (no limit); setting limits for projectiles is common on anarchy servers.
• `redstone-implementation` chooses the redstone dust algorithm. ALTERNATE_CURRENT is much cheaper than VANILLA and resists dust-based lag machines, at the cost of different update order for a few contraptions.

The vanilla maxEntityCramming game rule (default 24) kills mobs packed too tightly, which limits mob-based lag machines. And spigot.yml has entity activation and tracking ranges that reduce the cost of entities far from players; Paper optimisation goes through them.

None of this stops a determined player completely. What it does is turn "one player can stop the server" into "one player can make their own area slow", which is the realistic goal. Profile regularly with spark to find the chunk where the tick is going, then decide whether it is gameplay or an attack. Reading a spark report shows how to find a single expensive chunk.

Movement, elytra and chunk generation#

On an anarchy server the most expensive normal activity is travel. Players fly elytra in straight lines for hours to get away from spawn, and every new chunk they reach has to be generated. One player on a fast elytra can keep the server's chunk generation busy on their own; ten can lag it for everybody.

Paper limits how fast a single player can make the server load and generate chunks:

chunk-loading-basic:  player-max-chunk-generate-rate: -1.0  player-max-chunk-load-rate: 100.0  player-max-chunk-send-rate: 75.0

player-max-chunk-generate-rate is chunks per second per player, -1 meaning unlimited. Setting a limit means a fast traveller outruns the terrain and flies into unloaded void until it catches up, which anarchy players dislike but accept on most servers. Measure your server's total generation rate first, then pick a per-player limit that leaves room for several travellers at once.

Movement speed checks in spigot.yml are the other half:

settings:  moved-wrongly-threshold: 0.0625  moved-too-quickly-multiplier: 10.0

These decide when the server rejects a movement as impossible. Hacked clients that move far faster than the game allows are effectively tools for generating chunks faster than the server can afford. Many anarchy servers run a movement-focused anti-cheat - Grim is a widely used option - configured to stop speed and flight beyond what elytra allow, while leaving combat hacks alone. That is consistent with "no rules": the check protects the server, not anyone's fairness.

Map size, disk and memory#

Anarchy servers are defined by a world that never resets, and that world grows forever. Every chunk anyone has ever visited is stored. On a busy server with players travelling outward, disk usage climbs steadily, and it never comes back down.

There are three honest choices:

1. A border. Set a large world border - 100,000 or 500,000 blocks - and accept that the world is finite. Pre-generate the inner area so spawn is cheap. Purists object; your disk does not.
2. No border, with a budget. Let it grow and plan disk upgrades. Know your growth rate by checking the world folder size weekly, and do the arithmetic before the disk fills rather than after.
3. Trimming. Delete chunks that were generated but never really used - visited once in passing, very low inhabited time - with MCA Selector on a copy of the world. Much of a travelled world is highway corridors nobody returns to. Some communities consider this a reset; announce your policy.

When the disk fills, the server cannot save. Chunks fail to write, players lose progress, and corruption becomes likely. That is worse than any of the three choices above.

On RE:NODE, Minecraft plans have between 15 and 100 GB of disk and 2 to 14 GB of memory depending on the tier, and the disk graph sits next to the console. A long-lived anarchy world can outgrow a small plan within months, so watch the graph and move up a tier before it is urgent - changing plan does not rebuild the server. Backups are the other disk cost: a 40 GB world is a 40 GB backup, which takes a long time to make and to restore. How much RAM a Minecraft server needs covers memory; on anarchy, view distance and the number of separate places players are loading matter more than the player count.

Attacks, crashes and staying online#

Anarchy servers attract attacks, on the network as well as through the game. Assume someone will try to flood your address the day your server becomes known.

• Network attacks. RE:NODE has upstream filtering that drops obvious volumetric floods, plus reflection and malformed traffic. Attacks that look like real players are not filtered - including bot joins that log in and do expensive things. No host can promise that nothing gets through, and DDoS attacks on game servers explained is honest about what filtering can and cannot do.
• Bot joins. Floods of accounts joining at once. online-mode=true means each needs a real account, which limits the scale; a connection throttle and a plugin that rate-limits joins help more.
• Crash loops. If an unpatched exploit crashes the server repeatedly, that is a server problem to fix fast. On RE:NODE, a watcher counts unexpected restarts: three in an hour put a warning on the server page and open a ticket automatically, and six suspend the server. Restarts you trigger yourself are not counted. An exploit someone runs over and over is exactly the pattern that trips this, so patch, or stop the server while you work out what is happening.
• Memory exhaustion. Some exploits aim to fill memory. On RE:NODE a container that reaches its memory limit is stopped and restarted clean rather than left to swap, so the attack becomes a restart and the unsaved minutes are lost. Keep the autosave interval short enough that this costs little.

Why your game server keeps restarting helps tell an exploit from an ordinary crash, and what to do when your server is hacked covers the case where the attack was against the panel or an operator account rather than the game.

Backups and the no-rollback rule#

Most anarchy servers promise no rollbacks for in-game events. That is a fair promise, and it is compatible with taking backups, because backups are for the server's failures, not for the players'.

Write the policy down: no rollbacks for griefing, theft, deaths or anything else a player did in the game; rollbacks only for corruption, a disk failure or a crash exploit that damaged the world. Then take backups as seriously as any other server. Every RE:NODE game plan has backup slots stored off the machine, on demand or scheduled, downloadable and restored with a button - and you can lock one, so rotation does not remove the last good copy before an exploit you are still cleaning up.

FAQ#

Do anarchy servers need anti-cheat?

Not for fairness - hacked clients are part of the genre. Many still run a movement-focused anti-cheat to stop speed and flight beyond elytra, because those clients generate new chunks faster than the server can afford and make the server easier to crash.

How do I stop chunk bans and book bans?

Run a current Paper build and leave its item-validation limits on. They cap the size of book pages, titles and item names so that a chunk cannot be filled with enough data to disconnect players. If a specific chunk still disconnects people, inspect or remove it offline with MCA Selector.

Should an anarchy server have a world border?

That is a community decision, but plan for the disk either way. With no border the world grows indefinitely and eventually needs a larger plan or trimming. A large border keeps the world finite and lets you pre-generate the inner area.

Can players crash a Paper server?

They try. Paper fixes known crash exploits quickly, so most come from servers running old builds. Update promptly, keep the packet and item limits on, and treat repeated crashes as an urgent server problem rather than as gameplay.

Is offline mode acceptable on an anarchy server?

No. Offline mode lets anyone join with any name, including an operator's, and removes the cost of bot floods. Keep online-mode=true.