GUIDES · BETSLIP DOCTOR
Why must a recorded pick be posted before kickoff?
A public pick can count only if BSD records its publication before every event in the pick reaches its scheduled start. BSD uses its server clock and the feed's kickoff time, not the capper's device clock. The cutoff establishes that the pick and its available price were on the record before the result could be known; a later post cannot be backdated into an eligible pick.
For Bettors reading public capper picks and asking when a pick can count in the record · Updated
The record needs to exist before the event begins
A pick posted before kickoff creates a timestamped record of what the capper shared before play began. That order matters: without a publication time ahead of the event, a later post could not establish that the same selection and price were on the record before the result was known.
The rule applies to every event in the posted pick. If a combination has events starting at different times, posting before a later event does not fix a pick that was posted after an earlier event's scheduled start.
BSD uses its server time and scheduled feed kickoff
The official comparison uses BSD's server-recorded post time and the event start in BSD's feed. It does not use the capper's phone clock or a later typed explanation to set the record time. A device clock can be different from the service clock, so it cannot determine whether a pick meets the cutoff.
A posted pick is locked and cannot be edited. Removing the post after publication keeps the pick and its result in the record with a deleted-after-posting label. That preserves the original record instead of allowing the timeline to be rewritten after the event.
The publication time also anchors the available price
The capper record stores prices available in BSD's feed in the minute the pick is published. The record rules also say a claimed price better than the best available line is capped at that line. If fresh server evidence is unavailable, BSD shows the pick as unverified and the badge stays off.
A pre-event timestamp therefore does not prove that every price will stay available later. It documents the post and price evidence BSD had at publication; sportsbook prices and the event can change afterward.
Compare the post time with every event start
When reading a record, check the pick's BSD publication time and the scheduled starts for all events included in it. The pick must precede each one. If an event start is missing or the record lacks fresh server evidence, do not assume the pick met the cutoff.
This timing rule is one part of record eligibility. BSD still requires settled-pick volume and complete evidence for the record badge. A timely post does not by itself verify a record or predict a result.
- Use the publication time recorded by BSD.
- Compare it with every event's scheduled feed start.
- Do not substitute a phone clock or a later edit.
- Treat missing time or price evidence as unverified.
Illustrative example: a combination with two start times
Imagine a fictional public pick combining two events. BSD's feed shows one scheduled start earlier than the other. If the pick is published after the earlier start, it fails the before-every-event rule even if the later event has not begun. A capper cannot use the phone's clock or remove-and-repost it later to establish an earlier server time. No real event, pick, price or outcome is represented.
Related questions
If the capper's phone shows an earlier time, can that establish when a pick was posted?
No. BSD uses its server clock for publication time; it does not use the capper's device clock.
Can a pick count if one event in the combination already started?
The rule requires posting before every event's scheduled start. A start that has already passed fails that condition for the pick.