This paper proposes a decentralized software version control system leveraging blockchain technology. Traditional version control systems suffer from central points of failure, lack of transparency, and limited traceability. This system addresses these shortcomings by utilizing a blockchain to immutably record and manage software version information. The core mechanism involves hashing software versions and storing these hashes on a blockchain, ensuring data integrity and providing a transparent, auditable trail. This approach enhances security, improves transparency, and offers enhanced traceability compared to centralized solutions. The system utilizes a distributed consensus mechanism to maintain blockchain integrity, mitigating the risks associated with a single point of failure. This research explores the feasibility and potential benefits of applying blockchain technology to software version control, representing a novel approach to managing software evolution.
This paper proposes a novel system for program code version control leveraging the principles of blockchain technology. Traditional version control systems are vulnerable to manipulation and security breaches, necessitating a more robust and transparent solution. Our system utilizes blockchain's inherent properties – immutability and distributed consensus – to provide a highly secure and auditable record of code changes. The core mechanism involves hashing each code version and storing the hash on a blockchain, ensuring that any alteration to the code will be immediately detectable. This approach significantly enhances the integrity of the codebase and promotes trust among developers and stakeholders. The system is designed for flexibility and scalability, adaptable to various programming languages and development workflows. This paper outlines the architecture, key features, and theoretical underpinnings of the proposed system, emphasizing its advantages over existing methods.
With the increasing development of Solidity contracts on Ethereum , more developers are reusing them on other compatible blockchains. However, developers may overlook the differences between the designs of the blockchain system, such as the Gas Mechanism and Consensus Protocol , leading to the same contracts on different blockchains not being able to achieve consistent execution as on Ethereum . This inconsistency reveals design flaws in reused contracts, exposing code smells that hinder code reusability, and we define this inconsistency as EVM-Inequivalent Code Smells . In this paper, we conducted an empirical study to reveal the causes and characteristics of EVM-Inequivalent Code Smells . To ensure the identified smells reflect real developer concerns, we analyzed 1,379 security audit reports, 823 bug bounty reports, and 326 Stack Overflow posts related to reused contracts on EVM-compatible blockchains, such as Binance Smart Chain (BSC) and Polygon . Using the Open Card Sorting method, we defined nine types of EVM-Inequivalent Code Smells . To enable efficient detection, we developed EquivSage , a tool that leverages the contextual understanding capabilities of large language models (LLMs) to guide slicing and static taint analysis via task-specific prompts. Symbolic execution is integrated to improve detection reliability. An analysis of 1,263,683 contracts across six EVM-compatible blockchains using EquivSage reveals that, on average, 15.45% contain at least one EVM-Inequivalent Code Smell , underscoring its widespread prevalence. Since 2024, code smells in reused contracts on Ethereum , Polygon , and Optimism have increased significantly. While not all instances lead to financial loss, high frequency and asset exposure highlight the risks inherent in contract reuse. Developers are encouraged to avoid copy-and-paste practices and to detect such smells proactively before reuse.
Solidity has undergone 116 version iterations between August 2015 and February 2026, during which compiler updates have introduced behavioral changes, including issues later fixed in subsequent releases. Contracts compiled under specific versions may exhibit version-dependent execution behaviors, particularly in low-level code. These differences are often difficult for developers and users to recognize, creating opportunities for adversaries to exploit legacy compiler behaviors and deploy contracts with potentially deceptive outcomes. We define this issue as the Compiler Version Discrepancy (CVD) risk , where attackers leverage compiler-version-dependent behaviors to produce misleading or unfair outcomes while contracts appear functionally benign. We summarize five representative CVD risk patterns from real compiler inconsistencies. To mitigate this risk, we develop the CompileGuard detection tool. It combines Abstract Syntax Tree (AST) analysis, taint analysis, and symbolic execution with Control Flow Graph (CFG) analysis to identify version-sensitive code patterns. Evaluation on 227 smart contracts shows CompileGuard achieves an overall F1 score of 95.22%. A user study with 21 blockchain practitioners shows contracts exploiting CVD risks can mislead users, while detection reports enable all participants to correctly identify risk-inducing behaviors. These results highlight the practical exploitability of CVD risks and the effectiveness of automated detection in preventing such deception.
A controlled timestamp-only projection of an ABD-style multiwriter quorum-register tag leaves completed reads current, exact, and linearizable while omitting the writer-identity component of the full protocol tag. Correctness therefore does not imply auditability at a distributed read boundary. A deterministic five-state host gives the protocol-independent companion: four sequential operations are totally ordered in real time, yet the read boundary exposes no source evidence. For an external specification fixed before the realization is chosen, zero-error boundary recovery exists exactly when all co-encoding locations agree and native source evidence aligns with the specified source and derivation relation. Under edit-generated source semantics, boundary agreement is equivalent to temporal zero-delay synchronization. Disjoint audited systems compose, but two independently verified services can assign incompatible roles to one shared location. Value projection likewise fails to preserve auditability; a certified refinement law transports it. A CAP partition carrier induces the corresponding read-boundary discriminator, but carrier data alone cannot supply the scheduler continuations required for an FLP transport. Finite DLS histories yield an exact stabilization-certificate bound and exclude one fixed evidence budget across all horizons. Protocol and replicated-storage rows illustrate the criterion across distributed boundaries. The substrate-independent ledger records the broader scope. Lean 4 verifies the finite models, reductions, abstraction maps, and internal bounds; the premises linking named systems to those models remain documentary.
Morena Barboni, Filippo Lampa, Andrea Morichetta, Andrea Polini
The immutability of deployed smart contracts increases the impact of undetected faults. Mutation testing evaluates test suite effectiveness by injecting controlled faults (mutants) into contract code and observing whether existing tests detect them. However, the number of generated mutants and the required test executions make mutation testing costly, limiting its scalability in realistic settings. We present ASCENT , an online test prioritization technique based on a Neural Monte Carlo Tree Search (Neural-MCTS) algorithm that dynamically learns and adapts test execution strategies during mutation analysis. The approach prioritizes tests in real time without requiring prior knowledge of the system under test, reducing execution cost while preserving fault detection effectiveness. This paper provides a comprehensive evaluation across five real-world Solidity projects. We analyze behavior under a wide range of hyperparameter configurations, examine how different state representations influence prioritization performance, and evaluate an asynchronous execution model that decouples search, inference, and training to reduce wall-clock execution time. The results show consistent reductions across all projects, ranging from 28–61% depending on project features and hyperparameter configurations, alongside a parallelized variant that substantially reduces wall-clock execution time with controlled trade-offs in prioritization performance.
Smart contracts have attracted rapid development and widespread application. Due to the complexity of real-world smart contracts, it is error-prone to correctly enforce all intended functionalities in code implementations, resulting in unintended functional behaviors and security issues in practice. Code-comment inconsistency detection has emerged as an important solution to these issues, which leverages the redundant functional specifications in comments to detect code implementations that violate developers' intentions. However, existing inconsistency detection solutions are typically pattern-based and limited to fixed types of inconsistencies, which prevents them from detecting the diverse inconsistencies between real-world code implementations and casually written comments. To bridge the gap, this paper presents SmartComment, the first technique that combines LLMs with program analysis techniques for detecting code-comment inconsistencies in smart contracts. SmartComment introduces an LLM-driven workflow which simulates real-world interactions between code reviewers and developers to identify inconsistencies. It incorporates various program analysis techniques into the workflow, including comment propagation and code context extraction for generating input context for inconsistency detection, as well as program variant generation and differential analysis for inconsistency confirmation. Our evaluation results show that SmartComment detects 203 valid inconsistencies from a dataset of 1,000 real-world contracts with a precision of 79.9%, highlighting its effectiveness in detecting prevalent and diverse real-world inconsistencies. Compared to previous work, SmartComment achieves both higher precision and recall, detecting over 90% of inconsistencies that existing methods fail to identify. Furthermore, an ablation experiment demonstrates the effectiveness of incorporating program analysis techniques into SmartComment, improving the F1-score from 58.7% to 81.3%.
Smart contract decompilation aims to recover high-level source code from bytecode, but evaluating decompilers remains difficult because existing studies use narrow datasets, inconsistent metrics, and limited semantic consistency checks. This gap is increasingly important as large language models (LLMs) begin to generate source-like Solidity that may compile and appear plausible, even when its semantics diverge from the original contract. We introduce SCDBench, a dataset and benchmark methodology for LLM-based smart contract decompilation. The dataset contains 600 real-world Solidity contracts with paired bytecode inputs, ground-truth source code, and replayable semantic checkpoints. SCDBench evaluates decompiler outputs through four cumulative stages: format completeness, compilability, Application Binary Interface (ABI) recovery, and semantic consistency via differential replay. We evaluate Claude Opus 4.7, GPT-5.3-Codex, and GLM-5 in a zero-shot decompilation setting, including GLM-5 variants with and without extended reasoning and a zero-shot compilation-repair setting. The results show that frontier LLMs can often produce structured and compilable Solidity, but achieving semantic consistency remains far from solved: the best-performing frontier model perfectly decompiles only 42/600 contracts. We further show that introducing same-model compilation repair substantially improves performance at modest additional cost. SCDBench establishes a common ground for rigorous, reproducible evaluation and aims to accelerate the development of reliable smart contract decompilers for blockchain security and transparency.
This replication package contains the data and scripts used in this empirical study, including the LLM-based semantic validation pipeline, the observed practice extraction process, and all figures from the research questions (RQ1–RQ5). ERC_Observed_Practicess.xlsx: workbook of observed practices ERC_Observed_Practices_Process_Review.xlsx: Phases to generate the workbook of observed practices Other supplementary materials: Essential data files (data/) results_semantic_validation.json: 11,559 issues classified by LLM (substantive, category, justification) sample_manual_review_updated.csv: ~400 manually reviewed entries for LLM quality validation eips_labels.csv / ercs_labels.csv: PR metadata from Ethereum repositories for status evolution analysis (RQ5) Scripts (scripts/) 01: scrapes the official ERC list from ethereum.org 02 : filters the dataset for ERC mentions via regex 03: classifies issues via Gemini (substantive + category) 03: removes duplicates from the validation JSON 03: merges LLM results with issue metadata 04: extracts observed practices per ERC via Gemini, cross-referenced with official specs 05: fetches GitHub labels and generates ERC status evolution figure (RQ5) 06: generates all quantitative figures (RQ1–RQ4)
Abstract Non-Fungible Tokens (NFTs) have be- come a significant component of the dig- ital asset ecosystem, yet the visualiza- tion of rarity—a primary determinant of NFT value—remains fragmented, in- consistent, and methodologically opaque across web platforms. This paper pro- poses a comprehensive framework for NFT rarity visualization in web systems, integrating on-chain metadata extrac- tion, information-theoretic rarity scor- ing, and interactive, multi-layered vi- sualization components. The frame- work addresses three core challenges: (1) the absence of a unified, transpar- ent rarity computation standard; (2) the lack of effective visual encodings tai- lored to trait-level and collection-level rarity distributions; and (3) the scala- bility constraints inherent in real-time web-based rendering of large NFT col- lections. We describe the architecture in detail—from blockchain data ingestion pipelines through normalization, scoring, and front-end rendering—and present a prototype implementation using modern web technologies. A comparative eval- uation against existing commercial rar- ity tools demonstrates improvements in computational transparency, visual inter- pretability, and user task performance. The contributions of this work are three- fold: a formalized rarity scoring model grounded in information content theory, a modular visualization architecture for web deployment, and empirical evidence of the framework’s effectiveness for collec- tors, analysts, and marketplace designers.
Mohamad Kassab, Rabeya Zahan Mily, Valdemar Vicente Graciano Neto
We report a five-year, construct-preserving longitudinal replication of a 2020 empirical study of blockchain-engineer job advertisements, extended to a global 2025 cohort. Using mixed text-mining and expert-validated coding grounded in established competency taxonomies, we analyze 235 postings from 31 countries to examine how blockchain-specific, general technical, and soft-skill demands have evolved under an aligned measurement protocol. The findings indicate professional maturation from single-platform prototyping toward multi-chain, production-grade engineering that integrates back-end development, deployment operations, and security. Ethereum remains the most frequently cited platform, while Solana and other ecosystems increase platform diversity. Smart-contract development becomes a baseline expectation, with Solidity remaining central and Rust and Move becoming mainstream. Operational tooling such as cloud and containerization, alongside security-oriented practices including audits and zero-knowledge proofs, appears as recurring demand signals. Soft-skill mentions rise substantially, while formal degree requirements decline in favor of experience-based qualification. We contribute an updated 2025 competency atlas and empirically grounded implications for software engineering research, hiring, and curriculum design, while acknowledging comparability limits inherent to global sampling and cross-period labor-market conditions.
Matteo Vaccargiu, Sabrina Aufiero, Silvia Bartolucci, Ronnie de Souza Santos · 6 authors
Labels on platforms such as GitHub support triage and coordination, yet little is known about how well they align with code modifications or how such alignment affects collaboration across contributor experience levels. We present a case study of the Kubernetes project, introducing label-diff congruence - the alignment between pull request labels and modified files - and examining its prevalence, stability, behavioral validation, and relationship to collaboration outcomes across contributor tiers. We analyse 18,020 pull requests (2014--2025) with area labels and complete file diffs, validate alignment through analysis of over one million review comments and label corrections, and test associations with time-to-merge and discussion characteristics using quantile regression and negative binomial models stratified by contributor experience. Congruence is prevalent (46.6\% perfect alignment), stable over years, and routinely maintained (9.2\% of PRs corrected during review). It does not predict merge speed but shapes discussion: among core developers (81\% of the sample), higher congruence predicts quieter reviews (18\% fewer participants), whereas among one-time contributors it predicts more engagement (28\% more participants). Label-diff congruence influences how collaboration unfolds during review, supporting efficiency for experienced developers and visibility for newcomers. For projects with similar labeling conventions, monitoring alignment can help detect coordination friction and provide guidance when labels and code diverge.
The Ethereum ecosystem, which secures over $381 billion in assets, fundamentally relies on client APIs as the sole interface between users and the blockchain. However, these critical APIs suffer from widespread implementation inconsistencies, which can lead to financial discrepancies, degraded user experiences, and threats to network reliability. Despite this criticality, existing testing approaches remain manual and incomplete: they require extensive domain expertise, struggle to keep pace with Ethereum’s rapid evolution, and fail to distinguish genuine bugs from acceptable implementation variations. We present APIDiffer , the first specification-guided differential testing framework designed to automatically detect API inconsistencies across Ethereum’s diverse client ecosystem. APIDiffer transforms API specifications into comprehensive test suites through two key innovations: (1) specification-guided test input generation that creates both syntactically valid and invalid requests enriched with real-time blockchain data, and (2) specification-aware false positive filtering that leverages large language models to distinguish genuine bugs from acceptable variations. Our evaluation across all 11 major Ethereum clients reveals the pervasiveness of API bugs in production systems. APIDiffer uncovered 72 bugs, with 90.28% already confirmed or fixed by developers, including one critical error in the official specifications themselves. Beyond these raw numbers, APIDiffer achieves up to 89.67% higher code coverage than existing tools and reduces false positive rates by 37.38%. The Ethereum community’s response validates our impact: developers have integrated our test cases, expressed interest in adopting our methodology, and escalated one bug to the official Ethereum Project Management meeting. By making APIDiffer open-source, we enable continuous validation of Ethereum client API implementations, thereby strengthening the foundational integrity of the entire Ethereum ecosystem.
We study what model-identifying information leaks through commercial language-model APIs that expose top-k token log probabilities. Building on extreme-value theory predictions for logit order-statistic gaps, we confirm that the normalized third logit gap (δ norm) remains near the Gumbel-class constant ≈0.318 across 6 models from 3 providers (OpenAI, Google Vertex AI, xAI) and 3 independent measurement sessions, demonstrating that output-layer universality persists through API truncation and quantization. We introduce a PPP-residualization transform that removes the dominant tail scale factor and reveals a low-dimensional but stable endpoint-specific geometry in the remaining gap spectrum. Contrary to common assumption, "provider" is not a geometrically coherent label: models do not cluster by corporate origin under these observables, but they do separate by model identity across independent sessions. Using a challenge-response protocol with centroid averaging and per-model thresholds, we demonstrate cross-session endpoint verification with a 0.83% breach rate (119/120 correct identifications across three temporal sessions); per-model thresholds eliminate all breaches on this dataset. We observe a robustness phase transition governed by enrollment depth. Under single-session enrollment, prompt selection is load-bearing: the majority of bootstrapped banks fail to separate the six endpoints. Under two-session enrollment, bank sensitivity collapses on this dataset, and a bank compiler produces small compiled banks that exceed the margin of larger uncompiled banks. A dimensionless robustness parameter SNR(K,S) unifies both axes: prompt count K and enrollment depth S jointly govern the transition from bank-sensitive to bank-robust verification. We discuss operational implications for re-enrollment cadence and template management in production deployments. Addendum (02/26/2026): Post-publication results extend this framework in two directions. A distillation experiment across six training protocols demonstrates that a model's structural fingerprint (weight-geometry regime) is completely invariant to knowledge distillation, while its functional fingerprint (PPP-residual template) converges 31--52% toward the teacher's — enabling forensic detection of distillation provenance through API measurements alone. A conditional impossibility theorem, machine-checked in Coq (41 theorems, 0 Admitted), proves that no standalone model can spoof another's PPP-residual template across independent challenge prompts without exhausting its KL divergence budget, under four explicit trust assumptions. Technical Note: Gap Invariance: Why PPP Measurements Are Domain-Independent by Construction (DOI: 10.5281/zenodo.19275524) The Neural Network Identity Series — Mathematical foundations, empirical validation, and governance frameworks for verifying which model is running Newest addition: Technical Note: The Disappearing Window — AI Logprob Access Withdrawal and the Structural Verifiability of Frontier Model Contracts (DOI: 10.5281/zenodo.20362098) Paper 1: The δ-Gene: Inference-Time Physical Unclonable Functions from Architecture-Invariant Output Geometry (DOI: 10.5281/zenodo.18704275) Paper 2: Template-Based Endpoint Verification via Logprob Order-Statistic Geometry (DOI: 10.5281/zenodo.18776711) Paper 3: The Geometry of Model Theft: Distillation Forensics, Adversarial Erasure, and the Illusion of Spoofing (DOI: 10.5281/zenodo.18818608) Paper 4: Provenance Generalization and Verification Scaling for Neural Network Forensics (DOI: 10.5281/zenodo.18872071) Paper 5: Beneath the Character: The Structural Identity of Neural Networks — Mathematical Evidence for a Non-Narrative Layer of AI Identity (DOI: 10.5281/zenodo.18907292) Paper 6: Which Model Is Running?: Structural Identity as a Prerequisite for Trustworthy Zero-Knowledge Machine Learning (DOI: 10.5281/zenodo.19008116) Paper 7: The Deformation Laws of Neural Identity (DOI: 10.5281/zenodo.19055966) Paper 8: What Counts as Proof? — Admissible Evidence for Neural Network Identity Claims (DOI: 10.5281/zenodo.19058540) Paper 9: Composable Model Identity — Formal Hardening of Structural Attestations in the Enterprise Identity Stack (DOI: 10.5281/zenodo.19099911) Paper 10:Where Identity Comes From: Path Sensitivity and Endpoint Underdetermination in Neural Network Training (DOI: 10.5281/zenodo.19118807) Paper 11: Post-Hoc Disclosure Is Not Runtime Proof: Model Identity at Frontier Scale (DOI: 10.5281/zenodo.19216634) Paper 12: Family-Dependent Response to Reasoning Distillation Across Structural and Functional Identity Layers (DOI: 10.5281/zenodo.19298857) Paper 13: Safety-Alignment Removal as a Model-Identity Failure — Structural Evidence from Published Weight-Level Mutation Checkpoints (DOI: 10.5281/zenodo.19383019) Technical Note: Agent Identity Is Not Model Identity (DOI: 10.5281/zenodo.19240883) Technical Note: Measured Model Substitution Under Valid Agent Credentials (DOI: 10.5281/zenodo.19342848) Technical Note: Artifact Identity Is Not Runtime Identity — Trustfall Lite and the Boundary of File-Level Model Verification (DOI: 10.5281/zenodo.20019127) Formal Verification Stack for Neural Network Structural Identity (IT-PUF Coq Proofs) (DOI: 10.5281/zenodo.18930621) Copyright (c) 2026 Anthony Ray Coslett / Fall Risk AI, LLC. All Rights Reserved. Confidential and Proprietary. Patent Pending (Applications 63/982,893, 63/990,487, 63/996,680, 64/003,244).
Large language models (LLMs) have been widely adopted in modern software development lifecycles, where they are increasingly used to automate and assist code generation, significantly improving developer productivity and reducing development time. In the blockchain domain, developers increasingly rely on LLMs to generate and maintain smart contracts, the immutable, self-executing components of decentralized applications. Because deployed smart contracts cannot be modified, correctness and security are paramount, particularly in high-stakes domains such as finance and governance. Despite this growing reliance, the security implications of LLM-generated smart contracts remain insufficiently understood. In this work, we conduct a systematic security analysis of Solidity smart contracts generated by state-of-the-art LLMs, including ChatGPT, Gemini, and Sonnet. We evaluate these contracts against a broad set of known smart contract vulnerabilities to assess their suitability for direct deployment in production environments. Our extensive experimental study shows that, despite their syntactic correctness and functional completeness, LLM-generated smart contracts frequently exhibit severe security flaws that could be exploited in real-world settings. We further analyze and categorize these vulnerabilities, identifying recurring weakness patterns across different models. Finally, we discuss practical countermeasures and development guidelines to help mitigate these risks, offering actionable insights for both developers and researchers. Our findings aim to support safe integration of LLMs into smart contract development workflows and to strengthen the overall security of the blockchain ecosystem against future security failures.
Recently, extensive research has focused on addressing the unique challenges of smart contract fuzzing. Nevertheless, existing fuzzers still struggle to generate adequate function call arguments that can explore the deep smart contract states. In this paper, we introduce novel classes of argument constraints that capture the inter-argument relationships required to exercise meaningful contract logic. We propose a static analysis algorithm to extract these constraints from Solidity source code. In addition, we design a constraint-aware argument mutation strategy that leverages the identified constraints to guide test case generation for smart contract fuzzing. We implement our approach in a fuzzer named IConFuzz. Our evaluation on realistic benchmarks with integer overflow, suicidal contract, and ether leakage vulnerabilities demonstrates that IConFuzz outperforms state-of-the-art testing tools in both the number of bugs discovered and the speed of bug detection.
Muhammad Faruq, Rahmad Abdillah, Nazruddin Safaat H., Pizaini
Smart contract vulnerabilities, particularly reentrancy, have caused hundreds of millions of dollars in losses across the Ethereum ecosystem. While static analysis tools dominate current auditing practice, empirical evaluations have consistently demonstrated their high false negative and false positive rates for reentrancy detection. Dynamic analysis, exemplified by property-based fuzzing with Echidna, offers an alternative by evaluating contracts through actual execution. However, systematic empirical evaluation of dynamic tools under controlled ground-truth conditions remains limited. This study adapts the bug injection methodology, previously applied only to static analysis evaluation, to assess Echidna's effectiveness in detecting reentrancy. A dataset of 50 Solidity contracts was instrumented with oracle properties and injected with two reentrancy variants, single-function and cross-function, producing 100 ground-truth contract variants. Three fuzzing configurations of increasing intensity were evaluated across three metrics: detection rate, activation rate, and average detection time. Results show that Echidna achieved 100% activation but detected only 20% to 42% of injected bugs depending on the configuration and variant. Nearly all detections occurred within the first 25 seconds of each campaign, with no benefit from extended timeouts. These findings reveal a fundamental gap between bug reachability and exploitability confirmation under standard fuzzing conditions.
Microservice architecture has emerged as a dominant paradigm for building largescale software systems, promising modularity, scalability, and independent evolution of services. A central premise of this paradigm is that architectural decomposition reduces inter-service dependencies and enables teams to develop and deploy services autonomously. Despite these expectations, empirical evidence on whether microservice systems actually achieve loose coupling in practice remains limited, particularly in open-source environments where development processes are highly decentralized. This thesis investigates coupling phenomena in microservice-based open-source systems from both technical and organizational perspectives. The research follows a progressive investigative design structured around three stages: <i>measurement, observation</i>, and <i>explanation</i>. First, the thesis introduces the <i>Microservice Logical Coupling</i> (MLC) metric, a repository-based approach for identifying evolutionary dependencies between microservices. By extending traditional logical coupling analysis from file-level artifacts to service-level entities, MLC enables the detection of cross-service evolutionary dependencies using version control data without requiring runtime instrumentation. Second, the thesis conducts a large-scale empirical analysis to assess the prevalence and evolution of logical coupling across microservice-based open-source projects. The results show that logical coupling is a widespread phenomenon and tends to increase over time, suggesting that architectural boundaries alone do not guarantee independent service evolution. Third, the study examines the socio-technical factors associated with coupling by analyzing developer contribution patterns and service ownership structures. The findings reveal a consistent association between cross-service developer activity and higher levels of logical coupling, indicating that organizational structures influence the emerqence of architectural dependencies. Overall, this work contributes a replicable measurement approach, an empirically grounded empirical analysis of coupling in microservices, and a socio-technical perspective on microservice evolution. The results suggest that service independence is not solely an architectural property but a socio-technical outcome shaped by both system design and development practices.
Formal verification of smart contracts is widely regarded as an effective method for ensuring correctness and security properties across all possible executions. Its practical relevance has been driven by the availability of automatic verification tools that discharge intricate proofs. Another area of growing interest is the integration of specification paradigms - for example, combining Hoare-logic–style specifications (pre/postconditions and invariants) with SMT and symbolic reasoning - so that each technique can precisely capture complementary aspects of contract behavior. In this article we present a comparative analysis of four leading Solidity verification tools - solc-verify, SMTChecker, VeriSmart and the Certora Prover - and define what is meant here by a formal verification tool: a system that provides mathematically rigorous proofs that stated properties hold for every possible execution of a contract. We also describe a consistent evaluation framework that considers the Solidity version support, the preservation of the original contract structure, the local execution capability, the verification time, and the modeling-language requirements, among other criteria. We used the ERC-20 token standard as a benchmark and applied this framework to obtain empirical evidence of each tool’s capabilities and limitations. Our results expose substantial variability in the tools performances that undermines their trustworthiness in practice and highlights a gap between an academic tool capabilities and the industrial requirements. Finally, we discuss how these findings can inform developers and researchers in selecting appropriate verification tools, thereby contributing to improved smart contract security and reliability.
This poster introduces HarvETHter, a smart contract decompiler for EVM-based platforms such as Ethereum, Binance, and Polygon. We present the corpus completeness hypothesis, which we investigate through HarvETHter. Relying on our hypothesis, HarvETHter sources knowledge of the Ethereum blockchain and leverages it to decompile smart contracts to Solidity source code.
This thesis investigates critical software delivery latency at a large fintech organization, where a modern micro-application architecture was severely bottle-necked by a legacy, manual, ticketing-based approval system. This hybrid environment created an acute organizational bottleneck, imposing high coordination burdens and unpredictable delays on globally distributed feature teams. Using an Action Research (AR) methodology, the study first established a high-friction baseline, measuring the median Lead Time for Changes (LTC) at 20.2 hours. The core intervention involved replacing the mandatory manual approval gate with a fully automated, self-service deployment model integrated directly into the Continuous Integration/Continuous Delivery (CI/CD) pipeline. The intervention successfully drove significant organizational efficiency, yielding a 69% reduction in LTC, dropping the median time from 20.2 hours to 6.2 hours. Concurrently, Deployment Frequency (DF) increased by 213% (from 47 to 100 releases per week). This improvement solidified the organization's position within the DORA elite performance tier. The primary practical guidance derived from this case study is that sustained software acceleration requires prioritizing the decentralization of control over the deployment trigger. This is achieved not merely through technical automation, but by deliberately eliminating all mandatory human coordination steps via external systems (e.g., tickets), relying instead on real-time visibility tooling integrated into the developer workflow. Additionally, and more importantly, this required a complementary organizational culture shift, which involved transfer-ring accountability for production stability directly from administrative roles, such as the Program Manager, to the autonomous development teams.