Pith. sign in

REVIEW 2 major objections 8 minor 2 cited by

An Empirical Analysis of EOS Blockchain: Architecture, Contract, and Security

T0 review · 2 major / 8 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read EOS mainnet averaged about 56.40 transactions per second across 90 million blocks, far below the million-TPS claim.

desk verdict A readable EOS survey with one correct TPS calculation and one missing promised section on voting, so the decentralization claims outrun the evidence. read the letter →

arxiv 2505.15051 v1 pith:YZQPJU3W submitted 2025-05-21 cs.CR cs.SE

Haiyang Liu , Yingjie Mao , Xiaoqi Li This is my paper · ORCID
classification cs.CRcs.SE
keywords EOSblockchainDelegatedProofofStaketransactionthroughputdecentralizationsmartcontractvulnerabilitiesbehavioralsecurityempiricalanalysis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish a full empirical picture of the EOS blockchain, spanning its system architecture, decentralization, transaction performance, smart-contract security, and real-world attacks. Using block-level data covering the first 90 million EOS blocks, it finds that the network averaged about 28.20 transactions per block at a 0.5-second block interval, which is roughly 56.40 transactions per second, with a measured peak around 126 TPS. The paper argues this is far below the million-TPS performance EOS has been advertised as targeting. It also reports that account activity is low, that token-holding accounts show limited participation in the supernode election process, and that the set of block producers changes very little. These findings matter because EOS is presented as a Blockchain 3.0 competitor to Ethereum, and the paper's measurements test whether that positioning matches on-chain reality.

What carries the argument

The machinery that carries the performance argument is a block-level dataset of the first 90 million EOS blocks, organized by block number, creation time, producer, CPU and NET usage, and counts of transactions and actions. The paper combines the average transaction count per block, 28.20, with the fixed 0.5-second block production interval to derive the 56.40 TPS figure, and uses the monthly block counts to check that block producers were producing on schedule. For decentralization, the same dataset's account and token records are used to measure how many accounts hold tokens and how concentrated account creation is among creators. The architecture discussion sets the context by describing the six system components, including the Delegated Proof of Stake consensus in which token holders elect 21 block producers.

What would settle it

A direct count of votes cast in EOS supernode elections over the same window would settle the decentralization claim: if accounts that hold tokens voted at high rates, the limited-participation conclusion would fail. For the throughput claim, re-measuring transaction counts from raw blocks in a later period, using the same counting rule, would show whether 56.40 TPS is stable or an artifact of the early dataset.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that EOS's real mainnet throughput falls far short of its advertised target. Averaging the 2,538,345,954 transactions recorded across the 90 million blocks gives 28.20 transactions per block; with the 0.5-second block interval, the paper computes an average throughput of about 56.40 TPS and a peak of roughly 126 TPS once block height passed 87.7 million. The paper attributes the peak to an airdrop project that made about 80% of on-chain transactions, and notes that ordinary transactions and DApps suffered from the resulting CPU congestion. In the decentralization analysis, the paper reports that only about 63.67% of the 2,034,330 accounts hold token assets, interprets the remaining third as inactive and unlikely to join supernode elections, and observes minimal variation in the block producer set. Together, these measurements are used to argue that EOS is less decentralized and much slower in practice than its design goals suggest.

Load-bearing premise

The load-bearing premise is that an account holding tokens is a reasonable proxy for an account that participates in the supernode election, because the paper never presents direct voting records; if token holdings do not track voting, the limited-election-participation claim is not established.

Editorial extensions

If this is right

  • EOS's advertised million-TPS performance should be read as a theoretical design target, not an observed mainnet capability, since the measured average is about 56 TPS.
  • The low account-activity and small block-producer set imply that EOS's DPoS governance is more concentrated than its '21 elected producers' design might suggest.
  • Because most transactions consist of a single action and the traffic spike was dominated by an airdrop, any TPS benchmark for EOS is workload-dependent and should state what kind of transactions are being counted.
  • The five recurring smart-contract vulnerability patterns, integer overflow, missing permission checks, fake EOS transfers, fake transfer notifications, and predictable randomness, provide a focused checklist for auditing EOS contracts.
  • The four behavioral attacks, block delay, CPU exhaustion, RAM exhaustion, and ransomware via altered permissions, all exploit EOS's resource-staking and permission model, so defenses should target resource accounting and permission verification.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper's measurements, a fair comparison with Ethereum would apply the same block-level counting method to Ethereum over the same window, because raw TPS numbers depend on block interval and transaction batching choices.
  • The finding that an airdrop generated about 80% of all transactions suggests a testable extension: recompute throughput after filtering out airdrop-related accounts to see how much of the 'normal' EOS workload remains.
  • The unsupported link between token holdings and voting points to a concrete next study: extract the actual voting transactions from the chain and measure what fraction of token-holding accounts ever cast a ballot.
  • If the resource-exhaustion attacks are as easy as the case studies suggest, then raising minimum stake requirements or separating contract-owned resources from user-owned resources could be tested as a practical mitigation.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 8 minor

Summary. This manuscript presents a multi-dimensional analysis of the EOSIO/EOS blockchain. It describes six architectural components, uses XBlock data to analyze 2,034,330 accounts and 90 million blocks, and derives an average throughput of about 56.40 TPS (28.20 transactions per block at a 0.5-second block interval), which it contrasts with EOS's advertised 'million TPS' claims. It also surveys five EOSIO smart-contract vulnerability classes, four vulnerability detection tools, and four attack types against EOS architectural features. The paper claims that the data reveal low account activity, limited participation in supernode elections, and little variation in the set of block producers.

Significance. The strongest and most reproducible contribution is the performance calculation: given the stated totals (2,538,345,954 transactions over 90,000,000 blocks and a 0.5-second block interval), the 56.40 TPS figure follows by simple arithmetic and provides a quantitative, falsifiable counterpoint to the project's marketing claims. This part of the analysis is parameter-free and can be recomputed directly from the cited counts. The paper also offers a useful consolidation of known EOS smart-contract vulnerabilities and real-world incidents. The decentralization conclusions, however, are currently not supported by the presented data, because the promised voting and block-producer analysis is absent. This makes the significance uneven: the throughput finding is solid, but the abstract's decentralized-election claims should not be accepted until they are backed by direct evidence or removed.

major comments (2)
  1. [§4, §4.1, §5] Section 4 opens by promising an analysis of 'account data, the voting process, and block producer behaviors,' and Section 4.1 ends with 'The next section will discuss whether these token-holding accounts are involved in the voting process.' Section 5 then moves directly to 'PERFORMANCE ANALYSIS' and contains no voting records and no block-producer variation data. The abstract and Section 8 nevertheless state as findings that EOS has 'limited participation in the supernode election process' and 'little variation in the set of block producers.' The only basis offered is the statistic that 36.33% of accounts hold no tokens and so 'will not participate in the election of block producers.' Token-holding status is not voting behavior, and the authors themselves flag the inference as incomplete. This is a load-bearing gap because the decentralization headline is a central claim of the paper.
  2. [§4.1] Section 4.1's related conclusion about 'low account activity' rests on the same conflation. The text infers from 'one-third of the accounts do not hold tokens' that 'these accounts are not active in the EOS ecosystem.' Holding tokens is not a definition of activity: accounts can transact using rented CPU/NET resources, hold non-EOS tokens, or be dormant while still holding EOS. The paper presents no per-account transaction/action activity metric, despite having transaction and action counts available in the XBlock block dataset. Please either add activity measures (for example, the fraction of accounts with at least one transaction or action in a period) or remove or soften the 'low account activity' claim from the abstract and conclusion.
minor comments (8)
  1. [§3.3.2] The sentence 'the majority (more than two-thirds) of the 15 block producers (out of the total 21 block producers)' is internally inconsistent: the majority of 15 is 8, two-thirds of 15 is 10, and EOS finality conventions typically cite 15 of 21 producers. Use the precise count or fraction rather than mixing these numbers.
  2. [§4.1] The text says 63.67% of all accounts hold token assets, so 36.33% do not; referring to this as 'one-third of the accounts' is an approximation. Use the exact percentage or write 'about one-third.'
  3. [§5.1] The sentence 'When the block height exceeded 87.7 million, the throughput peaked at around 126 TPS' is not derivable from the numbers given in the text; state the underlying transaction count and the one-million-block window used for this peak.
  4. [§5.2] The Titan Labs analysis reports no numerical results in the text; give the observed TPS, CPU, NET, and action values and compare them explicitly with the historical 56.40 TPS figure.
  5. [§5 introductory paragraph] The text says 'XBlock data in this section is only available until November 2019,' while Section 4.1 uses XBlock account and token data dated up to September 3, 2020; clarify which datasets cover which time ranges.
  6. [§6.1] The phrase 'Below is an example of code' appears several times, but the manuscript text contains no code listings; include the promised code snippets or revise the prose to reference existing listings.
  7. [§6.2] The text contains a typo: 'W ANAis' should be 'WANA is.'
  8. [§8] The conclusion that EOS performance 'does not exceed Ethereum's by a significant margin' is unsupported because no Ethereum measurements appear in the paper; add a comparative source or remove this sentence.

Circularity Check

0 steps flagged · score 1.0 of 10

No circular derivation: throughput and account statistics are direct arithmetic on external XBlock/Titan Labs data, with no fitted parameters and no load-bearing self-citations; the promised voting analysis is omitted, which is an evidentiary gap, not a circular reduction.

full rationale

The paper's empirical core is self-contained against external data. The headline throughput figure (Section 5.1: 'the average number of transactions per block is approximately 28.20. Based on the 0.5-second block interval, the average transaction throughput of the EOS system is about 56.40 TPS') is arithmetic on the XBlock block dataset (90 million blocks, 2,538,345,954 transactions); no parameters are fitted and no author-defined quantity is rediscovered. The account and token statistics in Section 4.1 (2,034,330 accounts; 1,295,389 holding tokens) are direct counts from XBlock, an external platform created by Zheng et al., not by the present authors. The architecture, smart-contract, and behavioral-security sections are surveys of prior work (the four EOSIO attacks are attributed to Lee et al. [19]), so no derivation chain is at issue. The reference list contains many self-citations (references [2], [22]-[35] include co-authors Xiaoqi Li and Yingjie Mao), but each is used only as background support in the Introduction and Background sections, and none carries the empirical conclusions; this is citation hygiene, not load-bearing circularity. One promised analysis is missing: Section 4.1 ends with 'The next section will discuss whether these token-holding accounts are involved in the voting process,' yet Section 5 moves directly to performance, so the abstract/conclusion claims of 'limited participation in the supernode election process' and 'little variation in the set of block producers' are not directly evidenced by voting records. This is an omitted-support/correctness concern, not circularity, because those claims are broader than the token-holding evidence rather than equivalent to it by construction.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no free parameters or invented entities. Its central claims rest on the external XBlock dataset, an unverified proxy for election participation, and the accuracy of prior published taxonomies, which are domain assumptions rather than new theoretical commitments.

assumptions (4)
  • domain assumption XBlock dataset accurately represents EOS on-chain data for the analyzed period.
    Sections 4 and 5 base all account, token, block, and TPS statistics on XBlock; if the dataset is incomplete or erroneous, the empirical claims fail.
  • domain assumption Token holdings serve as a sufficient proxy for supernode election participation.
    The decentralization conclusion about limited election participation is inferred from account and token statistics, not from direct voting data, as shown by the unfulfilled promise at the end of Section 4.1.
  • domain assumption Prior published taxonomies of vulnerabilities and attacks are correct.
    Sections 6 and 7 relay vulnerability types and attack categories from WANA, EOSFuzzer, EOSafe, and Lee et al. without independent verification.
  • domain assumption Titan Labs monitoring data as of April 30, 2022 reflects actual EOS current performance.
    Section 5.2 relies on a third-party screenshot (Figure 9) with no raw data or collection methodology.

how reviews work

0 comments
Cite this review

Pith. "Pith review of An Empirical Analysis of EOS Blockchain: Architecture, Contract, and Security." pith.science (2026). https://pith.science/paper/YZQPJU3W

@misc{pith2026250515051,
  author       = {Pith},
  title        = {Pith review of: An Empirical Analysis of EOS Blockchain: Architecture, Contract, and Security},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YZQPJU3W}},
  note         = {Machine review of arXiv:2505.15051}
}
read the original abstract

With the rapid development of blockchain technology, various blockchain systems are exhibiting vitality and potential. As a representative of Blockchain 3.0, the EOS blockchain has been regarded as a strong competitor to Ethereum. Nevertheless, compared with Bitcoin and Ethereum, academic research and in-depth analyses of EOS remain scarce. To address this gap, this study conducts a comprehensive investigation of the EOS blockchain from five key dimensions: system architecture, decentralization, performance, smart contracts, and behavioral security. The architectural analysis focuses on six core components of the EOS system, detailing their functionalities and operational workflows. The decentralization and performance evaluations, based on data from the XBlock data-sharing platform, reveal several critical issues: low account activity, limited participation in the supernode election process, minimal variation in the set of block producers, and a substantial gap between actual throughput and the claimed million-level performance. Five types of contract vulnerabilities are identified in the smart contract dimension, and four mainstream vulnerability detection platforms are introduced and comparatively analyzed. In terms of behavioral security, four real-world attacks targeting the structural characteristics of EOS are summarized. This study contributes to the ongoing development of the EOS blockchain and provides valuable insights for enhancing the security and regulatory mechanisms of blockchain ecosystems.

Figures

Figures reproduced from arXiv: 2505.15051 by the authors.

Figure 1
Figure 1. A comparison of the layered architectures of Bitcoin, Ethereum, and EOS. [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Code architecture of EOS. Cleos Keosd Nodeos Digital Signature Wallet Account Contract Transaction Private Key [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. The interaction process among the three programs: Cleos, Keosd, and Nodeos. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (5 more)
Figure 5
Figure 5. Figure 5: Account Name Word Cloud. 5.1 The Analysis of XBlock Data The XBlock block dataset contains detailed data for 90 million EOS blocks, including information such as block number, creation time, producer, CPU and NET usage, as well as the number of transactions and actions…
Figure 6
Figure 6. Figure 6: Block Production Over Time [PITH_FULL_IMAGE:figures/full_fig_p015_6.png]
Figure 7
Figure 7. Figure 7: Statistics of Transaction and Action Counts. [PITH_FULL_IMAGE:figures/full_fig_p015_7.png]
Figure 8
Figure 8. Figure 8: CPU and NET Usage Statistics. 5.2 Performance Analysis of the Current EOS System The previous section analyzed block data collected from XBlock. However, since the dataset only includes the first 90 million blocks, ending in November 2019, it does not reflect the curre…
Figure 9
Figure 9. Figure 9: Statistical Results. 6.1 Common Vulnerabilities and Defense Methods of EOSIO Smart Contracts In this section, five known typical vulnerabilities in EOSIO smart contracts will be introduced, along with their defense mechanisms. Integer Overflow: Integer overflow vulnera…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Securing High-Concurrency Ticket Sales: A Framework Based on Microservice

    cs.SE 2025-12 reject novelty 2.0 of 10

    A railway ticketing system built from standard Spring Cloud components is reported to reach 817 req/s on a train-query interface, but only under a 100-thread local VM test with inconsistent purchase-interface data.

  2. A Comprehensive Evaluation and Practice of System Penetration Testing

    cs.CR 2025-10 conditional novelty 2.0 of 10

    A survey-style paper that proposes a weighted tool-scoring rubric, then demonstrates routine host and web penetration tests on vulnerable virtual machines.

Reference graph

Works this paper leans on

35 extracted references · 28 canonical work pages · cited by 2 Pith papers

  1. [1]

    Sybil attack detection in vanets: An lstm-based bigan approach,

    Y. Zhong, H. Yang, Y. Li, B. Yang, X. Li, Q. Yue, J. Hu, and Y. Zhang, “Sybil attack detection in vanets: An lstm-based bigan approach, ” in2023 International Conference on Data Security and Privacy Protection (DSPP) . IEEE, 2023, pp. 113–120

    work page 2023

  2. [2]

    Sok: Security analysis of blockchain-based cryptocurrency,

    Z. Liu and X. Li, “Sok: Security analysis of blockchain-based cryptocurrency, ” arXiv preprint arXiv:2503.22156, 2025

    arXiv 2025

  3. [3]

    Xblock-eos: Extracting and exploring blockchain data from eosio,

    W. Zheng, Z. Zheng, H.-N. Dai, X. Chen, and P. Zheng, “Xblock-eos: Extracting and exploring blockchain data from eosio, ”Inf. Process. Manage., vol. 58, 2021

    work page 2021

  4. [4]

    Eos: An architectural, performance, and economic analysis,

    B. Xu, D. Luthra, Z. Cole, and N. Blakely, “Eos: An architectural, performance, and economic analysis, ”Retrieved June, vol. 11, p. 41, 2018

    work page 2018

  5. [5]

    Decentralization in bitcoin and ethereum networks,

    A. E. Gencer, S. Basu, I. Eyal, R. Van Renesse, and E. G. Sirer, “Decentralization in bitcoin and ethereum networks, ” in International conference on financial cryptography and data security . Springer, 2018, pp. 439–457

    work page 2018

  6. [6]

    Sybil attacks detection and traceability mechanism based on beacon packets in connected automobile vehicles,

    Y. Zhu, J. Zeng, F. Weng, D. Han, Y. Yang, X. Li, and Y. Zhang, “Sybil attacks detection and traceability mechanism based on beacon packets in connected automobile vehicles, ”Sensors, vol. 24, no. 7, p. 2153, 2024

    work page 2024

  7. [7]

    Quantitative evaluation method for degree of decentralization of blockchain network based on entropy theory,

    K.-k. WU, B. PENG, H. XIE, Z. HUANG, and X. YAN, “Quantitative evaluation method for degree of decentralization of blockchain network based on entropy theory, ” inComputer and Modernization, vol. 0, 2019, pp. 21–

    work page 2019

  8. [8]

    Coefficient of variation to measure the degree of decentralization of blockchain network,

    W. Ke-ke, P. Bo, and H. Duan, “Coefficient of variation to measure the degree of decentralization of blockchain network, ” Computer and Digital Engineering , vol. 49, pp. 143–147, 2021

    work page 2021

Show all 35 references
  1. [9]

    Understanding the decentralization of dpos: Perspectives from data-driven analysis on eosio,

    J. Liu, W. Zheng, D. Lu et al., “Understanding the decentralization of dpos: Perspectives from data-driven analysis on eosio, ”arXiv preprint arXiv:2201.06187, 2022

    2022 arXiv

  2. [10]

    Exploring eosio via graph characterization,

    Y. Zhao, J. Liu, Q. Han et al., “Exploring eosio via graph characterization, ” inInternational Conference on Blockchain and Trustworthy Systems. Springer, Singapore, 2020, pp. 475–488

    2020

  3. [11]

    Blockchain development platforms: Performance comparison,

    I. Dernayka and A. Chehab, “Blockchain development platforms: Performance comparison, ” in2021 11th IFIP Interna- tional Conference on New Technologies, Mobility and Security (NTMS) . IEEE, 2021, pp. 1–6

    2021

  4. [12]

    A survey on smart contract platforms and features,

    M. Suvitha and R. Subha, “A survey on smart contract platforms and features, ” in2021 7th International Conference on Advanced Computing and Communication Systems (ICACCS) , vol. 1. IEEE, 2021, pp. 1536–1539

    2021

  5. [13]

    Challenges and common solutions in smart contract development,

    N. Kannengiesser, S. Lins, C. Sander et al., “Challenges and common solutions in smart contract development, ”IEEE Transactions on Software Engineering , 2021

    2021

  6. [14]

    A survey on vulnerability detection tools of smart contract bytecode,

    J. Xu, F. Dang, X. Ding et al., “A survey on vulnerability detection tools of smart contract bytecode, ” in2020 IEEE 3rd International Conference on Information Systems and Computer Aided Education . IEEE, 2020, pp. 94–98

    2020

  7. [15]

    Bytecode similarity detection of smart contract across optimization options and compiler versions based on triplet network,

    D. Zhu, F. Yue, J. Panget al., “Bytecode similarity detection of smart contract across optimization options and compiler versions based on triplet network, ”Electronics, vol. 11, no. 4, p. 597, 2022

    2022

  8. [16]

    Wana: Symbolic execution of wasm bytecode for cross-platform smart contract vulnerability detection,

    D. Wang, B. Jiang, and W.-K. Chan, “Wana: Symbolic execution of wasm bytecode for cross-platform smart contract vulnerability detection, ”arXiv preprint arXiv:2007.15510, 2020

    2007 arXiv

  9. [17]

    Security analysis of eosio smart contracts,

    N. He, R. Zhang, L. Wu et al., “Security analysis of eosio smart contracts, ”arXiv preprint arXiv:2003.06568, 2020

    2003 arXiv

  10. [18]

    Eosfuzzer: Fuzzing eosio smart contracts for vulnerability detection,

    Y. Huang, B. Jiang, W.-K. Chanet al., “Eosfuzzer: Fuzzing eosio smart contracts for vulnerability detection, ” in12th Asia-Pacific Symposium on Internetware , 2020, pp. 99–109. 22

    2020

  11. [19]

    Who spent my EOS? on the (In) Security of resource management of EOS. IO,

    S. Lee, D. Kim, D. Kim et al., “Who spent my EOS? on the (In) Security of resource management of EOS. IO, ” in13th USENIX Workshop on Offensive Technologies (WOOT 19) , 2019

    2019

  12. [20]

    Understanding (mis) behavior on the eosio blockchain,

    Y. Huang, H. Wang, L. Wu et al., “Understanding (mis) behavior on the eosio blockchain, ”Proceedings of the ACM on Measurement and Analysis of Computing Systems , vol. 4, no. 2, pp. 1–28, 2020

    2020

  13. [21]

    Xblock.eosio-on-chain-data,

    X.-O. chain Data, “Xblock.eosio-on-chain-data, ” http://xblock.pro/#/search?keywords&types=datasets&tags=EOS& page=1&pageSize=5&sort=relevance&order=desc, 2021, accessed: 2022-05-01

    2021

  14. [22]

    Defitail: Defi protocol inspection through cross-contract execution analysis,

    W. Li, X. Li, Y. Zhang, and Z. Li, “Defitail: Defi protocol inspection through cross-contract execution analysis, ” in Companion Proceedings of the ACM Web Conference 2024 , 2024, pp. 786–789

    2024

  15. [23]

    Malicious code detection in smart contracts via opcode vectorization,

    H. Zou, Z. Li, and X. Li, “Malicious code detection in smart contracts via opcode vectorization, ” arXiv preprint arXiv:2504.12720, 2025

    2025

  16. [24]

    Smartbugbert: Bert-enhanced vulnerability detection for smart contract bytecode,

    J. Bu, W. Li, Z. Li, Z. Zhang, and X. Li, “Smartbugbert: Bert-enhanced vulnerability detection for smart contract bytecode, ”arXiv preprint arXiv:2504.05002, 2025

    2025

  17. [25]

    Scla: Automated smart contract summarization via llms and semantic augmentation,

    Y. Mao, X. Li, W. Li, X. Wang, and L. Xie, “Scla: Automated smart contract summarization via llms and semantic augmentation, ”arXiv preprint arXiv:2402.04863, 2024

    2024 arXiv

  18. [26]

    Hybrid analysis of smart contracts and malicious behaviors in ethereum,

    X. Li et al., “Hybrid analysis of smart contracts and malicious behaviors in ethereum, ” 2021

    2021

  19. [27]

    On discovering vulnerabilities in android applications,

    X. Li, L. Yu, and X. Luo, “On discovering vulnerabilities in android applications, ” in Mobile Security and Privacy . Elsevier, 2017, pp. 155–166

    2017

  20. [28]

    Smart contracts in the real world: A statistical exploration of external data dependencies,

    Y. Wang, X. Li, S. Ye, L. Xie, and J. Xing, “Smart contracts in the real world: A statistical exploration of external data dependencies, ”arXiv preprint arXiv:2406.13253, 2024

    2024

  21. [29]

    Gastrace: Detecting sandwich attack malicious accounts in ethereum,

    Z. Liu, X. Li, H. Peng, and W. Li, “Gastrace: Detecting sandwich attack malicious accounts in ethereum, ” in2024 IEEE International Conference on Web Services (ICWS) . IEEE, 2024, pp. 1409–1411

    2024

  22. [30]

    Scalm: Detecting bad practices in smart contracts through llms,

    Z. Li, X. Li, W. Li, and X. Wang, “Scalm: Detecting bad practices in smart contracts through llms, ” arXiv preprint arXiv:2502.04347, 2025

    2025

  23. [31]

    Detecting malicious accounts in web3 through transaction graph,

    W. Li, Z. Liu, X. Li, and S. Nie, “Detecting malicious accounts in web3 through transaction graph, ” inProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering , 2024, pp. 2482–2483

    2024

  24. [32]

    Enhancing smart contract vulnerability detection in dapps leveraging fine-tuned llm,

    J. Bu, W. Li, Z. Li, Z. Zhang, and X. Li, “Enhancing smart contract vulnerability detection in dapps leveraging fine-tuned llm, ”arXiv preprint arXiv:2504.05006, 2025

    2025

  25. [33]

    Eosio developers,

    eosio developers, “Eosio developers, ” https://developers.eos.io/, accessed: 2022-05-01

    2022

  26. [34]

    An android vulnerability detection system,

    J. Zhang, Y. Yao, X. Li, J. Xie, and G. Wu, “An android vulnerability detection system, ” inNetwork and System Security: 11th International Conference, NSS 2017, Helsinki, Finland, August 21–23, 2017, Proceedings 11 . Springer, 2017, pp. 169–183

    2017

  27. [35]

    System-level attacks against android by exploiting asynchronous programming,

    T. Chen, X. Li, X. Luo, and X. Zhang, “System-level attacks against android by exploiting asynchronous programming, ” Software Quality Journal, vol. 26, pp. 1037–1062, 2018. 23

    2018

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.