Pith. sign in

REVIEW 3 major objections 4 minor 50 references

When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments

T0 review · 3 major / 4 minor · reviewed 2026-08-01 · deepseek-v4-flash

Pith's one-line read The paper claims that x402's third-party payment facilitators — the shared infrastructure for HTTP-402 blockchain micropayments — routinely fail basic authorization and cost-safety rules, enabling four new attack classes.

desk verdict First systematic security study of x402 facilitators; the empirical claims are plausible but the headline violation counts rest on a black-box oracle whose false-positive rate is unquantified. read the letter →

arxiv 2607.19545 v1 pith:NKFOLOLQ submitted 2026-07-21 cs.CR

classification cs.CR
keywords x402HTTP402PaymentRequiredfacilitatorsblockchainmicropaymentsauthorizationcorrectnessexecutionsafetyblack-boxsecuritytestingERC-3009/ERC-6492
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

x402 turns HTTP 402 into a machine-payable API protocol: clients attach signed payment proofs, servers forward them to third-party facilitators that verify and settle on-chain. Because facilitators are shared infrastructure, a single flawed facilitator can misauthorize access or misdirect settlement for many merchants at once. This paper tries to establish that deployed facilitators are systematically unsafe: after distilling eight security rules from the protocol's verify-then-settle workflow, black-box testing of 15 major facilitators found 49 rule violations, with every facilitator violating at least one rule and every rule violated by at least one platform. The authors map the violations to four attack classes — free shopping, asset theft, service denial, and gas abuse — and supplement controlled tests with a measurement of over 119 million on-chain transactions showing settlement failures and sponsor-paid cost exposure. If the claims hold, the x402 ecosystem's trust model is currently not met in practice.

What carries the argument

The load-bearing object is the set of eight facilitator security rules (SR1-SR8), which translate the protocol's abstract trust requirements into concrete, black-box-checkable predicates: proof binding to server requirements, authentic payer authorization, freshness, settlement-grounded validity, fail-fast rejection of meaningless proofs, bounded sponsored execution, pre-settlement re-validation, and allow-listed settlement semantics. The companion mechanism is X402SCOPE, a feature-aware rule-guided tester that instantiates payment-proof templates (ERC-3009, ERC-1271, ERC-6492, SPL transfers), mutates fields per rule, and maps HTTP responses plus on-chain transaction receipts to violations.

What would settle it

Audit one evaluated facilitator with its internal source or a staged test deployment, and compare the tool's per-rule classifications against ground truth; if a 'violation' such as a zero-amount settlement is actually rejected for an unrelated reason, or if an inferred missing check is actually present, the 49-violation and 31-vulnerability counts are overstated. A single well-documented false positive in a rule that currently shows violations would undermine the 'every rule is violated' claim more than one false negative would.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is a measured non-compliance result: in every real-world facilitator tested, the necessary invariants of authorization correctness (SR1-SR4) and execution safety (SR5-SR8) are violated somewhere. The eight rules are derived from an end-to-end analysis of the verify/settle split and the supported payment-proof formats (ERC-3009 on EVM, SPL Token transactions on Solana, plus ERC-1271 and ERC-6492 signature variants). Using a semi-automated black-box tool that mutates payment proofs and reads HTTP responses and on-chain receipts as oracles, the authors report 49 rule violations leading to 31 previously unknown vulnerabilities, including two fully

Load-bearing premise

The reported violation counts depend on the tool's assumption that its mapping from black-box HTTP responses and on-chain receipts to the eight rules correctly distinguishes real violations from legitimate rejections; the paper itself notes there is no ground-truth violation corpus, so precision and recall are undefined.

Editorial extensions

If this is right

  • Verification-success/settlement-failure divergence — enabled by SR5/SR7 violations and tight validity windows — makes free shopping plausible for any merchant that releases resources after verification, which the paper shows is common in official SDKs.
  • ERC-1271 and ERC-6492 support without strict semantic binding (SR8) gives attackers a path to turn sponsored settlement into arbitrary calldata execution, enabling theft of facilitator-held assets.
  • Because 14 of 15 tested facilitators permit economically meaningless settlements (SR5 violations), an attacker can repeatedly force sponsor-paid on-chain fees, making service denial and gas abuse practical against the facilitator layer.
  • A measurement of 119M transactions finds non-trivial settlement failure rates (1.99% on Base) and over $202K in burned sponsor fees, so the cost-safety risks are not only theoretical.
  • The eight-rule baseline can be instantiated for other settlement networks (e.g., Starknet) and used as a pre-deployment test suite for new facilitators.

Reading between the lines

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

  • If the 'every facilitator violates a rule' result is robust, the emerging x402 default of trusting a facilitator's word for payment status is unsound; merchants would need on-chain confirmation or fallback facilitators before releasing resources, not after.
  • The heavy-tailed ATA creation and rapid closure patterns in the on-chain data suggest automated churn of subsidized accounts may already be occurring; a testable extension is to correlate per-facilitator ATA churn with settlement failure rates.
  • The paper's rule set suggests a broader design principle: any protocol that separates cheap verification from irreversible settlement needs explicit binding (nonce reservation or server-bound tokens) and cost caps; similar check-execute gaps likely exist in other sponsored-execution payment schemes.
  • One could extend X402SCOPE into a continuous regression monitor that re-tests facilitators whenever they update SDKs or settlement templates, catching drift before it is exploited.
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

3 major / 4 minor

Summary. This paper presents the first systematic security study of x402 payment facilitators. It derives eight security rules (SR1–SR8) from a workflow/threat-model analysis, builds X402SCOPE, a semi-automated black-box tester that mutates payment proofs and uses HTTP responses and on-chain receipts to infer rule violations, evaluates 15 real-world facilitators, reports 49 rule violations and 31 exploitable attack instances across four classes (free shopping, asset theft, service denial, gas abuse), and measures 119M on-chain transactions to characterize ecosystem adoption and risk. The paper also reports responsible disclosure to affected vendors.

Significance. If the empirical claims hold, this is a valuable contribution: it provides the first facilitator-layer security analysis of an emerging payment protocol, a unified rule set, a reusable black-box testing tool, and an ecosystem-scale measurement. The top-down rule derivation is not circular: the rules are grounded in the protocol workflow and threat model, and the attacks follow from rule violations rather than being fitted to data. The paper is appropriately hedged in many places, distinguishing high-risk evidence from fully validated exploits, and it ships public/restricted artifacts and responsible-disclosure details. However, the central claim of systematic non-compliance rests on an unvalidated black-box oracle mapping, and the count of validated asset-theft exploits is partly based on approval-only proofs of concept. These points need strengthening before the headline results can be accepted.

major comments (3)
  1. [§6.1] The headline claim that 'every evaluated facilitator violates at least one rule, and every rule is violated by at least one platform' (and the 49/31 counts) depends entirely on X402SCOPE's mapping from HTTP responses and on-chain receipts to SR violations. §6.1 concedes that 'no ground-truth violation corpus exists, precision and recall are not well defined,' and only four custom-format responses were manually adjudicated. A systematic misclassification—e.g., a rate-limit response read as SR7, a 'success:true' with a reverted transaction read as SR4, or an unsupported proof format read as SR8—would overturn the existential claim over 15 facilitators. Please include per-violation evidence for all 49 (or a representative audited sample), a conservative mapping policy, and a sensitivity analysis; alternatively, soften the universal claims.
  2. [§5.3 / §6.2, Table 2] The 'directly validated' asset-theft exploit in Table 2 (and the count of 31 exploitable instances) is supported by inducing the facilitator to submit a token-approval transaction only; §5.3 states 'we did not perform any subsequent transfer.' An approval is an important vulnerability primitive, but it is not yet asset theft. Please reclassify these as 'approval-granting primitive' or high-risk evidence, or justify explicitly why the approval alone warrants the asset-theft label. As written, the abstract's 'theft of facilitator-held assets' overstates what was demonstrated.
  3. [§6, Table 2 / restricted artifacts] The evidence underpinning the 49 violations and 31 attacks is not in the paper: Table 2 is anonymized and not machine-readable, and the full per-violation logs are only in a restricted Zenodo record. For a measurement/security paper, the central quantitative claims should be reviewable from the paper or a public appendix: a per-facilitator, per-rule test-to-evidence matrix with the exact response/receipt used for each classification. Without this, an independent reviewer cannot check the oracle mapping or the attack classification.
minor comments (4)
  1. [§7.3] The text reports '37,959 ATA creation events, corresponding to approximately $9,489.75' but summing Table 5 rents gives $9,678.75; the intro's '22.9K transactions... $5.7k' is not reconciled with these numbers. Please align the figures.
  2. [Table 2 / §6.1] The table formatting is difficult to read: the legend for numeric IDs, the meaning of the threshold column, and the exact reading of the ✔/✘ entries are not clear. Also check consistency between the text ('14 deployments violating SR5 and SR7') and the table entries.
  3. [§5.2] The statement 'Testnet and mainnet deployments are configured identically, so our testnet results carry over to mainnet behavior' is an assumption rather than a demonstrated fact. Please provide supporting evidence or soften the claim.
  4. [§4] The free-shopping analysis introduces Server-SR1 and Server-SR2, but these server-side rules are not part of the measured SR1–SR8 evaluation. Please clarify that they are recommendations derived from the analysis, not properties that were empirically measured in the facilitator study.

Circularity Check

0 steps flagged · score 2.0 of 10

No material circularity; only a minor, non-load-bearing self-citation to the authors' prior methodology.

full rationale

The derivation chain is self-contained rather than circular. SR1–SR8 are derived in §3 from the x402 specification, the threat model, and the verify/settle workflow; they are not fitted outputs. X402SCOPE (§5) operationalizes these rules through mutation tests and maps observed HTTP/on-chain outcomes to violations, and §5.3 explicitly states 'we do not infer attacks from SR violations alone; instead, we require attack-specific evidence,' so the four attack classes are not merely the rules renamed. The empirical counts (49 violations, 31 exploitable instances) are tallies of black-box evidence, not predictions derived from fitted parameters. The paper's own §6.1 caveat that 'no ground-truth violation corpus exists, precision and recall are not well defined' is a real evidentiary limitation of the oracle mapping, but it is a validity threat, not a circularity: a potential false positive would make the counts inaccurate, not make the conclusion an input to the derivation. The only self-citation is [12], used in §5 as methodological inspiration ('X402SCOPE adopts a feature-aware, rule-guided approach [12]'); it is from the authors' prior Git LFS study, is not load-bearing, and imports no uniqueness claim or ansatz. The score therefore reflects only this minor, non-load-bearing self-citation.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The paper's formal content is empirical, not a derivation. The main 'parameters' are methodological thresholds used to select facilitators and classify transactions; the main axioms are the protocol-semantics baseline, the sponsor-cost model, and the oracle reliability assumption that supports the violation counts.

free parameters (2)
  • Minimum buyer activity filter = 10 distinct buyers
    Two low-activity registered facilitators with fewer than 10 distinct buyers were excluded from the evaluation set; this hand-chosen threshold shapes the sample but not the rule definitions.
  • Transaction inclusion filters = ERC-3009 selector 0xcf092995; facilitator-address matching; payment-field parsing
    On-chain measurement labels transactions as x402-related using hand-chosen filters; false-positive rate is not quantified, so cost and volume estimates depend on these thresholds.
assumptions (5)
  • domain assumption The x402 protocol specification (as implemented by major vendors) defines the intended semantics for verify/settle and safety invariants.
    The eight security rules are derived from the specification (Sec. 3) and are treated as the correctness baseline for judging facilitator behavior.
  • domain assumption Facilitators sponsor settlement costs (gas/fees), making sponsor-paid cost an attack surface.
    This cost model is central to SR5/SR6 and the gas abuse/service denial attacks; if facilitators passed all costs to clients, the impact would shrink.
  • ad hoc to paper The black-box oracle mapping from HTTP responses and on-chain receipts to rule violations is reliable.
    The paper notes no ground-truth corpus exists and precision/recall are undefined; the whole violation count rests on this interpretive mapping (Sec. 6.1).
  • domain assumption The 15 evaluated facilitators are representative because they account for 99% of observed transactions.
    Sampling is from x402scan-registered facilitators; unregistered facilitators are not covered, and the 99% claim depends on the measurement filters.
  • ad hoc to paper Proof-of-concept token approvals count as evidence of asset-theft exploitability.
    For the ERC-6492 asset-theft finding, the paper treats a successful attacker-influenced approval transaction as demonstrating theft potential without executing a transfer (Sec. 5.3, 6.3).

how reviews work

0 comments
Cite this review

Pith. "Pith review of When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments." pith.science (2026). https://pith.science/paper/NKFOLOLQ

@misc{pith2026260719545,
  author       = {Pith},
  title        = {Pith review of: When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NKFOLOLQ}},
  note         = {Machine review of arXiv:2607.19545}
}
read the original abstract

x402 is an emerging payment protocol for Web APIs and autonomous AI agents. x402 extends HTTP 402 with a payment negotiation flow and delegates payment proof verification and on-chain settlement to third-party facilitators. As a result, facilitators serve as a shared payment infrastructure for many independent merchants. This centralizes trust and validation in one component, so a single flaw can affect many services. Despite rapid adoption by major vendors and economically meaningful mainnet activity, the security posture of real-world x402 deployments remains poorly characterized. We present the first systematic study of authorization correctness and execution safety in current facilitator-mediated x402 deployments in the wild, identifying eight security rules for facilitators as critical payment infrastructure. Based on our analysis of rule violations, we derive four new attack vectors, including Free Shopping, Asset Theft, Service Denial, and Gas Abuse. These attacks exploit weaknesses in the real-world facilitator and server implementations and cause severe harm, including direct financial loss to merchants, theft of facilitator-held assets, unbounded sponsor-paid gas/fees, and disruption of payment services. To assess the security of x402 deployments at scale, we propose a semi-automated black-box tool and apply it to 15 major x402 facilitators collectively used by over 60K sellers and 360K buyers. Alarmingly, we find violations in all evaluated facilitators. We responsibly disclosed our findings to the affected parties, who acknowledged the issues and adopted mitigations, including changes by Coinbase. Finally, we complement our controlled testing with an empirical measurement of over 119 million recent Base and Solana transactions, quantifying x402 adoption, facilitator centralization, and ecosystem-level risk indicators.

Figures

Figures reproduced from arXiv: 2607.19545 by the authors.

Figure 1
Figure 1. Overview of x402 protocol payment paradigms. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overview of X402SCOPE. non-fresh proofs at verification time under SR1 to SR3 or SR5, and also fails to perform re-validation at settlement time under SR7, it may sponsor settlement transactions that revert on-chain while still consuming gas; (2) SR5 and SR7 gaps that fail to enforce SR5 fail fast checks and SR7 settle time re-validation. Under SR5, the facilitator should reject eco￾nomically meaningless payments su… view at source ↗
Figure 3
Figure 3. Growth of x402 transaction activity and USDC [PITH_FULL_IMAGE:figures/full_fig_p014_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Top-10 x402 facilitators by transaction count and [PITH_FULL_IMAGE:figures/full_fig_p014_4.png]
Figure 6
Figure 6. Figure 6: Revert reason distribution of x402 transactions on [PITH_FULL_IMAGE:figures/full_fig_p015_6.png]
Figure 7
Figure 7. Figure 7: Concentration of ATA creations across owners. [PITH_FULL_IMAGE:figures/full_fig_p015_7.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

50 extracted references · 1 canonical work pages

  1. [1]

    https://www

    Cryptocurrency prices by market cap. https://www. coingecko.com/. Accessed: 2026-01-01

  2. [2]

    https://www.x402secure.com/

    x402-secure: Secure every agent payment on x402. https://www.x402secure.com/. Accessed: 2026-01- 25

  3. [3]

    Doing good by fighting fraud: Ethical anti-fraud systems for mobile payments

    Zainul Abi Din, Hari Venugopalan, Henry Lin, Adam Wushensky, Steven Liu, and Samuel T King. Doing good by fighting fraud: Ethical anti-fraud systems for mobile payments. In2021 IEEE Symposium on Security and Privacy (SP ’21), pages 1623–1640. IEEE, 2021. doi:10.1109/SP40001.2021.00100

  4. [4]

    Monetize any HTTP appli- cation with x402 and CloudFront Lambda@Edge

    Amazon Web Services. Monetize any HTTP appli- cation with x402 and CloudFront Lambda@Edge. https://builder.aws.com/content/38fLQk6zKR fLnaUNzcLPsUexUlZ/monetize-any-http-appli cation-with-x402-and-cloudfront-lambdaedge ,

  5. [6]

    Lanturn: Measuring economic security of smart contracts through adaptive learning

    Kushal Babel, Mojan Javaheripi, Yan Ji, Mahimna Kelkar, Farinaz Koushanfar, and Ari Juels. Lanturn: Measuring economic security of smart contracts through adaptive learning. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communica- tions Security (CCS ’23), pages 1212–1226, 2023. doi:10.1145/3576915.3623204

  6. [7]

    Agentic com- merce and payments: Exploring the implications of robots paying robots.Journal of Payments Strategy & Systems, 19(1):72–84, 2025

    David GW Birch and Debbie Gamble. Agentic com- merce and payments: Exploring the implications of robots paying robots.Journal of Payments Strategy & Systems, 19(1):72–84, 2025. doi:10.69554/NGEA 2302

  7. [8]

    EIP-712: Ethereum typed structured data hashing and signing

    Remco Bloemen, Leonid Logvinov, and Jacob Evans. EIP-712: Ethereum typed structured data hashing and signing. Ethereum Improvement Proposals, 2017. Ac- cessed 2026-02-05. URL: https://eips.ethereum. org/EIPS/eip-712

  8. [9]

    Security analysis and implemen- tation of relay-resistant contactless payments

    Ioana Boureanu, Tom Chothia, Alexandre Debant, and Stéphanie Delaune. Security analysis and implemen- tation of relay-resistant contactless payments. InPro- ceedings of the 2020 ACM SIGSAC Conference on Com- puter and Communications Security (CCS ’20), pages 879–898, 2020.doi:10.1145/3372297.3417235

Show all 50 references
  1. [11]

    Devils in the guid- ance: predicting logic vulnerabilities in payment syndi- cation services through automated documentation anal- ysis

    Yi Chen, Luyi Xing, Yue Qin, Xiaojing Liao, XiaoFeng Wang, Kai Chen, and Wei Zou. Devils in the guid- ance: predicting logic vulnerabilities in payment syndi- cation services through automated documentation anal- ysis. InProceedings of the 28th USENIX Security Symposium (USENI...

  2. [12]

    Unveiling security vulnera- bilities in git large file storage protocol

    Yuan Chen, Qinying Wang, Yong Yang, Yuanchao Chen, Yuwei Li, and Shouling Ji. Unveiling security vulnera- bilities in git large file storage protocol. In2025 IEEE Symposium on Security and Privacy (SP), pages 468–

  3. [13]

    Autonomous pay- ments using Circle wallets, USDC, and x402

    Circle Internet Financial. Autonomous pay- ments using Circle wallets, USDC, and x402. https://www.circle.com/blog/autonomous-pay ments-using-circle-wallets-usdc-and-x402 ,

  4. [14]

    Cloudflare agents

    Cloudflare. Cloudflare agents. https://github.com /cloudflare/agents. Accessed: 2026-01-17

  5. [15]

    The Internet-native payment proto- col

    Coinbase. The Internet-native payment proto- col. https://www.coinbase.com/developer-pla tform/products/x402. Accessed: 2026-01-17

  6. [16]

    x402 Specification

    Coinbase. x402 Specification. https: //github.com/coinbase/x402/blob/b4464ce/ specs/x402-specification.md, 2026. Accessed: 2026-01-17

  7. [17]

    PURE: Payments with UWB RElay- protection

    Daniele Coppola, Giovanni Camurati, Claudio Anliker, Xenia Hofmeier, Patrick Schaller, David Basin, and Srd- jan Capkun. PURE: Payments with UWB RElay- protection. InProceedings of the 33rd USENIX Security Symposium (USENIX Security ’24), pages 4553–4569,

  8. [18]

    EIP-1271: Standard signature validation method for contracts

    Jacques Dafflon and Alex Beregszaszi. EIP-1271: Standard signature validation method for contracts. Ethereum Improvement Proposals, 2018. Accessed 2026-02-05. URL: https://eips.ethereum.org/ EIPS/eip-1271

  9. [20]

    Solana Documentation: Accounts

    Solana Foundation. Solana Documentation: Accounts. https://docs.solana.com/developing/program ming-model/accounts#rent-exemption. Accessed: 2026-01-25

  10. [21]

    ERC-6492: Sig- nature validation for predeploy contracts

    Ivo Georgiev and Agustin Aguilar. ERC-6492: Sig- nature validation for predeploy contracts. Ethereum Improvement Proposals, February 2023. URL: https: //eips.ethereum.org/EIPS/eip-6492

  11. [22]

    The Agent-to-Agent (A2A) protocol x402 Ex- tension

    Google. The Agent-to-Agent (A2A) protocol x402 Ex- tension. https://github.com/google-agentic-c ommerce/a2a-x402. Accessed: 2026-01-17

  12. [23]

    x402 analytics

    hashed_official. x402 analytics. Dune dashboard. Ac- cessed 2026-02-02. URL: https://dune.com/has hed_official/x402-analytics

  13. [24]

    ERC- 3009: Transfer with authorization

    Peter Jihoon Kim, Kevin Britz, and David Knott. ERC- 3009: Transfer with authorization. Ethereum Improve- ment Proposals, October 2020. Draft. URL: https: //eips.ethereum.org/EIPS/eip-3009

  14. [25]

    Security analysis of unified payments interface and payment apps in India

    Renuka Kumar, Sreesh Kishore, Hao Lu, and Atul Prakash. Security analysis of unified payments interface and payment apps in India. InPro- ceedings of the 29th USENIX Security Sympo- sium (USENIX Security ’20), pages 1499–1516, 2020. URL: https://www.usenix.org/conference/us en...

  15. [26]

    Demo: Enhancing smart contract security comprehensively through dy- namic symbolic execution

    Zhaoxuan Li, Ziming Zhao, Wenhao Li, Rui Zhang, Rui Xue, Siqi Lu, and Fan Zhang. Demo: Enhancing smart contract security comprehensively through dy- namic symbolic execution. InProceedings of the 2024 ACM SIGSAC Conference on Computer and Communi- cations Security (CCS ’24), p...

  16. [27]

    Messy states of wiring: Vulnerabilities in emerging personal payment systems

    Jiadong Lou, Xu Yuan, and Ning Zhang. Messy states of wiring: Vulnerabilities in emerging personal payment systems. InProceedings of the 30th USENIX Security Symposium (USENIX Security ’21), pages 3273–3289,

  17. [28]

    Towards automatic discovery of denial of ser- vice weaknesses in blockchain resource models

    Feng Luo, Huangkun Lin, Zihao Li, Xiapu Luo, Ruijie Luo, Zheyuan He, Shuwei Song, Ting Chen, and Wenx- uan Luo. Towards automatic discovery of denial of ser- vice weaknesses in blockchain resource models. InPro- ceedings of the 2024 ACM SIGSAC Conference on Com- puter and Comm...

  18. [29]

    Who pays whom? Anonymous EMV-Compliant contactless pay- ments

    Charles Olivier-Anclin, Ioana Boureanu, Liqun Chen, Christopher Newton, Tom Chothia, Anna Clee, An- dreas Kokkinis, and Pascal Lafourcade. Who pays whom? Anonymous EMV-Compliant contactless pay- ments. InProceedings of the 34th USENIX Security Symposium (USENIX Security ’25), ...

  19. [30]

    Col- lisionRepair: First-Aid and automated patching for storage collision vulnerabilities in smart contracts

    Yu Pan, Wanjing Han, Yue Duan, and Mu Zhang. Col- lisionRepair: First-Aid and automated patching for storage collision vulnerabilities in smart contracts. InProceedings of the 34th USENIX Security Sym- posium (USENIX Security ’25), pages 4035–4052,

  20. [31]

    More is less: Extra features in contactless payments break security

    George Pavlides, Anna Clee, Ioana Boureanu, and Tom Chothia. More is less: Extra features in contactless payments break security. InPro- ceedings of the 34th USENIX Security Sympo- sium (USENIX Security ’25), pages 7977–7996, 2025. URL: https://www.usenix.org/conference/us eni...

  21. [32]

    Se- curity certification in payment card industry: Testbeds, measurements, and recommendations

    Sazzadur Rahaman, Gang Wang, and Danfeng Yao. Se- curity certification in payment card industry: Testbeds, measurements, and recommendations. InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS ’19), pages 481–498, 2019.doi:10.1145/3319...

  22. [33]

    The agentic economy

    David M Rothschild, Markus Mobius, Jake M Hof- man, Eleanor W Dillon, Daniel G Goldstein, Nicole Immorlica, Sonia Jaffe, Brendan Lucier, Aleksandrs Slivkins, and Matthew V ogel. The agentic economy. arXiv preprint arXiv:2505.15799, 2025. URL: https: //arxiv.org/abs/2505.15799

  23. [34]

    AI agents vs

    Ranjan Sapkota, Konstantinos I Roumeliotis, and Manoj Karkee. AI agents vs. agentic AI: A conceptual tax- onomy, applications and challenges.arXiv preprint arXiv:2505.10468, 2025. URL: https://arxiv.or g/abs/2505.10468

  24. [35]

    Smarter contracts: Detecting vulnerabil- ities in smart contracts with deep transfer learning

    Christoph Sendner, Huili Chen, Hossein Fereidooni, Lukas Petzi, Jan König, Jasper Stang, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, and Farinaz Koushanfar. Smarter contracts: Detecting vulnerabil- ities in smart contracts with deep transfer learning. InProceedings of the 30th N...

  25. [36]

    URL: https://www.usenix.org/conferenc e/usenixsecurity25/presentation/pan-yu

  26. [37]

    Sybil-resistant service discovery for agent economies.arXiv preprint arXiv:2510.27554, 2025

    David Shi and Kevin Joo. Sybil-resistant service discovery for agent economies.arXiv preprint arXiv:2510.27554, 2025. URL: https://arxiv.or g/abs/2510.27554

  27. [38]

    From human-centric to agent-native: Building trust- less payment infrastructure for agentic AI

    Scott Shi, Zerui Cheng, Chen Xi, Yi Huang, Lyon Li, Uddhav Marwaha, David Weber, and Chi Zhang. From human-centric to agent-native: Building trust- less payment infrastructure for agentic AI. Whitepa- per, Kite AI, Oct 2025. Accessed: 2026-01-17. URL: https://www.zerui-cheng.c...

  28. [39]

    Fuzz on the beach: Fuzzing Solana smart con- tracts

    Sven Smolka, Jens-Rene Giesen, Pascal Winkler, Ous- sama Draissi, Lucas Davi, Ghassan Karame, and Klaus Pohl. Fuzz on the beach: Fuzzing Solana smart con- tracts. InProceedings of the 2023 ACM SIGSAC Confer- ence on Computer and Communications Security (CCS ’23), pages 1197–12...

  29. [40]

    Transfer tokens

    Solana Foundation. Transfer tokens. Solana Documen- tation. Accessed 2026-02-05. URL: https://sola na.com/docs/tokens/basics/transfer-tokens

  30. [41]

    All your tokens are belong to us: Demystifying address verifica- tion vulnerabilities in solidity smart contracts

    Tianle Sun, Ningyu He, Jiang Xiao, Yinliang Yue, Xiapu Luo, and Haoyu Wang. All your tokens are belong to us: Demystifying address verifica- tion vulnerabilities in solidity smart contracts. In Proceedings of the 33rd USENIX Security Sympo- sium (USENIX Security ’24), pages 35...

  31. [43]

    SmartInv: Multimodal learning for smart contract in- variant inference

    Sally Junsong Wang, Kexin Pei, and Junfeng Yang. SmartInv: Multimodal learning for smart contract in- variant inference. In2024 IEEE Symposium on Security and Privacy (SP ’24), pages 2217–2235. IEEE, 2024. doi:10.1109/SP54263.2024.00126

  32. [44]

    Automated inference on finan- cial security of Ethereum smart contracts

    Wansen Wang, Wenchao Huang, Zhaoyi Meng, Yan Xiong, Fuyou Miao, Xianjin Fang, Caichang Tu, and Renjie Ji. Automated inference on finan- cial security of Ethereum smart contracts. In Proceedings of the 32nd USENIX Security Sympo- sium (USENIX Security ’23), pages 3367–3383, 202...

  33. [45]

    The x402 analytics dashboard and block explorer

    x402scan.com. The x402 analytics dashboard and block explorer. https://www.x402scan.com/. Accessed: 2026-01-17

  34. [46]

    Solana: A new architecture for a high performance blockchain v0.8.13

    Anatoly Yakovenko. Solana: A new architecture for a high performance blockchain v0.8.13. Whitepaper,

  35. [47]

    When crypto fails: Demystifying cryptographic defects in Ethereum smart contracts.IEEE Transactions on Software Engineering, 51(5):1381–1398, 2025

    Jiashuo Zhang, Jiachi Chen, Yiming Shen, Tao Zhang, Yanlin Wang, Ting Chen, Jianbo Gao, and Zhong Chen. When crypto fails: Demystifying cryptographic defects in Ethereum smart contracts.IEEE Transactions on Software Engineering, 51(5):1381–1398, 2025. doi: 10.1109/TSE.2025.3551776

  36. [48]

    Universal atomic swaps: Secure exchange of coins across all blockchains

    Sri AravindaKrishnan Thyagarajan, Giulio Malavolta, and Pedro Moreno-Sanchez. Universal atomic swaps: Secure exchange of coins across all blockchains. In 2022 IEEE Symposium on Security and Privacy (SP ’22), pages 1299–1316. IEEE, 2022. doi:10.1109/SP 46214.2022.9833731

  37. [2018]

    URL: https://sola na.com/solana-whitepaper.pdf

    Accessed: 2026-01-17. URL: https://sola na.com/solana-whitepaper.pdf

  38. [2019]

    URL: https://www.usenix.org/conferenc e/usenixsecurity19/presentation/chen-yi

  39. [2021]

    URL: https://www.usenix.org/conferenc e/usenixsecurity21/presentation/lou

  40. [2024]

    URL: https://www.usenix.org/conferenc e/usenixsecurity24/presentation/coppola

  41. [2025]

    Published September 12, 2025; accessed 2026-02-06

  42. [2026]

    Accessed: 2026-02-06

Pith tools

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