Pith. sign in

REVIEW 3 major objections 4 minor 29 references

Smart Contracts for SMEs and Large Companies

T0 review · 3 major / 4 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 A business analyst, not a blockchain developer, can deploy a smart contract straight from a BPMN diagram when the collaboration is document exchange.

desk verdict A plausible but unvalidated extension to the authors' BPMN-to-contract pipeline; the central premise collapses when you ask what a signed hash actually certifies. read the letter →

arxiv 2505.22619 v1 pith:HT4AP2HM submitted 2025-05-28 cs.SE cs.CRcs.DC

C. G. Liu , P. Bodorik , D. Jutla This is my paper
classification cs.SEcs.CRcs.DC
keywords smartcontractsBPMNautomatedcodegenerationblockchaincertifieddocumentexchangeoff-chaincomputationbusinessprocessmodelsSMEs
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

The paper claims that for a restricted but common class of collaborative business processes—those whose interactions consist only of exchanging documents—the final barrier to fully automated smart-contract generation can be removed. Instead of writing script code for BPMN task elements, all task computation runs off-chain and the smart contract records only digitally signed hashes of the documents exchanged. As a result, a business analyst who can model the process in BPMN can generate and deploy the contract without a software developer or blockchain expertise. The paper argues this makes smart contracts usable by SMEs with little IT and by large companies with sophisticated infrastructure, and demonstrates the workflow on a product-sale example.

What carries the argument

The load-bearing mechanism is the certified exchange of documents: each task is treated as a black-box off-chain step whose only on-chain footprint is a digitally signed content-addressed hash of the resulting document. Off-chain web services are invoked through contract events, and reply by calling a contract method that records the new document's hash. This replaces task-element scripts entirely. The mechanism is layered on the authors' existing pipeline that transforms BPMN into an HSM-based model and then into interconnected state-machine sub-models, but that pipeline now orchestrates hashes rather than executing business logic.

What would settle it

Run the generated contract on a permissioned blockchain test network. Have the off-chain actor sign and submit a Delivery document that is not the one the contract expected; if the contract accepts it and proceeds to payment, then the off-chain work is unverified. If it rejects the mismatched document, the claim that certified hashes preserve the workflow survives.

Watch

Extended reading notes

Core claim

The paper's central claim is that when the work of each BPMN task element can be executed off-chain and the on-chain/off-chain interaction can be modeled as a certified exchange of documents, the BPMN-to-smart-contract transformation needs no scripts for task elements. Under that condition the tool can generate and deploy the contract automatically, under a business analyst's control. The mechanism is that documents live off-chain, typically on IPFS, while their content-addressed hashes are signed and stored on-chain, creating a certified record of authorship and integrity. The paper exercises this on a sale-and-delivery process where transport requirements, insurance, and transport contracts are obtained off-chain and the contract coordinates the flow.

Load-bearing premise

The approach assumes that moving all task computations off-chain, leaving only signed hashes on-chain, preserves the trust and integrity of a multi-step trade; if an off-chain actor can substitute or withhold a document without detection, the contract records interactions but does not enforce the trade.

Editorial extensions

If this is right

  • For document-exchange-only BPMN models, the tool can generate and deploy the contract directly from the model under a business analyst's control.
  • The same pattern works for SMEs with manual off-chain work and large companies with web-service automation, so the pipeline spans both settings.
  • Because task logic lives off-chain, repairing or upgrading the contract does not require rewriting smart-contract code for individual task elements.
  • The signed hash trail gives an immutable, versioned history of document exchanges, providing a verifiable record of the collaboration.

Reading between the lines

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

  • The integrity guarantee shifts to off-chain actors: if one actor controls both a document and its signing key, they can present any document to the contract, so high-value steps would likely need multi-party signing or an independent notary.
  • The automated class is strictly exchange-only; any task requiring rule-based decisions on document contents would still need a script or an oracle, which the paper does not address.
  • The pattern resembles sidechain attestation: the main chain records outcomes without verifying the work, trading enforcement for scalability and deployability.
  • A testable extension is to require two or more independent off-chain signers for each document before the contract accepts it; the paper does not discuss this.
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. The paper describes an extension of the authors' TABS/TABS+R approach for generating smart contracts from BPMN models. The proposed extension moves the computation of BPMN task elements off-chain and records on the blockchain only digital signatures of IPFS content-addressed hashes (CIDs) of the resulting documents. The authors claim that, for applications whose interactions consist solely of certified document exchange, this allows a Business Analyst with no blockchain or smart-contract expertise to generate and deploy smart contracts automatically. Two scenarios are presented: a small SME where off-chain work is performed manually (possibly by the same BA), and a large company with separate departments and external partners. The paper frames this as democratizing smart-contract and blockchain technology, but explicitly defers validation to future work.

Significance. The high-level idea of combining off-chain task execution with on-chain certification of exchanged documents is relevant, and the paper usefully identifies a class of applications for which BPMN-to-smart-contract generation could potentially be automated. If the claimed mechanism were sound, it could lower the barrier for SMEs to adopt blockchain-based process support. However, the paper's central mechanism only authenticates authorship and non-modification of documents, not the correctness of the off-chain task output, and no threat model or experimental evaluation is provided. As it stands, the paper is a conceptual vision rather than a validated approach; the claimed trust guarantees are not established.

major comments (3)
  1. [III.B and IV.A] The certification mechanism described in Section III.B stores a digitally signed hash of an off-chain document, where authenticity is explicitly limited to '(i) authorship and (ii) that the document has not been modified.' It does not certify that the document's content is correct or that the off-chain task was performed as specified. Consequently, any signer — including the BA in the SME scenario of Section IV.A — can fabricate a document with arbitrary content (e.g., a false transport requirement or a fictitious insurance contract), sign it, and the smart contract will accept it and advance the workflow. The paper provides no threat model, dispute-resolution mechanism, or incentive analysis to show that substitution, withholding, or fabrication are detectable. This undermines the load-bearing claim that the generated smart contract 'support[s] such a certified exchange' and that the resulting contract enforces the multi-step trade; in fact it records submissions but does not verify task outcomes.
  2. [VI] Section VI states that 'actual success can only be achieved by further experimentation and in particular development of complementary tools.' The paper indeed contains no generated contract, no deployment test on HLF or EVM, no security analysis, and no comparison with existing BPMN-to-chain tools (Lorikeet, Caterpillar, CoBuP) beyond descriptive related work. The central feasibility claim — that a BA can automatically generate and deploy a smart contract for document-exchange applications without a software developer — is therefore under-supported by the manuscript itself. The reader cannot assess whether the transformation is complete or correct, or whether the TABS+R monitor (a self-cited component with no independent artifact) actually provides the claimed execution environment.
  3. [III.B] The condition under which the approach applies — 'the interaction between the on-chain and off-chain components can be modeled simply by a certified exchange of documents' — is left informal. The paper does not characterize which BPMN models admit this simplification, nor does it define the protocol by which off-chain web services and the on-chain smart contract interact (e.g., event handling, timeouts, error responses). Without a precise characterization and protocol specification, the claim of automated generation for 'certain applications' is neither reproducible nor falsifiable, and a third party cannot determine whether a given BPMN model is within scope.
minor comments (4)
  1. [References] References [1] and [2] are identical duplicates; reference [3] is an incomplete citation to a ScienceDirect URL with no author list; and the numbering around references [15]–[17] is inconsistent (the OMG BPMN spec citation appears to be missing or misplaced).
  2. [Fig. 1 caption] The figure caption reads 'PMN Model' and should be 'BPMN Model'; the figure itself is not accompanied by a description of the gateways and swimlanes used, which makes the example harder to follow.
  3. [IV.A] The statement that off-chain computation 'may simply be manual by, perhaps, BA performing the off-chain work' is vague: it is unclear who holds the signing keys, how the BA's role is separated from the subsequent verification of documents, and how conflicts of interest are avoided.
  4. [V] The related-work discussion describes Lorikeet, Caterpillar, and CoBuP individually but does not compare their required developer expertise, support for off-chain tasks, or validation status; a comparative table would help position the contribution.

Circularity Check

0 steps flagged · score 1.0 of 10

No circular derivation: the off-chain document-exchange step is a conditional design extension, not a prediction fitted to its conclusion; self-citations are infrastructural and the paper itself concedes the need for further experimentation.

full rationale

The paper's central step, in Section III.B, is conditional: 'when the work of a task element can be executed off-chain and the interaction between the on-chain and off-chain components can be modeled simply by a certified exchange of documents, then the transformation of the BPMN model into a smart contract is used to support such a certified exchange of documents and thus avoid coding of the task elements.' The no-coding outcome is the intended consequence of the stated assumption, not a result obtained by fitting or by defining the conclusion into the premise. The certification mechanism is imported from the external Plasma approach [23] and from standard IPFS/signed-hash practice, so it is not an ansatz hidden in a self-citation. No quantitative prediction is made from data, and no uniqueness theorem is invoked. The authors do cite their own prior TABS/TABS+ work [10-12] for the transformation pipeline and state in Section IV.A that they 'provide the TABS+R monitor smart contracts for Hyperledger Fabric (HLF) and for blockchains based on Ethereum Virtual Machine (EVM)'; this is a self-citation burden because no artifact is included, but it supports infrastructure rather than serving as the proof of the new document-exchange mechanism. Section VI concedes that 'actual success can only be achieved by further experimentation', which further limits the strength of the feasibility claim. The skeptical concern about off-chain actors submitting signed hashes of fabricated documents (Section III.B limits authenticity to 'authorship and that the document has not been modified') is a real soundness gap, but it is a correctness/security limitation, not circularity.

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

The central workflow rests on four domain assumptions about document-only collaborations, off-chain trust, event bridges, and the authors' own TABS+R monitor. There are no fitted parameters in this conceptual paper. No independently verified entity is introduced; the only nonstandard entity is the self-cited TABS+R monitor, which is not publicly verifiable.

assumptions (4)
  • domain assumption Tasks can be executed off-chain, with results reported to the smart contract as signed document hashes, without losing the trust guarantees of the multi-step transaction.
    Core enabler of developer-free generation; assumed in Section III.B with no threat model or security analysis.
  • domain assumption The supported application class consists solely of interactions that can be modeled as exchange of documents, so no on-chain task computation is required.
    Disclosed as a limitation in Section III.A, but it is also load-bearing: the tool's automation claim only applies to this restricted class.
  • domain assumption Smart contracts cannot access external resources, so an event-driven web service bridge is necessary and sufficient to connect on-chain flow to off-chain actors.
    Stated in Section III.B; standard for EVM chains, but the sufficiency of the event bridge for reliable delivery is not tested.
  • ad hoc to paper The TABS+R monitor, deployed on the target blockchain, provides the execution environment described in earlier self-cited work.
    No public artifact, bytecode, or deployment is linked in this paper; the entire toolchain depends on this unevidenced component.
invented entities (1)
  • TABS+R monitor smart contract
    purpose: On-chain execution environment for DE modeling and concurrent FSMs; required for every generated contract to run on Hyperledger Fabric or EVM chains.
    Mentioned only through self-citations [10-13]; no repository, address, or test results are supplied, so its behavior cannot be independently checked.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Smart Contracts for SMEs and Large Companies." pith.science (2026). https://pith.science/paper/HT4AP2HM

@misc{pith2026250522619,
  author       = {Pith},
  title        = {Pith review of: Smart Contracts for SMEs and Large Companies},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HT4AP2HM}},
  note         = {Machine review of arXiv:2505.22619}
}
read the original abstract

Research on blockchains addresses multiple issues, with one being writing smart contracts. In our previous research we described methodology and a tool to generate, in automated fashion, smart contracts from BPMN models. The generated smart contracts provide support for multi-step transactions that facilitate repair/upgrade of smart contracts. In this paper we show how the approach is used to support collaborations via smart contracts for companies ranging from SMEs with little IT capabilities to companies with IT using blockchain smart contracts. Furthermore, we also show how the approach is used for certain applications to generate smart contracts by a BPMN modeler who does not need any knowledge of blockchain technology or smart contract development - thus we are hoping to facilitate democratization of smart contracts and blockchain technology.

Figures

Figures reproduced from arXiv: 2505.22619 by the authors.

Figure 1
Figure 1. PMN Model for a Sale of Product and Its Delivery However, such computation also causes difficulties due to amendments required for either repairing bugs or for new features that need to be introduced, as it is likely that the required amendments would be within the task elements that are executed as a part of a smart contract. And repairing/upgrading smart contracts is not easy [25-27]. Many applications include sim… view at source ↗
Figure 2
Figure 2. BPMN Model in the Context of a Large Company [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

29 extracted references · 12 canonical work pages

  1. [1]

    In our previous research we described methodology and a tool to generate, in automated fashion, smart contracts from BPMN models

    Smart Contracts for SMEs and Large Companies Christian Gang Liu Faculty of Computer Science Dalhousie University Halifax, Canada Chris.Liu@dal.ca Peter Bodorik Faculty of Computer Science Dalhousie University Halifax, Canada Peter.Bodorik@dal.ca Dawn Jutla Sobey School of Business Saint Mary’s University Halifax, Canada Dawn.Jutla@gmail.com Abstract— Rese...

    work page 2019

  2. [5]

    In Proceedings of the the 2nd International Conference on Blockchain Technology (ICBCT'20)

    A Review on Scalability of Blockchain. In Proceedings of the the 2nd International Conference on Blockchain Technology (ICBCT'20). Association for Computing Machinery, New York, NY, USA, 1–6. DOI:https://doi.org/10.1145/3390566.3391665

    arXiv

  3. [6]

    CATERPILLAR: A Business Process Execution Engine on the Ethereum Blockchain,

    O. López-Pintado, L. García-Bañuelos, M. Dumas, I. Weber, and A. Ponomarev, “CATERPILLAR: A Business Process Execution Engine on the Ethereum Blockchain,” Apr. 22, 2019, arXiv: arXiv:1808.03517. doi: 10.48550/arXiv.1808.03517

    arXiv doi:10.48550/arxiv.1808.03517 2019

  4. [7]

    First, the BPMN model is analyzed and transformed into smart contract methods, which are subsequently deployed and executed on a blockchain platform, specifically Ethereum

    employs a two-phase methodology for converting BPMN models into smart contracts. First, the BPMN model is analyzed and transformed into smart contract methods, which are subsequently deployed and executed on a blockchain platform, specifically Ethereum. An off-chain component handles communication with the decentralized application (DApp), ensuring that a...

    work page 2021

  5. [8]

    Controlled flexibility in blockchain-based collaborative business processes,

    O. López-Pintado, M. Dumas, L. García-Bañuelos, and I. Weber, “Controlled flexibility in blockchain-based collaborative business processes,” Information Systems, vol. 104, p. 101622, Feb. 2022, doi: 10.1016/j.is.2020.101622

    arXiv 2022

  6. [9]

    Lorikeet: A Model-Driven Engineering Tool for Blockchain-Based Business Process Execution and Asset Management,

    Tran, Q. Lu, and I. Weber, “Lorikeet: A Model-Driven Engineering Tool for Blockchain-Based Business Process Execution and Asset Management,” in Proc. 2018 Int. Conf. on Business Process Management, 2018, pp. 1–5. [Online]. Available: https://api.semanticscholar.org/CorpusID:52195200

    work page 2018

  7. [10]

    Blockchains for Business Process Management - Challenges and Opportunities,

    J. Mendling et al., “Blockchains for Business Process Management - Challenges and Opportunities,” ACM Trans. Manage. Inf. Syst., vol. 9, no. 1, pp. 1–16, Mar. 2018, doi: 10.1145/3183367

    doi:10.1145/3183367 2018

  8. [11]

    of the nested multi-step transactions. Most recently, we further extended the underlying concepts and the tool to support upgrade/repair of smart contract, which is necessary (i) to repair bugs in smart contracts and/or (ii) to amend the smart contracts to model new functionalities or features in business processes as they continually evolve [12]. One of ...

    work page 1999

Show all 29 references
  1. [12]

    Decentralized collaborative business process execution using blockchain,

    F. Loukil, K. Boukadi, M. Abed, and C. Ghedira-Guegan, “Decentralized collaborative business process execution using blockchain,” World Wide Web, vol. 24, no. 5, pp. 1645–1663, Sep. 2021, doi: 10.1007/s11280-021-00901-7

    2021 doi

  2. [14]

    BPMN 2.0 Introduction - Flowable Open-Source Documentation. (n.d.). Retr. 2024/02/15 https://flowable.com/open-source/docs/

    2024

  3. [15]

    BPMN 2.0 Symbols—A complete guide with examples. (n.d.). Camunda. Retr. 2024/02/15 https://camunda.com/bpmn/reference/

    2024

  4. [16]

    Business Process Model and Notation (BPMN), Version 2.0.2. (n.d.). Retr. 2024/02/15 https://www.omg.org/spec/BPMN/2.0.2/PDF

    2024

  5. [17]

    About the Business Process Model and Notation Specification 2.0. (2010). Retr. 2024/02/15 https://www.omg.org/spec/bpmn/2.0/About-BPMN

    2010

  6. [18]

    Process Orchestration for end-to-end automation

    Camunda (n.d.). Process Orchestration for end-to-end automation. Retr. 2024/02/15 https://camunda.com

    2024

  7. [20]

    Hierarchical State Machines,

    M. Yannakakis, “Hierarchical State Machines,” in Proc. Int. Conf. IFIP on Theoretical Computer Science, Exploring New Frontiers of Theoretical Informatics. In TCS ’00. Berlin, Heidelberg: Springer-Verlag, Aug. 2000, pp. 315–330

    2000

  8. [21]

    Hierarchical finite state machines with multiple concurrency models,

    Girault, B. Lee, and E. A. Lee, “Hierarchical finite state machines with multiple concurrency models,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 18, no. 6, pp. 742–760, Jun. 1999, doi: 10.1109/43.766725

    1999 doi

  9. [22]

    Communicating sequential processes,

    A. R. Hoare, “Communicating sequential processes,” Commun. ACM, vol. 21, no. 8, pp. 666–677, Aug. 1978, doi: 10.1145/359576.359585

    1978

  10. [26]

    {EVMPatch}: Timely and Automated Patching of Ethereum Smart Contracts,

    M. Rodler, W. Li, G. O. Karame, and L. Davi, “{EVMPatch}: Timely and Automated Patching of Ethereum Smart Contracts,” presented at the 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 1289–1306. Accessed: Aug. 07,

    2021

  11. [27]

    SolSaviour: A Defending Framework for Deployed Defective Smart Contracts,

    Z. Li, Y. Zhou, S. Guo, and B. Xiao, “SolSaviour: A Defending Framework for Deployed Defective Smart Contracts,” in Proc. of the 37th Annual Computer Security Applications Conference (ACSAC ’21). New York, NY, USA: Association for Computing Machinery, Dec. 2021, pp. 748–760. d...

    2021

  12. [28]

    Aroc: An Automatic Repair Framework for On-Chain Smart Contracts,

    H. Jin, Z. Wang, M. Wen, W. Dai, Y. Zhu, and D. Zou, “Aroc: An Automatic Repair Framework for On-Chain Smart Contracts,” IEEE Transactions on Software Engineering, vol. 48, no. 11, pp. 4611–4629, Nov. 2022, doi: 10.1109/TSE.2021.3123170

    2022

  13. [29]

    (Re-)Justifying BPM: A Quest for the Interaction Turn Reviewing Subject-Oriented BPM

    Fleischmann, A., Schmidt, W., Stary , C. “(Re-)Justifying BPM: A Quest for the Interaction Turn Reviewing Subject-Oriented BPM.” In CBI '13: Proceedings of the 2013 IEEE 15th Conference on Business Informatics, pp. 228-233. DOI:10.1109/CBI.2013.40

    2013 doi

  14. [31]

    Upgradeability Concept for Collaborative Blockchain-Based Business Process Execution Framework,

    P. Klinger, L. Nguyen, and F. Bodendorf, “Upgradeability Concept for Collaborative Blockchain-Based Business Process Execution Framework,” in Blockchain – ICBC 2020, Z. Chen, L. Cui, B. Palanisamy, and L.-J. Zhang, Eds., Cham: Springer International Publishing, 2020, pp. 127–1...

    2020 doi

  15. [32]

    Solving the Buyer and Seller’s Dilemma: A Dual-Deposit Escrow Smart Contract for Provably Cheat-Proof Delivery and Payment for a Digital Good without a Trusted Mediator,

    Asgaonkar and B. Krishnamachari, “Solving the Buyer and Seller’s Dilemma: A Dual-Deposit Escrow Smart Contract for Provably Cheat-Proof Delivery and Payment for a Digital Good without a Trusted Mediator,” Jun. 21, 2018, arXiv: arXiv:1806.08379. doi: 10.48550/arXiv.1806.08379

    2018 doi arXiv

  16. [35]

    A Three-Layered Approach for Designing Smart Contracts in Collaborative Processes,

    Bagozi, D. Bianchini, V. De Antonellis, M. Garda, and M. Melchiori, “A Three-Layered Approach for Designing Smart Contracts in Collaborative Processes,” in OTM 2019 Conferences, H. Panetto, C. Debruyne, M. Hepp, D. Lewis, C. A. Ardagna, and R. Meersman, Eds., Cham: Springer In...

    2019 doi

  17. [319]

    https://doi.org/10.1007/978-3-319-94214-8_4A

    Springer, Cham. https://doi.org/10.1007/978-3-319-94214-8_4A

    doi

  18. [2016]

    Proceedings of Business Process Management Conference, Rome, Italy, 2016, 329-347

    Untrusted Business Process Monitoring and Execution Using Blockchain. Proceedings of Business Process Management Conference, Rome, Italy, 2016, 329-347

    2016

  19. [2021]

    Peer Peer Netw Appl

    Blockchain smart contracts: Applications, challenges, and future trends. Peer Peer Netw Appl. 2021 Apr 18:1-25. doi: 10.1007/s12083-021-01127-0. Epub ahead of print. PMID: 33897937; PMCID: PMC8053233

    2021 doi

  20. [2022]

    Blockchain: Research and Applications (Elsevier journal), 100115

    TABS: Transforming Automatically BPMN Models into Smart Contracts. Blockchain: Research and Applications (Elsevier journal), 100115. https://doi.org/10.1016/j.bcra.2022.100115

    2022

  21. [2024]

    ACM Distributed Ledger Technologies: Research and Practice (DLT) Journal

    Tabs+: Transforming Automatically BPMN Models To Smart Contracts with Nested Collaborative Transactions. ACM Distributed Ledger Technologies: Research and Practice (DLT) Journal. https://doi.org/10.1145/3654802

    doi

Pith tools

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