Salary Cap Rules for Existing Hockey Pools

PoolForge Salary Cap guidance is for existing pools. New Salary Cap pools cannot currently be created. New commissioners can create Standard or Draft League on Free; paid plans also add H2H and Daily. See the current plan formats before choosing a new pool.

A fair salary-cap hockey pool names one salary source, one budget, one compliance moment, and one correction policy before roster choices begin. Participants should be able to reproduce the cap total from visible salaries and predict whether a proposed roster is valid. Complexity is acceptable; hidden arithmetic is not.

Define what the cap is trying to reward

A salary constraint changes roster building from “pick the best projected players” to “buy the most useful production within a budget.” Decide whether the pool rewards opening-day value, continuous cap management, or another clearly stated objective. That choice determines when salaries are frozen and when compliance is checked.

Do not confuse a fantasy budget with the NHL’s real club accounting rules. Your pool can use cap-hit-inspired values, another published salary dataset, or commissioner-defined prices. Name the exact source and edition instead of implying that every real-world CBA rule applies.

Publish the salary snapshot

Salary source: [publisher and URL]
Snapshot date: [date and time]
Budget: [amount and currency or fantasy units]
Precision: [whole units / one decimal / other]
Unknown salary rule: [ineligible / assigned value / correction process]

Save the snapshot or a dated export if the source changes during the season. A live external page without a snapshot can make yesterday’s legal roster appear illegal tomorrow. State whether later real-world contract changes affect the pool.

Use a complete worked roster

Here is a fictional teaching example with a 100-unit budget. These are not PoolForge defaults or real player salaries.

The roster is compliant because every required slot is filled and the total is exactly 100.0. Test a second roster at 100.1 to prove how precision and rejection work. Never rely on a displayed rounded total when the system validates greater hidden precision; publish the precision used by enforcement.

Choose the compliance moment

• Submission-only: the roster must fit when initially saved; later source changes do not affect it.
• Transaction-time: every roster move must leave the roster under the cap.
• Continuous: the roster must remain compliant at defined checkpoints.

Submission-only is easiest to explain. Transaction-time creates ongoing strategy without retroactively invalidating passive rosters. Continuous enforcement requires a dependable salary refresh and a remedy for changes participants did not cause. Pick one model and show it in the rules and platform configuration.

Specify roster and bench treatment

List every position, bench or reserve slot, and whether each cost counts. State how multi-position eligibility is evaluated. If injured or inactive players receive relief, define the evidence, amount, start time, replacement rule, and end time. “Commissioner discretion” is not enough because high-value injuries can change the standings.

PoolForge’s Salary Cap format enforces a configured pool budget. In an existing Salary Cap pool, test one compliant and one over-budget roster in the pool's roster tools so the group recognizes the actual validation.

Align scoring with the scarcity created by cost

A cap does not automatically balance positions. Compare fictional stat lines at several cost levels. If a cheap goalie can outscore every premium skater under the configured weights, that may dominate roster construction. Use the scoring audit to test the relationship without presenting projections as facts.

Do not change player prices to repair a scoring problem after rosters lock. Correct the scoring model before launch or publish a future-season change.

Write transaction rules as cap equations

For every addition, trade, or replacement, define whether the outgoing cost leaves before the incoming cost is tested. Example: a 98-unit roster drops a 7-unit player and adds a 9-unit player. The resulting total is 98 − 7 + 9 = 100, so the move is compliant. If simultaneous multi-player trades exist, state whether the final roster alone or every intermediate state must pass.

Also define whether salaries remain at the frozen snapshot or use a current value for new acquisitions. Mixing frozen roster salaries with current free-agent salaries can be legitimate, but it must be intentional and visible.

Handle source errors and missing values

When the source corrects a salary, record the old value, new value, source timestamp, affected rosters, and effective rule. Do not punish a participant retroactively unless the constitution explicitly uses continuous enforcement and provides a remedy period. For a new player without a value, use the published unknown-salary rule; never invent a private estimate for one request.

Run the cap audit before opening

1. Match every salary in a sample roster to the dated source.
2. Recalculate the total independently.
3. Test exactly-at-cap and one-step-over-cap rosters.
4. Test one injury or reserve scenario.
5. Test one transaction equation.
6. Compare the visible review screen with the written constitution.

If all six results are reproducible, link the rules from the pool and preserve the salary snapshot. If the group is still deciding whether the added constraint is worthwhile, revisit the format guide before collecting rosters.