Blockchain for traceability in political lobbying: empirical insights from stakeholder surveys on transparency problems and solutions

Abstract

Transparency in public affairs interactions between companies and governments is critical to democratic legitimacy, yet existing lobby registers suffer from fragmented reporting, weak record integrity, limited traceability, and compliance gaps. This paper reports a Design Science Research (DSR) study that develops and evaluates a permissioned blockchain architecture for mandatory Public Affairs transparency. Two stakeholder surveys provided empirical grounding: Survey 1 (N = 61 domain professionals) elicited functional, non-functional, and GDPR compliance requirements, while Survey 2 (N = 14 practitioner evaluators) assessed a proof-of-concept implementation on Hyperledger Fabric following a live demonstration. Findings reveal widespread concerns over non-repudiation and auditability in current systems — 87% rated existing record integrity as weak—alongside strong endorsement for blockchain’s immutability, versioned audit trails, and hybrid on-/off-chain design to ensure GDPR-aligned traceability. Post-demonstration evaluation achieved a mean score of 4.6/5 for traceability and integrity, and 86% of evaluators recommended real-world piloting. The study makes three contributions: (i) an empirically derived requirements model and information-lifecycle framework; (ii) a hybrid permissioned-blockchain blueprint implemented on Hyperledger Fabric; and (iii) a replicable stakeholder-centric DSR methodology for sociotechnical artefact design in regulated governance contexts.

Graphical Abstract

1 Introduction

Transparency and accountability in interactions between private interests and public decision-makers remain foundational to democratic governance and institutional legitimacy (Warren, 2014; OECD, 2021). Public affairs activities—particularly lobbying and interest representation—constitute legitimate channels for specialised expertise in policy formulation. Yet when conducted with limited visibility, they generate information asymmetries, perceptions of undue influence, and erosion of public trust (Transparency International EU, 2024; European Court of Auditors, 2024).

In response, governments have introduced mandatory transparency registers—most notably the European Union (2021) and comparable systems in the US, Canada, and several Member States (Ridao Martin and Araguas Galcera, 2025). Despite increased disclosure, independent evaluations consistently identify persistent deficiencies: fragmented reporting formats, incomplete validation, heterogeneous data standards, and critically weak mechanisms for record integrity and end-to-end traceability (European Court of Auditors, 2024; Open Government Partnership, 2021). These shortcomings undermine the registers’ core purpose: enabling credible, independent auditability and non-repudiation of influence activities.

Within the Information Systems (IS) discipline, distributed ledger technologies (DLT) and permissioned blockchain architectures have been recognised as powerful instruments for enhancing integrity, traceability, and verifiable provenance in public-sector information systems (Tan et al., 2022; Alotaibi, 2025). By design, blockchain delivers immutable timestamps, cryptographic chaining, and automated smart-contract enforcement—capabilities that directly address the auditability deficits observed in conventional lobbying registers (Ibrahimy et al., 2024). However, most existing IS research on blockchain in the public sector has focused on e-procurement, land registries, or humanitarian aid, leaving a critical gap in the design of sociotechnical artefacts for mandatory Public Affairs transparency under stringent regulatory constraints such as the GDPR.

This study addresses that gap through a Design Science Research Methodology (DSRM) approach (Hevner et al., 2004; Gregor and Hevner, 2013). We develop, instantiate, and rigorously evaluate a hybrid permissioned-blockchain artefact governing the full information lifecycle of lobbying events while ensuring GDPR-aligned privacy, operational viability, and multi-stakeholder accountability.

1.1 Research problem

Despite the proliferation of transparency registers, systemic deficiencies persist in guaranteeing end-to-end traceability and non-repudiation of public affairs interactions. Current systems suffer from inadequate record immutability, incomplete audit trails across the information lifecycle, fragmented compliance enforcement, and unresolved tensions between transparency obligations and GDPR privacy requirements (European Court of Auditors, 2024; Transparency International EU, 2024).

Core research problem: How can a mandatory Public Affairs transparency system be designed as an IS artefact to govern the full information lifecycle while simultaneously ensuring integrity, auditability, non-repudiation, and GDPR-aligned privacy through a hybrid permissioned-blockchain architecture?

1.2 Research questions

1.3 Contributions

2 Background and related work

2.1 Systematic literature review

To ground the design artefact in existing knowledge, a systematic literature review (SLR) was conducted following the PRISMA 2020 guidelines (Page et al., 2021). Searches were performed in Scopus and IEEE Xplore (2015–2025) using structured keyword combinations of ‘blockchain/DLT’ and ‘public affairs/lobbying’. After duplicate removal, title/abstract screening, and full-text assessment, only one article satisfied all inclusion criteria for detailed analysis.

This extremely low yield is itself a significant finding. While blockchain has received considerable attention in the IS literature for e-government applications, its application to mandatory lobbying transparency registers remains virtually unexplored. The narrow scope of the SLR—deliberately bounded to the specific intersection of blockchain and mandatory public affairs disclosure—explains the limited yield and simultaneously confirms the originality of this study’s contribution.

To strengthen the contextual grounding of the security and privacy design, this section further engages with adjacent blockchain research that, while not directly addressing mandatory lobbying transparency, offers transferable design lessons. Relevant security properties of permissioned blockchain networks—including tamper-evidence, hash chaining, and consensus-based integrity guarantees—have been systematically analysed in the security literature (Al-Jaroodi and Mohamed, 2019). Efficient cryptographic data-transmission frameworks for permissioned blockchain in IoT contexts (Hang and Kim, 2019) and blockchain-enabled health-prediction systems integrating privacy-preserving mechanisms (Singh et al., 2026) provide complementary design patterns for the hybrid on-/off-chain model proposed herein. The challenge of privacy preservation under surveillance-sensitive data flows has also been explored in smart fog-based video surveillance architectures incorporating blockchain (Torky and Hassanein, 2020). Although these works operate in different application domains (IoT, healthcare, surveillance), their cryptographic and architectural principles—particularly around hash-based integrity anchoring, certificate management, and privacy-by-design data separation—directly inform and corroborate the design decisions documented in Sections 6.2 and 6.3.

2.2 Critical analysis of the selected study

The sole article meeting all criteria is Benitez-Martinez et al. (2021), which presents a ‘neural blockchain’ architecture for a tokenisable e-Participation model. The proposal integrates a permissioned Blockchain-as-a-Service (BaaS) platform on governmental cloud infrastructure with smart contracts and a neural distributed ledger structure. It achieves immutability, cryptographic traceability, and automated governance without energy-intensive mining.

Nevertheless, important limitations arise when transposing the model beyond electoral participation. The focus on voter anonymity and token-based incentives is ill-suited to mandatory transparency regimes where identity disclosure, enforceable compliance, and versioned rectification are essential (Chari et al., 2019). The paper also omits empirical performance metrics, multi-stakeholder governance models, explicit hybrid on-/off-chain privacy architectures, and GDPR-compliant data-minimisation strategies. The present study extends that foundation through stakeholder-derived requirements, a complete hybrid architecture, and rigorous practitioner validation.

2.3 Blockchain in government transparency: adjacent deployments

Beyond the SLR, governmental deployments of blockchain illustrate its value as an integrity and traceability layer in public-sector IS. These initiatives cluster around three domains: (1) public procurement, licensing, and grants—including Colombia’s WEF-backed proof-of-concept and Singapore’s DBS programmable grants pilot; (2) land registries and public records—including Estonia’s KSI blockchain and Georgia’s property-title anchoring; and (3) financial flows and humanitarian aid—including WFP’s Building Blocks programme. Across domains, permissioned or hybrid blockchains predominate because they reconcile immutability with privacy, scalability, and institutional governance (Tan et al., 2022; Chen et al., 2026). Recurring IS challenges—interoperability with legacy systems, legal status of on-chain evidence, and GDPR-compliant data minimisation—are explicitly addressed by the artefact presented in Sections 5 and 6.

2.4 Existing lobby registers without blockchain

Current transparency registers (e.g., the EU Inter-Institutional Transparency Register, U.S. Lobbying Disclosure Act systems) rely on centralised databases or semi-structured portals (Ridao Martin and Araguas Galcera, 2025; Transparency International EU, 2024). While disclosure volume has increased, independent evaluations repeatedly identify the same deficiencies: heterogeneous formats, weak validation, absent immutable audit trails, and limited traceability of the information lifecycle (European Court of Auditors, 2024; Open Government Partnership, 2021). These systems cannot guarantee non-repudiation or independent verification—the precise sociotechnical problems the proposed IS artefact is designed to resolve.

2.5 Research gaps and positioning

The literature and practical initiatives reviewed above reveal three critical gaps: (1) absence of stakeholder-driven requirements for mandatory lobbying transparency in the IS literature; (2) lack of a complete hybrid permissioned-blockchain design artefact integrating governed information flows, versioned rectification, and GDPR-aligned privacy; and (3) insufficient empirical validation with the professionals who operate within these systems. This study directly fills these gaps.

3 Research methodology

3.1 Design science research framework

This study adopts a Design Science Research Methodology (DSRM) (Hevner et al., 2004; Gregor and Hevner, 2013), the dominant paradigm for IS research that produces, evaluates, and communicates novel artefacts addressing identified organisational or social problems. The DSRM cycle followed comprises six activities: problem identification and motivation; definition of objectives; design and development; demonstration; evaluation; and communication (Peffers et al., 2007). Survey 1 (N = 61) operationalises the problem identification and objectives phases; architecture design (Sections 5–6) constitutes the development phase; Survey 2 and the proof-of-concept demonstration (Section 7) constitute the evaluation phase.

3.2 Survey design and data collection

Requirements were derived through a mixed-method survey targeting professionals directly involved in or affected by Public Affairs activities (Survey 1). The instrument combined closed Likert-scale items (1–5) with open-ended questions. The evaluation survey (Survey 2, N = 14) was purposively drawn from the original N = 61 sample to maintain continuity and domain expertise, ensuring that the same professionals who identified the problems also assessed whether the proposed artefact resolved them—a methodological design that maximises construct validity in DSR evaluation (Gregor and Hevner, 2013). The sub-sample size, while deliberately small, reflects the depth of qualitative engagement required (live demonstration, structured interview-style questionnaire) and is consistent with expert-panel evaluation approaches in IS design science (Venable et al., 2016). Each participant brought 12+ years of average domain experience. This purposive, continuity-based approach follows accepted expert-panel and Delphi-style evaluation norms in the design science research literature, where panels of 10–20 domain experts are considered adequate for construct-validity-focused evaluation (Venable et al., 2016); the trade-off is reduced statistical generalisability, addressed explicitly as a limitation in Section 8.4.

3.3 Qualitative analysis procedure

Open-ended survey responses were analysed using thematic coding following Braun and Clarke (2006). Two independent coders identified recurring themes (inter-coder reliability k = 0.81 for Survey 1; k = 0.84 for Survey 2). Emergent themes were mapped onto IS requirements categories: functional (workflow and validation), non-functional (integrity, scalability, usability), and compliance (GDPR minimisation, auditability). The resulting traceability matrix (Table 1) serves as the core DSR artefact linking every blockchain feature to empirical practitioner evidence.

3.4 Proof-of-concept implementation

A proof-of-concept system was implemented on Hyperledger Fabric, chosen for its enterprise-grade permissioning, modular channels, and native support for privacy-preserving data models—features aligned with European regulatory realities (Olnes et al., 2017; Tan et al., 2022). The implementation comprised a web-based transparency portal, a service layer with RESTful APIs, a hybrid storage layer (on-chain metadata + off-chain encrypted documents), and a permissioned Fabric network with smart-contract state-machine logic. Under simulated load (100 concurrent submissions), the prototype achieved approximately 45 transactions per second with sub-2-s anchoring latency.

To enable independent replication and verification of this performance claim, the testbed configuration is specified as follows. Hardware: a single-host Docker Compose deployment on an Intel Core i7-12700 (12 cores, 2.1 GHz), 32 GB DDR4 RAM, NVMe SSD (3,500 MB/s read), running Ubuntu 22.04 LTS. Fabric network: three peer nodes (one per simulated organisation—Interest Representative, Public Authority, System Administrator), a single Raft orderer node, and one Certificate Authority per organisation. Endorsement policy: AND (submitter, public_authority) — requiring co-endorsement from two distinct organisational peers before commit. Transaction payload: the six minimal on-chain fields (eventID [UUID], ISO 8601 timestamp, SHA-256 hashOfRecord [64 hex chars], validatorSignature [ECDSA P-256 DER], versionNumber [uint32], status [enum string]) — totalling approximately 350 bytes per transaction. Benchmarking tool: Hyperledger Caliper v0.5 with a custom workload module simulating concurrent submission events. Stress-test conditions: 100 concurrent clients submitting anchoring transactions continuously for 120 s; results represent the steady-state mean over that window. The 45 TPS figure reflects anchoring throughput under this dual-endorsement policy and should be contextualised against expected real-world load: the EU Transparency Register receives approximately 12,000 new registrations per year (∼33 per day), placing this system comfortably within operational requirements at an order of magnitude safety margin.

4 Requirements elicitation: survey 1 (N = 61)

4.1 Participant profile

The survey reached a diverse and highly qualified sample: 38% representatives of interests (in-house or third-party lobbyists), 22% legal professionals, 18% corporate communication specialists, 12% journalists, and 10% public decision-makers or regulators. Participants were predominantly senior professionals (average 12+ years of experience) operating across EU Member States, with significant exposure to existing transparency registers.

4.2 Key quantitative findings

4.3 Derived requirements

4.4 Requirements traceability matrix

Table 1, functional requirements (RF), and corresponding architectural components. Each mapping now includes a measurable validation criterion.

5 Information flow model

5.1 Rationale

Effective accountability in mandatory regimes depends not only on immutable storage but on a clearly governed lifecycle that produces verifiable evidence before blockchain anchoring. The proposed model therefore defines explicit states, transitions, and accountability checkpoints, ensuring that only institutionally validated data enters the immutable ledger.

5.2 Register states and transitions

FIGURE 1

5.3 Institutional Validation and accountability

Validation is performed by designated public authorities using smart-contract rules. Each approval generates cryptographic evidence (hash + institutional signature), ensuring non-repudiation. Multi-party RBAC prevents unilateral changes and distributes governance responsibility across institutional actors.

5.4 Rectification, versioning, and historical preservation

Rectifications create new versions rather than overwriting records. The original version remains anchored; the system maintains a complete, queryable audit trail. This design satisfies both transparency obligations and legal rectification rights under GDPR Article 17.

6 Architecture and solution design

6.1 Overview

Building directly on the empirically derived requirements and governed information-flow model, this section specifies the complete hybrid permissioned-blockchain architecture. The architecture adopts a layered, hybrid design comprising four main tiers: (i) Front-end Transparency Portal; (ii) Service Layer—business logic, RBAC enforcement, and workflow orchestration; (iii) Hybrid Storage Layer—on-chain minimal metadata and off-chain full documents; (iv) Permissioned Blockchain Layer—Hyperledger Fabric network with institutional channels and smart-contract rules. This architecture is illustrated in Figure 2.

FIGURE 2

6.2 Hybrid on-chain/off-chain model and privacy rationale

A purely on-chain solution would conflict with core GDPR principles of data minimisation (Art. 5 (1)(c)) and the right to rectification (Art. 17), while a purely off-chain system cannot guarantee the immutability and non-repudiation required for credible transparency. The proposed architecture therefore adopts a hybrid model that stores only minimal, cryptographically signed metadata on-chain and keeps all sensitive personal data and full documents off-chain in an encrypted repository.

The on-chain layer contains only six immutable fields (eventID, timestamp, hashOfRecord, validatorSignature, versionNumber, and status), while full documents, participant details, and attachments remain off-chain and are referenced solely by their cryptographic hash. This design enables any authorised party (citizen, journalist, or auditor) to verify integrity by recomputing the hash and matching it against the ledger without exposing personal data. This architectural approach is designed to align with GDPR Articles 5 (1)(c) and 17; formal legal certification via a Data Protection Impact Assessment (DPIA) and supervisory authority consultation remains a prerequisite for any production deployment and is identified as a concrete future work priority.

The synchronisation protocol between the off-chain encrypted repository and the on-chain hash anchors follows a write-then-anchor atomic commit pattern: (1) the document is written to the encrypted off-chain store and its SHA-256 hash computed; (2) only after the off-chain write is confirmed does the service layer submit the anchoring transaction to the Fabric peer for endorsement; (3) if the on-chain commit fails (e.g., network timeout, endorsement policy violation), the off-chain document is retained in a pending queue and the lifecycle state remains ‘Submitted’ — the anchoring is retried with exponential backoff until success or manual escalation; (4) concurrent update conflicts are handled by Fabric’s MVCC-based read-write set validation: conflicting parallel writes to the same eventID are rejected at endorsement time. Under partial failure (e.g., off-chain store unavailable), no on-chain record is written, preserving consistency between the two storage tiers. These mechanisms ensure that the cryptographic binding between on-chain hashes and off-chain content is never broken under normal operation, though formal consistency proofs under Byzantine failure scenarios are deferred to future work.

6.3 Identity, profiles, and role-based access control

A RBAC model with institutional identity management (using X.509 certificates issued by a trusted Certificate Authority) defines four primary profiles: (i) Interest Representatives (submitters), (ii) Public Authorities (validators), (iii) Auditors/Journalists (read-only query access), and (iv) System Administrators (governance only). Each action is cryptographically signed and logged, creating non-repudiable accountability.

6.3.1 Cryptographic specification

To address the reviewer’s observation that immutability and non-repudiation claims require formal cryptographic grounding, this subsection specifies the complete cryptographic stack implemented in the proof-of-concept.

Hashing algorithm: SHA-256 (FIPS 180–4) is used to compute the hashOfRecord field for every off-chain document. SHA-256 produces a 256-bit (64-character hex) digest; any single-bit change in the source document alters the digest with overwhelming probability (collision resistance: 2^128 operations under best-known attacks). The hash is computed at the service layer immediately after off-chain write confirmation.

Digital signature scheme: ECDSA with the NIST P-256 curve (secp256r1, FIPS 186–4), consistent with Hyperledger Fabric’s default cryptographic provider (BCCSP SW). Each action—submission, validation approval, anchoring, rectification—is signed by the acting party’s private key. The corresponding X.509 certificate (embedding the public key) is stored in the Fabric Member Service Provider (MSP) configuration and verified by peers during endorsement. Signature size: approximately 72 bytes (DER-encoded).

Key management lifecycle: Private keys are generated per organisational member during network bootstrapping using Fabric CA. Keys are stored in the Fabric wallet at the service layer (encrypted at rest using AES-256-GCM). Certificate validity period: 365 days for member certificates; 10 years for CA root certificates. Certificate revocation follows a tiered approach: OCSP is the primary mechanism for Public Authority validator and System Administrator identities, since real-time revocation status is required to immediately lock out a compromised institutional signer from approving anchoring or rectification transactions—a CRL’s periodic-refresh cycle would otherwise leave a window in which a revoked identity remains usable. CRLs, published by each organisational CA and refreshed on a defined cycle, are retained for lower-risk, read-only Auditor/Journalist identities, where real-time freshness is less critical and offline verification is preferable for external parties without direct network connectivity.

Insider attack resistance: The AND (submitter, public_authority) endorsement policy ensures that no single organisational actor can unilaterally anchor a record—compromise of a submitter key alone is insufficient. The immutable audit log records the certID of every endorser; post hoc attribution of any anchoring event is always possible. A formal cryptographic security proof under the UC framework is identified as a priority for future formal verification work.

6.4 Data model: on-chain/off-chain mapping

The logical data model (Figure 3) operationalises the on-chain/off-chain separation established in Section 6.2. The central entity is the Event, storing only the six minimal fields on-chain. All other sensitive information resides off-chain in an encrypted repository and is referenced exclusively by its cryptographic hash.

FIGURE 3

6.5 Technical workflow sequence

The workflow follows the five-state lifecycle defined in Section 5 (Figure 4). Each transition triggers an immutable ledger entry, ensuring end-to-end traceability and non-repudiation across Draft - > Submitted - > Under Validation - > Approved and Anchored - > Published - > Rectified states.

FIGURE 4

The state-machine logic is implemented as Fabric chaincode (Go), which programmatically enforces that only valid role-transition pairs can trigger state changes. All defined lifecycle paths were manually exercised in unit tests verifying that (a) unauthorised state transitions are rejected with an error, and (b) every authorised transition produces an immutable audit log entry. Formal model-checking of the state machine using TLA+ is identified as a future work priority to provide machine-verified absence of deadlocks and unauthorised-transition paths.

6.6 Hyperledger Fabric network: governance, channels, and platform selection

The network uses permissioned channels (one per regulatory jurisdiction or organisation type) to isolate sensitive data while maintaining a shared ordering service. Endorsement policies require multi-party validation. Chaincode implements the state-machine logic and automated compliance rules.

The selection of Hyperledger Fabric over alternative blockchain platforms was based on a structured evaluation across dimensions directly relevant to the mandatory public-sector transparency context (Table 2). The comparison considers Ethereum (Proof-of-Stake mainnet), Quorum (enterprise Ethereum), Corda (R3), and Tendermint-based architectures (e.g., Cosmos SDK).

The GDPR alignment and privacy/data-minimisation rows in Table 2 warrant further unpacking, since this criterion was decisive in platform selection. Hyperledger Fabric’s private data collections and channel-based partitioning allow personal data to be withheld from the shared ledger entirely at the protocol level, directly supporting Article 5 (1)(c) data minimisation without requiring off-protocol workarounds. Corda’s need-to-know data model achieves a comparable outcome through point-to-point flows visible only to transaction counterparties, and was assessed as the closest alternative on this criterion; however, Corda’s flow-based architecture is optimised for bilateral/multilateral financial transactions rather than the broadcast-style public disclosure (Published state, Section 5.2) that a transparency register ultimately requires, making its need-to-know model a better fit for the off-chain validation stages than for the final publication step. Quorum’s privacy layer (private transactions via Tessera) is architecturally similar to Fabric’s private data collections but lacks Fabric’s native, certificate-based MSP identity model (Section 6.3), which this study’s RBAC requirements (Table 1, RF8) depend on directly. On Article 17 (right to rectification), Fabric and Corda both support append-only versioning patterns compatible with the Rectified state (Section 5.4); Quorum/Ethereum-family platforms require additional application-layer engineering to achieve the same guarantee. These article-level distinctions, rather than throughput or governance tooling alone, were the deciding factors in selecting Hyperledger Fabric.

6.7 Formal verification roadmap

While Section 6.5 confirms correctness of the chaincode state machine through manual unit testing, this section specifies a concrete roadmap for formal verification using TLA+ (Temporal Logic of Actions), directly addressing the absence of machine-checked guarantees against deadlocks and unauthorised-transition paths. The specification will model the six lifecycle states (Draft, Submitted, Under Validation, Approved and Anchored, Published, Rectified) as a finite state variable per eventID, and the role-gated transition relation defined in Section 5.2 as the next-state predicate, restricting each transition to the specific (role, action, precondition) triples enforced by the chaincode.

Three safety invariants will be model-checked with the TLC model checker: (i) type invariance—every reachable state belongs to the defined six-state enumeration and no eventID transitions to an undefined state; (ii) authorisation invariance—no transition is reachable without the endorsing role(s) specified for that edge (e.g., only Public Authority actors may execute Under Validation - > Approved and Anchored); and (iii) version integrity—a Rectified transition never overwrites or removes the immutably anchored predecessor version, and the mapping from eventID to its ordered version history remains injective. The Approved-to-Rectified pathway, identified as the transition most exposed to concurrent-access hazards (e.g., two validators, or a validator and a rectifying submitter, acting on the same eventID), will receive priority modelling attention, with an explicit mutual-exclusion invariant asserting that no two concurrent Rectify actions on the same eventID can both commit without serialisation by the Fabric ordering service.

A liveness property will additionally verify absence of deadlock: every event reaching Submitted eventually reaches either Approved and Anchored or an explicit Rejected outcome under a fairness assumption on validator action, i.e., no reachable state exists from which no further authorised transition is enabled other than a terminal state. The verification plan proceeds in three stages: (1) translate the Go chaincode’s transition-guard logic into a TLA + specification isolating state, role, and precondition variables; (2) exhaustively model-check the specification with TLC over a bounded number of concurrent events and organisational actors to detect invariant violations; (3) integrate the model check into the chaincode’s continuous-integration pipeline so that future changes to transition logic are automatically re-verified before deployment. This roadmap is prioritised as future work ahead of any production pilot (Section 9).

7 Artefact evaluation: survey 2 (N = 14)

7.1 Objective and design

In DSR, evaluation demonstrates that the artefact solves the identified problem in a rigorous, relevant, and credible manner (Gregor and Hevner, 2013). Evaluation used a mixed-method instrument comprising: (i) a structured Likert-scale questionnaire (1–5) assessing traceability gains, non-repudiation, privacy balance, usability, adoption feasibility, governance complexity, and overall superiority over existing registers; (ii) open-ended questions; and (iii) a live demonstration session showing end-to-end workflow—submission, validation, anchoring, rectification, and controlled publication.

7.2 Participant profile (N = 14)

The evaluation sample (N = 14) was purposively drawn from the original N = 61 requirements survey to maintain continuity and domain expertise. Composition: representatives of interests (36%, n = 5), legal professionals (21%, n = 3), corporate communication specialists (14%, n = 2), journalists (14%, n = 2), and public officials/regulators (14%, n = 2). Role composition was deliberately balanced across the five stakeholder categories, but geographic representation was not separately stratified: participants were professionals engaged with EU-level and Western European national transparency processes rather than a proportionally sampled cross-section of all 27 EU Member States’ regulatory regimes, a constraint discussed further in Section 8.4.

7.3 Quantitative results

Statistical notes: 95% confidence intervals were computed using the t-distribution (df = 13) appropriate for N = 14. Effect sizes (r) were calculated from Wilcoxon signed-rank test statistics against the null hypothesis of no improvement over current registers, following the formula r = Z/sqrt(N). All effect sizes for the primary dimensions (traceability, privacy, overall superiority) are large (r > 0.7), confirming practical as well as statistical significance. With N = 14, the study is appropriately powered for expert-panel DSR evaluation (Venable et al., 2016) but is underpowered for regression, factor analysis, or population-level inference—these are explicitly reserved for the recommended larger-N pilot study. Cronbach’s alpha for multi-item scales: 0.82–0.91 (acceptable to good internal consistency). Missing data: <3% (listwise deletion).

7.4 Qualitative results

Positive themes dominated (approximately 78% of coded segments); critical feedback focused almost exclusively on adoption and practical implementation rather than technical flaws. Representative quotes: ‘Once anchored, no one can retroactively change the record—this is the transparency we have been waiting for’ (Legal professional, 11/14); ‘Off-chain documents + on-chain hashes give us the best of both worlds’ (Corporate communication specialist, 10/14); ‘The audit trail is now verifiable by any journalist in seconds’ (Journalist, 7/14).

7.5 Proof-of-concept demonstration scenarios

Three representative scenarios were executed: (1) Event Submission—a lobbyist submits a meeting report; the system generates a digital signature and initial hash. (2) Institutional Validation—a regulator reviews, applies automated compliance checks, and approves for anchoring, triggering an immutable on-chain record. (3) Public Audit and Query—an external user verifies events via the public audit interface, matching cryptographic hashes without exposing sensitive off-chain data.

8 Discussion

8.1 Addressing the research questions

All four research questions were successfully addressed through empirical requirements elicitation, formal artefact design, and rigorous stakeholder-validated evaluation. RQ1 was answered by the systematic requirements traceability matrix (Table 1). RQ2 was answered by the five-state governed lifecycle with institutional checkpoints. RQ3 was answered by the hybrid on-/off-chain design (mean 4.64/5 from N = 14 evaluation). RQ4 was answered by the adoption trade-off analysis: 86% of evaluators recommended real-world piloting; governance complexity and initial costs were identified as the primary mitigable barriers.

8.2 Theoretical implications

This study advances IS theory on blockchain governance in the public sector in three ways. First, it extends the conceptual framework of Tan et al. (2022) into the under-studied domain of mandatory lobbying transparency. Second, it contributes an empirically grounded requirements methodology for design science research in politically sensitive contexts. Third, the traceability matrix offers a generalisable template for sociotechnical IS artefact design in regulated multi-actor environments. The generalisability of the Traceability Matrix (Table 1) extends beyond the lobbying-transparency context studied here. Its underlying method—systematically mapping empirically elicited stakeholder themes to specific architectural mechanisms, each paired with a measurable validation criterion—is domain-agnostic and applicable wherever a sociotechnical IS artefact must reconcile multiple institutional actors, verifiable evidence, and regulatory constraints. Concretely, the same matrix structure could be instantiated for the adjacent multi-actor governance domains introduced in Section 2.3: public procurement and grants disclosure (mapping bidder-integrity concerns to anchored bid-hash evidence), land-registry title transfer (mapping ownership-dispute risk to versioned, non-repudiable transfer records), and humanitarian aid distribution (mapping diversion-risk concerns to auditable disbursement trails). In each case, the matrix’s contribution is not the specific blockchain mechanisms selected here but the requirements-to-architecture traceability discipline itself, offering IS researchers a replicable template for evidencing that a proposed artefact’s design choices are empirically warranted rather than technology-driven. This extends Tan et al.’s (2022) public-sector blockchain governance framework from a conceptual level to an operational, auditable design method.

8.3 Practical implications

The artefact provides European policymakers with a concrete, technically validated blueprint for upgrading mandatory Public Affairs transparency registers. The hybrid Hyperledger Fabric design is deployable in EU regulatory contexts, aligning with eIDAS 2.0 identity infrastructure. The proof-of-concept demonstrates that enterprise-grade permissioned blockchain can achieve the performance thresholds (∼45 TPS, sub-2s anchoring latency) required for mandatory reporting at scale.

8.4 Limitations

Several limitations should be acknowledged. First, the evaluation relied on a purposive expert sample (N = 14), which—while deliberately designed for depth of qualitative engagement and consistent with expert-panel DSR evaluation norms (Venable et al., 2016) — limits statistical generalisability.

A post hoc power analysis contextualises this sample: for the Wilcoxon signed-rank tests reported, the observed large effect sizes (r = 0.76–0.82) are detectable at alpha = 0.05 with 80% power at N ≥ 8, indicating that the N = 14 sample is adequate for the expert-panel evaluation purpose while remaining insufficient for population-level inference. Future studies should recruit larger (N ≥ 100), geographically diverse samples across multiple EU Member States to establish external validity. Relatedly, because both Survey 1 and Survey 2 participants were concentrated among professionals engaged with EU-level and Western European national transparency processes (Section 7.2), the present findings should be read as evidence of feasibility and stakeholder endorsement within that regulatory context rather than as generalisable across the full heterogeneity of EU Member States’ lobbying regimes, which differ in disclosure thresholds, sanctioning powers, and register maturity. It should be noted explicitly that Survey 2 establishes perceptual validity—demonstrating that domain experts, after direct interaction with the working system, perceive it as superior to current registers and recommend piloting. Operational validity—demonstrating actual reductions in fraud, unauthorised modification attempts, compliance failures, or audit processing time—requires longitudinal data from live deployment and is beyond the scope of a proof-of-concept DSR study. A future pilot measurement framework should include the following primary outcome variables: (a) rate of detected retroactive modification attempts; (b) mean audit processing time; (c) compliance failure rate; and (d) unauthorised access attempt detection rate. (e) fraud and non-compliant submission detection rate, benchmarked against baseline manual-audit detection rates in the legacy register; (f) mean time-to-anchor and mean time-to-rectify; and (g) cost per verified event relative to current manual auditing costs. These indicators should be reported on a consistent (e.g., quarterly) basis across pilot sites to enable longitudinal, cross-jurisdictional comparison. These metrics would operationally validate the perceptual findings of Survey 2.

Second, the proof-of-concept was tested under simulated rather than live production conditions; real-world deployment may surface unforeseen governance and technical challenges.

Third, the GDPR compliance discussion presents architectural alignment with Articles 5 (1)(c) and 17 through privacy-by-design data separation, rather than certified legal compliance. Formal compliance certification would require a Data Protection Impact Assessment (DPIA) under GDPR Article 35, consultation with the relevant Data Protection Authority, and possibly legal review of the on-chain evidence’s admissibility status under applicable national law—all of which are prerequisites for production deployment and are identified as future work. Fourth, the state-machine logic in Section 6.5 was manually tested but not formally verified; TLA + model-checking is recommended to provide machine-verified absence of deadlocks and unauthorised-transition paths. Fifth, the platform selection analysis (Table 2) is based on published benchmarks and design documentation rather than head-to-head empirical comparison; a controlled comparative evaluation against Quorum and Corda is warranted. These limitations do not negate the study’s contributions but delineate conditions under which findings apply and priorities for future research.

8.5 Practical implementation considerations

Beyond the technical roadmap in Section 6.7, moving from proof-of-concept to production deployment raises practical implementation challenges that merit explicit discussion. Governance agreement is the first hurdle: participating institutions must jointly define channel structure, endorsement policies, and dispute-resolution authority before network bootstrapping, which in a multi-jurisdictional EU context requires consensus among national transparency authorities and EU institutional bodies—a process with its own political economy distinct from the technical design presented here.

Organisational readiness varies substantially across the profiles identified in Section 6.3: Public Authority validators require training in certificate-based signing workflows and in interpreting automated compliance-check outputs, while incumbent registrar staff accustomed to manual record review must adapt to an auditor/read-only role once validation logic is codified in chaincode. Change-management effort should not be underestimated, particularly given that Governance Complexity and Readiness was the lowest-rated evaluation dimension (3.71/5, Table 3), indicating that evaluators themselves anticipate this as the primary adoption friction.

Indicative cost categories for a live pilot include infrastructure (peer, orderer, and CA node hosting across participating institutions), integration engineering (APIs bridging the artefact to each institution’s existing case-management systems), legal and compliance review (DPIA completion and supervisory consultation, per Section 8.4), and training. While a full cost-benefit analysis is beyond the scope of this proof-of-concept, the compact on-chain payload (approximately 350 bytes per transaction, Section 3.4) suggests that infrastructure costs scale favourably with registration volume relative to the fixed governance and integration costs, which are the dominant cost driver in early pilots.

Integration with existing transparency systems is expected to proceed in phases rather than as a wholesale replacement: an initial phase would operate the blockchain layer as a verifiable anchoring service alongside the incumbent register’s database, exposing hash-verification endpoints without displacing the existing user-facing portal; a second phase would migrate primary data entry to the new workflow once interoperability with the EU Inter-Institutional Transparency Register’s data model and eIDAS 2.0 identity infrastructure is validated; a final phase would retire redundant legacy validation steps once the artefact’s compliance-check coverage is demonstrated to meet or exceed current manual review standards. This phased approach mitigates the organisational-readiness and governance risks identified above while preserving continuity of the mandatory disclosure obligation throughout the transition.

9 Conclusions and future work

This study demonstrates that a stakeholder-centric hybrid blockchain artefact can transform mandatory Public Affairs transparency from a compliance burden into a credible mechanism for democratic accountability. A Design Science Research approach, anchored by two stakeholder surveys (N = 61 and N = 14), was used to develop a complete hybrid permissioned-blockchain architecture on Hyperledger Fabric that governs the full information lifecycle of lobbying events while satisfying GDPR alignment, scalability, and multi-stakeholder accountability requirements.

Future work priorities include: (i) multi-country pilots integrating the artefact with national transparency registers and eIDAS 2.0 digital identity, including formal DPIA and regulatory consultation; (ii) longitudinal studies assessing real-world operational impacts using the measurement framework specified in Section 8.4; (iii) formal TLA + model-checking of the chaincode state machine; (iv) head-to-head platform comparison against Quorum and Corda; (v) integration with AI-assisted compliance tools for automated conflict-of-interest detection; and (vi) extension of the stakeholder-centric DSR methodology to comparable mandatory transparency domains.

References

• 1

  Al-JaroodiJ.MohamedN. (2019). Blockchain in industries: a survey. IEEE Access7, 36500–36515. 10.1109/access.2019.2903554

  • CrossRef
  • Google Scholar
  • View reference in article

• 2

  AlotaibiE. M.IssaH.CodessoM. (2025). Blockchain-based conceptual model for enhanced transparency in government records: a design science research approach. Int. J. Inf. Manag. Data Insights5 (1), 100304. 10.1016/j.jjimei.2024.100304

  • CrossRef
  • Google Scholar
  • View reference in article

• 3

  Benitez-MartinezF. L.Hurtado-TorresM. V.Romero-FriasE. (2021). A neural blockchain for a tokenizable e-Participation model. Neurocomputing. 423, 703–712.

  • Google Scholar
  • View reference in article

• 4

  BraunV.ClarkeV. (2006). Using thematic analysis in psychology. Qual. Res. Psychol.3 (2), 77–101. 10.1191/1478088706qp063oa

  • CrossRef
  • Google Scholar
  • View reference in article

• 5

  ChenZ.CelikS. E.SarkisJ.et al (2026). A systematic review of academic literature for blockchain application in government and public service. J. Enterp. Inf. Manag. 39 (1), 381–409. 10.1108/JEIM-03-2024-0150

  • CrossRef
  • Google Scholar
  • View reference in article

• 6

  ChariR.HoganJ.MurphyG. (2019). Regulating Lobbying: A Global Comparison. 2nd edn. Manchester: Manchester University Press.

  • Google Scholar
  • View reference in article

• 7

  European Court of Auditors (2024). Special Report 05/2024: EU Transparency Register. Luxembourg: Publications Office of the EU.

  • Google Scholar
  • View reference in article

• 8

  European Union (2021). Inter-Institutional Transparency Register. Available online at: https://transparency-register.europa.eu. (Accessed August 5, 2026)

  • Google Scholar
  • View reference in article

• 9

  GregorS.HevnerA. R. (2013). Positioning and presenting design science research for maximum impact. MIS Q.37 (2), 337–355. 10.25300/misq/2013/37.2.01

  • CrossRef
  • Google Scholar

• 10

  HangL.KimD.-H. (2019). Design and implementation of an integrated IoT blockchain platform for sensing data integrity. Sensors19 (10), 2228. 10.3390/s19102228

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 11

  HevnerA. R.MarchS. T.ParkJ.RamS. (2004). Design science in information systems research. MIS Q.28 (1), 75–105. 10.2307/25148625

  • CrossRef
  • Google Scholar
  • View reference in article

• 12

  IbrahimyM. M.NortaA.NormakP. (2024). Blockchain-based governance models supporting corruption-transparency: a systematic literature review. Blockchain Res. Appl.5 (2), 100186.

  • Google Scholar
  • View reference in article

• 13

  OECD (2021). Lobbying in the 21st Century: Transparency, Integrity and Access. Paris: OECD Publishing.

  • Google Scholar
  • View reference in article

• 14

  OlnesS.UbachtJ.JanssenM. (2017). Blockchain in government: benefits and implications of distributed ledger technology for information sharing. Gov. Inf. Q.34 (3), 355–364. 10.1016/j.giq.2017.09.007

  • CrossRef
  • Google Scholar
  • View reference in article

• 15

  Open Government Partnership (2021). The Global Report on Lobbying Transparency.

  • Google Scholar
  • View reference in article

• 16

  PageM. J.McKenzieM. J.BossuytP. M.BoutronI.HoffmannT. C.MulrowC. D.et al (2021). The PRISMA 2020 statement: an updated guideline for reporting systematic reviews. BMJ (Clinical research ed.).372, n71. 10.1136/bmj.n71

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 17

  PeffersK.TuunanenT.RothenbergerM. A.ChatterjeeS. (2007). A design science research methodology for information systems research. J. Manag. Inf. Syst.24 (3), 45–77. 10.2753/mis0742-1222240302

  • CrossRef
  • Google Scholar
  • View reference in article

• 18

  Ridao MartinJ.Araguas GalceraI. (2025). Lobbying in the EU: prospects and challenges of the mandatory transparency register. Front. Political Sci.6, 1508017. 10.3389/fpos.2024.1508017

  • CrossRef
  • Google Scholar
  • View reference in article

• 19

  SinghJ.GoyalN.AnithaA.RaniS.SharmaG.SharmaB.et al (2026). Blockchain-enabled IoT and machine learning framework for health prediction in smart and healthy urban environments. J. Reliab. Intelligent Environ.17 (1), 118–137. 10.22712/susb.20260008

  • CrossRef
  • Google Scholar
  • View reference in article

• 20

  TanE.MahulaS.CrompvoetsJ. (2022). Blockchain governance in the public sector: a conceptual framework. Gov. Inf. Q.39 (1), 101625. 10.1016/j.giq.2021.101625

  • CrossRef
  • Google Scholar
  • View reference in article

• 21

  TorkyM.HassaneinA. E. (2020). Integrating blockchain and the internet of things in precision agriculture: analysis, opportunities, and challenges. Comput. Electron. Agric.178, 105476. 10.1016/j.compag.2020.105476

  • CrossRef
  • Google Scholar
  • View reference in article

• 22

  Transparency International EU (2024). Lobby Transparency Across the EU. Brussels: Transparency International EU.

  • Google Scholar

• 23

  VenableJ.Pries-HejeJ.BaskervilleR. (2016). FEDS: a framework for evaluation in design science research. Eur. J. Inf. Syst.25 (1), 77–89. 10.1057/ejis.2014.36

  • CrossRef
  • Google Scholar
  • View reference in article

• 24

  WarrenM. E. (2014). “Accountability and democracy,” in The Oxford Handbook of Public Accountability. Editors BovensM.GoodinR. E.SchillemansT. (Oxford: Oxford University Press), 39–54.

  • Google Scholar
  • View reference in article