feat(polymarket): verify incomplete candidate evidence - #339
Conversation
|
Warning Review limit reached
Next review available in: 17 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df607d8b9c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| match inputs { | ||
| ValidatedInputs::V1(inputs) if inputs.reference.trade_completions.is_empty() => { | ||
| Ok(BTreeMap::new()) | ||
| } | ||
| _ => validated_reference_trade_completions(inputs), |
There was a problem hiding this comment.
When a V2 candidate supplies a completion proof with the correct market identity, row count, and record-ID digest but an invalid completeness_basis, zero stability/finalization values, or out-of-range sequence/timestamp, this path merely aggregates it and frame_ndjson accepts it. Unlike complete artifacts, candidate manifests never run the existing segment/proof validation, so the API can report a present untrusted collector proof as verified despite invalid provenance; validate all supplied input identities and proof metadata while continuing to permit the proof itself to be absent.
AGENTS.md reference: AGENTS.md:L50-L54
Useful? React with 👍 / 👎.
| let event = parsed | ||
| .coverage | ||
| .get(market_id) | ||
| .ok_or_else(|| anyhow!("candidate market has no evidence coverage"))?; |
There was a problem hiding this comment.
When collection produces the required market-contract row but none of the five optional evidence surfaces, sealing succeeds because all surface counts may be zero, but verify_rows leaves coverage empty and this lookup rejects the candidate. This contradicts the incomplete-candidate contract: a legitimate fully missing candidate should verify with all five coverage fields set to zero so downstream qualification can record the absence rather than treating the artifact as malformed.
Useful? React with 👍 / 👎.
| "orderbook_snapshot".to_owned(), | ||
| surface_counts["up_book"] | ||
| .checked_add(surface_counts["down_book"]) | ||
| .context("candidate orderbook count overflow")?, |
There was a problem hiding this comment.
When a candidate manifest swaps or otherwise misstates up_book and down_book while preserving their sum, this conversion collapses both claims into one orderbook_snapshot count before frame_ndjson compares the manifest to the rows. The artifact therefore verifies even when its authenticated five-surface manifest says an Up book is present but the data contains only a Down book (or vice versa); compare the derived book sides against the two manifest fields so contradictory untrusted metadata is rejected.
AGENTS.md reference: AGENTS.md:L50-L54
Useful? React with 👍 / 👎.
Change contract
Add an independent
ploy-market-dataverifier for event-local Polymarket candidate triplets. It authenticates the immutable triplet with the existing bound-directory/FD and digest trust anchor, validates every present row with the existing semantics, reports derived five-surface coverage while allowing absent optional surfaces, and refreshes the two checked-in BTC/SOL mission policy pins affected by the verifier sources.Closes #337.
Out of scope
Task capability policy, catalog receipts/queries, OSS acquisition/download, snapshot/cohort construction, evaluator/MCTS behavior, deployment, and collector changes.
Dependency / merge order
Depends on #336 / PR #338 (merged as
d5dabc5bee09a5ab8802754ec3aba9bf5292cede). Merge this PR before #319.Focused validation
cargo test -p ploy-market-data polymarket_evidence --locked— 63 passedcargo test -p ploy-market-data --locked— 69 passedcargo test -p ploy-research --lib checked_in_btc_and_sol_templates_pin_current_brief_and_rust_policy --locked— 1 passedcargo check -p ploy-market-data --tests --locked --target x86_64-unknown-linux-gnu— passrustfmt --checkon both verifier files — passgit diff --check— passSafety counterexamples
Rollout / rollback impact
No runtime cutover. Rollback removes only the candidate seal/verify API, its tests, and the coupled checked-in pin refresh; the complete evidence path remains unchanged.