{"id":"ecb7c4bf-98fa-471e-bc71-fd5c48e8456d","arxiv_id":"2508.11925","paper_version":3,"verdict":"UNVERDICTED","confidence":"LOW","novelty_score":6.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":4,"one_line_summary":"An RL-trained policy adaptively biases token choices to watermark LLM-generated code while preserving executable behavior.","lead":"CodeTracer uses reinforcement learning to choose which tokens a code-generation model nudges, embedding a watermark while keeping the code runnable. It claims better detectability and preserved functionality than existing code watermarking methods, which matters for protecting AI-generated code from unauthorized use.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Detectability advantage may be an artifact of overlapping training reward and evaluation detector; cross-detector robustness is unverified.","rationale":"The reader's weakest_assumption—that the watermark embedding signal in the reward may be the same statistic used to measure detectability—is indeed a load-bearing concern, and it is the primary risk to the central claim. I partially agree because this concern is not fully verifiable from the abstract, and the supplied full text is corrupted, so the reader's UNVERDICTED status is appropriate. However, I would frame the issue slightly more broadly: even if the reward and detector are not identical, the abstract provides no evidence of generalization to unseen code, to different detectors, or to transformed/tampered code. That broader robustness gap is what makes the 'significant superiority' claim hard to assess. I do not treat the lack of verification as evidence of circularity or misconduct; the authors provide a public repository, which is a concrete asset that can settle the question. The recommended verdict remains UNCHANGED because the reader already correctly withheld endorsement, and the proposed concrete test is the natural next step before any stronger verdict could be issued.","tokens_in":6515,"tokens_out":3770,"duration_ms":51620,"concrete_test":"In the public repository (https://github.com/TimeLovercc/CodeTracer), locate the reward definition and the evaluation detector(s). Determine whether the watermark reward term is a function of the same statistic used to compute detectability in the experiments. Then rerun CodeTracer and the baselines on a held-out code benchmark and evaluate detectability with a detector not seen during training (e.g., a different statistical test or a separate classifier). Also apply semantics-preserving transformations—identifier renaming, comment removal, dead-code insertion—to watermarked outputs and recompute detection rates. If the detectability advantage collapses or degrades sharply, the central claim is weakened; if it transfers, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—CodeTracer shows 'significant superiority over state-of-the-art baselines in both watermark detectability and the preservation of generated code's functionality'—depends on whether the 'watermark embedding signal' used in the RL reward is sufficiently distinct from the detector used to measure detectability in the evaluation. The abstract says the reward 'seamlessly integrates execution feedback with watermark embedding signals' but does not specify that signal, nor does it identify the evaluation detector. The supplied full text is an unreadable corrupted stream, so this separation cannot currently be confirmed. If the reward's watermark term is the same statistic (or an approximation of the same detector) used in the reported detectability numbers, the improvement is an in-sample optimization effect: the policy is trained to maximize the exact score on which it is later evaluated. That would not demonstrate a genuinely robust watermark, especially under a different detector, a different key schedule, or semantics-preserving code transformations (renaming, reformatting, dead-code insertion). Even if the reward and detector are distinct, the abstract provides no evidence that the learned policy generalizes to out-of-distribution prompts or to tampered code. This is a verifiability concern, not an accusation of wrongdoing: the public repository could resolve it. But until the reward/detector relationship and cross-detector behavior are inspected, the detectability claim should be treated as unverified.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes CodeTracer, a code watermarking framework that trains a parameterized reinforcement-learning policy to bias token choices during next-token prediction, aiming to embed watermarks while preserving code functionality. The training reward combines execution feedback with watermark embedding signals, and Gumbel Top-k reparameterization is used for discrete optimization. The abstract claims significant superiority over state-of-the-art baselines in both detectability and functionality preservation, and the code is publicly available. The body of the manuscript, however, is supplied only as a corrupted byte stream; apart from the abstract and a header line, no technical content, experiments, or results are readable. Consequently, the paper's central claims cannot currently be verified.","tokens_in":6843,"tokens_out":2964,"duration_ms":32514,"significance":"If the claims are correct, CodeTracer would offer a conceptually interesting contribution: using RL to adapt watermark embedding to code's syntactic constraints, with execution feedback as an independent grounding signal. The availability of source code is a positive step toward reproducibility. However, the unreadable full text and the unspecified relationship between the reward's watermark signal and the evaluation detector leave the central claims unsubstantiated. The potential significance is real, but the submitted manuscript does not provide enough verifiable evidence to judge it.","major_comments":[{"comment":"The main body of the manuscript is an unreadable corrupted byte stream; only the abstract and the arXiv header line are legible. No equations, algorithms, experimental protocols, baselines, tables, or results are accessible. This is load-bearing for the central claim of 'significant superiority' because the supporting evidence cannot be inspected. The authors must resubmit a readable PDF or otherwise provide a machine-readable version. Until then, the technical content is unverifiable.","section":"Full text"},{"comment":"The reward is described as 'seamlessly integrat[ing] execution feedback with watermark embedding signals,' but the identity of the watermark embedding signal is not specified. If this signal is the same statistic (or an approximation of the same detector) used in the reported detectability evaluation, the reported gains would be an in-sample optimization artifact. The text must state explicitly whether the training signal and evaluation detector are distinct, and ideally report cross-detector and robustness results (e.g., against semantics-preserving transformations).","section":"Abstract"},{"comment":"No quantitative results, dataset descriptions, baseline names, error bars, or statistical tests appear in the abstract. The phrase 'extensive comparative evaluations' cannot be assessed without the full text. At minimum, the abstract should name the datasets and metrics or the paper should include a reproducible appendix. Given the unreadable full text, this concern is currently unresolvable.","section":"Abstract"}],"minor_comments":[{"comment":"The header line displays 'arXiv:2508.11923v1 [cs.LG]' while the paper is arXiv:2508.11925 (cs.CR). This appears to be a typo or a copy-paste error; please correct.","section":"Header"},{"comment":"The terms 'process-level' and 'outcome-level' rewards are introduced without explanation. A sentence or two defining these would help readers.","section":"Abstract"},{"comment":"The abstract would benefit from a precise statement of the threat model and the watermark detection setup (e.g., known/unknown key, white-box/black-box).","section":"Abstract"}],"recommendation":"uncertain","confidential_remarks":"The submission appears to be a corrupted PDF: the body is unreadable, so a normal technical review is impossible. I recommend asking the authors to resubmit a clean manuscript. If a readable version is provided, the reward/detector overlap issue should be a primary review focus. The repository link is promising, but it cannot substitute for a readable paper."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: I can only evaluate the abstract—the full text I received is a corrupted stream—so this is a partial read. What I see is a sensible idea: train a policy to bias token choices during generation, reward it with execution feedback plus a watermarking signal, and use Gumbel Top-k to make the discrete choices differentiable. That combination is genuinely different from the static token-scoring watermarks I know, and execution feedback gives the approach some independent grounding beyond just optimizing a detector statistic. If it works, it would be a practical step for IP protection on LLM-generated code.\n\nI like that the code is public; that makes the core claims checkable, and that matters in this area where many papers ship no artifacts. I also like the explicit tradeoff between detectability and functionality rather than treating them as separate.\n\nSoft spots: the abstract doesn't specify what the watermark embedding signal is, and the stress-test concern is real. If that signal is the same statistic used in the evaluation detector, the reported 'significant superiority' is partly an in-sample optimization effect. Execution feedback helps, but it doesn't automatically rule out metric fitting. I'd want to see the reward definition, the detector used in evaluation, and ideally a cross-detector or robustness test (renaming, reformatting, tampering) before trusting the detectability numbers. Also, no datasets, baselines, or error bars are visible from the abstract, so the superiority claim is unverified. That's not an accusation—the repo may resolve it.\n\nOne more caveat: I cannot tell whether the full paper has the same issues, because I couldn't read it. So this is an abstract-level verdict with low confidence. The paper itself might be fine.\n\nWho is it for: people working on code watermarking, LLM provenance, and maybe RL-based generation control. It might be worth bringing to a reading group as a discussion piece, but I wouldn't cite it until the reward/evaluation separation is clear.\n\nMy recommendation: send it to peer review. It's a real problem, the approach is novel, and the public code means reviewers can check the details. If the reward/evaluation overlap turns out to be fatal, the reviewers will catch it; if not, this could be a solid contribution.","headline":"CodeTracer is a plausible RL-based approach to code watermarking, but with only a readable abstract in front of me, the key reward/detector separation and the empirical claims are unverified.","tokens_in":7230,"tokens_out":4198,"would_cite":false,"duration_ms":38046,"reading_group":"maybe","serious_thinker":"unclear","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that an RL-trained policy for biasing token choices can embed detectable watermarks in generated code without degrading what the code does.","keywords":["code watermarking","reinforcement learning","next-token prediction","LLM-generated code","Gumbel Top-k","execution feedback","intellectual property protection","structured generation"],"falsifier":"Take CodeTracer's trained policy and generate code on a new benchmark of prompts, then run two detectors: the one used in the training reward and a second statistical detector never used in training. If watermarked code is flagged strongly by the first but only at chance level by the second, the claim that the watermark generalizes is falsified. Likewise, if watermarked code passes the training-time execution checks but fails hidden tests on fresh problems, the functionality-preservation claim is falsified.","tokens_in":6484,"feed_emoji":"💧","tokens_out":5260,"duration_ms":60992,"temperature":0.7,"pith_summary":"This paper is trying to establish that code watermarking can be improved by treating it as a learning problem rather than a fixed decoding rule. It proposes CodeTracer, a framework in which a parameterized policy learns where and how strongly to bias token choices inside an LLM, guided by a reinforcement-learning reward that combines whether the code executes correctly with a statistical watermark signal. The payoff, if true, is that LLM-generated code can carry an ownership mark that a detector can spot from token statistics without breaking compilation, runtime behavior, or tests. The paper reports that CodeTracer beats existing watermarking methods on both detectability and preservation of code functionality.","feed_headline":"CodeTracer: RL-trained token bias watermarks code without breaking it","feed_subtitle":"A parameterized policy shifts next-token choices so the mark stays statistically detectable and code still runs.","key_machinery":"The load-bearing machinery is the trained token-selection policy and its composite reward. At each next-token step, the policy reweights the LLM's candidate tokens; the reward sums execution feedback, which asks whether the generated code runs and passes behavior checks, with a watermark-embedding signal, which measures how strongly the resulting token distribution deviates in the intended statistical direction. Gumbel Top-k reparameterization makes the discrete token decision differentiable so the whole pipeline can be trained end to end by gradient-based reinforcement learning.","core_discovery":"CodeTracer's central claim is that watermarking code can be made adaptive: rather than applying a fixed bias to token probabilities, a parameterized policy decides which tokens to favor at each generation step so the output carries a statistically detectable pattern. The policy is trained with a reward combining outcome-level execution feedback, so the code still does what it should, and a process-level watermark-embedding signal, so the token deviations are strong enough to be detected. Gumbel Top-k reparameterization lets gradients flow through the discrete token choices. The paper contends this joint optimization yields watermarks that are both more detectable and less harmful to code fun","pith_inferences":["A natural stress test the paper leaves implicit: if the watermark-embedding reward is computed with the same detector used in evaluation, the reported detectability gain may partly reflect overfitting; testing on held-out detectors would separate robust watermarking from reward hacking.","The same learning setup could be adapted to structured generation tasks with verifiable outcomes, such as SQL query correctness or proof validity, where functional preservation matters as much as the embedded signal.","The trade-off between detectability and functionality could be plotted as a rate-distortion curve, letting users choose watermark strength before training; the paper does not derive such a curve.","Because the watermark is a learned distributional bias, an adversary might try to clean it by re-sampling or paraphrasing tokens; robustness to such attacks is not settled by this paper."],"forward_implications":["Code generators can embed ownership marks during generation itself, without needing a separate post-hoc watermarking pass.","Watermark detectability can be quantified from token-distribution statistics, giving a measurable way to audit provenance of LLM output.","Putting execution feedback in the reward means watermarked code is held to a functionality standard during training, not only evaluated afterward.","The same policy-trained biasing approach could apply to any structured token sequence with a checkable outcome, not just code.","Using Gumbel Top-k reparameterization makes watermark strength and placement learnable per context rather than fixed by a hand-designed rule."],"supporting_citations":[],"fun_headline_variants":["RL-trained policy biases tokens to watermark code subtly","Adaptive RL watermarking: optimize token bias without breaking code","CodeTracer: RL-optimized token bias for detectable, functional watermarks","RL decides which tokens to bias for stealthy code watermarks"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"The central bet is that the watermark signal used in the training reward produces watermarks that are detectable by independent detectors and on new code, rather than merely matching the detector or code samples seen during training.","fun_headline_variants_meta":{"raw":{"variants":["RL-trained policy biases tokens to watermark code subtly","Adaptive RL watermarking: optimize token bias without breaking code","CodeTracer: RL-optimized token bias for detectable, functional watermarks","RL decides which tokens to bias for stealthy code watermarks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.0008,"raw_usage":{"total_tokens":3332,"prompt_tokens":696,"completion_tokens":2636,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":440,"completion_tokens_details":{"reasoning_tokens":2564}},"tokens_in":440,"tokens_out":2636,"duration_ms":20314,"temperature":1.0,"reasoning_tokens":2564,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T19:41:52.082327+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take CodeTracer's trained policy and generate code on a new benchmark of prompts, then run two detectors: the one used in the training reward and a second statistical detector never used in training. If watermarked code is flagged strongly by the first but only at chance level by the second, the claim that the watermark generalizes is falsified. Likewise, if watermarked code passes the training-time execution checks but fails hidden tests on fresh problems, the functionality-preservation claim is falsified.","supporting_citations":[],"review_version":1}