{"id":"1cf133a1-18a6-49c0-b390-ab93858fb12e","arxiv_id":"2411.12347","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"A smart-contract scheme that tokenizes spectrum assets as ERC404 fungible/non-fungible tokens and rents them via ERC4907 to incentivize dynamic spectrum sharing.","lead":"This paper proposes a blockchain system that converts spectrum usage rights into tradable tokens, combining the ERC404 and ERC4907 standards so that spectrum can be fractionally owned and rented. It reports a small test-net demonstration with one primary user and two secondary users.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper's core 1:1 backing and NFT-minting logic is internally inconsistent: Figure 3.3 computes NFT counts from wei-denominated balance deltas, so a 0.1 ETH transfer mints 10^17 NFTs, and Figure 3.1 never checks uploaded channel count.","rationale":"Reading the paper in good faith, the intended contribution is a smart-contract design that uses ERC404 to securitize spectrum resources and ERC4907 to rent them, with the load-bearing invariant that every whole fungible token corresponds to an uploaded spectrum asset and that transfers mint/burn exactly one NFT per whole token. The Ganache demo shows events and balances, but the pseudo-code is the only technical specification, and it is internally inconsistent in exactly the way the Reader's verdict identifies. Figure 3.1 updates totalSupply_NFT by amount_eth rather than by asset count, and Figure 3.3 derives NFT mint/burn counts from wei-denominated balance deltas with no threshold or conversion. This is not a disagreement with an external consensus; it is a contradiction between the stated results in Tables II-IV and the functions in Figures 3.1-3.3. Because the invariant is the basis for the claimed transparency, backing, and incentive effects, the central argument does not hold as written. I found no independent evidence (machine-checked proofs, reproducible source, or parameter-free derivation) that would rescue the mechanism. The honest verdict remains REJECT, and my stress-test does not alter the Reader's assessment; hence the recommendation is UNCHANGED.","tokens_in":7289,"tokens_out":2118,"duration_ms":21941,"concrete_test":"Implement Figures 3.1-3.3 literally in a minimal JavaScript or Python EVM simulator, then execute: (1) mintFT(PU, 0.1); (2) updateChannelInfo(channel_1, loc); (3) transfer(PU, SU2, 0.1 ether). Record totalSupply_NFT and NFTNum_mint after each step. Under the stated formulas, totalSupply_NFT becomes 0.2 and NFTNum_mint becomes 10^17, contradicting Table III's 'Mint number of NFT = 0'. If the authors instead intend a threshold, the test should be repeated after adding the missing branch 'if balance[recipient]_new - balance[recipient]_old >= 1 ether' and the missing channelList.length check in mintFT; without those additions, the invariant is unenforced and the central securitization claim collapses.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that ERC404-based tokenization keeps the number of fungible tokens backed one-to-one by uploaded spectrum assets, and that the transfer logic mints or burns one NFT per whole FT transferred. This fails on the paper's own pseudo-code. In Figure 3.1, mintFT increments totalSupply_NFT by amount_eth (i.e., the ether-denominated amount), not by the number of uploaded spectrum assets, and there is no check that amount_eth <= channelList.length. Thus a PU can mint FT for spectrum assets that were never uploaded, breaking the asserted invariant that 'the number of FTs does not exceed the number of spectrum resources' (Section III.B, Conclusion). More seriously, Figure 3.3 defines NFTNum_mint and NFTNum_burn as differences in wei-denominated balances: NFTNum_mint <- balance[recipient]_new - balance[recipient]_old. In Case 2 (Table III), the PU transfers 0.1 FT to SU2; the stated result is that no NFT is minted. But the code as written yields NFTNum_mint = 10^17 wei and would call mintNFT(recipient, 10^17), minting an absurd number of NFTs. The paper does not show any 'if balance >= 1 ether' threshold, nor any conversion from wei to whole tokens, so the table contradicts the function. Even in Case 1, a 1 ETH transfer yields NFTNum_mint = 10^18, not 1. Without a correct threshold or a check that ties NFT counts to channel availability, the 1:1 backing and the rental-loop incentive both rest on an invariant that the demonstrated code does not implement. The demo screenshots do not resolve this because no contract source or executable code is provided.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a blockchain-based spectrum securitization system for 6G dynamic spectrum sharing. It combines the ERC404 standard (a hybrid ERC20/ERC721 token) to mint fungible tokens (FTs) backed by non-fungible spectrum assets and the ERC4907 standard to create rentable Non-Fungible Spectrum Tokens (NFSTs). Primary users (PUs) upload spectrum metadata and mint FTs; secondary users (SUs) purchase FTs and use them to lease NFSTs, obtaining temporary spectrum usage rights. The paper presents pseudo-code for minting, metadata upload, FT transfer, and NFST leasing, and reports a Ganache/Remix demo with three transfer cases.","tokens_in":7715,"tokens_out":10558,"duration_ms":101015,"significance":"If the implementation were correct, the system would offer an interesting and potentially useful mechanism for transparent, tokenized spectrum sharing with a rental market. The paper is among early attempts to apply the experimental ERC404 standard to a networking domain, and the rental-loop design is a reasonable incentive structure. However, the technical core is not demonstrated: the pseudo-code does not implement the claimed 1:1 backing, and the experimental section does not validate the invariant. The contribution is therefore currently an unverified design outline rather than a working system.","major_comments":[{"comment":"The transfer function computes NFTNum_mint and NFTNum_burn as raw balance differences, but balances are stored in wei (Section III.A: balance[recipient] is a wei-denominated value). Consequently a 1-FT transfer (1e18 wei) yields NFTNum_mint = 1e18 and would mint 1e18 NFTs, while the 0.1-FT transfer in Case 2 yields 1e17 NFTs instead of the reported 0. No conversion from wei to whole FTs and no fractional-threshold check ('balance >= 1 FT') appears in the pseudo-code. The NFT mint/burn counts in Tables II–IV are therefore not the values produced by the presented code, and the 1:1 NFT-per-whole-FT relation is not implemented.","section":"III.C, Figure 3.3, Tables II–IV"},{"comment":"mintFT increments totalSupply_NFT by amount_eth with no verification against the number of uploaded spectrum assets, and updateChannelInfo does not check totalSupply_NFT or enforce any relationship between channelList.length and the FT supply. The claim in Section III.A and the Conclusion that 'the ERC404 standard ensures that the number of FTs does not exceed the number of spectrum resources' is therefore asserted rather than enforced. In the presented code a PU could mint an arbitrary amount of FT without uploading corresponding assets, which would break the token-backing invariant on which the securitization model rests.","section":"III.A–B, Figures 3.1 and 3.2"},{"comment":"The experimental section reports successful function calls but does not verify the key invariant: for instance, there is no test that attempts to mint more FTs than uploaded spectrum assets, and no on-chain log is shown that confirms the NFT counts in Tables II–IV correspond to the actual transfer events. The description also calls Ganache an 'Ethereum test net,' although Ganache is a local personal blockchain. The demo therefore provides only UI-level evidence, not validation of the security or correctness of the contract logic.","section":"IV, Experimental Result"}],"minor_comments":[{"comment":"The paragraph introducing Figure 3.1 is duplicated verbatim immediately before and after the figure; one copy should be removed.","section":"III.A, Figure 3.1"},{"comment":"The parameter name amount_eth and the note 'the unit of FT is wei' are confusing: state explicitly whether the minting quantity is a number of whole FTs, an ETH quantity, or a wei quantity, and define the FT/ETH conversion if any.","section":"III.A, Figure 3.1"},{"comment":"The statement that 'the number of uploaded spectrum assets must be equal to the number of FTs minted' is inconsistent with the later claim that FT count must not exceed spectrum assets; clarify whether the relation is equality or an upper bound.","section":"III.B"},{"comment":"The text says 'we choose one PU and two SUs,' but Table I lists one PU and four SUs; explain the roles of SU3 and SU4 in the experiment.","section":"IV, Table I"},{"comment":"The phrase 'The transfer \"_amount\" is equal to 10 eths' should read '10 FTs' or '10 ETH' once the FT unit is defined.","section":"IV, Figure 4.1"},{"comment":"Reference [8] is incomplete: \"Spect-NFT: Non-Fungible Tokens for Dynamic Spectrum Management\" lacks publication venue and year; also verify the date for reference [10], which is described in the text as November 2022 but has a 2024 access date.","section":"References"},{"comment":"The function updateChannelInfo has no access-control restriction; the paper should state who is allowed to upload spectrum metadata and how the spectrum management department's authorization is recorded on-chain.","section":"Section III.B"}],"recommendation":"major_revision","confidential_remarks":"The manuscript reads like an extended abstract rather than a full journal paper. The central implementation claim is not supported by the provided pseudo-code, and the experimental evidence is only a local UI demo. Given that the core logic can in principle be repaired by adding unit conversion, a whole-FT threshold, and an on-chain check linking FT supply to uploaded spectrum assets, I recommend major revision. However, if the authors cannot provide a corrected implementation with a verified invariant and a reproducible deployment, the paper should be rejected."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper grafts ERC404 fractionalization onto ERC4907 rentals for spectrum securitization, which is a genuinely new combination in the NFT-spectrum line of work. The system model is clear, the workflows are sensible, and the Ganache/Remix demo is a nice touch. To its credit, the paper openly calls ERC404 unofficial and experimental, and it cites the prior NFT-spectrum papers ([7], [8], [15]) rather than ignoring them.\n\nThe stress-test note holds up, and it lands on the load-bearing part. Figure 3.1 increments totalSupply_NFT by amount_eth, not by the number of uploaded spectrum assets, and there is no check that the minted FT quantity is at most the number of uploaded channels. So the claimed invariant that FTs never exceed spectrum resources is asserted but not enforced by the shown code. More seriously, Figure 3.3 computes NFTNum_mint and NFTNum_burn as wei-denominated balance differences. Since FT balances are stored in wei (1 ETH = 10^18 wei), a 1 FT transfer yields NFTNum_mint = 10^18, not 1. The paper's own tables (Case 1, Case 2) contradict the function as written; the '0.1 FT does not mint an NFT' result only holds if there is an implicit threshold the pseudo-code never shows. This is a load-bearing internal inconsistency, not a cosmetic typo, because the whole securitization story depends on a 1:1 link between whole FTs and spectrum-backed NFTs.\n\nThere is also no contract source, only screenshots, so the demo cannot independently confirm the invariant. The self-citation to [15] for NFST minting is fine, and there is no circular fitting; the claims are implementation claims.\n\nNet: the concept is plausible and could be worth another iteration, but this draft is not ready for peer review as is. The authors need to fix the wei-to-whole-token conversion, add the supply-vs-channel check, and publish the actual contract code. The paper is most useful in a reading group as a case study of why pseudo-code can hide logic bugs. I would not cite it in its current form.","headline":"A fresh but flawed ERC404+ERC4907 spectrum securitization scheme whose core token-backing logic is internally inconsistent.","tokens_in":8224,"tokens_out":3836,"would_cite":false,"duration_ms":37405,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A blockchain tokenization design turns 6G spectrum access into rentable, fungible assets, giving primary users a revenue incentive to share their idle spectrum.","keywords":["spectrum securitization","dynamic spectrum sharing","6G networks","ERC404","ERC4907","fungible tokens","non-fungible tokens","smart contracts"],"falsifier":"Mint two whole FTs while uploading metadata for only one channel, then transfer one FT to a non-primary account; if the contract mints an NFT for the second FT, the claimed 1:1 backing between token supply and spectrum assets has failed.","tokens_in":7107,"feed_emoji":"📡","tokens_out":7709,"duration_ms":72420,"temperature":0.7,"pith_summary":"This paper tries to establish that spectrum securitization built on two Ethereum token standards can solve the incentive problem in dynamic spectrum sharing for 6G: primary users (PUs) who hold spectrum rights will share them if sharing yields revenue. To that end it proposes a system where each spectrum asset is represented by a non-fungible token (NFT), while the same assets are also minted as fungible tokens (FTs) under the ERC404 standard, so ownership can be bought and sold in small fractions. A secondary user (SU) buys FTs, and spends them to rent a Non-Fungible Spectrum Token (NFST) under the ERC4907 standard, obtaining temporary use of the corresponding channel. The paper reports a testnet deployment with one PU and several SUs, and shows minting, metadata upload, FT transfers, and rental transactions executing. If the scheme holds, the starting point for spectrum sharing is not policy coordination but a market where idle spectrum earns its owner an income.","feed_headline":"Smart-contract tokens turn 6G spectrum into rentable assets","feed_subtitle":"Splitting spectrum into fungible fractions that pay for rental rewards primary users who share idle bandwidth.","key_machinery":"The load-bearing machinery is the ERC404 standard, a hybrid of ERC20 and ERC721 that makes multiple NFTs splittable: the contract tracks FT balances in wei and mints or burns one NFT per whole FT held by a non-PU. The second piece is the ERC4907 rental standard, which separates an NFST's owner field from its user field and adds an expiration time, so a spectrum resource can be leased temporarily without transferring ownership. Together they do the work of connecting tradable fractions to real, uploaded channel-location metadata, and of making FT both an investment vehicle and the payment medium for spectrum rental.","core_discovery":"The central discovery is a concrete token architecture: a smart contract using ERC404 mints fungible tokens in wei denominations against uploaded spectrum resources, and whenever a non-PU account accumulates at least one whole FT, the contract automatically mints an NFT that points to a specific uploaded channel and location. Fractional FT holdings, such as 0.1 FT, deliberately do not mint an NFT, and when a holder sells enough FTs the corresponding NFT is burned. On top of this, ERC4907 defines an NFST whose ownership stays with the PU while a separate user field records the current renter and expiry time; the renter pays in FTs, so the same token that represents the asset also serves as the currency that rents it. The paper asserts that this design keeps the number of FTs no greater than the number of spectrum resources, keeps the spectrum transparently visible on-chain, and gives PUs a rental revenue stream that incentivizes them to share.","pith_inferences":["A natural extension is to enforce the backing invariant directly in the contract code: require that FT supply growth above some cap is rejected unless matching spectrum metadata has been uploaded, since the paper's mintFT function receives only recipient and amount and never checks the uploaded channel count.","The same ERC404-plus-ERC4907 pattern could be applied to other scarce, location-bound resources such as computing slots, parking spaces, or satellite capacity, where fractional ownership and rental by the same token would give holders liquidity.","If the rental price is denominated in FT, then renting consumes or recirculates FT rather than requiring an external currency, which could make the token's value partly self-sustaining; a testable prediction is that FT price becomes tied to rental demand for the underlying channels.","Before any production use, the scheme would need a legal check: the paper notes that whether the NFT carries ownership or merely transparent display depends on whether the region permits spectrum trading, so the same codebase must be configured differently per jurisdiction."],"forward_implications":["If the scheme is correct, spectrum access becomes tradeable in arbitrary fractions, so secondary users can buy a foothold in a spectrum asset for as little as 0.1 FT instead of purchasing or licensing the whole channel.","Primary users receive FT rental payments whenever their NFST is rented, creating a direct, on-chain income stream from idle spectrum and removing the main disincentive to sharing.","Because NFTs are minted only against uploaded channel/location metadata, the blockchain provides a public, inspectable record of which spectrum assets exist and whether they are currently occupied.","The ERC4907 rental loop means the same FT serves as both tokenized asset and payment currency, so demand for the asset itself is what funds the rental, a circularity the paper treats as a feature that stabilizes FT liquidity.","A working testnet implementation with one PU and multiple SUs shows the basic transaction flow is executable, though the paper does not claim production readiness."],"supporting_citations":[{"why":"Supplies the unofficial ERC404 standard that combines ERC20 and ERC721 to fragment multiple NFTs into fungible tokens.","marker":"[12]"},{"why":"Supplies the ERC4907 standard whose owner/user role separation is used to build rentable NFSTs.","marker":"[14]"},{"why":"Provides the NFST minting method the leasing module explicitly follows.","marker":"[15]"},{"why":"Defines ERC20, the fungible-token basis for the FT side of the hybrid standard.","marker":"[13]"},{"why":"Defines ERC721, the non-fungible-token basis for NFTs and NFSTs.","marker":"[5]"}],"fun_headline_variants":["NFT tokens make 6G spectrum rentable","6G spectrum securitized: NFTs enable rental income","Tokenized spectrum: ERC404 lets owners rent out 6G","Smart contracts turn idle 6G spectrum into rentable NFTs","Spectrum sharing pays: NFTs securitize 6G bandwidth"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"Everything rests on the assumption that each fungible token really is backed by an uploaded spectrum resource, so that minted tokens never outnumber the channels that exist; if that fails, the tokens are not securitized spectrum, they are just numbers on a ledger.","fun_headline_variants_meta":{"raw":{"variants":["NFT tokens make 6G spectrum rentable","6G spectrum securitized: NFTs enable rental income","Tokenized spectrum: ERC404 lets owners rent out 6G","Smart contracts turn idle 6G spectrum into rentable NFTs","Spectrum sharing pays: NFTs securitize 6G bandwidth"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000228,"raw_usage":{"total_tokens":1402,"prompt_tokens":799,"completion_tokens":603,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":415,"completion_tokens_details":{"reasoning_tokens":516}},"tokens_in":415,"tokens_out":603,"duration_ms":6258,"temperature":1.0,"reasoning_tokens":516,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T17:38:16.756938+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Mint two whole FTs while uploading metadata for only one channel, then transfer one FT to a non-primary account; if the contract mints an NFT for the second FT, the claimed 1:1 backing between token supply and spectrum assets has failed.","supporting_citations":[{"cited_title":"Dynamic Spectrum Sharing Based on the Rentable NFT Standard ERC4907[C]//2024 13th International Conference on Communications, Circuits and Systems (ICCCAS)","cited_arxiv_id":null,"evidence_quote":"Provides the NFST minting method the leasing module explicitly follows."},{"cited_title":"Fractional non ‐ fungible tokens: Overview, evaluation, marketplaces, and challenges[J]","cited_arxiv_id":null,"evidence_quote":"Supplies the unofficial ERC404 standard that combines ERC20 and ERC721 to fragment multiple NFTs into fungible tokens."}],"review_version":1}