Blockchain Tree for eHealth

Giada Sciarretta; Sergii Kushch; Silvio Ranise

REVIEW 3 major objections 3 minor 29 references

Blockchain Tree for eHealth

T0 review · 3 major / 3 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 This paper claims that a Blockchain Tree of three cross-linked chains makes patient records and their access logs impossible to alter or delete.

desk verdict The tree-of-subchains composition is a fresh idea, but the paper's 'impossible to change' claim is undone by its own 51% replacement rule in a permissioned network of the very insiders it is supposed to police. read the letter →

arxiv 1908.04613 v1 pith:62PXF632 submitted 2019-08-13 cs.CR

Sergii Kushch , Silvio Ranise , Giada Sciarretta This is my paper · ORCID

classification cs.CR

keywords blockchaineHealthpersonalrecordsaccesslogsauditloggingProofofAuthoritypermissionedtree

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 a Blockchain Tree for healthcare: a main chain whose blocks identify individual patients, with two subchains attached to each patient block, one holding medical history and the other holding access logs. The central claim is that because each new log block cross-hashes the patient's main block, the newly written medical block, and the previous log block, an insider cannot change or delete logs to hide privilege abuse, and stored diagnoses cannot be rewritten for fraud. The authors argue this structure, run on a private permissioned network with Proof of Authority consensus and no transaction fees, is better suited to medicine than existing blockchain designs. A sympathetic reader cares because the design targets the insider threat that drives most healthcare data breaches by turning every access attempt into an immutable record.

What carries the argument

The load-bearing mechanism is the cross-hash that links the three chains. In the paper's design, every block of the log subchain contains the hash of the corresponding main identity block, the hash of the newest block of the medical subchain, and the hash of the previous log block, so the chains cannot be modified independently without visible inconsistency. The design is completed by Proof of Authority consensus on a fixed list of verified network nodes, which keeps block creation cheap and transactions free, and by the standard Merkle-tree hashing used to build block hashes.

What would settle it

Deploy the proposed three-chain structure on a permissioned network of, say, nine nodes; have five of them collude to delete one access-log block and rewrite the corresponding medical and main blocks, then check whether the remaining four honest nodes detect and revert the change. If the rewritten chain is accepted as canonical, the immutability claim fails.

Watch

Extended reading notes

Core claim

The core proposal is structural: use one block per patient in a main chain and make that block the genesis of two per-patient subchains, one for the clinical record and one for the audit log. When a medical professional writes a new diagnosis, test result, or prescription, a block is appended to the clinical subchain, and simultaneously a block is appended to the audit subchain; that audit block carries three hashes: the hash of the patient's main block, the hash of the new clinical block, and the hash of the previous audit block. The authors claim this triple cross-reference binds the three chains together so that changing or deleting any record would require rewriting several chains at once, which they argue is detectable and uneconomical. They also propose closing the clinical subchain after death or loss of citizenship while letting the audit subchain continue to record access attempts.

Load-bearing premise

The entire tamper-resistance guarantee rests on the assumption that no group of node operators controlling more than half of the approved permissioned network will collude to rewrite the chains, and those operators are the same hospital insiders the audit logs are meant to police.

Editorial extensions

If this is right

Every successful or failed access attempt to a patient's records automatically creates a log block, yielding a non-repudiable audit trail for investigations.
Hiding an access event or changing a diagnosis would require rewriting the log block, the linked medical block, and the patient's main block together, and getting the rewritten version confirmed by more than 51% of the verified nodes.
Closing the medical subchain after death or loss of citizenship prevents retrospective additions of diagnoses while the audit subchain still logs all future access attempts.
The same three-chain structure can be applied to other identity-linked documents such as ID cards, driver's licenses, diplomas, and insurance records, as the paper notes.

Reading between the lines

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

The paper leaves the tamper-resistance property unproven; a natural extension is to formulate the cross-hash invariant and verify by model checking that modifying any one chain is detected unless all three linked chains are rewritten consistently.
Because the node operators are the hospitals and medical staff being audited, the 51% threshold is effectively an assumption that insiders will not collude; adding independent external auditors as nodes would strengthen the guarantee.
Regulatory rights such as erasure under data-protection law conflict with on-chain immutability, so a deployable system would likely store raw medical data off-chain and keep only hashes and access logs on-chain.

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.

Desk Editor's Note

read the letter

This is a clearly written design sketch for a blockchain tree in healthcare. The arrangement is genuinely new: a main chain carrying patient identity, with each block acting as a genesis block for two subchains—one for medical data, one for access logs—and cross-hashes linking all three. The per-patient genesis blocks and the triple cross-hash are not in the cited related work. The paper also gives a concrete sequence of operations for patient onboarding, writing, and reading, which helps make the idea concrete, and it is honest in Section IV that the work is a first step with GDPR and networking details left open.

What does not hold is the central security claim. The introduction and Section III assert that insiders cannot change logs and that stored information is 'impossible to change or delete.' But the only mechanism described in Section II is that a changed block is automatically replaced by the version held by at least 51% of nodes. In a permissioned Proof-of-Authority network whose nodes are hospitals and medical staff—exactly the insiders the paper opens by worrying about—a coalition of more than half of the approved nodes can rewrite the main chain, both subchains, recompute the cross-hashes, and broadcast the result. The stated rule tells the honest minority to accept the majority version. The cross-hash structure raises the cost for an attacker without majority control, but it adds nothing against a coalition that holds the consensus majority. The paper never states a threat model that excludes collusion among node operators, and no node-admission, fork-resolution, or penalty mechanism is proposed.

This is a load-bearing gap, not a minor omission. The architecture might still be useful if paired with explicit trust assumptions—say, an external authority that signs blocks, or a governance structure that makes a 51% coalition infeasible—but that is not in the paper. There is no implementation, no formal security argument, and no evaluation, so the 'impossible to change' language is simply unsupported.

The paper is a reasonable early-stage vision. I would send it to a workshop or a venue that accepts design proposals, but it needs a serious referee who will require the authors to either fix the threat model or soften the claims. The tree composition is worth discussing; the security conclusion, as stated, is not.

Referee Report

3 major / 3 minor

Summary. The paper proposes a "Blockchain Tree" architecture for eHealth: a main blockchain with one block per patient serves as the anchor for two subchains, one holding medical history (diagnoses, prescriptions, test results) and one holding access logs. The authors argue that the tree structure, combined with cross-hashes among the three chains and a permissioned Proof of Authority consensus, prevents insiders from altering PHRs or access logs after the fact. The manuscript describes the intended workflow (patient onboarding, writing and reading health data), discusses edge cases such as fiscal-code changes and closing a patient's subchain, and compares the proposal with several commercial healthcare-blockchain projects. It contains no formal security model, no implementation, and no experimental evaluation; the security argument rests on informal statements about hash chaining and the consensus rule that a block must be confirmed by more than 51% of verified nodes.

Significance. If the central security claim were established, the paper would address a real and well-documented problem: insider abuse of access to healthcare records. The proposed design has some merits: it separates patient-identity data, clinical data, and audit logs into distinct chains; it uses cross-hash references to couple those chains; and it explicitly targets the insider threat, which is a sensible motivation. The paper also gives credit for adopting a permissioned model with free transactions, appropriate for healthcare deployments. However, the contribution as presented is not yet a security result. The claims that logs and PHRs are "impossible to change or delete" are asserted rather than proven, and, more seriously, the stated majority-replacement rule appears to contradict the claimed guarantee in the very permissioned setting the paper assumes. The cross-chain structure is an interesting design intuition, but no formal adversary model, no rigorous integrity argument, and no implementation evidence are supplied, so the paper currently does not meet the evidentiary bar for a security venue.

major comments (3)

[Section II (confirmation rule) vs. Section III.A (permissioned network)] The paper's own replacement rule undermines the stated immutability guarantee. Section II says that if a change is detected in an existing block, that block is "automatically replaced by the 'right' that exists on at least 51% other nodes network." The network described in Section III.A consists of approved nodes operated by hospitals, ambulatories, and other medical organizations, and Section I identifies insiders as the primary threat. A coalition of more than 51% of these approved nodes can rewrite a block in Subchain 1, the corresponding log block in Subchain 2, and all descendant blocks, rebroadcast the rewritten tree, and the remaining nodes are instructed by the Section II rule to accept the majority version. The cross-hash tree structure forces the coalition to recompute a larger set of hashes, but this adds no cryptographic difficulty for a coalition that already controls the consensus majority. The manuscript needs either an explicit adversarial threshold with a mechanism that prevents majority collusion (for example, accountable admission and slashing), or a carefully qualified statement of what property is actually guaranteed.
[Section III.A and Section IV] The central claims that logs and stored PHR data will be "impossible to change or delete" are absolute, but the paper provides no formal threat model or security proof. It does not define the adversary's capabilities, the precise security properties to be established (e.g., persistence, liveness, or auditability), or the cryptographic assumptions (e.g., collision resistance of the hash function, authenticity of the approved-node list). The argument that triple hash cross-referencing "significantly complicates the possibility of tampering" is a heuristic, not a security analysis. A rigorous treatment would define the hash-chain invariants connecting blocks across the three chains and prove that any modification is detected unless the adversary controls more than a stated fraction of the consensus participants. Without such a model, the paper's main contribution is not established.
[Sections II–IV (protocol specification and evaluation)] The manuscript lacks a complete protocol specification and any implementation or measurement. There is no block format, no description of how blocks are proposed and ordered under Proof of Authority, no fork-resolution policy beyond the 51% rule, no identification of cryptographic primitives, and no analysis of communication or storage overhead. For a claim about deployability in healthcare and about deterring insider abuse, experimental validation or at least a detailed protocol-level design is necessary. The paper's own Section IV concedes that this is "only the first step" and that network delays and legal compliance are deferred, but the missing specification directly affects the credibility of the security and usability claims made earlier.

minor comments (3)

[Section I and Section II] The acronym POA is used inconsistently: Section I introduces "Proof of Authority (POA)," while Section II lists "Proof of Activity (POA)" among consensus algorithms. Please disambiguate these as distinct mechanisms and avoid reusing the abbreviation.
[Section II and Section III] The threshold wording is inconsistent: "more than 51%" and "at least 51%" are used interchangeably. The exact quorum condition should be stated precisely and used consistently.
[Throughout] There are several typographical and wording errors, including "Blokchein" in Section I-A, "Sabchain 1 Closing" in the numbered workflow, and "tamping" instead of "tampering" near the end of Section III.A. These should be corrected.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the security claims rest on standard blockchain properties, not on fitted inputs or self-citations.

full rationale

This is a design and proposal paper, not a derivation with fitted parameters or predicted quantities. The central claim that access logs and PHR data cannot be changed or deleted is justified by invoking standard blockchain properties: hash-linked blocks, the Merkle-tree construction, the 51% confirmation and replacement rule in Section II, and the private permissioned blockchain assumption in Section III. None of these steps is defined in terms of the conclusion, and no quantity is fitted to data and then renamed as a prediction. The paper's own caveat that the work is 'only the first step' and that real-network issues and legal compliance are left for future work is an admitted assumption gap, not a circular reduction. The self-citations are background references on blockchain applications and do not carry the load-bearing security argument. There is therefore no circularity in the claimed derivation chain.

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

The central security claim rests on standard blockchain assumptions, notably the 51% honest-majority rule applied to a permissioned network of healthcare institutions. Because the network is private and validated, these assumptions may be weaker than in public systems. No new physical entities are introduced; the subchains are a data-structure choice, not a new ledger entry requiring independent evidence.

assumptions (3)

domain assumption Blockchain immutability holds when no party controls more than 51% of block creation.
Stated in Section II: 'A created block must be conﬁrmed by more than 51% of veriﬁed nodes.' The security argument depends on this threshold being sufficient.
domain assumption The permissioned network nodes are approved and verified, and all nodes store the complete blockchain.
Section III: 'we assume a private and permissioned blockchain.' The claim that tampering is detectable relies on every node holding a full copy of the chain.
domain assumption GDPR compliance is achievable despite immutable records.
Section IV acknowledges 'legal compliance (in particular referring to GDPR)' is future work, yet the paper's design assumes no conflict between indelibility and data-protection law.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Blockchain Tree for eHealth." pith.science (2026). https://pith.science/paper/62PXF632

@misc{pith2026190804613,
  author       = {Pith},
  title        = {Pith review of: Blockchain Tree for eHealth},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/62PXF632}},
  note         = {Machine review of arXiv:1908.04613}
}

read the original abstract

The design of access control mechanisms for healthcare systems is challenging: it must strike the right balance between permissions and restrictions. In this work, we propose a novel approach that is based on the Blockchain technology for storage patient medical data and create an audit logging system able to protect health data from unauthorized modification and access. The proposed method consists of a tree structure: a main chain linked with the patient's identity and one or several Subchains which are used for storing additional critical data (e.g., medical diagnoses or access logs).

Figures

Figures reproduced from arXiv: 1908.04613 by the authors.

**Figure 1.** The overall structure of the network. Node holders are hospitals, dispensaries, other medical organizations. The users are patients, doctors, as well as third parties authorized by the state or patient. A. Related projects Currently there are several start-ups and commercial projects aimed at implementing Blokchein in health care. Developed on the Ethereum Blockchain, MedRec [20] is a ”system that gives priority to … view at source ↗

**Figure 2.** An example of a binary hash tree [28]. Hashes 0-0 and 0-1 are the hash values of data blocks L1 and L2, respectively, and Hash 0 is the hash of the concatenation of Hashes 0-0 and 0-1. the hashes of the associated transactions (hash(L1), hash(L2), hash(L3), and hash(L4), respectively), (ii) Hash 0, Hash 1 are calculated from the sum of transaction hashes (hash(Hash 0-0 + Hash 0-1), hash(Hash 1-0 + Hash 1-1), respect… view at source ↗

**Figure 3.** Blockchain Tree: a system of three Blockchains that are connected with each other. The green chain is the main and contains personal information about patients; the yellow chain is the 1st Subchain and contains information about medical services, diseases etc.; the red chain is the 2nd Subchain and contains access logs of patients and medical staff. III. MAIN RESULTS The solution we offer consists of several interco… view at source ↗

Figures from the paper (4 more)

**Figure 5.** Figure 5: Schematic of possible time steps of the proposed method use. 2) Creating a block in the main BC, which contains personal information of this person (time t1-t2); 3) Creating a block 1 for the Subchain 1, for recording the future history of diseases (time t2-t3); 4) Cr…

**Figure 4.** Figure 4: Creating a cross HASH of the block of the second subchain. After creating a new block in the yellow subchain, a new block is also created in the red subchain that contains three hashes one: of the main block which contains the basic information about a patient; of the …

**Figure 6.** Figure 6: Creation a list of medical tests and illnesses … [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]

**Figure 7.** Figure 7: Creation a report of medical tests and illnesses IV. SUMMARY AND DISCUSSION In this paper we propose a novel methodology based on Blockchain for building storage, access control and document verification mechanisms in a healthcare. The proposed work is based on Subchai…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 28 canonical work pages

[1]

V erizon

(2018, Dec) Protected health information data breach report. V erizon. [Online]. Available: https://enterprise.verizon.com/resources/reports/2018/protected health information data breach report.pdf

work page 2018
[2]

Hyperledger Fabric

(2019) A blockchain platform for the en- terprise. Hyperledger Fabric. [Online]. Available: https://hyperledger-fabric.readthedocs.io/en/release-1.4/

work page 2019
[3]

The bitcoin backbone protocol: A nalysis and applications,

L. Debin and L. J. Camp, “The bitcoin backbone protocol: A nalysis and applications,” Proof of W ork can W ork, Fifth W orkshop on the Economics of Information Security , 2006

work page 2006
[4]

The bitcoin ba ckbone protocol: Analysis and applications,

J. A. Garay, A. Kiayias, and N. Leonardos, “The bitcoin ba ckbone protocol: Analysis and applications,” ser. Lecture Notes i n Computer Science, by E. Oswald and M. Fischlin, Eds., vol. V ol.9057. S pringer, Dec 2015, pp. 281–310. [Online]. Available: https://ia.cr /2014/765

work page 2015
[5]

Matsuo, K

S. Matsuo, K. Miyazaki, A. Otsuka, and D. Basin, How to evaluate the security of real-life cryptographic protocols? the cases o f ISO/IEC 29128 and CRYPTREC , ser. Lecture Notes in Computer Science. Springer, Berlin, Heidelberg, Jan 25-28 2010, vol. V ol.6054, no. 11, p p. 182–194. [Online]. Available: https://doi.org/10.1007/978-3-64 2-14992-4 16

doi:10.1007/978-3-64 2010
[6]

Proof of activity: Extending bitcoin’s proof of work via proof of stake,

I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld, “Proof of activity: Extending bitcoin’s proof of work via proof of stake,” SIGMETRICS Perform. Eval. Rev. , vol. 42, no. 3, pp. 34–37, Dec 2014

work page 2014
[7]

(2018, Mar) Eos.io technical white pa- per v2. EOS.IO. [Online]. Available: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md

work page 2018
[8]

A. Koles. (2018, Jun) How blockchain could change the global remittance industry. [Online]. Available: https://www.bankingtech.com/2018/06/how-blockchain-could-change-the-global-remittance-industry/

work page 2018

Show all 29 references

[9]

DHL Trend Research

(2018) Blockchain in logistics, perspectives on the upc oming impact of blockchain technology and use cases for the logistics industry. DHL Trend Research. [Online]. Availab le: https://www.logistics.dhl/content/dam/dhl/global/core/documents/pdf/glo-core-blockchain-trend-report.p df

2018
[10]

A review of the appl ications of the blockchain technology in smart devices and distributed ren ewable energy grids,

S. Kushch and F. Prieto-Castrillo, “A review of the appl ications of the blockchain technology in smart devices and distributed ren ewable energy grids,” CADCAIJ: Advances in Distributed Computing and Artiﬁcial Intelligence Journal , vol. 6, no. 3, Dec 2017. [Online]. Availabl...

2017
[11]

Di stributed sequential consensus in networks: Analysis of partially co nnected blockchains with uncertainty,

F. Prieto-Castrillo, S. Kushch, and J. M. Corchado, “Di stributed sequential consensus in networks: Analysis of partially co nnected blockchains with uncertainty,” Complexity, vol. 2017, Nov 2017. [Online]. Available: https://doi.org/10.1155/2017/483 2740

2017 doi
[12]

Blockchain for dyn amic nodes in a smart city,

S. Kushch and F. Prieto-Castrillo, “Blockchain for dyn amic nodes in a smart city,” Apr. 2019, pp. 29–34. [Online]. Available: https://ieeexplore.ieee.org/document/8767336

2019
[13]

Blochie : A blockchain-based platform for healthcare information exc hange,

S. Jiang, J. Cao, H. Wu, Y . Y ang, M. Ma, and J. He, “Blochie : A blockchain-based platform for healthcare information exc hange,” 2018, pp. 49–56

2018
[14]

Jakobsson and A

M. Jakobsson and A. Juels, Proofs of W ork and Bread Pudding Proto- cols. Kluwer Academic Publishers, 1999, pp. 258–272

1999
[15]

Proof of work can work,

B. Laurie and R. Clayton, “Proof of work can work,” May 20 04
[16]

V . Buterin. (2013, Nov) What proof of stake is and why it matters. [Online]. Available: https://bitcoinmagazine.com/articles/what-proof-of-stake-is-and-why-it-matters-1377531463/

2013
[17]

U. W. Chohan, Proof-of-Stake Algorithmic Methods: A Comparative Summary, ser. TNotes on the 21 st Century. University of New South Wales, Canberra, Feb 2018. [Online]. Available: http://dx.doi.org/10.2139/ssrn.3131897

2018 doi
[18]

Beikverdi

A. Beikverdi. (2015, Mar) Proof-of-importance: How ne m is going to add reputations to the blockchain. [Online]. Avail able: https://cointelegraph.com/news/proof-of-importance-nem-is-going-to-add-reputations-to-the-blockchain

2015
[19]

Bentov, A

I. Bentov, A. Gabizon, and A. Mizrahi, Cryptocurrencies without Proof of W ork, ser. Lecture Notes in Computer Science. Springer, Berlin, 2016, vol. V ol.9604

2016
[20]

[O nline]

(2019) Blockchain to improve medical record access. [O nline]. Available: https://medrec.media.mit.edu/

2019
[21]

SimplyVital Health

(2018) Simplyvital health. SimplyVital Health. [Onli ne]. Available: https://www.simplyvitalhealth.com/

2018
[22]

[Onli ne]

(2018) Healthcare blockchain operating system. [Onli ne]. Available: https://phros.io/#home

2018
[23]

(2018) Farmatrust progress report dec

2018
[24]

(2018) Mtbc takes electronic health records to the next level with blockchain technology. MTBCInc. [Online]. Avai lable: https://ir.mtbc.com/news-releases/news-release-details/mtbc-takes-electronic-health-records-next-level -blockchain

2018
[25]

two it cities and the race for healthcare innovation

(2019) Nashville and austin. two it cities and the race for healthcare innovation. Hashed Health. [Online]. Avail able: https://hashedhealth.com/newsletter-may-2019/

2019
[26]

Cha ngeHealthcare

(2019) Change healthcare announces general availabil ity of ﬁrst enterprise - scale blockchain solution for healthcare. Cha ngeHealthcare. [Online]. Available: https://www.changehealthcare.com/

2019
[27]

MedicalChain

(2019) The medicalchain whitepaper. MedicalChain. [O nline]. Available: https://medicalchain.com/en/whitepaper/

2019
[28]

(2012) Hash tree.svg. Azaghal. [Online]. Available: https://commons.wikimedia.org/w/index.php?curid=18157888

2012
[2018]

[Online]

FarmaTrust. [Online]. Available: https://medium.com/@farmatrust/farmatrust-progress-report-dec-2018-4282442de07b

2018

Pith tools

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

[1] [1]

V erizon

(2018, Dec) Protected health information data breach report. V erizon. [Online]. Available: https://enterprise.verizon.com/resources/reports/2018/protected health information data breach report.pdf

work page 2018

[2] [2]

Hyperledger Fabric

(2019) A blockchain platform for the en- terprise. Hyperledger Fabric. [Online]. Available: https://hyperledger-fabric.readthedocs.io/en/release-1.4/

work page 2019

[3] [3]

The bitcoin backbone protocol: A nalysis and applications,

L. Debin and L. J. Camp, “The bitcoin backbone protocol: A nalysis and applications,” Proof of W ork can W ork, Fifth W orkshop on the Economics of Information Security , 2006

work page 2006

[4] [4]

The bitcoin ba ckbone protocol: Analysis and applications,

J. A. Garay, A. Kiayias, and N. Leonardos, “The bitcoin ba ckbone protocol: Analysis and applications,” ser. Lecture Notes i n Computer Science, by E. Oswald and M. Fischlin, Eds., vol. V ol.9057. S pringer, Dec 2015, pp. 281–310. [Online]. Available: https://ia.cr /2014/765

work page 2015

[5] [5]

Matsuo, K

S. Matsuo, K. Miyazaki, A. Otsuka, and D. Basin, How to evaluate the security of real-life cryptographic protocols? the cases o f ISO/IEC 29128 and CRYPTREC , ser. Lecture Notes in Computer Science. Springer, Berlin, Heidelberg, Jan 25-28 2010, vol. V ol.6054, no. 11, p p. 182–194. [Online]. Available: https://doi.org/10.1007/978-3-64 2-14992-4 16

doi:10.1007/978-3-64 2010

[6] [6]

Proof of activity: Extending bitcoin’s proof of work via proof of stake,

I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld, “Proof of activity: Extending bitcoin’s proof of work via proof of stake,” SIGMETRICS Perform. Eval. Rev. , vol. 42, no. 3, pp. 34–37, Dec 2014

work page 2014

[7] [7]

(2018, Mar) Eos.io technical white pa- per v2. EOS.IO. [Online]. Available: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md

work page 2018

[8] [8]

A. Koles. (2018, Jun) How blockchain could change the global remittance industry. [Online]. Available: https://www.bankingtech.com/2018/06/how-blockchain-could-change-the-global-remittance-industry/

work page 2018