Tough questions
Straight answers about voice accuracy, gate G3, the fake PayPal, the road to production and the security review.
Each answer says what is known, what is not, and where the evidence is. Where this page and docs/GATES.md disagree, the gate record wins.
Gate G5 is PARTIAL: voice bidding is measured on synthetic audio, and live-room confirmation is the next step. After the parser fixes and the provider options (Deepgram nova-3, Groq whisper-large-v3-turbo with a bid prompt), wrong accept is 0.000 and exact plus recoverable is 1.000 on all four runs: 24 synthetic eSpeak clips and 24 human-like synthetic clips, against a limit of 0.05. Those clips were used to choose the fixes. On a separate synthetic held-out noisy set (120 clips, simulated room and babble noise), measured once, neither provider met the thresholds: wrong accept 0.058 (Groq) and 0.092 (Deepgram) against 0.05.
The first run, on Deepgram nova-2 and Groq without a prompt, scored a wrong-accept rate of 0.125 and 0.083 on the eSpeak set and 0.083 and 0.167 on the second set. Nine of the eleven wrong accepts were a label defect in our own evaluation; the parser and provider options fixed the rest. Those fixes were chosen on the same clips, the clips are noise-free, and no real-room or noisy-room run exists yet, so the numbers are a strong start and not a pass of the gate question.
The decision recorded in docs/GATES.md is that spoken bids always go through the . The parser never decides a winner and never moves money; typed entry and QR bids are the other input paths, so the auction works if speech fails. At the text level (transcripts through the parser, no audio) wrong accepts are 0.000 on 169 cases, which measures the parser only.
G3 is a real timed probe on the sandbox. Day 0 was 7 Nov 2026 03:06 UTC and the day 0 checks are recorded: an immediate reauthorize was refused with REAUTHORIZATION_TOO_SOON, and three authorizations were approved to be read at 3.5, 4 and 5 days. The final reading is about 12 Nov 06:17 UTC. Earlier attempts on 4 to 7 Nov never ran, so no earlier day is claimed. Until the readings exist the gate reads NOT RUN / IN PROGRESS.
An early reading on an older G2 wallet authorization, taken on 8 Nov 17:36 UTC at age 3.24 days, accepted a partial capture of 1.00 (HTTP 201) and answered the reauthorize call with 422 UNPROCESSABLE_ENTITY and the issue PAYER_CANNOT_PAY. That authorization already carried a partial capture, so it is an early data point; the day 3.5, 4 and 5 authorizations give the clean answer. The older G2 guest card authorization, probed on 9 Nov at age 3.5075 days, also accepted a partial capture of 1.00 and refused reauthorize (run 42538613566); a final_capture and a void on a guest card authorization were not run.
PayPal's documentation names an (3 days) and a validity window (29 days, with one ), and GAVEL does not assume either until the probe reports. The plan is to capture within the verified window and reauthorize before the hammer. That is a plan, not a result. Meanwhile holds older than two hours at settlement are flagged stale, and a stale hold is still captured.
The 30-day run is a simulation on a fake clock against a model of PayPal. It shows our code is consistent with that model.
See honor period and gate G3.
Both exist and they are labelled. Real on the PayPal : G0 (connectivity, committed evidence file from 9 Nov), G1 (authorize 500, capture 350 with final capture, two PayPal-account buyers, one funded by a card), G2 (wallet and guest card authorize), G4 (six real webhooks verified) and one lot of three holds plus one in-process crash in the nightly specs R7, R8 and R10.
Fake: whole-auction settlement with many holds, crash and resume, and rejection of a tampered webhook. The is a test double in packages/payments/src/fake/; it says nothing about the real PayPal.
Never real: money. Every PayPal call is against the sandbox.
Inferred from the evidence. After the final capture the authorization reads CAPTURED and an explicit void answers 422 PREVIOUSLY_CAPTURED. Reading a buyer balance, and running a final_capture and a void on a guest card authorization (G1 used PayPal-account orders; only a 1.00 partial capture was seen on a guest card), are the next steps.
GAVEL runs in sandbox mode today, and the next steps are listed on Limits and next steps. In short:
- The hosted app (https://gavel.dualmindlab.tech, sandbox mode) is live with key-less judge rooms; a recorded walk of the hosted flow is the next step. The fake-PayPal run is the local path.
- The file stores run on one instance with a persistent disk.
- Latency: both targets are missed on the latest run (42563147792, n=49 settlements of 6 holds, INCOMPLETE: 1 timeout and 3 failed capture calls): hammer to settled 6.93 s against 6 s and hammer to captured p95 3.77 s against 2.5 s. An earlier n=20 run had 5.59 s and 3.01 s. Owner decision open: keep the targets, raise them with a reason, or reduce latency.
- A real server process kill ran once on a CI runner against the sandbox (run 42558021614: one SIGKILL after the capture request and before the response, restart on the same data folder, one capture of 12500, two losers voided, journal equals PayPal, ledger verifies). Whole-auction settlement through the deployed Render server, and a kill on that host, are the next sandbox runs.
- Rejected bids are kept in the room log, and the ledger holds accepted bids.
- One live run of the
/audiosocket is recorded (run 42575018866: the 24 synthetic clips streamed in real time to the real server with fake PayPal; both providers answered 24 of 24 and no spoken bid was accepted without a confirm). An audio sender from the web console to the socket is next; the console button stays disabled. - Accessibility: automated checks run; the manual screen reader and zoom pass is next.
docs/SECURITY-REVIEW.md lists SEC-01 to SEC-24: SEC-01 to SEC-18, SEC-19 and SEC-20 (judge rooms and receipt links, OPEN), and SEC-21 to SEC-24 (judge key, reviewer token, simulated holds, docs host headers; PARTIAL, agent-only). All eight P0 items (SEC-01 to SEC-07 and SEC-18) are PASS as of 2026-11-07, reviewed by someone other than the author. Of the 24 items, 13 are PASS, one (SEC-11, audio and personal data) is ACCEPTED with its justification, and SEC-09, SEC-10, SEC-14, SEC-15 and SEC-21 to SEC-24 are PARTIAL. For SEC-15, the log scan, a scan of one S01 server log and the data folder with 9 canary values found nothing, and a negative control failed as it should (run 42566851766). Render logs and routes the run does not call are not scanned. SEC-19 and SEC-20 are OPEN and wait for an independent reviewer. No FAIL is recorded. Automated checks cover access control, webhook authenticity and SSRF, the sandbox-only guard, abusive input, headers and denial of service in packages/e2e/test/security, and CI runs a secret scan and a dependency audit.
See security review and the threat model.
Accepted bids go into a . A public export can be checked with verifyPublicExport or the verify-ledger command in packages/engine; an edited entry fails at its index and a cut chain fails with truncated when the expected head is passed. The limit: rejected bids are not in the ledger, so it cannot prove them.
They are sandbox numbers from single runs, and they are specific. The end-to-end settlement numbers come from run 42346811713 (20 settlements of 6 holds, 0 failed, a redacted copy committed under docs/evidence/measure/): hammer to settled p95 5591.30 ms and hammer to captured p95 3010.04 ms. A later run (42563147792, n=49, INCOMPLETE) gave 6.93 s and 3.77 s, so both targets are missed. The per-call numbers come from run 42047543821 (10 cycles, 0 failures); its raw log is not committed. The larger repeat is recorded in latency; the owner decision on the targets is open.
Last updated on