{"id":"3ef716f6-03aa-4cd4-8d69-3f6ee67bbbbb","arxiv_id":"2607.06141","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":7.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":4,"one_line_summary":"Routine behavior of 85 popular browser-extension crypto wallets leaks user addresses, enabling cross-site tracking, address clustering, and potential deanonymization for 65-82% of 35 million users.","lead":"This paper identifies five privacy threats in browser-extension crypto wallets, showing that routine wallet behavior leaks user addresses across the network and web. A smart generalist should read it because it reveals systemic flaws affecting millions of Web3 users, enabling tracking and deanonymization without user interaction.","discovery_kind":"unclear","skeptic_critique":{"model":"glm-5.2","headline":"User-impact estimates assume all Chrome Web Store users of each affected wallet are equally vulnerable, but Threat #1 requires multiple addresses and Threat #4 requires prior dApp connection plus shared tracker infrastructure—both unmeasured prerequisites that could substantially reduce the headline","rationale":"The reader's CONDITIONAL verdict is appropriate. The five threats are real, well-formalized, and supported by empirical measurements. The responsible disclosure process and vendor responses (§10) provide external validation. The open-source artifacts and demo add credibility.\n\nHowever, the reader's identified weakest assumption—the automated interaction procedure—is not the most load-bearing concern. Network-side RPC behavior is background-driven (wallets auto-query balances), and web-side measurements use controlled API calls. The interaction procedure mainly affects the supplementary dApp-side findings in Table 4.\n\nThe more load-bearing concern is the user-impact methodology: the paper computes headline percentages by assuming all Chrome Web Store users of each affected wallet are equally vulnerable, without accounting for threat-specific prerequisites. Threat #1 requires multiple addresses (unmeasured prevalence), and Threat #4 requires prior dApp connection plus shared tracker infrastructure (partially measured). This inflates the 65.4% and 78.95% figures that underpin the 'majority of users' claim.\n\nThat said, this concern affects the precision of the prevalence claims, not the existence of the threats. Even if the actual affected fractions are halved, the threats would still affect millions of users. The paper's core contribution—identifying and formalizing five privacy threats with ecosystem-wide measurement—stands. The CONDITIONAL verdict correctly reflects that the threats are real but the impact estimates need refinement.\n\nThe paper would benefit from: (1) explicitly stating that Threat #1 only applies to multi-account users and providing a sensitivity analysis on the multi-account user fraction, (2) measuring tracker-domain overlap between iframe-embeddable dApps and common websites to validate Threat #4's practical exploitability, and (3) reporting confidence intervals or sensitivity bounds on all user-impact figures.","tokens_in":22084,"tokens_out":9020,"duration_ms":588147,"concrete_test":"For Threat #1: re-run the network interceptor on the 17 affected wallets with only a single account configured and confirm that co-occurrence and timing correlation signals disappear (expected by definition, since linkability requires ≥2 addresses). This confirms the 65.4% figure applies only to multi-account users. Then, to bound the actual affected population, use on-chain data: for addresses known to have queried the RPC endpoints of these 17 wallets (from Table 2's domain list), measure what fraction of distinct user sessions involve 2+ addresses transacting within a short time window. If this fraction is substantially below 100%, the headline '65.4% of users' overcounts the actually-affected population.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that these threats affect 'the majority of users,' supported by headline figures: 65.4% for network-side address linkability (§4.3.3) and 78.95% for iframe-based cross-site tracking (§5.6.4). These figures are computed by summing Chrome Web Store user counts for all wallets exhibiting a behavior, divided by the total user base. This methodology assumes uniform vulnerability across all users of each affected wallet, without accounting for threat-specific prerequisites.\n\nFor Threat #1 (§4.3.3): The linkability signals—address co-occurrence and timing correlation—only manifest when a wallet manages multiple addresses. The paper tests with 3 accounts per wallet, but many real users may use only one address, in which case there is nothing to link. The 65.4% figure (23.0M users) thus includes single-address users of the 17 affected wallets, for whom the threat does not apply. The paper does not measure or estimate what fraction of real users maintain multiple addresses.\n\nFor Threat #4 (§5.5–5.6.4): The attack chain requires (a) the wallet exposes its provider in iframes (measured: 23 wallets), (b) the user has previously connected to an iframe-embeddable dApp (18/30 dApps are embeddable, §5.6.4), and (c) the same tracker is embedded on both the dApp and the attacking site. The paper measures (a) and the dApp-side embeddability condition, but does not measure what fraction of real users have prior connections to iframe-embeddable dApps, nor does it explicitly verify tracker-domain overlap between iframe-embeddable dApps and arbitrary non-dApp websites. The 78.95% figure (27.76M users) assumes all users of the 23 wallets meet all prerequisites.\n\nThe reader's identified concern—the automated interaction procedure (§3.3.4)—is less load-bearing than this. Network-side threats depend on background RPC behavior that fires regardless of UI interaction (wallets auto-check balances), and web-side threats use controlled API calls (eth_accounts, wallet_revokePerm","agreement_with_reader":"partial"},"referee_report":{"model":"glm-5.2","summary":"This paper identifies and measures five privacy threats in browser-extension cryptocurrency wallets: (1) network-side address linkability via batched/timed RPC requests, (2) wallet fingerprinting via EIP-6963 discovery events, (3) cross-session tracking via stale permission state, (4) cross-dApp tracking via shared trackers and stale permissions, and (5) cross-site tracking and deanonymization via provider injection into cross-origin iframes. The authors build two measurement frameworks (an improved network request interceptor extending Torres et al., and a web exposure framework using Playwright), apply them to 85 popular Chrome Web Store wallets (35.16M users) and 30 dApps, and report prevalence figures for each threat. The paper also proposes mitigations and documents responsible disclosure.","tokens_in":22246,"tokens_out":2112,"duration_ms":166576,"significance":"The paper makes a solid empirical contribution to Web3 privacy. The iframe-based cross-site tracking vector (Threat #4) is novel and well-motivated: the attack chain connecting wallet provider exposure in cross-origin iframes to real-world deanonymization is clearly articulated and supported by measurements across both wallets and dApps. The improved network interceptor that captures service worker / background page traffic is a useful methodological extension over Torres et al. The reproducibility commitment (open-source frameworks, public demo) and responsible disclosure process are commendable. The systematic measurement of permission revocation behavior across 36 EVM-compatible wallets and 30 dApps fills a genuine gap in the literature.","major_comments":[{"comment":"§4.3.3 and Table 6: The headline user-impact figure for Threat #1 (65.4%, 23.0M users) is computed by summing CWS user counts for all 17 wallets exhibiting co-occurrence or timing correlation signals, divided by the total user base. However, this threat only applies to users who maintain multiple addresses in the same wallet. The paper tests with 3 accounts per wallet but does not measure or estimate what fraction of real users actually use multiple addresses. Single-address users of these 17 wallets are included in the 23.0M figure despite having no addresses to link. The paper should either (a) explicitly caveat this figure as an upper bound conditional on multi-address usage, or (b) provide an estimate of multi-address user prevalence. As stated, the figure overstates the population at risk.","section":null},{"comment":"§5.6.5 and Table 6: The 78.95% figure for Threat #4 represents the fraction of users whose wallets expose provider interfaces in cross-origin iframes (23/36 wallets). However, the full attack chain (§5.5) requires three additional preconditions: (i) the user previously connected to an iframe-embeddable dApp, (ii) that dApp includes the same tracker as the attacking site, and (iii) the wallet has not revoked the permission. The paper measures iframe embeddability of dApps (18/30) and wallet iframe exposure (23/36) but does not measure the joint probability of these conditions. Table 6 presents 78.95% as the 'ecosystem impact' for Threat #4, which conflates a necessary condition with the full attack feasibility. The paper should distinguish between 'wallets vulnerable to this vector' and 'users realistically exploitable' more clearly in the summary table.","section":null},{"comment":"§3.3.4: The automated interaction procedure (randomly clicking up to 10 UI elements or running for 60 seconds) is the basis for all network-side measurements. The paper does not validate that this procedure triggers representative RPC traffic. For Threat #1, the timing correlation signal depends on the wallet issuing multi-address RPC requests within the test window; if the random-clicking routine does not trigger balance refresh or similar operations, the measured linkability rates could be artificially low (or high, if the routine triggers unusual batched queries). The paper should discuss this limitation and, ideally, provide a sensitivity analysis or comparison with a scripted dApp-interaction scenario.","section":null}],"minor_comments":[{"comment":"Table 2: The legend explains • and ◦ symbols, but the 'Analytics embedded' column for MetaMask shows ◦ while the 'Addr. to Analytics' column shows •, which is confusing since metamask.io is listed as a recipient. Clarify whether metamask.io is classified as an analytics domain or a vendor backend.","section":null},{"comment":"§5.6.2: The text states '22 (61.1%) did not correctly implement permission revocation' and then 'The remaining 14 wallets successfully removed the permission entry.' 22 + 14 = 36, which is consistent, but the sentence structure implies 14 is a subset of the 22. Reword for clarity.","section":null},{"comment":"Table 3 caption: 'Revocation unsafe' is defined in the footnote, but 'Error returned?' column uses '–' and 'Not supported' without fully explaining the distinction. Some wallets marked 'Not supported' are also marked revocation-unsafe (•), while others with '–' are also marked •. Clarify the relationship between returning an error and being revocation-unsafe.","section":null},{"comment":"§5.5, Figure 4: The figure caption says 'tracker T on websiteA.com embeds an invisible iframe of dappX.com.' It would help to explicitly state in the figure or caption that the tracker inside the iframe runs with dappX.com's origin, as this is the key insight enabling the attack.","section":null},{"comment":"§6, Web-Threats #2–#3: The proposed 'script-level access-controlled localStorage' mitigation is interesting but described only at a high level. A brief note on how the JavaScript stack inspection would handle indirect calls (e.g., via eval or dynamic imports) would strengthen the discussion.","section":null},{"comment":"References [7] and [8] are cited to support the claim that many crypto users manage multiple wallets. These are industry reports with 'Version: 24.39.1' noted, which is unusual. Verify these are stable, citable sources or replace with peer-reviewed alternatives.","section":null},{"comment":"§4.3.3: The 10ms timing correlation window is used as a threshold but its choice is not justified. A brief rationale or sensitivity note would help.","section":null}],"recommendation":"major_revision","confidential_remarks":"The paper is a strong empirical study with a genuinely novel attack vector (iframe-based provider exposure). The core technical contributions are sound. The main issue is that the headline user-impact figures are presented as point estimates when they are better understood as upper bounds, because they do not account for threat-specific prerequisites (multi-address usage for Threat #1, prior dApp connection and shared tracker for Threat #4). This is fixable through revised framing and caveats rather than new experiments, but it does affect how the central claims should be interpreted. I would encourage the authors to add a paragraph in §4.3.3 and §5.6.5 that explicitly walks through the conditional probabilities, even if exact numbers are not available. The automated interaction procedure concern (§3.3.4) is a legitimate methodological gap but likely not fatal given that the web-side threats (the more novel contributions) are tested via direct API calls rather than random clicking."},"author_rebuttal":{"model":"glm-5.2","summary":"We thank the referee for the thorough and constructive review. The referee raises three major comments, all of which are valid and actionable. We agree with all three and will revise the manuscript accordingly. Below we address each point in turn.","responses":[{"response":"The referee is correct. The 65.4% figure represents the fraction of users whose wallets exhibit the linkability signal, not the fraction of users who are definitively exploitable, since the attack requires the user to maintain multiple addresses within the same wallet. We do not currently have an empirical estimate of multi-address user prevalence, and we agree that presenting 23.0M as the population at risk without this caveat overstates the impact. In the revision, we will explicitly label this figure as an upper bound in Table 6, in §4.3.3, and in the abstract. We will add a clarifying sentence stating that the figure represents the maximum potential exposure—i.e., the fraction of users whose wallets produce linkability signals, conditional on the user maintaining multiple addresses—and note that the actual exploitable population depends on multi-address adoption rates, which we do not measure. We will also discuss this as a limitation in the methodology section.","revision_made":"yes","referee_comment":"§4.3.3 and Table 6: The headline user-impact figure for Threat #1 (65.4%, 23.0M users) is computed by summing CWS user counts for all 17 wallets exhibiting co-occurrence or timing correlation signals, divided by the total user base. However, this threat only applies to users who maintain multiple addresses in the same wallet. The paper tests with 3 accounts per wallet but does not measure or estimate what fraction of real users actually use multiple addresses. Single-address users of these 17 wallets are included in the 23.0M figure despite having no addresses to link. The paper should either (a) explicitly caveat this figure as an upper bound conditional on multi-address usage, or (b) provide an estimate of multi-address user prevalence."},{"response":"We agree. The 78.95% figure captures the fraction of users whose wallets expose the provider in cross-origin iframes—a necessary precondition for the attack—but not the joint probability of all preconditions being met. We will revise Table 6 to distinguish between 'wallets vulnerable to this vector' (23/36, 78.95%) and a more nuanced 'realistic exploitability' assessment. Specifically, we will add a note to Table 6 clarifying that the 78.95% figure represents the population vulnerable to the iframe exposure precondition, and that full exploitation additionally requires (i) prior connection to an iframe-embeddable dApp (18/30 in our sample), (ii) a shared tracker between the attacking site and the embedded dApp, and (iii) unrevoked permissions. We will also add a sentence in §5.6.5 explicitly stating that we measure each precondition independently but not their joint probability, and that the 78.95% figure should be interpreted as an upper bound on the population vulnerable to this vector rather than a precise estimate of the exploited population.","revision_made":"yes","referee_comment":"§5.6.5 and Table 6: The 78.95% figure for Threat #4 represents the fraction of users whose wallets expose provider interfaces in cross-origin iframes (23/36 wallets). However, the full attack chain (§5.5) requires three additional preconditions: (i) the user previously connected to an iframe-embeddable dApp, (ii) that dApp includes the same tracker as the attacking site, and (iii) the wallet has not revoked the permission. The paper measures iframe embeddability of dApps (18/30) and wallet iframe exposure (23/36) but does not measure the joint probability of these conditions. Table 6 presents 78.95% as the 'ecosystem impact' for Threat #4, which conflates a necessary condition with the full attack feasibility. The paper should distinguish between 'wallets vulnerable to this vector' and 'users realistically exploitable' more clearly in the summary table."},{"response":"The referee raises a valid concern about the ecological validity of the automated interaction procedure. We acknowledge that the random-clicking routine may not trigger the exact same RPC traffic patterns that a real user would generate, and that this could bias the measured linkability rates in either direction. In the revision, we will add a dedicated paragraph in §3.3.4 discussing this limitation explicitly, noting that (i) the procedure may not trigger all balance-refresh or multi-address query patterns, potentially underestimating linkability, and (ii) conversely, the routine could trigger unusual batched queries that overestimate it. We will also note that we verified each wallet displayed correct balances for the funded test accounts (§3.3.3), which confirms that balance-fetching RPC traffic was triggered during the test window for all wallets included in the analysis. Unfortunately, we cannot provide a full sensitivity analysis with a scripted dApp-interaction scenario within the revision timeframe, as this would require designing wallet-specific interaction scripts for 55 multi-account wallets—a substantial engineering effort. We will state this as a limitation and suggest it as future work.","revision_made":"partial","referee_comment":"§3.3.4: The automated interaction procedure (randomly clicking up to 10 UI elements or running for 60 seconds) is the basis for all network-side measurements. The paper does not validate that this procedure triggers representative RPC traffic. For Threat #1, the timing correlation signal depends on the wallet issuing multi-address RPC requests within the test window; if the random-clicking routine does not trigger balance refresh or similar operations, the measured linkability rates could be artificially low (or high, if the routine triggers unusual batched queries). The paper should discuss this limitation and, ideally, provide a sensitivity analysis or comparison with a scripted dApp-interaction scenario."}],"tokens_in":21896,"tokens_out":1239,"duration_ms":173464,"standing_objections":[]},"desk_editor":{"model":"glm-5.2","letter":"The paper identifies five privacy threats in browser-extension crypto wallets and measures them across 85 wallets and 30 dApps. The genuinely new contributions are: (1) extending Torres et al.'s network interceptor to capture background/service-worker traffic, which reveals 25 additional wallets leaking addresses that the original framework missed; (2) the EIP-6963 fingerprinting vector, which is a real and previously undocumented attack surface; and (3) the iframe-based cross-site tracking attack (Threat #4), which bridges Web2 and Web3 identity without user interaction. The open-source frameworks and public demo are a plus. The responsible disclosure process — MetaMask confirming the risk is known internally, two wallets patching — lends external validation. This is a solid empirical contribution that deserves attention from the wallet standards community. The core threats are real and well-demonstrated. The soft spot is the user-impact accounting. The headline figures (65.4% for network-side linkability, 78.95% for iframe-based tracking) sum Chrome Web Store user counts for all wallets exhibiting a behavior, divided by the total user base. This assumes uniform vulnerability. Threat #1 requires multiple addresses per wallet — single-address users have nothing to link, and the paper doesn't estimate what fraction of real users maintain multiple addresses. Threat #4 requires prior dApp connection plus shared tracker infrastructure between the iframe-embeddable dApp and the attacking site — the paper measures wallet-side iframe exposure and dApp embeddability but doesn't verify tracker-domain overlap with arbitrary non-dApp websites. So the prevalence numbers are upper bounds, not point estimates. The paper should say so explicitly. The 10ms timing-correlation threshold (Threat #1) is also unjustified — no sensitivity analysis. The automated interaction procedure (random clicks, 60 seconds) is a lesser concern than the reader suggests: network-side threats depend on background RPC behavior that fires regardless of UI interaction, and web-side threats use controlled API calls. The dApp dataset (30 sites) is small but adequate for demonstrating the attack surface; the paper doesn't overclaim generalization here. These issues affect precision of impact estimates, not existence of the threats. The paper is for security researchers, wallet developers, and standards bodies. It deserves a serious referee who can push the authors to tighten the impact claims and add sensitivity analysis for the timing threshold. The threats themselves hold up.","headline":"Five wallet-privacy threats measured at scale; headline user-impact figures overcount but the threats are real","tokens_in":23235,"tokens_out":562,"would_cite":true,"duration_ms":85369,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"glm-5.2","headline":"Crypto Wallets Leak User Addresses to Any Website","keywords":["browser-extension wallets","privacy","address linkability","EIP-6963","permission revocation","cross-origin iframe","fingerprinting","Web3"],"falsifier":"Demonstrate that real-world wallet usage produces substantially different RPC request patterns (no address batching, no timing correlation) than the automated measurement procedure, which would invalidate the network-side threat prevalence rates.","tokens_in":22107,"feed_emoji":"🔓","tokens_out":1186,"duration_ms":225762,"temperature":0.7,"pith_summary":"This paper identifies five classes of privacy threats in browser-extension cryptocurrency wallets, showing that routine wallet behavior—background network requests, inconsistent permission revocation, and provider injection into cross-origin iframes—systematically leaks user addresses and enables cross-session, cross-site tracking. The authors tested 85 of the most popular Chrome Web Store wallet extensions (representing 35.16 million users) and found that 65.4% of users are affected by network-side address linkability, 82% are detectable through a new EIP-6963-based fingerprinting vector, and 78.95% are vulnerable to iframe-based address leakage on arbitrary websites. The core mechanism is a mismatch between what wallets promise (independent pseudonymous addresses) and what they actually expose: wallets batch multiple addresses into single RPC requests visible to external endpoints, fail to revoke stale permissions after a dApp requests disconnection, and inject their provider objects into cross-origin iframes where any embedded tracker script can read previously authorized addresses without user interaction. The paper traces these failures to two structural gaps: the absence of a standardized permission revocation mechanism in the EIP-2255 specification, and unrestricted provider injection into cross-origin contexts.","feed_headline":"Crypto Wallets Leak User Addresses to Any Website","feed_subtitle":"85 popular browser-extension wallets expose 35 million users to address linkability, cross-site tracking, and real-world deanonymization—no ","key_machinery":"The five privacy threats arise from two structural gaps in the Web3 wallet ecosystem: (1) EIP-2255 defines how permissions are granted but specifies no revocation mechanism, leaving wallets to implement disconnection inconsistently; (2) wallets inject their provider objects into cross-origin iframes without restricting access to top-level browsing contexts, allowing tracker scripts embedded in invisible iframes to call eth_accounts and read addresses. The EIP-6963 discovery protocol, designed to solve multi-wallet conflicts, additionally exposes installed wallet combinations as a fingerprinting signal on any website.","core_discovery":"The central discovery is that browser-extension crypto wallets passively disclose user addresses and address relationships through two distinct channels that users cannot control. On the network side, wallets issue background RPC requests that either batch multiple addresses together or send them in rapid succession, allowing any endpoint receiving these requests to definitively link addresses to the same wallet instance. On the web side, the EIP-6963 wallet discovery protocol creates a new fingerprinting vector (revealing which wallets are installed), while the lack of a standardized revocation mechanism means 22 of 36 EVM-compatible wallets continue returning previously authorizedaddresses","pith_inferences":["The paper's measurement framework captures wallet behavior through automated interaction (random UI clicks for up to 60 seconds), which may not fully replicate real user dApp usage patterns. If real users trigger different RPC call patterns during actual dApp interactions, the network-side linkability rates could differ from those reported.","The finding that most wallet vendors classified the iframe exposure issue as 'informational' or 'out of scope' suggests that market incentives alone may not drive adoption of the proposed mitigations, and regulatory or standards-body intervention may be necessary for ecosystem-wide change.","The shift toward wallet-specific backend domains (87.6% of address-receiving domains contacted by only one wallet) implies that address visibility is becoming more centralized within individual wallet vendors, creating concentrated data honeypots that could be attractive targets for compromise."],"forward_implications":["Any third-party tracker script on any website—not just dApps—can detect which crypto wallets a user has installed via EIP-6963 events, creating a Web3-specific fingerprinting vector that works even when cookies are blocked or browser storage is cleared.","Stale wallet permissions function as unforgeable, user-clearable-resistant tracking identifiers: because addresses are stored in extension-controlled storage rather than browser cookies or localStorage, clearing browser data does not remove them, making them more durable than traditional web tracking identifiers.","A single revocation-unsafe wallet installed by a user enables ecosystem-wide address clustering: any shared tracker across multiple dApps can merge address sets from different sites into a unified profile of the user's Web3 holdings.","Wallet vendors and RPC endpoint operators can observe which addresses belong to the same user through request batching and timing patterns, potentially enabling targeted attacks against high-value users.","The iframe-based attack vector means that linking a user's real-world identity (e.g., email, name from a Web2 site) to their on-chain wealth requires only one previously granted dApp permission and one shared tracker between that dApp and the identity-revealing site."],"fun_headline_variants":["Browser Wallets Passively Leak Crypto Addresses Across Sites","85 Web3 Wallets Leak User Addresses via RPC and Browser Flaws","Network and Web Flaws Let Crypto Wallets Leak User Addresses","Revoked Crypto Wallet Permissions Still Leak User Addresses","Browser Wallets Enable Cross-Site Tracking of Crypto Addresses"],"cache_read_input_tokens":0,"weakest_assumption_plain":"The measurement framework's automated interaction procedure—randomly clicking up to ten UI elements or running for sixty seconds—may not capture the same RPC call patterns that a real user would generate during normal dApp usage, which means the network-side address linkability rates could be higher or lower than measured.","fun_headline_variants_meta":{"raw":{"variants":["Browser Wallets Passively Leak Crypto Addresses Across Sites","85 Web3 Wallets Leak User Addresses via RPC and Browser Flaws","Network and Web Flaws Let Crypto Wallets Leak User Addresses","Revoked Crypto Wallet Permissions Still Leak User Addresses","Browser Wallets Enable Cross-Site Tracking of Crypto Addresses","Crypto Wallets Passively Link User Addresses Across the Web"]},"model":"glm-5.2","effort":"high","cost_usd":0.0,"raw_usage":{"total_tokens":1579,"prompt_tokens":584,"completion_tokens":995,"prompt_tokens_details":null},"tokens_in":584,"tokens_out":995,"duration_ms":49546,"temperature":1.0,"reasoning_tokens":874,"cache_read_input_tokens":0,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-08T15:15:28.806360+00:00","model_set":{"reader":"glm-5.2"},"falsifier":"Demonstrate that real-world wallet usage produces substantially different RPC request patterns (no address batching, no timing correlation) than the automated measurement procedure, which would invalidate the network-side threat prevalence rates.","supporting_citations":[],"review_version":1}