## 2 Experimental Set-Up
### Selection of Platforms  
To compile a list of potential blockchain platforms, we conducted a survey and analyzed existing literature sources such as [5,22,23]. We recorded the performance claims of these platforms, summarized in Table 1. Considering the nature of our in-the-wild testing methodology, we chose the popular permissioned enterprise blockchain platform, Hyperledger Fabric, as the performance baseline. To select platforms to benchmark against Hyperledger Fabric, we established three criteria. Firstly, the performance claims of the platforms needed to meet or exceed the transaction volume requirements of the Danish national scenario and ideally the transaction volume of the EU scenario. Secondly, the selected platforms had to employ a Byzantine fault tolerant (BFT) consensus mechanism to ensure resilience against malicious actors, providing \begin{table}
\begin{tabular}{l l l l l l} \hline \hline
**Framework** & **Type 1** & \begin{tabular}{c} **Consensus** \\ **Algorithm** \\ \end{tabular} & \begin{tabular}{c} **Open** \\ **Source** \\ \end{tabular} & \begin{tabular}{c} **Throughput** \\ **(tps)** \\ \end{tabular} & \begin{tabular}{c} **Response** \\ **Time (s)** \\ \end{tabular} \\ \hline Bitcoin & Open & PoW & Y & 3–5 & \textgreater{}500 \\ Ethereum & Open & PoW & Y & 15–30 & 360 \\ Kadena & Open & Scalable & N & 10,000 & \textless{}0.1 \\ Hedera & Open & \begin{tabular}{c} Hashgraph \\ (aBFT) \\ \end{tabular} & \begin{tabular}{c} (Y t) \\ \end{tabular} & 10,000 & \textless{}0.1 \\ IOTA & Semi-open & Tangle & Y & 200 & N/A \\ NEO & Semi-open & Delegated- & Y & 10,000 & 15-20 \\ EOS & Semi-open & \begin{tabular}{c} Delegated \\ BFT \\ \end{tabular} & Y & 3996 & \textless{}1 \\ Ripple & Closed & \begin{tabular}{c} RPCA \\ (Ripple \\ Protocol) \\ \end{tabular} & \begin{tabular}{c} 50,000 \\ \end{tabular} & 4 \\ Hyperledger & Closed & \begin{tabular}{c} Kafka/Raft \\ \end{tabular} & Y & \textgreater{}3500 & \textless{}1 \\ Fabric & \multicolumn{4}{c}{Proof of} \\ Hyperledger & Closed & \begin{tabular}{c} Elapsed Time \\ (PoET) \\ \end{tabular} & Y & \textgreater{}80,000 & \textless{}1 \\ MultiChain & Closed & \begin{tabular}{c} PBT + \\ MultiChain \\ \end{tabular} & Y & 1000–1500 & 5–10 \\ Quorum & Closed & \begin{tabular}{c} Istanbul BFT \\ (IBFT) \\ \end{tabular} & Y & 600–900 & 5 \\ Tendermint & Closed & \
\begin{tabular}{c} Tendermint \\ BFT \\ \end{tabular} & Y & 4000–14,000 & \textless{}1 \\ Red Belly & Closed &
\begin{tabular}{c} Democratic- \\ BFT \\ \end{tabular} & N & 660,000 & 2–4 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Blockchain performance claims, extended from [5,22,23]. The staging of each experiment reporting throughput and response time is different, making it difficult to draw meaningful comparisons between competing solutions. \(\dagger\) Hedera has open-source components such as SDKs, but the core consensus algorithm is not open-source due to the patented technology it is built on. higher trust and better overall fault tolerance compared to Hyperledger Fabric. Lastly, the platforms had to be easily accessible, non-proprietary, and not subject to performance caveats such as throttling. Based on these criteria, three BFT blockchain solutions were considered: Hedera, Quorum Istanbul, and Tendermint. However, Hedera's consensus service had a predefined limit of 500 transactions per second (tps) which could not be negotiated. Consequently, we focused on the remaining two BFT blockchain platforms: Quorum Istanbul and Tendermint, as they fulfilled the selection criteria and offered promising features for our use-case. In the above-mentioned criteria, equal emphasis on security and performance is not placed. We reasoned that if a system cannot handle the throughput requirements then security is irrelevant, but the inverse scenario, where a less-secure system exists, performance remains relevant. In the case where the performance requirements for this use-case cannot be meet, we measure the cost of additional trust by comparing CFT vs. BFT.