A 24-hour waiting period is two timestamps and a rule. Nobody in this industry proves them.

Fanatics Betting and Gaming is live in twenty-three states across sportsbook, iCasino, and Fanatics Markets, built at speed on an acquired PointsBet stack. Each state has its own timed consumer-protection rules. Waiting periods before self-imposed limit increases take effect. Self-exclusion windows. Cool-off periods. Age and location gates. When a court, a state attorney general, or a gaming regulator asks whether a specific control fired for a specific customer on a specific day, today's answer comes out of the operator's own logs. Those logs are admissible. They are also, structurally, a record the defendant wrote about itself.

Hive comes alongside Fanatics as a sidecar. At the moment of each timed consumer-protection control, it makes an independent, signed receipt that anyone can check offline. It never accepts a deposit, sets a limit, decides eligibility, or drives the platform. It does not judge. The receipt proves the clock ran and the rule was checked. It does not decide legality and does not guarantee compliance. It is invisible to your users, invisible to your risk engine, and fail-open. If Hive is unreachable, Fanatics operates exactly as it does today.

Three simple states

Where a timed-control record is now. Where a signed receipt takes it. What stays yours.

Follow one limit-increase request to a signed receipt pair

A customer opens the Fanatics app in one of several states and requests an increase to a self-imposed deposit or spending limit. Watch the state rule resolve, the current limit read, the requested limit apply, the 24-hour clock start, the request receipt sign, and, 24 hours later, the effective-time receipt sign. Switch the state to see a different waiting period apply. Nothing here is real Fanatics or customer data. It is synthetic, made to show how the sidecar works. Hive never sets a limit, allows a deposit, or drives the platform.

Check a waiting-period receipt yourself. No install.

This builds a real signed receipt pair for a synthetic 24-hour limit-increase request, checks it in your browser, lets you break one byte and watch the check refuse it, re-checks pasted evidence, and re-verifies a published 5,000-receipt soak test. Same signing engine, same offline check, same receipt structure Hive uses across every illustrative proof page on this site.

The signing engine is bundled and served from this same site. After the page loads it makes zero outside calls except two same-site file reads it names out loud. Core verification is fully offline.

Every click prints the recomputed hash next to the stored hash, one line per layer. A changed byte reads FAIL in the same output; a clean receipt reads PASS. Success is labelled, never color alone. There is no server round-trip.

Which state rule applied, and when it took effect

The waiting-period requirement, the self-exclusion window, and the cool-off duration vary state by state. Twenty-three states means twenty-three variations that can each be amended by a state regulator. When a plaintiff, a state attorney general, or an Indiana Gaming Commission-style inquiry asks which rule governed a specific request, this binds the exact rule set, its version, and its effective date into the same signed receipt as the request and the effective-time pair. The governing rule for one control becomes a matter of independent record, not an after-the-fact account. All values are synthetic.

Group many requests, then seal the bundle

A state AG production, a plaintiff discovery request, a gaming commission audit, or a settlement demand usually covers many requests, not one. This demo takes three signed timed-control receipts from one synthetic day and rolls them into a single grouped proof vector. It folds that into one signed bundle a court, a state, or opposing counsel can check offline. Change one receipt after signing to watch the check refuse it. All values are synthetic.

A signed record that the 24-hour clock ran

The Koester complaint alleges that six states' 24-hour waiting periods on self-imposed deposit and spending limit increases were not consistently honored. The evidentiary question is narrow. For one customer account, can Fanatics show, independently, that the request was received at time T, that the effective time was T plus 24 hours or later, and that the increase did not take effect early. This demo signs that pair as a receipt. All accounts and policies below are synthetic.

Move the sliders. See evidence volume and time you stop reconstructing.

This is an evidence-coverage tool. It counts how many signed timed-control receipts a given daily activity level produces and how much reconstruction time signed coverage can remove. Every value below is a number you set. It is not a forecast, a quote, or a dollar-savings claim, and it makes no assumption about Fanatics' real volume.

Whatever you enter, the last number is always zero. Receipts carry one-way fingerprints and commitments, never raw account or location data. Evidence volume scales with requests; proprietary data moved to Hive does not scale at all, because it never moves.

Seven upstream receipts, signed before the request receipt is cut

The request-level receipt above proves the 24-hour clock ran between request and effective time for one control. The seven upstream primitives below prove that the timed-controls engine, its policy state, its refusal thresholds, and every egress from the RG stack were themselves signed, before that request receipt was ever cut. Live and operational today.

These seven sit upstream of the session receipt described above. None of this decides eligibility, refuses a wager, or blocks a customer. Each one proves that the thing that made that call was itself the thing it claimed to be. Live and operational today.

Filed. July 26, 2026. USPTO application 64/119,279. See upstream group in Hive Proof Architecture → · Read the essay →

Eleven Fanatics surfaces, each a receipt

The same signed receipt fits eleven distinct Fanatics decision surfaces, from the timed controls at the heart of the Koester complaint out to the whole-platform record. Here is where it earns its keep, in plain words, with the Hive primitive named as a small label and a candid read on whether it helps now. Public reference material used in preparing this overview is linked at the foot of the page. Hive sits alongside, never inside the decision to allow or block.

Every primitive named here is live in the offline verifier on this page. Nothing is forced onto a use it does not fit. Hive proves conditions, never verdicts.

What supports this behind the scenes

You do not need any of this to understand the value. It is here for the people who want to look under the hood. Each row is a plain benefit first, with the Hive part named as a small label.

Explore Hive Proof Architecture.

The keys stay with you

In plain words: your organization holds the pen that signs. Hive never touches your proprietary account or location data, never decides who may transact, and never holds your keys.