POCTF 2026 Rules

Flags & Submissions

Flags are team-specific this year. A flag that is valid for one team will not be valid for another. The contest site will validate whether a submitted flag is correct for your team.

Some challenges also include team-specific content in the prompt itself — ciphertext, image variants, or other values generated uniquely for your team. Comparing challenge text across teams is therefore not useful and may be misleading. Use your own team's challenge page as the source of truth.

Unless a challenge states otherwise, flags must be submitted through the contest website on the relevant challenge page. Submissions outside the official submission mechanism are not eligible for points.

Challenge Release & Closure

Challenges may be released in waves or stages. Some challenges may also close early. Challenge closure means the challenge is no longer eligible for points and may stop accepting submissions.

POCTF includes both jeopardy-style challenges (standalone puzzles) and narrative tracks (staged sequences, such as Forensics and Game Hacking) where later stages may depend on earlier progress. Release windows and closure times (when applicable) will be shown on the challenge page and/or announced on Discord.

Fair Play

Participants must follow the contest rules at all times. Violating rules may result in score penalties, disqualification from specific challenges, removal from the contest, and ineligibility for prizes.

Do not interfere with challenges outside your team’s access. Do not attempt to access or modify other teams’ data or instances. DDoS/DoS attacks are strictly prohibited.

Decisions made by admins or organizers regarding disputes, scoring adjustments, and enforcement are final.

Support Channels

Grievances, concerns, questions, and bug reports should be made to admins or organizers. Discord moderators are not necessarily admins or organizers; moderators help keep order on the server.

If something is unclear, ask first. If you are too frustrated to be constructive, step away and come back later. This event is optional; treat people accordingly.

One Account per Person

Each participant must register and compete using a single account. Creating or using multiple accounts or aliases to gain an advantage is not allowed.

Brackets

POCTF offers three brackets:

• Solo — a single participant competing on their own.
• Team (standard) — a group of participants who register as a team. The captain receives a join code that other members redeem.
• Academic — a team representing a single accredited institution. Eligibility is verified by organizers; admin approval is required to enter or remain in this bracket. An institutional email may be requested as part of verification.

A participant may compete in only one bracket in the same event. You may not appear on multiple rosters or submit flags for more than one registered team.

Teams

Standard teams may have between 1 and 6 participants. The size cap is enforced by the contest system at join time. Academic teams are not capped, but eligibility for the academic bracket requires admin verification.

All participants on a team must be registered on the contest site to be considered valid participants. Teams are identified by a unique ID and profile in the contest system. Team join codes and roster management are part of the official contest workflow.

No Collusion

Collaboration between competing teams is not allowed. This includes sharing flags, full solutions, step-by-step instructions, private write-ups, or other direct solution material during the contest.

Using publicly available tools, documentation, and references is allowed, provided such use does not violate laws, licenses, or these rules.

Shared Environments

Participants working from shared labs or classrooms must ensure they are not sharing solutions or flags (even inadvertently) with other participants.

Purpose & Scope

This Code of Conduct applies to you as a participant across the contest website, Discord server, challenge infrastructure, and any other official communication channels associated with POCTF.

The goals are simple: maintain a respectful, welcoming environment; protect the integrity of the contest; and ensure organizers, admins, and volunteers can run the event without harassment or abuse.

Professionalism & Respect

Treat organizers, admins, moderators, and other contestants with professionalism and basic human respect.

• Harassment, insults, personal attacks, and hostile behavior are prohibited.
• Do not target organizers or volunteers with abuse, demands, or ridicule.
• Disagreements about challenge design or difficulty do not justify disrespect.

Discord & Communication Etiquette

The official Discord exists for announcements, clarifications, and community conversation. It is not a personal complaint box or exploit lab.

• Keep discussion on-topic, civil, and appropriate for an academic setting.
• Do not spam, derail channels, or flood chats with repetitive complaints.
• Do not incite dogpiles or coordinated hostility toward organizers, challenges, or other participants.
• Use private messages for direct questions to admins when appropriate.

Feedback & Criticism

Feedback is welcome when it is constructive. Critique ideas, not people. If something is broken or unclear, explain the issue calmly and precisely.

• Report broken challenges, ambiguous wording, or technical issues via support channels.
• Avoid turning public channels into complaint threads.
• Do not recruit others into hostility toward the contest or staff.

Fair Play & Infrastructure Abuse

Respect the intended scope of the contest and its infrastructure.

• Do not attack, probe, or disrupt contest infrastructure outside of challenge scope.
• Do not attempt DDoS/DoS, brute-force platform logins, or abuse support systems or scoring APIs.
• Do not attempt to access or modify other teams’ instances or data.
• Do not use the contest environment to launch attacks against unrelated external targets.
• Do not share flags, write-ups, or full solutions before the contest officially ends.

Attacking infrastructure is not “part of the game” unless explicitly stated by a challenge. If you are unsure whether something is in scope, ask first.

Content Standards

Contest spaces must remain appropriate for an academic environment.

• No hate speech, slurs, or discriminatory language.
• No targeted harassment or sustained personal attacks.
• No NSFW, explicit, or otherwise inappropriate content on official platforms.
• No sharing of pirated tools, books, or software in official contest spaces.

Responsibility to Read Rules

Participants are responsible for reading and understanding these Rules and individual challenge statements. If something is unclear, ask for clarification before acting in ways that may break rules or damage infrastructure.

Reporting Violations

If you experience or witness behavior that violates this Code of Conduct, report it.

• Contact an organizer or admin on Discord (e.g., @CTF-Admin).
• Or email the primary contest contact: cjohnson@uwsp.edu.

Provide as much detail as possible (timestamps, usernames, screenshots). Reports will be reviewed and handled as discreetly as reasonably possible.

The one-paragraph version

Every challenge starts with a baseline point value P0 set by the challenge author. During an initial observation window the actual finalized value is hidden. The scoring engine watches how many unique teams solve the challenge and how solvers rate its difficulty (1–5). Once quorum is reached — or a 7-day timeout expires — the engine freezes the challenge at a final value that reflects observed difficulty, ranging from a floor of 50 points to a ceiling of 500 points. The first team to solve earns a 10% bonus on top of the frozen value. Once frozen, a challenge's point value never changes again.

The formula

The finalized point value is computed as:

d̂  =  robust_trimmed_mean( (r − 1) / 4 )       ← player ratings, mapped to [0, 1]
ŝ  =  1 / √(1 + α · N_solves)                   ← solve-count proxy, in (0, 1]
D  =  λ · d̂ + (1 − λ) · ŝ                       ← blended difficulty, in [0, 1]

final  =  round( clamp( P_min,  P₀ · (1 + β · (2D − 1)),  P_max ) )

In plain English: d̂ is the "how hard did solvers say it was?" signal (1 → very easy, 5 → very hard, mapped onto the 0–1 range). ŝ is the "how many teams solved it?" signal (fewer solves → higher ŝ, i.e., harder). We blend the two into a single difficulty score D. D = 0.5 means the challenge was exactly as hard as its baseline; below 0.5 it's easier than expected and points drop toward P_min; above 0.5 it's harder than expected and points rise toward P_max.

Constants

Symbol	Value	What it controls
α (alpha)	0.02	Solve-count sensitivity. Lower α means solves matter less.
λ (lambda)	0.60	Weight of ratings vs. solves. 60% ratings, 40% solve-count.
β (beta)	0.75	How much D can swing points away from P₀. At D=0 or D=1, points shift by ±75% of P₀ before clamping.
P_min	50	Floor. No challenge finalizes below 50 points.
P_max	500	Ceiling. No challenge finalizes above 500 points.
First-blood bonus	+10%	Awarded to the first team to solve, applied once frozen.

The two signals

• Solve behavior (ŝ). Unique team solves only. Multiple people on the same team solving something still counts as one solve. Because ŝ uses 1/√(1+αN), it degrades smoothly — the 1st solver drops it from 1.00 to about 0.99, the 10th to about 0.91, the 50th to about 0.71, the 100th to about 0.58. No cliffs.
• Player difficulty ratings (d̂). After solving, you may rate difficulty 1–5. Only solvers can rate; each solver rates once. Ratings are aggregated via a robust trimmed mean: for N ≥ 5 ratings we drop the most extreme value from each tail; for N ≥ 10 we drop two from each tail. That limits any single lowball or over-hyped rating from swinging the outcome. A random-but-reproducible sample of ratings is used (HMAC-keyed shuffle seeded from the challenge ID and a server secret) so which ratings count cannot be gamed by coordinating submission order.

When ratings are sparse (below scoring_min_ratings_for_d = 5), the engine leans on ŝ alone rather than trusting a shaky d̂.

Freeze policy

A challenge freezes when any one of these fires, whichever happens first:

• Solve quorum — enough unique teams have solved. The quorum is dynamic: clamp(10, 100, ⌈active_teams × 0.10⌉). In practice: with 50 active teams the quorum is 10 solves; with 500 active teams it caps at 100.
• Rating quorum — enough solvers have rated. Also dynamic: clamp(5, 30, ⌈active_teams × 0.10⌉).
• Audit-period timeout — 168 hours (7 days) since release, regardless of solves or ratings. Prevents low-solve challenges from never freezing.

"Active teams" = teams with at least one login inside the rolling 7-day window. This scales the quorums to the contest's actual traffic, not a hardcoded number.

When a challenge freezes:

• The point value is announced in the contest Discord.
• The scoreboard updates to show the final score, and previously-hidden solves are credited at that value retroactively.
• The first-blood 10% bonus is applied to whichever team was the first to solve.
• The value will never change again. No live decay. No retroactive rebalancing.

What players see, when

• Before freeze: the challenge shows a "pending" status. Your solve is recorded and you can rate the difficulty, but the point value is hidden. Nobody knows the exact score yet.
• At freeze: Discord announcement. The scoreboard reveals the final value. Everyone who solved during the pending window is credited at once.
• After freeze: new solves earn the frozen value. First-blood is already assigned; new solvers don't get it.

Why this system

Traditional CTF scoring either uses static point values (unfair when difficulty is estimated wrong) or live-decaying values (unfair to early solvers who watch their reward shrink). POCTF's approach splits the difference: an observation window lets the actual difficulty settle before a single freeze commits the value. Early solvers aren't penalized for being early — they get the same final value as late solvers, plus first-blood if applicable.

The math is deliberately conservative. β = 0.75 caps how far a challenge can swing from its baseline; P_min and P_max hard-clamp the extremes. A challenge author who guessed the baseline reasonably will see a finalized value in the same ballpark; only badly miscalibrated baselines drift far from P₀.

The code implementing all of the above is in scripts/scoring.py — the constants live in the site_settings table and can be adjusted by admins, but any such adjustment made after a challenge freezes does not retroactively change its value.

Each challenge may carry up to three hints, revealed for a cost in finalized points. Hints are sequential: hint 1 must be purchased before hint 2, hint 2 before hint 3.

Cost & Spending Rules

• The default cost is 10 finalized points per hint.
• Only finalized points can be spent. Pending solves (challenges not yet frozen) do not contribute to your spendable balance.
• A team that cannot afford the cost without going negative cannot purchase. There is no debt.
• Hints are only available on unlocked, active challenges.

Authorization

For team and academic brackets, only the captain may spend the team's points on hints. Solo players spend their own points.

Refunds & Finality

Hint purchases are not refundable, including when a challenge later freezes at a lower point value than its seed. You paid for information, not insurance.

The CTF is a contest of skill. No purchase is necessary to enter. No sponsorship is offered or implied. By entering, participants agree to abide by the Rules and the decisions of the organizers.

Organizers reserve the right to refuse, withdraw, or disqualify participants at their discretion for rule violations, cheating, or misconduct. Prize eligibility requires valid registration, compliance with these rules, and (where applicable) verification of bracket requirements.

How Winners Are Determined

Winners are determined by total finalized score at contest end, per bracket. Your total is the sum of every challenge you solved, valued at each challenge's frozen point total (see the Weighted Scoring System section above for exactly how those frozen values are computed), plus any first-blood bonuses your team earned, minus any hint costs your team spent.

Concretely, your final team score is:

score  =  Σ (frozen_points for each solved challenge)
       +  Σ (first-blood bonuses awarded to your team)     ← 10% of frozen value, per challenge
       −  Σ (hint costs your team spent)                    ← 10 finalized points per hint, default

Pending (unfrozen) solves count toward your final score once they freeze — the value simply isn't visible on the scoreboard until then. There is no live point decay and no retroactive rebalancing after freeze.

Ties are broken in this order: (1) most first-blood bonuses earned, (2) most challenges solved, (3) earliest timestamp on the most recent solve. If a team solves every available challenge and earns every available point before the contest ends, the first team to do so may be declared the winner outright, depending on bracket format.

Winners are decided per bracket (Solo, Team, Academic). A participant registered for one bracket is not eligible for placement in another. See the Accounts, Brackets, & Team Composition section for bracket eligibility rules.

The following principles guide how organizers, admins, and moderators interact with participants throughout the contest:

• No direct solutions. Organizers will not provide step-by-step exploit guidance or full solutions during the contest.
• No deception. Hints may be indirect or intentionally limited, but organizers will not intentionally mislead participants.
• Equal access to impactful clarifications. Clarifications that affect gameplay will be posted publicly when appropriate.
• Corrections. Verified mistakes will be corrected. Fixes and impactful changes will be announced.
• Challenge changes. Any modification to challenge content, wording, scoring, or availability that affects fairness will be announced.
• Checksums when feasible. When downloadable files are provided, organizers will make reasonable efforts to publish checksums for integrity verification.
• No organizer participation. Organizers, admins, challenge authors, and infrastructure staff do not compete in any bracket.
• Reasonable confidentiality. Participant data and private messages are handled with discretion and used only for contest operations.
• Consistent enforcement. Organizers aim to enforce rules fairly and consistently.
• No pre-end solution releases. Official write-ups and explanations are provided after the event concludes.