Pith. sign in

REVIEW 4 major objections 5 minor 17 references

Secure Open Federation of IoT Platforms Through Interledger Technologies -- The SOFIE Approach

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read SOFIE federates existing IoT platforms through distributed ledgers without changing the platforms themselves.

desk verdict A clear architecture overview for interledger-based IoT federation, but the no-platform-changes claim is unverified and the pilot status is contradictory. read the letter →

arxiv 1908.02487 v1 pith:YDKXRA3M submitted 2019-08-07 cs.CR cs.CY

Dmitrij Lagutin , Francesco Bellesini , Tommaso Bragatto , Alessio Cavadenti , Vincenzo Croce , Yki Kortesniemi , Helen C. Leligou , Yannis Oikonomidis
show 5 more authors
George C. Polyzos Giuseppe Raveduto Francesca Santori Panagiotis Trakadas Matteo Verber
This is my paper · ORCID
classification cs.CRcs.CY
keywords InternetofThingsdistributedledgertechnologiesinterledgerblockchainsmartcontractsfoodsupplychaingridelectricvehiclecharging
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 proposes SOFIE, an architecture that federates existing, mutually isolated IoT platforms by connecting them through distributed ledger technologies, without requiring changes inside the platforms themselves. The central claim is that a layer of Federation Adapters plus an interledger transaction layer can give different IoT platforms shared trust, automation, auditability, and access control that none of them has alone. The paper supports this by describing two real-world pilots: a farm-to-fork food supply chain spanning several DLTs, and a distribution grid where the grid operator and EV fleet managers use a decentralized marketplace to schedule charging and balance local photovoltaic production. A sympathetic reader would care because the approach promises to break vendor lock-in and create data markets while preserving privacy and GDPR compliance.

What carries the argument

Three mechanisms carry the argument. The Federation Adapter is a software component that bridges an existing IoT platform's services and API to the SOFIE federation framework, so platform data and actuation become usable across the federation without platform modification. The interledger transactions layer links multiple distributed ledgers, public and permissioned, so that transactions on one ledger can be matched with transactions on another; in the food pilot, a Consortium Ledger run by the participating members and supervised only for membership control serves as the interledger hub. Smart contracts provide automation: they run the auction in the energy marketplace, record access-control and payment rules, and store meter, vehicle, and charging-event data so payouts and rewards can be executed without a central operator.

What would settle it

Connect a widely deployed commercial IoT platform that exposes only read APIs, with no actuation endpoints, to SOFIE; if its devices cannot be actuated or its data cannot be used in federated workflows without the vendor changing code, the 'no internal changes' claim fails.

Watch

Extended reading notes

Core claim

SOFIE's core claim is that interoperability between heterogeneous IoT platforms can be achieved by augmenting, not replacing, the platforms: each platform is attached to a federation framework through a Federation Adapter that translates between the platform's own services and API and an interledger transactions layer spanning multiple distributed ledgers. In the food pilot, five supply-chain segments run on different ledgers (Ethereum- and Hyperledger Fabric-based platforms), linked by a consortium-run Ethereum ledger that acts as an interledger hub and lets a consumer verify provenance from farm to fork. In the energy pilot, a private Ethereum blockchain hosts a smart-contract marketplace where the distribution system operator posts flexibility requests and fleet managers offer charging schedules, while a public DLT periodically anchors the private state for tamper-evident auditability. The paper argues this yields automation, transparency, auditability, and new business models while leaving the underlying IoT platforms technically unmodified.

Load-bearing premise

The approach stands on the assumption that every IoT platform can be linked to the federation through a Federation Adapter that uses only the platform's existing, publicly available interfaces; if even one common platform requires internal changes to join, the central 'no modifications' claim fails for that platform.

Editorial extensions

If this is right

  • In the food pilot, produce moving from a smart farm to a supermarket is tracked across Ethereum- and Hyperledger Fabric-based platforms through a consortium Ethereum ledger, so consumers can verify provenance from field to fork.
  • In the energy pilot, a grid operator and an EV fleet manager trade flexibility requests and charging offers on a private Ethereum marketplace whose state is periodically anchored to a public ledger for auditability.
  • Smart contracts automate payments and rewards, such as tokens or discounts for EV charging, based on stored meter, vehicle, and charging-event data.
  • Federation adapters let heterogeneous platforms participate without internal changes, enabling cross-pilot interactions such as gaming rewards linked to ethically produced food or discounts for EV charging.
  • Open data markets and new business models can be built on the federated infrastructure without requiring any single platform vendor to open up its system.

Reading between the lines

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

  • If the adapter-only claim holds, SOFIE-style federation could be retrofitted to legacy systems such as building automation or industrial control systems, turning them into data-market participants without a re-platforming project; this is a testable extension the paper does not itself make.
  • The paper asserts atomicity across heterogeneous ledgers as a property of interledger techniques, but the pilots have not yet demonstrated it; if atomicity fails under real-world latency, the practical federation shrinks to separate per-platform ledgers with a shared audit trail.
  • The auction-on-blockchain pattern in the energy pilot could plausibly be reused for other flexibility markets, such as heat or water management, an inference beyond the paper's own examples.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The manuscript describes SOFIE, an EU H2020 project architecture for federating heterogeneous existing IoT platforms through distributed ledger technologies (DLTs) and interledger mechanisms, with the stated goal of doing so without requiring internal changes to the platforms themselves. It motivates the approach, presents a high-level architecture with Federation Adapters and an interledger transactions layer, discusses related work, and describes two pilots: a farm-to-fork food supply chain spanning multiple Ethereum and Hyperledger Fabric segment platforms plus a Consortium Ledger, and an electricity grid balancing pilot with EV charging using a private Ethereum-based marketplace anchored to a public DLT. The paper closes with a discussion of openness, privacy, security, automation, and future business models. The paper is primarily an architecture and vision paper: it contains no measurements, no security proofs, no implementation details of the Federation Adapters, and no completed pilot results.

Significance. If the central claim holds, the SOFIE architecture would offer a meaningful path to interoperability across IoT silos without requiring platform owners to modify their systems, potentially reducing vendor lock-in and enabling new business models and decentralized data markets. The paper's strengths are its clear articulation of a federated architecture using multiple ledger types, its use of an interledger layer to connect heterogeneous DLTs, and its concrete pilot scenarios spanning food supply chain and energy. However, the paper ships no reproducible artifacts, no quantitative evaluation, no security analysis, and no completed pilot results; at present the contribution is a plausible architectural design rather than a validated system. The announced open-source release is future work rather than a reported outcome.

major comments (4)
  1. [Section IV, Fig. 1] The central claim 'without making internal changes to the platforms themselves' is load-bearing, yet the paper gives no design or specification of the Federation Adapter concept: there are no compatibility requirements, no API mapping rules, no interface contracts, and no example of an adapter built against a genuinely unmodified third-party platform. If some existing platforms cannot be bridged by an adapter that only uses their existing APIs, the central claim fails. The authors should either specify the adapter interface and its assumptions or provide a concrete demonstration on an unmodified platform.
  2. [Sections V, VII, and VIII] The manuscript contradicts itself on validation status. Section VII states 'All pilots are currently being implemented and their results will be presented in future publications,' while Section VIII states 'The SOFIE solution is tested in four real-life pilots.' These cannot both be true. Furthermore, the farm-to-fork pilot uses platforms described as 'Ethereum-based Smart Farm IoT platform,' 'Ethereum-based Transportation IoT platform,' and 'Hyperledger Fabric based SDC IoT Platform,' which appear to have been created for the pilot; they do not demonstrate federation of pre-existing, unmodified platforms. The authors must either report actual pilot results and platform provenance or explicitly scope the paper as a design description without claiming tested deployment.
  3. [Section VI] The energy pilot claims federation of existing platforms, namely the EV platform and the DSO's Advanced Metering Infrastructure, but gives no evidence that these platforms' existing APIs were actually bridged by a Federation Adapter, nor any technical detail of how their data and actuation interfaces are exposed to the SOFIE marketplace. Without this evidence, the pilot description does not substantiate the no-modification claim for real third-party platforms.
  4. [Section II] The security properties of the interledger layer, particularly atomicity across heterogeneous ledgers, are asserted but not analyzed. Since 'secure' appears in the title and in the central claim, the paper should specify the trust model and attack surface of the interledger transactions layer, and should provide at least a security argument or a reference to a concrete mechanism for the claimed atomicity. The current hand-waving example in Section II does not establish that SOFIE delivers end-to-end security.
minor comments (5)
  1. [Section II] The phrase 'Multiple ledgers are also necessary crypto-agility' appears to be missing a word; it should likely read 'necessary for crypto-agility.'
  2. [Section IV] The text 'such as W3C Web of Things (W3C) and the FIWARE IoT platform' is unclear: W3C Web of Things is a standardization activity, not an IoT platform. The abbreviation should be WoT, and a reference should be provided.
  3. [Section V] The sentence 'Consumers can now reliably verify the provenance of a specific product from farm to fork' uses a temporal claim ('now') that is not supported by any pilot results presented in the paper; suggest changing to a future or conditional formulation.
  4. [Section V] The description of the QR labels and consumer retrieval of information would benefit from a figure or a more detailed explanation of how the smartphone interface interacts with the ledger or the Consortium Ledger.
  5. [Section VI] The phrase 'the interledger capabilities theoretically will also permit' is vague; either explain the concrete interledger mechanism that would allow external DSOs or fleet managers to join, or omit the theoretical claim.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: SOFIE's architectural claim is asserted, not derived from its inputs, and the self-citations are background references, not load-bearing reductions.

full rationale

This paper makes no formal derivation and contains no equations, fitted parameters, or empirical predictions that could reduce to inputs by construction. The central claim—that SOFIE federates existing IoT platforms without modifying them—is an architectural assertion supported by a proposed design (Federation Adapters, interledger layer, Fig. 1), not by a chain of reasoning that assumes the conclusion. The self-citations to project deliverables and prior work by the same authors (refs. 4, 11, 12, 13) are used for background on interledger approaches and for prior proposals using smart contracts with constrained IoT devices; the paper's central federation claim does not reduce to these citations. The absence of demonstrated pilot results, and the internal contradiction between 'All pilots are currently being implemented' (Section VII) and 'The SOFIE solution is tested in four real-life pilots' (Section VIII), are evidence concerns about verification and correctness, not circularity. No load-bearing step is definitionally equivalent to its input, no fitted quantity is renamed as a prediction, and no uniqueness theorem from the authors' prior work is invoked to forbid alternatives. The honest finding is therefore no significant circularity.

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

The central claim rests on several unverified domain assumptions about DLT security, adapter feasibility, interledger atomicity, and pilot outcomes. These are not fitted parameters, but they are load-bearing postulates. The absence of validation means the paper is currently a design proposal.

assumptions (5)
  • domain assumption Distributed ledgers provide immutable, consensus-based, replicated storage that yields security properties.
    Invoked in Section II as the basis for why DLTs are suitable for IoT interoperability; no formal security model is given.
  • domain assumption Federation Adapters can expose a uniform interface to arbitrary existing IoT platforms without internal platform changes.
    Central to the no-modification claim; asserted in Section IV and Fig. 1 without implementation evidence.
  • domain assumption Interledger mechanisms can provide atomic cross-ledger transactions and preserve security properties.
    Relies on prior interledger patterns described in Section II and the SOFIE project deliverable [4]; not demonstrated in this paper.
  • domain assumption A private Ethereum blockchain provides adequate privacy and low transaction cost for the energy marketplace.
    Stated in Section VI without measurement.
  • domain assumption The planned pilots will validate the architecture's feasibility.
    Section VII states results will appear in future publications; no current evidence.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Secure Open Federation of IoT Platforms Through Interledger Technologies -- The SOFIE Approach." pith.science (2026). https://pith.science/paper/YDKXRA3M

@misc{pith2026190802487,
  author       = {Pith},
  title        = {Pith review of: Secure Open Federation of IoT Platforms Through Interledger Technologies -- The SOFIE Approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YDKXRA3M}},
  note         = {Machine review of arXiv:1908.02487}
}
read the original abstract

The lack of interoperability among IoT platforms has led to a fragmented environment, where the users and society as a whole suffer from lock-ins, lack of privacy, and reduced functionality. This paper presents SOFIE, a solution for federating the existing IoT platforms in an open and secure manner using Distributed Ledger Technologies (DLTs) and without requiring modifications to the IoT platforms, and describes how SOFIE is used to enable two complex real life pilots: food supply chain tracking from field to fork and electricity distribution grid balancing with guided electrical vehicle (EV) charging. SOFIE's main contribution is to provide interoperability between IoT systems while also enabling new functionality and business models.

Figures

Figures reproduced from arXiv: 1908.02487 by the authors.

Figure 1
Figure 1. An overview of the SOFIE architecture An overview of the SOFIE architecture is depicted in [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. An overview of the SOFIE food-chain pilot, describing how produce [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. An overview of the SOFIE energy pilot, describing how DSO, EV fleet [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

17 extracted references · 17 canonical work pages

  1. [1]

    SOFIE - Secure Open Federation for Internet Everywhere, available at: https://www.sofie-iot.eu/ (accessed 30.1.2019)

    work page 2019

  2. [2]

    Distributed Ledger Technology Systems - A Conceptual Framework,

    M. Rauchs, "Distributed Ledger Technology Systems - A Conceptual Framework," University of Cambridge Report, 2018, available at: https://www.jbs.cam.ac.uk/fileadmin/user_upload/research/centres/altern ative-finance/downloads/2018-10-26-conceptualising-dlt-systems.pdf (accessed 4.2.2019)

    work page 2018

  3. [3]

    certification authority

    bridging, 4) transactions across a network of payment channels, 5) ledger-of-ledgers, and 6) the W3C Interledger Protocol (ILP). Voulgaris et al. compare the approaches according to whether they support the transfer or the exchange of value, their interconnection trust mechanism, complexity, scalability, and cost [4]. A concrete example of the use of inte...

    work page 2019

  4. [4]

    Agreement with Satoshi - On the Formalization of Nakamoto Consensus,

    N. Stifter, A. Judmayer, P. Schindler, A. Zamyatin, and E. Weippl, "Agreement with Satoshi - On the Formalization of Nakamoto Consensus," in Cryptology ePrint Archive, Report 2018/400, 2018

    work page 2018

  5. [5]

    SOFIE Deliverable D2.1: State of the Art Report,

    S. Voulgaris et al., “SOFIE Deliverable D2.1: State of the Art Report,” 2018, available at: https://media.voog.com/0000/0042/0957/files/SOFIE_D2.1- State_of_the_Art_Report.pdf (accessed 1.2.2019)

    work page 2018

  6. [6]

    BIG IoT - Bridging Interoperability Gap of the Internet of Things, available at: http://big-iot.eu/ (accessed 6.2.2019)

    work page 2019

  7. [7]

    WAVE: A Decentralized Authorization System for IoT via Blockchain Smart Contracts,

    M. P. Andersen et al., "WAVE: A Decentralized Authorization System for IoT via Blockchain Smart Contracts," University of California at Berkeley Technical Report UCB/EECS-2017-234, 2017, available at: http://www2.eecs.berkeley.edu/Pubs/TechRpts/2017/EECS-2017- 234.pdf (accessed 4.2.2019)

    work page 2017

  8. [8]

    LO3 Energy, available at: https://lo3energy.com/ (accessed 5.2.2019)

    work page 2019

Show all 17 references
  1. [9]

    Grid Singularity, available at: http://gridsingularity.com/ (accessed 5.2.2019)

    2019

  2. [10]

    SolarCoin, available at: https://solarcoin.org/ (accessed 5.2.2019)

    2019

  3. [11]

    Decentralized Identifiers (DIDs) v0.11 - Data Model and Syntaxes for Decentralized Identifiers (DIDs),

    D. Reed et al., “Decentralized Identifiers (DIDs) v0.11 - Data Model and Syntaxes for Decentralized Identifiers (DIDs),” Draft Community Group Report, January 2019, available at: https://w3c-ccg.github.io/did-spec/ (accessed 30.1.2019)

    2019

  4. [12]

    Enabling Decentralised Identifiers and Verifiable Credentials for Constrained Internet-of-Things Devices using OAuth-based Delegation,

    D. Lagutin, Y. Kortesniemi, N. Fotiou, and V.A. Siris, "Enabling Decentralised Identifiers and Verifiable Credentials for Constrained Internet-of-Things Devices using OAuth-based Delegation," in proceedings of Workshop on Decentralized IoT Systems and Security (DISS 2019), in ...

    2019

  5. [13]

    Interacting with the Internet of Things using Smart Contracts and Blockchain Technologies,

    N. Fotiou, V. A. Siris, S. Voulgaris, G. C. Polyzos, “Interacting with the Internet of Things using Smart Contracts and Blockchain Technologies,” in proceedings of 11th SpaCCS, Melbourne, Australia, December 2018

    2018

  6. [14]

    Bridging the Cyber and Physical Worlds using Blockchains and Smart Contracts,

    N. Fotiou, V.A. Siris, G.C. Polyzos, D. Lagutin, “Bridging the Cyber and Physical Worlds using Blockchains and Smart Contracts,” in proceedings of Workshop on Decentralized IoT Systems and Security (DISS 2019), in conjunction with the NDSS Symposium 2019, San Diego, USA, February 2019

    2019

  7. [15]

    Statistical Analysis of Prosumer Behaviour in a Real Distribution Network Over Two Years,

    T. Bragatto et al., “Statistical Analysis of Prosumer Behaviour in a Real Distribution Network Over Two Years,” IEEE EEEIC/I&CPS 2018

    2018

  8. [16]

    Future challenges and mitigation methods for high photovoltaic penetration: A survey,

    T. O. Olowu, A. Sundararajan, M. Moghaddami, and A. I. Sarwat, “Future challenges and mitigation methods for high photovoltaic penetration: A survey,” Energies, vol. 11, no. 7, 2018

    2018

  9. [17]

    Reverse Power Flow Protection in Grid Connected PV Systems,

    S. Rahman, H. Aburub, M. Moghaddami, and A. I. Sarwat, “Reverse Power Flow Protection in Grid Connected PV Systems,” in proceedings of IEEE SoutheastCon, 2018

    2018

Pith tools

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