Fairness and Security Controls
FCTF applies multiple controls to keep competition fair under load while protecting challenge runtime infrastructure.
Control Matrix
| Control area | Contestant-visible behavior | Practical effect |
|---|---|---|
| Prerequisite gating | Locked challenge indicators and blocked solve actions | Prevents progression bypass |
| Captain-only policies | Only captain can start/submit notices | Enforces team governance rules |
| Submission cooldown | Cooldown countdown after incorrect/rate-limited submits | Reduces brute-force pressure |
| Attempt budget | Attempts counter and max-attempt stop behavior | Preserves challenge fairness |
| Deploy quota | Deploys: current/max indicator on challenge detail | Prevents unlimited environment churn |
| Tokenized gateway access | [YOUR ACCESS TOKEN] block with HTTP/TCP access format | Restricts runtime entry to authorized teams |
| Team activity logging | Action history with filters/search | Provides accountability and dispute evidence |
Runtime Access Security
Deploy-required challenges expose access only after token issuance.
- HTTP mode requires query token in gateway URL.
- TCP mode requires token authentication in terminal session.
- Access token is tied to challenge runtime state and can be invalid after stop/expiry.
Runtime Safety Limits
The following limits may be active per challenge or event configuration:
- Maximum submission attempts
- Cooldown between submissions
- Maximum deploy count
- Team-level challenge concurrency limits
- Time limit with auto-stop behavior
Contestants should monitor these values in challenge detail before starting aggressive solve attempts.
Operational Guidance
- Check
Attempts,Deploys, andTimebefore starting. - Avoid rapid repeated submissions during cooldown windows.
- Stop runtime when done to release capacity for other teams.
- Use tickets with action-log context when reporting anomalies.