prepared privately · illustrative only · not affiliated with Kalshi · not indexed
After the Washington order, injunction compliance is now an evidence problem.
A court can order a geofence. What a court, outside counsel, or a state cannot easily see is whether, for one specific user session, the check actually ran, under which jurisdiction, under which rule version, and with what result. Today that answer lives inside the same platform whose conduct is in question.
Hive comes alongside the platform as a sidecar. At the moment of each eligibility decision it makes an independent, signed receipt that anyone can check offline. It never places a trade, sets a price, decides who may transact, or drives the platform. It does not judge. The receipt proves the fence ran. It does not decide legality and does not guarantee compliance.
Washington · July 20, 2026
King County Superior Court found the state likely to succeed and ordered records preserved; specific injunction terms are due Aug. 5, 2026. This is a preliminary order, not a final ruling.
A state-court order sets a geolocation deadline with fines escalating to $500,000 per day from Aug. 13 for missed compliance. This is an interim order, not a final ruling.
A federal court denied a preliminary injunction against the state gaming regulator; the AG and Governor issued an official joint statement. This is a preliminary-injunction denial, not a final ruling.
Where an eligibility-decision record is now, where a signed receipt takes it, and what stays yours.
● today · current state
You can show your logs
When a court, an outside counsel team, or a state asks whether a specific session was screened, you look it up and explain it from your own logs. Useful, but the record is held by the same platform whose conduct is in question, so the dispute becomes he-said, she-said.
● with Hive · sidecar state
You can hand over proof
Each eligibility decision gets an independent, signed receipt made at the moment it happened: that a location check ran, the jurisdiction determined, the rule version and effective date applied, the allow or block result, and the timestamp. Anyone can check it offline, without querying your systems.
● travels with the record · portable
The receipt goes with the evidence
The signed receipt can travel with a discovery production, a filing, an outside-counsel packet, or an independent monitor review. The evidence is built at the moment of the decision, not reconstructed under deadline pressure weeks later.
follow one user session · synthetic data · runs in this tab
Follow one Washington user session to a signed receipt
A user opens the app in Washington and tries to take a sports contract. Watch the location signal resolve, the jurisdiction and rule version apply, the sports contract get blocked, a receipt get signed, and the block become independently checkable offline. Switch the jurisdiction to see the same session resolve differently. Nothing here is real Kalshi or user data. It is synthetic, made to show how the sidecar works. Hive never decides who may transact.
● what a log shows today
● what a signed receipt adds
Signedanyone can check it
Press Run this session to watch the eligibility receipt get stamped at the moment of the decision.
offline verifier · runs entirely in this tab · no telemetry after page load
Check an eligibility receipt yourself. No install.
This builds a real signed receipt for a Washington eligibility decision, 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. Everything runs in this tab, using the same signing engine, offline check, and 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.
In-browser · offline The verifier never leaves this page except to read its own sample and soak-test file from this site.
Idle. Click 1 · Build & check a receipt to load the engine and run the first check. Everything runs in this tab.
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.
rule version and effective date · runs in this tab
Which rule applied, and when it took effect
Many disputes turn not on whether a rule existed, but on which version governed a specific action at a specific moment, and when that version took effect. This binds the exact jurisdiction rule set, its version string, and its effective date into the same signed receipt as the eligibility decision, so the governing rule for one session is a matter of independent record rather than an after-the-fact account. All values are synthetic.
the session
jurisdiction · WA
rule set · wa-gambling-block
version · v2026.07.20
effective · 2026-07-20
the decision
contract type · sports event
location check · performed
result · blocked
at · synthetic timestamp
what the receipt fixes
rule version bound · yes
effective date bound · yes
independently checkable · offline
raw account data · 0 bytes
Idle. Press Seal this rule-version receipt to bind the jurisdiction, rule version, and effective date into a signed receipt.
The rule version and effective date are content-addressed inside the receipt. Change either after signing and the address changes, which breaks the seal. This proves which rule governed the session. It does not judge whether that rule was correct, adequately disclosed, or lawful.
discovery evidence bundle · deterministic · runs in this tab
Group many sessions, then seal the bundle
A discovery production, a filing exhibit, or an independent-monitor review usually covers many sessions, not one. This compact demo takes three signed eligibility decisions from one synthetic day, rolls them into a single grouped proof vector, folds it into a signed bundle a court or an opposing party can check offline, and lets you change one session after signing to watch the check refuse it. All values are synthetic.
session 1 · Washington
location · WA resolved
contract · sports event
rule · wa-block v2026.07.20
result · blocked
session 2 · Michigan
location · MI resolved
contract · sports event
rule · mi-geo v2026.07.13
result · blocked
discovery rollup
sessions sealed · 3 of 3
weakest link · none flagged
state · recoverable
raw account bytes · 0
Idle. Press Assemble and seal to roll the day's eligibility decisions into one grouped proof vector and fold it into a signed bundle.
This is a grouped proof over synthetic sessions folded into a real signed frame, not a Kalshi production and not user data. The rollup names the weakest link for review; it does not grade the underlying legal question.
insider-surveillance receipt · synthetic data · runs in this tab
A signed record that the surveillance check ran
Kalshi's head of enforcement, Robert DeNault, has publicly described monitoring for insider trading as the platform's top priority, and has described blocking campaign-affiliated accounts from trading on their own races whether or not they hold nonpublic information. Those are Kalshi's own public self-descriptions of its priorities. The open question is evidentiary: for one flagged account, can Kalshi show independently that the screen ran, against which affiliation list, and with what result. This demo signs that check as a receipt. All accounts and affiliations below are synthetic.
synthetic screen · one election market
account SYN-4471 · campaign-affiliatedblock
account SYN-2093 · no affiliation matchedallow
account SYN-8810 · candidate self-matchblock
screen ran against listfec-affiliations-v2026.07
what the receipt attests
that a screen was performedyes
the affiliation list versionbound
the per-account resultbound
the timestampbound
Idle. Press Sign the surveillance receipt to seal a signed record that the screen ran, against which list, with what per-account result.
This attests only that a screen ran and what it returned. It does not detect insider trading, does not define material nonpublic information as a legal matter, and it does not judge any account. DeNault's statements are cited as Kalshi's own public self-description, not as a regulatory or court finding (ABC News, May 28, 2026; NPR, July 9, 2026).
your numbers · arithmetic tool, not a forecast, quote, or ROI claim
Move the sliders. See evidence volume and time you stop reconstructing.
This is an evidence-coverage tool. It counts how many signed eligibility 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 Kalshi's real volume.
Every slider is a labelled assumption you set. This is arithmetic on numbers you enter, not a forecast, a quote, or a claim about Kalshi's real activity. No return-on-investment figure is implied.
Signed eligibility receipts / day·
Signed receipts / 30 days·
Fenced-jurisdiction decisions with a receipt per day·
Reviewed or produced sessions covered by a receipt per 30 days·
Reconstruction hours avoided covered sessions, no manual rebuild·
Raw account data moved to Hive0 bytes
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 sessions; proprietary data moved to Hive does not scale at all, because it never moves.
just filed · USPTO 64/119,279 · Jul 26, 2026
Seven upstream receipts, signed before the session receipt is cut
Here is how Kalshi could use Hive to prove eligibility, rule version, and insider surveillance
for each signed session. The seven upstream primitives below could prove that the eligibility model, its
policy state, its refusal thresholds, and every egress from the trading stack were themselves signed before
that session receipt was cut.
Environment and policy provenance
PBS™ · Provenance-Bonded SandboxThe eligibility-scoring model ran in a sandbox whose kernel, model-weights hash, and firmware version were on the signed heartbeat chain when it evaluated a Washington user.PBS · Merkle heartbeat chainupstream to the eligibility decision
Refusal Ledger™Kalshi's state-eligibility refusal thresholds live on a public Merkle mutation ledger with a ZK envelope-bond, so a regulator can verify the bounds without seeing the exact number.Refusal Ledger · ZK envelope-bondupstream to the refusal decision
Interpretability and perimeter integrity
Howler™ (SAE-triggered)A signed freeze receipt fires the instant a market-manipulation-adjacent feature activates during automated market-maker reasoning.Howler · SAE probeupstream to market-maker inference
Perimeter Bond™The eBPF bytecode enforcing insider-trading DLP on internal analytics is fingerprint-bound to the exact version filed with the CFTC.Perimeter Bond · eBPF hashupstream to every egress attempt
Weekend, incident, and settlement regimes
Diurnal Bond™High-impact settlement actions taken during weekend hours or a CFTC-declared-incident regime require k-of-n countersign before they run.Diurnal Bond · k-of-n countersignupstream to weekend and incident regimes
Egress Bond™Caps on customer-identity egress from surveillance systems are Pedersen-metered per semantic class, and a cap breach retroactively invalidates the surveillance DAG.Egress Bond · Pedersen meteringupstream to the surveillance DAG
Post-incident and regulator replay
Forensic Rail™Post-incident settlement analysis runs under a threshold-signed consortium credential and is deterministic-replayable by the CFTC, the NFA, or an independent auditor.Forensic Rail · threshold-signed credentialupstream to incident response
These seven sit upstream of the session receipt described above. None of this decides eligibility, refuses a trade, or blocks a transfer. Each one proves that the thing that made that call was itself the thing it claimed to be.
The same signed receipt fits many parts of the exposure surface documented in the current 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 or is a fast-follow. Kalshi facts referenced are drawn from primary filings and named reporting, linked at the foot of the page. Hive sits alongside, never inside the decision to allow or block.
Injunction compliance and geofencing
Per-decision geofence evidenceEach eligibility decision is sealed with the location check result, the jurisdiction, the rule version, the allow or block outcome, and the timestamp, so a court or a state has an auditable record that the ordered control ran rather than dueling assertions.HiveBound · Imprimaturhelps now for Washington Aug. 5 terms and Michigan Aug. 12 deadline
Contempt-risk postureA demonstrable, signed record of good-faith operation of the ordered control supports a contempt-risk-reduction posture in disputes like Nevada's pending contempt motion. It is evidence that the check occurred, not a defense on the merits.R3Pv · Protected Flowhelps now where a state alleges the fence was not implemented
Discovery, filings, and independent monitoring
Discovery evidence bundlesThe Washington order requires preservation of consumer records including location data. Many signed decisions roll into one grouped proof vector, so a production is a stack of independently checkable receipts rather than a screenshot of an internal dashboard.R3Pv · Protected Flowhelps now for the Washington preservation and production duty
Rule-version and effective-date bindingCustomer and settlement disputes often turn on which rule version governed a specific action and when it took effect. Binding the version and effective date into the receipt lets an arbitrator or court verify the governing rule for one session.Imprimatur · Carnac™helps now for settlement-rule and disclosure disputes
Surveillance, integrity, and trade finality
Surveillance-check attestationAn independent, append-only, signed attestation that a screen ran against a named affiliation list, with per-account results, lets an outside auditor or a regulator verify a pattern-detection claim without relying solely on internal say-so. The pending CFTC rule would weigh surveillance-infrastructure adequacy as a public-interest factor.SPIRE · SiGRhelps now as evidence a control ran; fast-follow for continuous audit feeds
Trade-finality chain of custodyThe Michigan standoff exposed that there is no neutral, tamper-evident record of what state a trade was in before and after a modification or cancellation order. A signed settlement receipt at execution and at each change creates a verifiable chain of custody.R3Pv · Hive Receipthelps now for a neutral ledger-state record; does not decide which sovereign has authority
Data feeds, keys, and the evidence floor
Integrity data-feed provenanceKalshi has named third-party data and integrity providers. A capture-side provenance receipt binds an integrity feed input to the decision it informed as a fingerprint, never the raw feed, so a downstream finding is traceable to its source.SiGR · AFiRfast-follow pending a live feed integration
Hardware-held signing keysThe signing key is born random and lives in hardware, so a stolen key cannot forge your receipts, and the compute that ran the check can be attested too. Your organization holds the pen; Hive never holds your keys.XCALIBUR · SPIREhelps now for key custody and device binding
helps now means the primitive is live in the offline verifier on this page. fast-follow means it needs an integration before it applies. Nothing here is forced onto a use it does not fit.
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.
A single eligibility decision becomes a signed exhibit: the location check, the jurisdiction, the rule version and effective date, and the allow or block result, sealed into one receipt. SiGR patent pendingSiGR →
SiGR, the Signed Inference Guarantee Receipt, signs a decision into one receipt anchored on Base. It turns trust our logs into a signed exhibit that stands up in a filing or an independent review. See the SiGR page.
The authority or eligibility is checked before a transaction runs, and any attempt without a valid pass is blocked and recorded. Imprimatur · HiveBound patent pendingImprimatur →
Imprimatur is a pre-action attestation gate. It signs a clearance before a consequential action runs and blocks any call without a valid, unexpired pass, so the authority was in place is proved up front rather than reconstructed after the fact. HiveBound binds a decision to a jurisdiction and policy boundary. Both sit alongside the platform and never decide who may transact. See the Imprimatur page.
The exact jurisdiction rule set, its version, and its effective date are pinned to the decision, so which rule governed a session is a matter of record. Carnac™ family · Carnac Gateway™ patent pendingCarnac™ →
Carnac™ sizes how much proof a decision deserves, CarnacPrompt™ carries the human-visible context and proof demand, and Carnac Gateway™ clears an action before it runs. The rule version and effective date are carried in the signed context so a change in rule is traceable to the sessions it first affected. See the Carnac™ plane, CarnacPrompt™, and Carnac Gateway™.
Many receipts from one day, jurisdiction, or account roll into a single grouped proof vector that flags the weakest link. R3Pv · Protected Flow patent pendingR3Pv →
R3Pv, the Receipt Proof Vector, groups receipts into one signed vector: verification depth, weakest boundary, recoverability, and next action. One machine-readable summary per day, jurisdiction, or account lets a review or discovery team triage instead of re-checking everything. Protected Flow rolls many receipts into one proof-state view. See the R3Pv benchmark.
Big screening jobs and multi-step checks get proof at the piece level, and streaming inputs are signed as they flow. AFiR · SiGR patent pendingAFiR →
AFiR, Attested Fragmented Inference Routing, breaks a request into signed, routable sub-tasks and signs each fragment inside the path, so a multi-step surveillance or eligibility check is provable step by step. See the AFiR page.
The signing key is born random and lives in hardware, so a stolen key cannot forge your receipts. XCALIBUR · SPIRE patent pendingXCALIBUR →
XCALIBUR is a hardware root of trust: a signing device that keeps the key in silicon, born from quantum-grade randomness and bound to the device. SPIRE gives a service or agent instance a signed identity, so which system signed a receipt has a signed answer. See the XCALIBUR page and SPIRE in the proof architecture.
Under it all sits the evidence floor that holds a decision record still while proof is attached, so it can be rebuilt and re-checked offline. InkFrame v1 · Carnac Live Ink™ patent pendingInkFrame →
Carnac Live Ink™ writes non-mutating evidence frames. InkFrame v1 holds a proof-completion frame still using eight content-addressed roots and a hybrid Ed25519 with ML-DSA-65 signature. Change one byte and the address changes, which breaks the seal. See InkFrame v1 and Carnac Live Ink™.
Settlement receipts can be anchored and, where a partner wants it, paid and reconciled on a public rail. Hive Receipt · x402 · Base USDC patent pendingHive Receipt →
A Hive Receipt can be anchored on Base (chain 8453) and, where a counterparty wants a settled record, verified through the x402 rail with USDC settlement. This is optional infrastructure for a neutral, checkable ledger-state record, not a requirement for the offline verifier on this page. See the receipts page.
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.
You hold your own signing keys
You keep the private key that stamps your receipts. Nobody else can sign in your name, and the key never leaves your own hardware. The signature is yours, not Hive's.
Hive stays a non-custodial sidecar
Hive gives you the way to make and check receipts. It does not place a trade, set a price, decide eligibility, or run the platform, does not enter the decision loop, and does not move or store your raw account or location data. Each decision is recorded as a one-way fingerprint and cryptographic commitment, never the underlying data.
Turn an eligibility decision into a portable trust asset
As the state patchwork deepens and orders carry deadlines and fines, a court, outside counsel, or a state will ask whether the ordered control ran for a specific session. A signed, independently checkable receipt at each eligibility decision is how that answer stays provable. Naming Kalshi does not imply any agreement, and this page does not state or imply that Kalshi is a customer, partner, pilot, or endorser, or that Kalshi uses Hive.
This page is illustrative only. It is prepared privately by Hive Civilization Inc. and is not affiliated with, sponsored by, or endorsed by Kalshi or KalshiEX LLC. It does not state or imply that Kalshi is a customer, partner, pilot, or endorser, or that Kalshi uses Hive.
Every session, account, jurisdiction rule, timestamp, and receipt shown in the demos is synthetic and made to illustrate how the service works. None of it is real Kalshi, user, account, or location data.
A signed receipt proves that a check ran and what it returned. It does not decide legality, does not guarantee compliance, does not resolve federal preemption, and does not adjudicate any court matter. Court and current facts on this page are cited to primary filings or named reporting and carry their exact status, which is preliminary, pending, interim, or final as labelled. They should be re-verified before any external use given the pace of docket activity.
Private, illustrative overview · noindex / nofollow / noarchive / nosnippet · not affiliated with Kalshi or KalshiEX LLC; this page does not state or imply that Kalshi is a customer, partner, pilot, or endorser, and does not imply Kalshi uses Hive · the sessions, accounts, jurisdictions, rules, and receipts shown are synthetic and made to illustrate how the service works; they are not Kalshi or user data · Hive is a sidecar; it does not place a trade, set a price, decide eligibility, or run the platform, does not enter the decision loop, and does not move or store raw account or location data · a signed record that a check ran is not a statement of legality, and does not guarantee compliance · Hive never reads the underlying data; each decision is recorded as a one-way SHA-256 fingerprint and cryptographic commitment, not the raw signal · Carnac™ sizes how much proof a decision deserves. It does not judge. · verification is free, works offline, and needs no account · signatures use a hybrid of Ed25519 and ML-DSA-65 (NIST FIPS 204), a federal standard · court and current facts are drawn from primary filings and named reporting and to be re-verified before external use: Washington King County order (MarketWatch, PNW Daily); New York (NY AG, Reuters); Michigan (World Casino News, Bloomberg Law); Ninth Circuit tribal appeal (Bloomberg Law); CFTC Michigan order (Reuters); DeNault statements (ABC News, NPR) · Carnac™, CarnacPrompt™, Carnac Gateway™, and Carnac Live Ink™ are Hive marks · all Hive methods patent pending · prepared by Hive Civilization Inc. · Wyoming, USA
HIVE UNDER THE STACKInvisible protection. Signed verification. Every step. End to end.Intent›Authorize›Prove›Execute›Attest›SettleNo engines touched. No data moved. Every step checkable.
new in the canon · runnable on this page
Make each eligibility fence inspectable
This receipt adds a portable account of a particular eligibility and exclusion screen beside the jurisdiction rules and session evidence described here. It is deployed and open to verify, so the run below is a live check, not a mock.
screening.attestation · Deployed in production
Show the screening context behind one contract decision
For a regulated event contract, this receipt records that a named screening engine evaluated a protected participant reference against the declared eligibility and exclusion lists. It fixes the rule set, list versions, content fingerprints, screening time, external clock reference, verdict, and validity period in one signed record. A compliance reviewer can see whether the Washington session was cleared, matched, or rejected under the stated materials without receiving the underlying identifier. The record also retains the signing authority that was required for that result. Legal, risk, and market operations can use the same compact evidence when one contract access decision becomes a question.
What it does not do. It does not show that the lists were complete, accurate, current, or appropriate for any legal obligation, and it does not decide that a person was actually prohibited or eligible. It cannot catch every false negative, reveal the participant, list entry, or match score, enforce a block, or establish legal or regulatory compliance.
POST /verify/screening-attestation · case pass, a clean record
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/screening-attestation · case matched, a name matched the list
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/screening-attestation · case fail, a forged record
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Every run above posts a verified request body from this domain to the open verify route and prints what came back. The example receipts are signed with published example keys, so verify reports key_trust example_registry. That is on purpose. Nothing on this page is a production issuance, a customer record, or an endorsement. Patent Pending.
Canon cross reference
The exact canon entries behind this page
Each link opens that entry in the canon implementation explorer, where its schema, mint route, open verify route, auth requirement and implementation state are stated. The state shown here is read from the same registry file the explorer renders from, so the two cannot drift apart. Nothing here implies a customer, a deployment or an endorsement.