How to Build a Proxy Sealed Pool for Custom-Set or Limited Testing

TLDR

A proxy sealed playtest set should be visibly unofficial, mechanically consistent, and tied to one documented card-file version. Choose a pool model, randomize assignment without leaking information, use matching opaque sleeves, record which pool each player received, and change the environment only after reviewing the session. Use Sealed to test card function, deck construction, mana, and pool-level experience. Switch to Draft when you need to study picks, signals, contested colors, archetype lanes, or pack composition.

The purpose of a proxy sealed playtest set is not to imitate authentic product. It is to create a repeatable Limited experiment. Players should be able to open—or be assigned—an unknown pool, build without accidental clues, play fair games, and produce notes that still make sense after the card file changes.

That requires more discipline than shuffling a custom set into six vaguely pack-shaped piles. The important work is defining what each session tests, controlling hidden information, and preserving enough records to tell whether a change helped. Limited variance will never disappear, but the process does not need to become chaos with sleeves.

What a Proxy Sealed Playtest Set Is

Here, “proxy Sealed” means casual, unsanctioned Sealed using clearly non-authentic playtest cards. It can represent a custom set, recreate an existing Limited environment, or test a curated group of cards. It is not an official format name, and it is not permission to use unofficial cards at a sanctioned event.

Wizards distinguishes visibly unofficial personal playtest cards from counterfeits intended to pass as real cards. That distinction matters even at the kitchen table: a playtest piece communicates what it is, while a counterfeit is represented or intended to be represented as authentic. Wizards’ policy discussion of proxies and playtest cards provides the official context for that boundary.

Sanctioned Limited has additional controls. The official Magic Tournament Rules address product distribution, player-created proxies, marked cards, hidden information, Sealed registration, and Draft procedure. A home group can borrow fairness principles from those rules, but casual agreement does not override tournament, organizer, or store policy.

Start With One Test Question

Before constructing pools, write down the main question for the session. “Is the set fun?” is too broad to diagnose. Better questions connect a design concern to something players can observe.

Card function: Did players understand what a new mechanic or unusual template did?
Deck construction: Could players find enough coherent cards to build functional decks?
Mana: Could typical pools cast their spells without every deck becoming three-color soup?
Archetype density: Did themes appear often enough in pools to be noticed and used?
Individual balance: Did a card repeatedly dominate games or remain unplayable in plausible decks?
Onboarding: Could a player unfamiliar with the file build without needing the designer to translate every third card?

A test can reveal unexpected problems, but naming a primary question keeps feedback useful. Wizards’ discussion of playtesting similarly presents testing as an iterative process in which feedback informs revisions and different testing constraints expose cards to meaningful play. Early tests can focus on whether cards function at all; later tests can ask whether the full Limited environment holds together.

Choose the Pool Model Before You Shuffle

“Sealed” can describe several home-testing systems. Disclose which one you are using because each answers different questions.

Pool model	Best use	Main limitation
Simulated boosters	Testing a proposed collation model and natural pool variance	Requires enough stable cards and a defined pack schema
Fixed pools	Repeating the same construction problem after card revisions	Players may remember previous builds or hidden contents
Curated pools	Giving specific mechanics, colors, or cards meaningful exposure	Cannot represent ordinary random distribution
Cube-like Sealed	Testing a reusable environment without pretending it matches retail boosters	Results apply to that curated environment, not normal booster collation

A familiar baseline is six boosters followed by construction of a deck containing at least 40 cards, with basic lands available. Wizards uses that structure in its prerelease guidance. It is a useful starting point, not a sacred number. A small custom file may need fewer, larger, or deliberately curated packets. If you depart from the baseline, document the difference so players understand what the results represent.

For a very early custom set, fixed or curated pools are usually more informative than simulated boosters. They guarantee that the mechanic under review appears. Once the file and rarity structure settle, simulated boosters become more useful for exposing distribution problems. Do not claim that a homemade collation method reproduces retail variance unless it actually models the relevant distribution rules.

Freeze and Label the Test Version

Every card and pool-construction rule used in one session should belong to the same version. Give the file a simple identifier such as SET-0.4 and put that identifier in a neutral place on each playtest card. Keep a dated change log that records additions, removals, wording changes, cost changes, rarity movement, and changes to the pool schema.

Version labels should help after the game without revealing information during it. Avoid identifiers on card backs or visible sleeve areas that encode color, rarity, archetype, pool, or revision. “B-17” is harmless only if players cannot infer that B means blue or that the number maps to a bomb rare.

If a wording change occurs during a test cycle, either replace every affected copy or use one announced correction sheet for all players. Quietly correcting only some copies creates both a rules problem and a marked-card risk. If your group eventually replaces rough slips with ordered MTG proxy cards, keep the same version identifiers and retire obsolete copies rather than mixing revisions.

Protect Hidden Information and Prevent Marked Cards

A fair pool does not begin when deckbuilding starts. It begins when every game piece is indistinguishable while face down. Players should not be able to identify a card from its sleeve wear, backing paper, thickness, cut, opacity, or the location of a handwritten correction.

Use the same opaque sleeve model and color for the entire test batch.
Put every thin paper insert in front of the same type of backing card.
Replace split, cloudy, bent, or unusually loose sleeves before assignment.
Shuffle and assign pools by neutral pool ID, not by player preference.
Keep the pool key in an organizer record that players cannot see during construction.
Do not label packets with colors, archetypes, rarity distributions, or featured cards.
Use identical exterior packaging if pools are meant to remain unknown before opening.
Check cards under ordinary play lighting; a sleeve that looks opaque on a desk may reveal contrasts when held up.

The same principle applies to reusable pools. If Pool 3 always contains the dragon deck, changing its envelope from red to blue does not restore hidden information. Rebuild pools, rotate contents under a documented rule, or let an organizer who is not playing perform blind assignment. For a fuller physical check, use the proxy deck marked-card audit before game night.

Handle double-faced cards separately

Double-faced cards can reveal themselves unless the sleeves are fully opaque. Clean options include helper cards in the deck with the represented card stored separately, or a fully opaque sleeve system with a clear reference copy available outside the deck. Whatever method you choose must be consistent across pools and explained before construction. The guide to double-faced cards in proxy decks covers the practical options in more detail.

Tokens and reminder cards should also be visibly distinct from cards that can enter a deck. Keep them in a shared supply rather than hiding them inside pools, unless token availability is itself part of the test. Nobody should lose a match because the 1/1 token looked exactly like a playable rare from the back.

Run the Sealed Session With a Repeatable Protocol

Before distributing anything, explain the pool model, card-file version, deck-size rule, basic-land access, deckbuilding period, match structure, sideboarding rule, and when pool contents may be discussed. This is a casual protocol, so the group can choose its timings. Consistency matters more than copying tournament timing without understanding why.

Randomly assign each player a neutral pool ID.
Have players verify the pool count without revealing contents to other players.
Build decks using the announced minimum and land policy.
Record the final deck and sideboard with a decklist, sorted photo, or digital entry.
Play the agreed number of matches while keeping between-game sideboarding rules consistent.
Collect observations during games, but postpone major design arguments until the round ends.
Reveal pools only at the agreed time, then collect structured feedback.
Return every card to its recorded pool or sort the full batch back into inventory before the next test.

If players register pools before passing them to someone else, that can improve accountability and prevent accidental card migration. It also adds work and may expose pool contents to the registering player. Decide whether that tradeoff helps your test. For a four-person kitchen-table session, labeled sorting trays and post-build photos may provide enough control.

Log Enough Information to Learn From the Games

Memory is excellent at preserving the story of the absurd mythic and terrible at preserving the three games where a common quietly made combat miserable. Use one short form per player or pool.

Date, card-file version, and pool-schema version
Player count and player experience level, described broadly
Pool ID and assignment method
Built deck colors, splash colors, and approximate land configuration
Decklist or clear photos of the deck and unused pool
Match results, including games played rather than only match wins
Cards that were confusing, repeatedly uncastable, unexpectedly strong, or never considered
Mana problems and whether they came from building choices or available fixing
Archetypes attempted and whether the pool supplied enough support
Proposed changes, recorded separately from direct observations

Separating observation from proposal is crucial. “This creature ended three stalled games” is an observation. “Make it cost two more” is one possible response. Keeping those fields separate prevents the first suggested fix from becoming accepted truth.

Do Not Treat One Pool as Proof of Balance

A single Sealed session can expose wording failures, miserable play patterns, missing interaction, unusable mana, or themes players cannot recognize. It cannot establish that the environment is balanced or that every archetype appears at the intended rate. One player may open the strongest cards, build better, draw better, or simply understand the designer’s intentions faster.

Review repeated patterns across pools and sessions. When one problem appears, flag it for observation. When it recurs under different players and pools, investigate the card or structural rule. Change one connected group of variables when practical, then identify the next session with a new version number. Rewriting half the file after every dramatic game produces motion, not knowledge.

Know When Sealed Has Finished Its Job

Sealed tests what players can build from private pools. It does not show whether drafters can read signals, whether an archetype attracts the right number of players, whether key cards wheel, or whether pack composition creates meaningful picks. Those questions require Draft.

Official Booster Draft guidance describes concealed selections, face-down passing, roughly 45 drafted cards per player, and construction of decks containing at least 40 cards. A custom environment can use a different pack or player configuration, but Draft’s defining information comes from sequential choices and competition for cards.

Move from Sealed to Draft when individual cards mostly function, the file is stable enough that players can evaluate choices, and you need to test lanes rather than pools. A reusable MTG proxy Cube workflow can also help when the environment is intentionally curated rather than designed to emulate booster collation.

Reusable Pre-Event and Post-Event Checklist

Before the session

State the test question and pool model.
Freeze the card file and construction rules under one version.
Replace damaged or distinguishable sleeves.
Verify that correction marks and identifiers reveal nothing while face down.
Prepare neutral pool IDs and a private assignment record.
Publish deckbuilding, land, match, sideboarding, and reveal rules.
Confirm that the venue and organizer permit the casual proxy activity.

After the session

Save decklists or deck photos with pool IDs.
Collect observations before debating solutions.
Record confusing wording, mana failures, and unused themes.
Check that all cards returned to the correct inventory.
Separate damaged sleeves and obsolete card versions.
Decide whether the next test should repeat Sealed or move to Draft.
Create a new version only after documenting the changes.

Build an Experiment, Not Just Six Piles

The best proxy Sealed setup is boring in the right places. Backs match. Labels reveal nothing. Players know the rules. The card file stays frozen for the session. Notes can be connected to a specific pool and version afterward.

Start with one test question and the simplest pool model capable of answering it. Run the session, preserve the evidence, and make deliberate revisions. If the next unanswered question concerns picks, signals, or contested archetypes, stop asking Sealed to solve a Draft problem and schedule the draft.