Escribir un comentario

Does the introduction explain the objective of the research presented in the preprint?

Yes

It clearly explains the objective. The introduction states plainly that existing AI-based detection models for NFT smart contract vulnerabilities are limited because of their complexity, while manual review is too slow and costly, and that this paper proposes an AI-driven approach to close that gap. It backs this up with a concrete plan: collect a large dataset of real smart contracts, sort them into five specific vulnerability categories, and train a random forest model to detect them. The three stated contributions at the end of the introduction (the dataset, the targeted vulnerability categories, and the tuned model) make the goal easy to follow before getting into the technical sections.

Are the methods well-suited for this research?

Somewhat inappropriate

They have certain flaws that limit the value of the insights they share. Using a real dataset of 16,527 contracts and choosing CART/random forest with a reasonable justification over ID3 and C4.5 are sound decisions, and the parameter tuning process (GridSearch across tree count, depth, and feature count) is genuinely thorough. But there's a gap that matters a lot here: the paper never explains how the boolean features themselves were extracted from the raw Solidity code. Features like "whether there is a locking mechanism" or "whether there is permission control" require someone or something to actually read and interpret the contract logic, and the paper never says whether this was done manually, through a separate static analysis tool, or some other method. Having built and deployed Solidity contracts myself, I can say this distinction is not a minor detail: if a human or a separate tool already did the hard work of recognizing these patterns before the model ever sees the data, the random forest is classifying already-interpreted labels, not detecting vulnerabilities directly from code. That's a fundamentally different (and much easier) task than what the paper's framing suggests, and without knowing which one actually happened, it's hard to trust how much of the reported success belongs to the AI model versus the upstream labeling process.

Are the conclusions supported by the data?

Highly unsupported

The conclusions do not follow from the data because the core data needed to support them isn't actually presented. The abstract states plainly that "the random forest model excels in detecting all five vulnerabilities," and the conclusion reinforces this by describing the process as a "comprehensive leap." But nowhere in the paper do I see reported accuracy, precision, recall, or any other held-out test performance numbers for the trained models. What's shown instead is the hyperparameter tuning process itself (which parameter settings were chosen and why) and the Gini coefficients used during tree construction, which describe how the model was built, not how well it actually performs on data it wasn't trained on. This is a significant gap for a paper whose entire contribution is a detection model. Tuning a model carefully and choosing sensible parameters doesn't tell a reader whether the final result actually catches real vulnerabilities reliably or produces too many false positives or false negatives to be usable in practice. Without that number, the claim that the model "excels" at detection isn't something I can verify from what's presented, it's asserted rather than demonstrated.

Are the data presentations, including visualizations, well-suited to represent the data?

Somewhat inappropriate or unclear

The decision tree diagrams and the feature comparison tables (mapping each function name to a feature number like A1 through A6) are genuinely useful for understanding how each vulnerability was broken down and which features mattered most during training. The 3D visualizations for GridSearch hyperparameter tuning are also a nice touch for showing how parameter choices affected performance during that stage. But this is exactly where the missing results become a data presentation problem, not just a results problem. The paper visualizes the training and tuning process in real detail, but there's no equivalent chart, table, or figure showing the model's actual detection performance (accuracy, precision, recall, or a confusion matrix) for any of the five vulnerabilities. Given how much visual effort went into showing the tuning process, the complete absence of a results visualization for the actual outcome the paper is claiming, working vulnerability detection, is a significant omission, not just a stylistic one.

How clearly do the authors discuss, explain, and interpret their findings and potential next steps for the research?

Neither clearly nor unclearly

The conclusion mentions that the process gave the model "strong interpretability" and that extensive visualization work was done for parameter selection, but it doesn't actually explain or interpret what the findings mean in practice. There's no discussion of which vulnerability categories were hardest to detect, why the chosen feature sets worked or didn't, what the model's limitations are, or how it compares to the existing detection tools the introduction mentions (like the ones from Harvard's Blockchain Security Laboratory or the HGAT model). The paper also doesn't lay out concrete next steps, it ends by restating that the tuning process was thorough rather than pointing toward what should be studied or built next. Given that this is a Random Forest model and the interpretability advantages of Random Forest are specifically called out earlier in the paper (Section 5.3.1), I'd have expected the conclusion to actually use that interpretability to explain something concrete about the vulnerabilities themselves, but that discussion doesn't happen.

Is the preprint likely to advance academic knowledge?

Not likely

The preprint offers no significant advancements or confirmations, though the underlying idea, breaking NFT smart contract vulnerabilities into specific, well-defined categories and building a targeted detection model for each, is a reasonable one, and the dataset itself (16,527 contracts) could be a useful resource if properly documented. But two gaps limit what this actually adds to the field: the missing description of how features were extracted from raw code, which makes it impossible to know how much of the classification task the model is genuinely solving versus inheriting from prior labeling, and the absence of any reported accuracy or performance metrics, which means the central claim, that the model successfully detects these vulnerabilities, isn't something a reader can actually verify. Without those two pieces, this reads more as a description of a training pipeline than a validated contribution to NFT security research.

Would it benefit from language editing?

Yes

Grammatical errors and awkward phrasing show up throughout the paper and do get in the way of following the argument in places. Sentences like "we strive to accumulate experience in NFT smart contract vulnerabilities and contribute to the application of large-scale artificial intelligence models" and "the attacks are divided into five categories; they are processed and studied separately and finally trained, in addition, this paper also continues to explore its shortcomings" are hard to parse on a first read, and there are recurring issues with article usage, sentence fragments, and run-on sentences across the introduction and background sections in particular. A pass with a proofreading tool or a native-English-speaking editor would meaningfully improve readability without needing to touch the technical content itself.

Would you recommend this preprint to others?

No, it’s of low quality or is majorly flawed

The two gaps here aren't polish issues that a revision could quickly patch, they go to the core validity of the paper's central claim. Without knowing how the input features were extracted from code, there's no way to know whether the model is actually detecting vulnerabilities or just classifying labels someone else already assigned. And without any reported accuracy, precision, or recall numbers, the paper's headline claim, that the model "excels" at detecting all five vulnerability types, isn't something a reader can verify at all. A paper whose main contribution is a detection model needs to show that the detection actually works; this one describes how the model was built and tuned in detail but never demonstrates that it performs. Given both of those gaps sit at the center of what the paper is claiming to contribute, rather than at the edges, I don't think this is a "good idea with rough execution" situation, it's a paper that hasn't yet demonstrated its own core claim.

Is it ready for attention from an editor, publisher or broader audience?

No, it needs a major revision

Two things need to be addressed before this is ready for wider attention, and neither is minor. First, the authors need to explicitly document how the input features were extracted from the raw Solidity code, whether that was manual labeling, a static analysis tool, or something else, since this directly determines what the model is actually being credited with detecting. Second, and more importantly, the paper needs to report actual held-out test performance (accuracy, precision, recall, or a confusion matrix) for each of the five vulnerability categories. Right now the paper documents the training and tuning process in real depth but never demonstrates that the resulting models work, and that's the one thing a vulnerability detection paper has to show. Once both of those are added, the underlying idea and dataset could support a genuinely useful contribution, but as it stands, the central claim isn't yet backed by presented evidence.

Competing interests

The author declares that they have no competing interests.

Use of Artificial Intelligence (AI)

The author declares that they did not use generative AI to come up with new ideas for their review.