> For the complete documentation index, see [llms.txt](https://jordan-7.gitbook.io/jordan-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jordan-7.gitbook.io/jordan-docs/internal/run-b-verification/limitations-register.md). # Limitations register Every assumption and unverified claim, by id, with source, mitigation, residual risk, and what would close it. L1–L12 are summarised on the public [verification limitations](/jordan-docs/verification/verification/limitations.md) page and expanded here; L13 onward are internal. Ids are stable: a closed item keeps its row with a **CLOSED** note rather than disappearing. | Id | Limitation | Source | Mitigation | Residual risk | What closes it | | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | L1 | No stranger has been verified; every real-broadcast proof was the operator's channel or a harness | `OPEN-ISSUES.md`, 2026-08-26 → 09-03 | `_gate-run-b-pipeline.mjs`; the rehearsal harnesses; the retest checklist | a configuration, platform or network shape never produced | a launch retest with a second party's stream | | L2 | Self-capture assumes a broadcast delay of at least 12 s; at D = 0 a 30 s clip loses its first 6 s | `bounty-claim.config.js`, "WHAT 51s DOES NOT COVER" | D\_min = 12 s measured on a real broadcast; stub clips are short | a faster platform, or a clip cap above 30 s, breaks the derivation unless both values are re-derived | measure D on every new platform; a gate that plays a 30 s clip through a zero-delay stub | | L3 | Kick self-capture underperformed the Twitch archive path on its first real run (1/5 vs 4/5) | `OPEN-ISSUES.md`, "KICK'S FIRST REAL BROADCAST" | freeze window re-derived (`b3ccf8b`); 2× sampling; run #5 PASS 5/5 predates the re-derivation | not re-measured since | a Kick rehearsal on the current window (Outstanding B2) | | L4 | The OBS scene check is client-reported | `web/lib/obs-scene-check.mjs` | never a hard gate; corroboration only; tiers 2 and 3 pay the same | none for payout; support quality depends on it | none needed — by design (`DECISIONS.md`, 2026-08-25) | | L5 | Self-capture is MegaChat's own artefact | `bounty-confidence.js`, tier 3 | freshness checks (`_gate-capture-stall.mjs`: a stalled recording is marked stale on its evidence row; `_gate-stale-capture.mjs`, which replayed the preserved 2026-08-29 captures, fails by design since 2026-10-24, its fixture gone); external cross-check where a replay exists | no external copy on X or Kick-without-URL | a streamer-supplied Kick VOD URL (Roadmap) | | L6 | A legible badge with a covered clip would verify | this pass, reading `bounty-ocr.js` and the tile layout | the badge is drawn inside the tile | a layout that reveals the badge and hides the video | a visual check of the tile, not built or specced | | L7 | 720p minimum; 480p marginal | `docs/run-b-verification.md` | streamers warned (`_gate-quality-and-platform.mjs`) | 480p-only streamers | a larger badge at low resolutions ("nobody has", `OPEN-ISSUES.md` 07-29) | | L8 | A fixed corpus hides what it holds fixed | `5ebd643`; `OPEN-ISSUES.md` 07-29 | `_gate-decoder-codes.mjs` re-draws codes | any other fixed property | vary the next property before quoting a number from it | | L9 | Stubs publish instantly (D ≈ 0) | `OPEN-ISSUES.md`, "Why 23 green gates missed both" | `_gate-broadcast-delay.mjs` | any gate not using the lagging stub proves nothing about delay | adopt the lagging stub wherever delay matters | | L10 | Bounty settlement is a stub; the app's other transfers now go through a real door | `bounty-settlement.js`; `settlement.js` (E38) | Gate H every run: the legacy scan for the bounty modules, Tier 1 for the door; a damaged money ledger halts both doors rather than reading as empty (`bounty-ledger.js`, `ledgerHealth`) | the bounty path is untested by definition; the door's outbound transfers and every escrow write are now signed ahead, and sign-ahead has never run on chain — stand-ins only (`OPEN-ISSUES.md` U7) | `RealSettlement` for bounties + retest rows 8–12, 24; Part 4 and the U7 dust runs for the door | | L11 | The evidence chain and ledger live on one volume, unreplicated | `bounty-evidence.js`, `bounty-ledger.js` | integrity chain; torn-tail recovery; a damaged interior latches, so every later read and append refuses instead of serving an empty view or writing onto the damage (`ledgerHealth`, reported on `/api/health`) | loss of the volume is loss of the evidence | replication or off-volume backup — not specced | | L12 | Captures retained 14 days | `captureRetentionMs` | `claimTtlMs` matches | a late dispute has no frames | a longer retention for disputed sessions — not specced | | **L13** | **CLOSED 2026-09-16 (Pass C).** The badge WAS pinned bottom-left regardless of the layout origin, so a bottom-left stack covered the one thing the verifier reads. It now takes the corner diagonally opposite where the stack actually lands, and a layout that would still reach it at the ceiling is refused at save time with a reason. | `public/overlay.html`, `applyBadgeAnchor`; `rooms-store.js`, `layoutCollision` | `_gate-overlay-layout.mjs` 33/0 across all sixteen origin/direction combinations, measured in a real browser | none known; no production room had ever chosen a non-default origin | — | | L14 | X's self-capture address is client-supplied and unbound to the X identity (A1) | `OPEN-ISSUES.md`, adversarial review | platform derived from the claim | an X claimant supplies a URL to a stream they control | pin to a handle-derived URL or require an ownership proof on the URL | | L15 | One degraded Privy fetch can delete `platformLogins` (A2) | `privy-identity.js:191` per `OPEN-ISSUES.md` | none | a transient upstream failure silently revokes a streamer's ownership proof | additive merge; never write an empty fetch | | L16 | `verifiedClips` counts scaffolding windows | `OPEN-ISSUES.md`, pump.fun P1 | none | the payout unit is inflated on rehearsals; real sessions have no canary unless the harness is used | a marker excluding canary/setup windows from scoring | | L17 | pump.fun's "hollow live" placeholder is indistinguishable from a real broadcast by API signals | `OPEN-ISSUES.md` T6 | `live && !!playlistUrl` narrowing (insufficient, measured) | a session airs to a placeholder and verifies 0/5, looking like a capture bug | the fail-safe report option (T6, chosen not built) | | L18 | Calibration residual can exceed code validity (R1); `minDetectionRate` sits on a 0.05 margin (R2) | `OPEN-ISSUES.md` R1–R3 | edge-shifted sample instants; err high on the rate | honest sessions routed to review more often than necessary | measure `timelineSpreadMs` across real broadcasts | | L19 | A truncated calibration once reported a confident MEASURED on an inconsistent timeline; unreproduced in five attempts | `OPEN-ISSUES.md`, "Calibration once swallowed" | majority-cluster safety; DISAGREEMENT routes to review | "confidence the system has not earned" if it recurs | log discarded probes and cluster size on every calibration | | L20 | Capture storage has no global ceiling | `OPEN-ISSUES.md` (08-24 onward) | per-session bound (\~28 MB live, one window per clip); at most 50 recorders at once, each stopping itself after 12 h or 30 min of failed polls (`bounty-claim.config.js`, `captureMaxActive`, `captureMaxAgeMs`, `captureMaxErrorRunMs`) | many concurrent sessions fill the volume; no byte cap on `bounty-captures/` | a ceiling like `clipStoreMaxBytes` | | L21 | Eleven browser gates judge whatever `web/.next` is on disk | `OPEN-ISSUES.md`, 2026-09-16 | G0 in `_gate-bounty-claim.mjs`; the same check lifted into `_gate-helpers.mjs` as `assertFreshBuild()` | a browser gate that does not call it, and grades a `web/` page, still describes the previous tree | every gate that renders a `web/` page calls `assertFreshBuild()` | | L22 | Several gates sleep a fixed time after spawning a dev server; one appeared to pass against a zombie | `OPEN-ISSUES.md` W5 | `startGateServer` exists | a stale server passes a gate | port the listed gates | | L23 | The gate suite has no single entry point and four result formats | `OPEN-ISSUES.md` T2 | none | "the suite is green" is unverifiable in one command; T1 hid for weeks | a runner with isolation/retry and one result format | | L24 | The breaker is inert until Cloud webhooks are configured; capacity figures are models | `OPEN-ISSUES.md` L3, L4, L2 | the abandon cap; the long-session alarm | a leak spends money before a human looks | O3, O4 on the owner's list | | L25 | Earned reward credits are in memory | `reward-credits.js` | none | a restart zeroes viewers' earned balances | persistence — not specced | | L26 | `followersOnly` / `subsOnly` gates are stored but unenforced | `checkFeatureGates`, `server.js` | the dashboard says so | a streamer believes a gate holds that does not | platform verification (Roadmap) | | L27 | Handles are reassignable at the identity layer; consumers must pin the identity | `OPEN-ISSUES.md`, "A HANDLE IS NOT AN AUTHORIZATION TOKEN" | the whitelist pins `identityKey` | the next consumer forgets | a resolve-to-identity helper in `identity-store.js`, or non-reassignable handles | | L28 | The docs' HTML-comment markers (``, ``) assume GitBook preserves HTML comments on sync | `scripts/docs-sync.mjs` | comparison is on normalised text so re-indentation is tolerated | if GitBook strips comments, `docs:sync --write` cannot find its regions after the first sync-back | confirm on the first bi-directional sync; fall back to fenced-block sentinels if needed | | L30 | **The z-order direction real OBS uses is unverified.** `web/lib/obs-visibility.mjs` treats a higher `sceneItemIndex` as nearer the viewer; the shared mock returns the array position and cannot settle it, and nothing in the repo states the real convention. | `web/lib/obs-visibility.mjs`, `HIGHER_INDEX_IS_ON_TOP`; `_gate-mock-obs.mjs` | If the direction is backwards the result is a MISSED occlusion detection, never a false accusation and never a payout difference — the signal does not gate a payout. | An occluded overlay reported as visible. | One real OBS session — the same one B1 tracks. | | L31 | **Occlusion cannot see transparency.** Bounding boxes are all OBS reports, so a 10%-opacity full-screen source reads as a full cover and a transparent PNG reads like an opaque one. | `web/lib/obs-visibility.mjs`, `coveredFraction` | The 60% coverage threshold and the fact that the signal never gates a payout. | A streamer with a decorative full-screen frame could see a spurious "covered" banner. | Reading actual pixels, which obs-websocket does not offer. | | L32 | **Five browser gates assert against a replaced UI** and have been red since the overhaul. | `OPEN-ISSUES.md`, 2026-09-16 | The freshness guard now stops any of them grading a stale build. | "The browser gates are green" is unverifiable; the retest checklist depends on them. | Re-pointing them at the current UI (E35). | | L33 | **CLOSED 2026-09-18 (E38).** The seat pending bucket now controls real money: ticks pull into the platform wallet (`settlement.pull`), and every sweep, buried-seconds refund, clawback and maturity is an intent at the door (`settlement.js`), paid by `flush()` once `PLATFORM_SETTLEMENT_KEY` is set. Residual: that key is unset on production, so every outbound intent is recorded and PENDING — nothing has paid out yet, by design until Part 4. | `settlement.js`; `_gate-money.mjs` E1–E3 | — | — | Part 4 (fork rehearsal, capped mainnet run) | | L34 | **MPP seats do not pause on `overlay_hidden`.** Client-signed vouchers cannot be refused without tripping the stale-kick. | `server.js`, `tickAllMeters` | The bucket still records and refunds buried seconds for them. | An MPP guest keeps being charged during a bury until the refund lands. | A pause message to the client meter, or a server-side tick window; U1 decides whether MPP is even live. | | L35 | **CLOSED 2026-09-18 (E38).** A credit-bearing seat fixture exists: a viewer earns points over the rewards WebSocket, joins as `points_stream`, goes live over the real socket and is metered by the real tick loop; the gate reads ACCRUE rows off the seat ledger, posts `overlay_hidden` as the owner and asserts the rows stop, then resume. Building it found E42 (points seats were priced in USDC atomics and kicked on their first tick) and E43. | `_gate-meter-pause.mjs` 14/0 | — | — | — | | L36 | **Tier 2 is blind to the settle itself.** The MPP SDK settles a channel on the `settlementSchedule` it is handed; no call site exists in our source to scan or intercept. | `meter-mpp.js`; `_gate-money.mjs` T2 | The schedule is asserted to be configured in exactly one file; a second configuration fails the gate. | A channel could settle at a moment and amount the ledger did not intend, and only the chain would know. | U1 (whether MPP is live at all); if it is, a receipt-reconciliation pass over channel settles. | | L37 | **Tier 3 pins names, not behaviour.** A viewer's session-cap approve and channel open are signed in the viewer's wallet; the operator gates and probes sign with keys on this machine. No server door can mediate them. | `_gate-money.pins.mjs`; `_gate-money.mjs` T3 | The per-file count of transfer-shaped names is pinned; a new site or file fails the gate. | A change inside an existing site (a different amount, a different recipient) keeps the count and passes. | Nothing static can; a browser rehearsal that reads the wallet prompt. | | L38 | **There is no Tempo testnet stage.** The app went from Arc testnet to Tempo mainnet (chain 4217) with nothing in between: no Moderato token addresses, RPC or wallet layer exist in the tree, and `TEMPO_CHAIN_ID` overriding the id would not make them exist. Every chain-touching rehearsal is a fake chain, a fork, or mainnet dust. | `server.js`, chain config; `OPEN-ISSUES.md`, 2026-09-18 (E38) | `_gate-money.mjs` runs the door against a counting fake chain; Part 4 plans an anvil fork of Tempo. | A fork may not replicate Tempo's fee-token / DEX precompile behaviour; if it does not, the only rehearsal is capped mainnet spend. | Part 4's first 30 minutes decide it. | | L39 | **Credit- and points-funded seats never pay the streamer.** Their escrow buckets carry no token address, so every sweep and refund for them is RETAINED at the door. That is the pre-E38 behaviour made explicit — the credit lives in the reward pool, not the platform wallet — not a decision about who should pay. | `server.js`, `addParticipant` (E43); `settlement.js` | Nothing pays out money the platform wallet never received. | A streamer whose room pays points, or earned USDC credit, earns nothing from those seats. | O15: decide whether the reward pool pays the streamer's share (signer `rewardPool`) or the platform funds it. | | L40 | **A gate-booted server reads `.env`, so the seller and reward-pool keys are live in every HTTP gate.** Only the fixture's payment mode (points, credit, the bounty stub) keeps a gate off-chain, and the flush timer would pay a reward-pool intent for real if one were enqueued. | `_gate-helpers.mjs`, `startGateServer`; `server.js` boot | `startGateServer` now starts every signer, secret and token blank, on a scratch `DATA_DIR`, unless the gate names it in `keepEnv` (`_gate-helpers.mjs`, `SENSITIVE_ENV`). | A gate that spawns `server.js` itself, outside the helper, still reads `.env`, and a future fixture there that creates a paid seat spends real money. | Port the remaining self-spawning gates to `startGateServer`. | | L41 | **The escrow contract enforces the arithmetic of an attestation, not its truth.** No contract can see an OBS scene; `hiddenSeconds` is whatever the attester reports, and silence pays the streamer in full. The signals it will consume are the Pass C visibility signals. | `contracts/MegaChatEscrow.sol`, `attest`; `docs/internal/escrow-contract.md` | An attestation can only move money toward the viewer, never toward the platform; the attest key is separate from every payout key. | A bury the platform declines to report is invisible on-chain. Row 25a records the visibility signals as mock-only, never run against real OBS. | A real-OBS rehearsal of the signals (row 25a), then a live seat through the contract (Session 2). | | L42 | **A viewer has no unilateral exit from the escrow.** The viewer never calls the contract (fee-token rules), so a deposit is locked until the deadline or a streamer refund. | `contracts/MegaChatEscrow.sol`, `MAX_HOLD`, `MAX_EXTENSION` | The deadline is at most 14 days out, escalation adds at most 7 more, once, and `finalize` is permissionless. | A viewer whose stream ended early waits for the deadline unless the streamer refunds. | Session 2 sets `releaseAt` to stream end plus the tail, which is hours, not weeks. | | L43 | **The recorded Moderato deployment is administered by nobody.** Every role is an ephemeral key discarded at exit. | `contracts/deployments.json` | It is a rehearsal artifact: readable and finalizable by anyone, never a place funds should go. | Someone treating the testnet address as operational. | The mainnet deployment in Session 2, with held keys. | | L44 | **The primary wallet path still pays the platform wallet.** Privy wallets — the wallet layer — take `/api/join/mpp` whenever the server has the MPP meter (production does), and E38 set those channels' payee to the platform wallet. Only the MetaMask / allowance path reaches the escrow. | `web/lib/join-page.ts`, `joinSeat`; `server.js`, the MPP tick handler | The escrow path is proven on mainnet and one client condition away (E48). | Real users on Privy are custodial today; the scoping claim that MPP was unreachable from the UI was wrong. | E48: route Privy users through the metered join, or point the MPP channel payee at the streamer. | | L45 | **An escrow seat's deadline is fixed at deposit.** The contract has no early release, so an honest stream waits `cap + tail + review` (24 h 10 min by default past the seat's latest possible end) before the streamer is paid. | `escrow-chain.js`, `releaseAtFor`; `contracts/MegaChatEscrow.sol` | `SEAT_ESCROW_REVIEW_MS` is configurable; finalize is prompt once due. | A streamer waits about a day for seat money; shortening the review window shortens the time a bury can still be attested. | A streamer-signed early release in a later contract version, or a shorter review window by decision. | | L46 | **The attestation's `hiddenSeconds` comes from signals no real OBS has produced.** The pause, the buried rows, and `obs_disconnected`-as-blindness all rest on row 25a's mock-only signals; on the mainnet run the bury produced a pause and `hidden` stayed 0, so the nonzero path is proven on Moderato only. | `server.js`, `attestSeatFromLedger`; `overlay-visibility.js`; `docs/internal/escrow-contract.md`, the row-25a list | The contract clamps and bounds whatever figure arrives; a wrong figure can only under-charge or over-refund the viewer, never pay the platform. | A real OBS that orders or times its events differently charges a buried viewer in full. | Row 25a against a real OBS, then one mainnet seat with a real bury. | | L47 | **A fee token reaches the chain only through viem's own Tempo chain definition.** The hand-rolled chain object the server used dropped `feeToken`, so every door transfer since E38 would have failed on mainnet with `insufficient funds … have 0` — none had ever flushed. Fixed; the dependency remains. | `server.js`, `tempoViemChain`; `settlement.js`; `escrow-chain.js`, `tempoChainFor` | Every server signer is built on viem's Tempo chain and every transfer names its fee token; `_gate-escrow-seat.mjs` exercises both doors on mainnet. | A new signer built on a bare chain object fails the same way, silently, until its first real send. | A Gate H assertion that every `createWalletClient` in the server modules is built on the Tempo chain (E50). | | L48 | **The classifier's thresholds are guesses.** 100k followers for `recognized`, 180 days and 50 followers for `plausible`, 1,000-following-under-30-days for `suspect` — every number was picked by reasoning about what a bought or farmed account can and cannot clear, with zero users to calibrate against. | `classifier.js`, `THRESHOLDS`; `docs/internal/account-model.md` | Nothing consumes the classifier, so a wrong tier costs nothing today; the numbers are exported and documented rather than buried. | The first feature that reads it inherits untested thresholds. | Real accounts to calibrate against, and a decision about what each tier should unlock. | | L49 | **Attributes are a snapshot, and go stale silently.** They are fetched at link time and when the same login re-authorises, which refreshes the username too. One consumer refreshes on read: a campaign check re-reads the X profile, with the app token, once the last read is over a day old (`campaign-engine.js`, `check`, `ATTR_MAX_AGE_MS`). Nothing else polls, so a follower count can be years old with only `attributesFetchedAt` to say so. | `attestation/`; `auth.js`, the callback's `grabAttributes` | The fetch timestamp is stored per link and shown on the account page; the classifier prefers the fresher record when trust ties. | A classification can rest on numbers that no longer hold. | A refresh prompt when `attributesFetchedAt` is old, or refresh on read for every consumer, as campaigns do. X user tokens are now stored, encrypted (`x-token-store.js`), for campaign connection checks; nothing uses them to refresh attributes. | | L50 | **A social an aggregator reports is a name without an id.** Privy tells us someone has Twitch linked and what they are called there; it does not give a platform id, so that name cannot carry attributes, cannot be proven to be them, and is not a link. | `accounts.js`, `setAccountPlatformLogins`; `privy-identity.js` | Shown separately on the account page; connecting the same platform through our own OAuth upgrades it to a real link. | Someone may believe their Privy-linked Twitch is verified to us when it is only reported. | Reading platform ids out of Privy's `linked_accounts`, if they are there, or requiring our own OAuth for anything that matters. | | L51 | **Producer mode holds a fan's money for as long as it holds the clip.** An approved MegaChat sits in `ready` until a mod airs it; the payer is not refunded until `LETTER_HOLD_TTL_MS` (6 h) elapses. | `letters.js`, `HOLD_TTL_MS`, `HELD` | The expiry is automatic and the two causes are recorded apart (`review_expired`, `never_aired`); the dashboard row counts down to the refund in words. | A fan who paid early in a show and was never aired is out the money until that timer runs. | A shorter TTL tied to the room's actual stream end rather than a fixed window — the room already knows when a stream ends (`airings-store.js`). | | L52 | **MegaChat media is now durable against a restart, which reverses a documented invariant.** Clips used to live only in memory; they are now written to `DATA_DIR/letters/media/`. | `letter-store.js`; `letters.js` | One-shot is unchanged — media is deleted about a minute after playback (`MEDIA_TTL_MS`) and on reject, refund or expiry; the handbook pages were corrected in the same pass. | A paid clip exists on the volume for as long as it is unplayed, up to the 6 h hold — where before a restart erased it. Both handbook pages asserted the opposite until 2026-09-19. | Nothing pending; the durability is the point. Sized by `GLOBAL_MAX_BYTES` (120 MB). Since 2026-09-25 a clip that completed on a recorded broadcast is also copied for that broadcast's replay, up to 30 days (`aired-clips.js`; DECISIONS "MegaChat replays"). | | L29 | The docs' claim-keyword window is ±2 lines; GitBook may reflow paragraphs | `scripts/docs-check.mjs` | bullet/whitespace-insensitive matching | a citation two lines away becomes three after reflow and a page fails spuriously | widen the window or cite on the same line — a spurious failure is visible, not silent | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://jordan-7.gitbook.io/jordan-docs/internal/run-b-verification/limitations-register.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.