Cost-Effective and Reliable Sidechain Approach for Managing Small-Scale Digital Asset Trading Platforms

Abstract

This study proposes a cost-effective and reliable blockchain-based approach for managing small-scale digital asset trading platforms. Instead of developing an independent blockchain, the proposed method constructs a sidechain anchored to established blockchains known for their stability and reliability, such as Bitcoin and Ethereum. In this study, we refer to these established blockchains serving as the mainchain for our sidechain as the reference chain. The proposed sidechain, termed the platform chain in this paper, inherits the security and trust of the reference chain, while reducing operational costs and requiring no modifications to it. To enhance efficiency and privacy, the proposed method introduces a dual-sidechain architecture. The platform chain can be constructed either as a private blockchain or a consortium blockchain, depending on the specific operational requirements. In this architecture, only the hash values of transactions are recorded on the platform chain by default, while complete transaction content is disclosed through a dual platform chain under controlled conditions. This enables strong privacy guarantees, alongside auditable transparency when needed. To evaluate the security and feasibility of our approach, we perform a comprehensive threat assessment, addressing critical threats such as operator-level manipulation, invalid or harmful user actions, collusion among system entities, and dishonest behavior by the auditor. Our results confirm that the proposed sidechain framework provides a secure, scalable foundation for digital asset trading platforms, effectively enhancing privacy and ensuring robust protection under various adversarial conditions.

1. Introduction

Blockchain is a distributed ledger technology that securely connects data blocks using cryptographic hash pointers, forming a tamper-resistant ledger. By employing cryptographic techniques and consensus mechanisms, blockchain removes the need for centralized control, which enhances security, transparency, and robustness. Its broad applicability extends across various fields, including cryptocurrency transactions, smart contracts, supply chain management, healthcare record management, and digital asset trading platforms [1,2,3,4,5,6,7,8,9,10,11,12].

The emergence of smart-contract-based cryptocurrencies such as Ethereum has expanded the application areas of blockchain technology. Smart contracts are self-executing code designed to run in a distributed virtual machine spanning a global network. They enable the application of various business logics beyond simple cryptocurrency transactions using blockchain technology [13,14]. The use of smart contracts is widely applied in various areas such as prediction markets [15,16,17], fractional ownership [18,19,20], and digital asset exchanges [21,22], driving innovations in blockchain-based asset trading.

Blockchain technology offers several advantages for trading certain types of physical assets. For instance, if a physical asset can be tokenized on the blockchain and endowed with digital uniqueness, it can benefit from digitalization in various ways. Specifically, if token transactions on the blockchain network can be recognized as equivalents of actual asset transactions, this could significantly enhance the security and efficiency of the asset trading process [21,23,24]. In this study, we define the process of tokenizing and making assets tradable on the blockchain network as digital assetization, and the assets themselves as digital assets. Furthermore, platforms that facilitate the trading of such digital assets will be referred to as Digital Asset Trading Platforms (DATPs).

This paper explores a blockchain method for tokenizing specific physical assets and facilitating a DATP for such tokenized assets. In this study, we refer to the blockchain developed for this purpose as the platform chain of the DATP. The primary goal of the platform chain is to tokenize physical assets, reduce transaction costs through token-based trading, and increase market accessibility. Furthermore, the platform chain seeks to increase trust in trading activities on the DATP utilizing the transparency and immutability of blockchain technology. Moreover, as observed in other business applications of blockchain [23,25], the platform chain can enhance overall efficiency of DATPs by streamlining the transaction process through the integration of cryptocurrencies and smart contracts.

To ensure the platform chain effectively supports DATP operations, certain conditions must be met to guarantee its reliability. These conditions are as follows:

• C1: Transactions recorded on the platform chain are practically immutable and cannot be arbitrarily deleted or altered.
• C2: Transactions recorded on the platform chain are acknowledged by the vast majority of participants.

• In addition to these, another condition that contributes to the reliability of the platform chain is

• C3: All participants can engage in decentralized management of the platform chain.

This condition (C3) is crucial in preventing platform administrators from arbitrarily rejecting or delaying the registration of specific transactions.

Currently, to satisfy conditions C1, C2, and C3, most blockchain projects related to platform management implement reward mechanisms for block mining (the process of adding new blocks to the blockchain) to encourage broad participation. However, these mechanisms can significantly increase operational costs, as competitive block mining may require excessive energy consumption. Some blockchain networks also charge transaction fees as compensation for transaction processing on the blockchain. While this approach may be sustainable for blockchains with high transaction volumes, it poses a challenge for blockchains with low transaction volumes, where higher per-transaction fees are required to sustain operations [26,27,28,29,30].

Various methods have been proposed to reduce the operational costs of blockchain. The most commonly adopted approach is to implement cost-effective consensus algorithms for block mining [31,32,33,34,35,36]. While this approach can achieve certain cost savings, it is not ideal for platform chains for small-scale DATPs. The main limitation is the inability to offer sufficient incentives for block mining within these smaller platform chains, making it challenging to attract a sufficient number of block miners. Another approach is to delegate block mining authority to specific individuals or a limited group, as seen in private or consortium blockchains [37]. However, this approach may struggle to build trust among general users, as block mining authority is restricted to certain entities or individuals.

1.1. Objectives of Study

This study proposes a blockchain-based system optimized for managing small-scale Digital Asset Trading Platforms (DATPs). Before presenting the proposed approach, it is important to explain why this study focuses on blockchain-based platform management, particularly why small-scale platforms are emphasized.

First, the need for blockchain-based platform management stems from the ability to leverage blockchain’s decentralized nature to neutralize platform governance. Platform monopolization often has detrimental effects: it restricts fair competition by creating barriers for new entrants and stifling innovation. Users are compelled to conform to monopolistic platform policies and pricing, which limits choice, while the risk of data misuse for private gain raises privacy concerns. Moreover, limited transparency in decision-making can lead to decisions that overlook user needs, ultimately hindering the platform’s potential for broad adoption across diverse fields.

Next, this study focuses on small-scale platforms because blockchain-based tokenization is highly dependent on the characteristics of the associated physical assets, making it likely that platforms facilitating the trade of tokenized assets will be small in scale. In other words, a specialized small-scale platform tailored to specific physical assets is expected to be necessary. The blockchain-based tokenization model assumed in this study goes beyond merely recording the transfer of digital asset ownership; rather, it considers cases where transactions of blockchain-based tokens directly affect the ownership rights of the corresponding physical assets.

For instance, if a tokenized digital asset represents the right to operate a specific electric vehicle, ownership of the token on the blockchain serves as definitive proof of the right to use the vehicle. In such cases, the tokenization process is influenced not only by the attributes of the digital asset but also by the characteristics of the associated physical asset. Therefore, a DATP must account not only for digital token transactions but also for the operational rights of the physical asset—such as driving range, usage duration, and liability—alongside the specific characteristics of the individual vehicle. Given these considerations, small-scale platforms designed for specific assets are expected to be more effective and more widely adopted than large-scale platforms.

Thus, this study’s exploration of blockchain methods tailored to small-scale platforms for trading specific tokenized assets is particularly valuable and contributes to the growing field of asset-specific digital trading platforms.

One of the primary challenges in converting a small-scale platform that trades physical assets or associated rights into a blockchain-based tokenized asset trading platform is the high operational cost associated with blockchain technology. For instance, ensuring the reliability of the platform chain (the blockchain that governs the operation of the tokenized asset trading platform) by incentivizing a large number of participants to engage in block mining is particularly challenging for platform chains designed for small-scale digital asset trading. This is because, if the incentives are insufficient, the number of participants will decrease, making it difficult for the blockchain to satisfy conditions C1, C2, and C3 at any meaningful capacity. Conversely, if the rewards are set too high, the operational costs of the platform chain will increase, thus reducing the benefits of adopting the platform chain.

Most existing blockchain projects seek to mitigate this cost issue through the use of native cryptocurrencies. However, for this model to be sustainable, it relies on the assumption that the value of the cryptocurrency will continuously increase or at least remain stable. This assumption is often unrealistic, and without it, most blockchain networks cannot sustain their operations.

In this study, we propose the use of a private blockchain as a practical solution to address the cost challenges associated with operating small-scale digital asset trading platforms. Specifically, we propose a method that foregoes condition C3 under ideal blockchain conditions, while still satisfying conditions C1 and C2. For this proposal to be meaningful, the following question must be answered:

• Q: How can conditions C1 and C2 be satisfied when the platform chain for digital asset trading operates without block mining rewards and is centrally managed by individuals or a small group of entities?

1.2. Outline of Proposed Method

To address the aforementioned issue Q, this study proposes constructing the platform chain, which governs the operation of the tokenized asset trading platform, as a sidechain anchored to a reliable existing blockchain, such as Bitcoin or Ethereum, rather than as an independent blockchain. This approach allows the platform chain to inherit the security and trust of the existing blockchain (hereafter referred to as the reference chain), while maintaining platform-specific configurations. The platform chain operates independently of modifications to the reference chain, minimizing dependency on it and thus reducing operational costs. All computations related to tokenization are performed exclusively on the platform chain, ensuring that the specialized configuration of the platform remains unaffected by external factors.

Additionally, all platform operations are managed through predefined smart contracts on the platform chain, ensuring that all activities strictly adhere to preset regulations. Only the hash value of each transaction is stored on the platform chain, while the actual transaction data are selectively disclosed on the dual platform chain upon request, after secure registration. This mechanism is designed to prevent platform operators from manipulating transaction registrations for personal gain. Furthermore, the proposed approach leverages the fact that only hash values are stored on the platform chain. By aggregating multiple transactions into a Merkle tree and recording its root hash on the platform chain, all transactions within the Merkle tree can be stored on the secondary platform chain, supporting scalable and efficient platform operations.

This paper focuses on the blockchain architecture required for operating small-scale digital asset trading platforms, and specific blockchain tokenization methods for digital assets are omitted. This decision stems from the inherent difficulty of describing blockchain tokenization methods as a single approach, given their reliance on the unique characteristics of the underlying physical assets. Future research on specific blockchain tokenization methods will be addressed in a separate study.

1.3. Key Contributions

This study proposes a method for constructing a platform chain optimized for small-scale DATPs. Instead of building the platform chain as a standalone blockchain, the proposed method constructs a platform chain anchored to established blockchains, such as Bitcoin and Ethereum, which serve as reference chains due to their proven stability and reliability.

The main contributions of the proposed method are as follows:

• Designing the platform chain as a sidechain of existing blockchains within a private or consortium blockchain framework. This setup leverages the trust and security of established blockchains, while reducing the setup and maintenance costs of the platform chain.
• Enabling seamless integration of the platform chain without requiring any modifications to the reference chain, thereby preserving its autonomy and facilitating the deployment of customized platform blockchains.
• Recording only the hash values of transactions on the platform chain, while disclosing the actual transaction contents on the dual platform chain, thereby enhancing data privacy and confidentiality.
• Enabling scalable transaction processing by consolidating multiple transactions into a single hash value, thereby enhancing the efficiency and flexibility of the platform.

These contributions collectively provide a scalable, privacy-aware, and economically viable foundation for digital asset trading on small-scale platforms.

In lieu of empirical results or simulation-based benchmarks, this study adopts a formal threat analysis to evaluate the robustness and trustworthiness of the proposed framework. This approach is aligned with the design-oriented nature of the work, where system security and integrity are ensured by structural safeguards and role-specific constraints rather than probabilistic performance metrics.

Since the framework is intended for permissioned blockchain environments with explicit governance mechanisms, well-defined participant roles, and contract-based execution, its effectiveness is best demonstrated through adversarial modeling. Accordingly, the security evaluation is structured to identify potential vulnerabilities and to analyze how each threat is mitigated by the proposed design.

1.4. Organization of the Paper

The remainder of this paper is organized as follows: Section 2 provides background on blockchain technology and reviews related work. Section 3 introduces the proposed method in detail. Section 4 evaluates the proposed method through a comprehensive threat analysis and discusses its limitations as well as directions for future research. Finally, Section 5 provides discussions and concluding remarks.

2. Background and Related Work

In this section, we define the key terms and notations used in this paper and provide relevant background on blockchain technology. Additionally, we review prior research on sidechain methods and rewardless block mining.

2.1. Blockchain Fundamentals

A blockchain can be conceptualized as a state machine that maintains a record of historical states and user interactions. Specifically, miners, participants in the blockchain network who compete to compute a new block and are typically incentivized by rewards, gather transactions to form a new block, denoted as $B^{\left[n\right]}$. Miners then attempt to compute a proof of work (explained shortly) to append this new block $B^{\left[n\right]}$ to the existing blockchain ${\mathbb{BC}}^{[n-1]}$, which contains all previous states and interactions up to the $(n-1)$-th state. The addition of $B^{\left[n\right]}$ enables a state transition from the $(n-1)$-th state to the n-th state, formally expressed as

$${\mathbb{BC}}^{\left[n\right]}={\mathbb{BC}}^{[n-1]}\left|\right|B^{\left[n\right]},$$

(1)

where $\left|\right|$ denotes concatenation.

The proof of work mechanism establishes a competitive process for appending new blocks (referred to as block mining) to the blockchain, thereby preventing monopolization by a small number of miners. Specifically, let

$$t^{\left[n\right]}=(t_1,t_2,\cdots ,t_{c_n})$$

(2)

denote the set of transactions collected by a miner for inclusion in block $B^{\left[n\right]}$, where $c_n$ denotes the total number of transactions in $B^{\left[n\right]}$.

Block $B^{\left[n\right]}$ consists of the hash value $h^{[n-1]}$ of the immediately preceding block $B^{[n-1]}$, the transaction set $t^{\left[n\right]}$, and a nonce $r^{\left[n\right]}$ that ensures the block meets predefined conditions. When a miner is said to have obtained the proof of work to add their constructed block $B^{\left[n\right]}$ to the existing blockchain ${\mathbb{BC}}^{[n-1]}$, this implies that they have successfully calculated the nonce $r^{\left[n\right]}$ to satisfy the required conditions based on the transaction set $t^{\left[n\right]}$ they intend to register. This process can be expressed as

$$h^{\left[n\right]}=H(h^{[n-1]}\left|\right|t^{\left[n\right]}\left|\right|r^{\left[n\right]})\in \mathcal{C},$$

(3)

where H is a cryptographic hash function, $\mathcal{C}$ represents the set of conditions that the hash value $h^{\left[n\right]}$ of $B^{\left[n\right]}$ must meet, and $r^{\left[n\right]}$ is the nonce number that satisfies (3). In Bitcoin, H is the SHA-256 hash function [38], and $\mathcal{C}$ is defined as the set of 256-bit strings that are smaller than a predetermined target value. In (3), the blockchain includes the hash value of the last connected block in a new block, ensuring the integrity of the blockchain by preventing arbitrary modifications to previously linked blocks.

A smart contract is a self-executing computer program deployed on a blockchain that automates the execution of contractual logic between parties. As demonstrated in Ethereum, a smart contract consists of program code that maintains internal variables and state, and can generate outputs deterministically based on input data. While a smart contract cannot initiate itself, it is triggered explicitly by a user through a transaction. For example, the transaction

$$TX=u\to sc:d$$

(4)

instructs all nodes in the blockchain network to execute the smart contract $sc$ with input d, based on a valid request from user u. To verify the authenticity of the initiating user, the transaction must include a digital signature, though this aspect is omitted in this discussion for simplicity. Once invoked, a smart contract can maintain cryptocurrency balances, update internal state, and even trigger other smart contracts during its execution.

In the standard format of a transaction, this is represented as follows:

$$TX=\mathrm{sender}’\mathrm{s}\mathrm{address}\to \mathrm{receiver}’\mathrm{s}\mathrm{address}:\mathrm{transmitted}\mathrm{content}.$$

(5)

For the sake of simplicity, we will use the owners instead of their addresses in the sender and receiver fields. For example, in (4), u represents $addr\left(u\right)$. Here, $addr\left(X\right)$ refers to the address of X, which acts as an identifier on the blockchain network. This simplification does not lead to any ambiguity in the sender and receiver fields, as only addresses are permitted in these fields. However, in the transmitted content field, omitting addresses may cause confusion, as the distinction between an address and its owner can have different implications in this context.

A sidechain is a blockchain that operates autonomously but remains closely connected to the main blockchain network (hereafter referred to as the mainchain). Sidechains are frequently utilized to perform specific functions or provide specialized capabilities, thereby extending the utility of the mainchain.

In this study, sidechains are employed to construct platform chains optimized for the operation of small-scale platforms, while leveraging the established reliability of an existing blockchain. The existing blockchain serves as a reference for recording platform activities on the platform chain in an immutable manner. Instead of using the more common term mainchain, we use the term reference chain to describe this existing blockchain in relation to the platform chain, emphasizing its role as a trust anchor and integrity reference.

2.2. Previous Studies on Sidechain Methods and Rewardless Block Mining

Previous research on sidechain methods has explored various aspects, highlighting their diverse applications and technical challenges in blockchain ecosystems. For example, studies such as [39,40,41,42,43,44,45] have focused on the technical design and implementation of sidechains, investigating key aspects, including interoperability, security, scalability, sharding, and consensus mechanisms. In contrast, the research in [46,47,48] examined the security and trust implications of sidechains, including their impact on the security of the mainchain, potential vulnerabilities, and strategies to ensure trust and integrity in sidechain operations.

Additionally, studies such as [24,49,50] have explored the practical applications of sidechains across various domains, including finance, digital content management, supply chain management, healthcare, and identity management. These works sought to identify use cases in which sidechains can offer specific benefits and address industry-specific challenges. Furthermore, the economic and incentive models associated with sidechains, including token economics, staking mechanisms, and reward structures, were investigated in [51,52], with the goal of aligning incentives for participants in sidechain networks.

Two notable sidechain implementations, Liquid and RSK, illustrate contrasting approaches to trust and incentive structures. Liquid, developed by Blockstream [53], is a federated sidechain governed by a consortium of functionaries and offers no monetary rewards for block production, instead relying on institutional trust and multisignature consensus. RSK [54], by contrast, employs merge mining, where Bitcoin miners are incentivized through transaction fees and token rewards. While both systems provide strong security, they are better suited to large-scale or token-driven environments. For small-scale digital asset trading platforms without native tokens or the infrastructure to manage economic incentives, these models may be unnecessarily complex.

Alternative incentive models for decentralized blockchain systems without block mining rewards have attracted considerable attention within the blockchain research community. Most studies have concentrated on developing consensus algorithms that do not rely on block mining rewards [34,35,55]. Other research has explored alternative compensation models, such as transaction-fee-based systems or community governance and funding mechanisms, to replace traditional mining incentives [36,56,57,58].

However, these approaches encounter several challenges. Consensus mechanisms such as Byzantine Fault Tolerance (BFT) and Proof of Stake (PoS), despite eliminating the need for mining rewards, encounter scalability challenges and security vulnerabilities, such as the ‘nothing-at-stake’ problem, particularly in high-throughput environments [55]. Additionally, the absence of traditional block rewards complicates the design of effective incentive mechanisms, making it challenging to sustain validator participation and ensure network security during low transaction periods [34]. Transitioning to new consensus mechanisms can also introduce governance complexities and adoption barriers, potentially leading to reduced participation or even network splits [59].

Moreover, reliance on transaction fees or community funding models can reduce validator incentives during periods of low transaction volumes, thereby affecting both security and decentralization [36,57]. Governance complexities and the transition from existing reward models further complicate the adoption of these approaches [56,58]. While these models present promising alternatives, their practical implementation requires further research to address these critical challenges comprehensively.

Unlike previous studies that emphasized extending mainchain functionalities through sidechains, this study adopts a different approach by using the mainchain as a reference for independently purposed sidechain networks. A key contribution of this study is its focus on addressing block mining reward issues through the use of private or consortium blockchains, rather than designing new consensus algorithms primarily for public blockchains.

3. Proposed Method

3.1. Notations and Terminologies

This study aims to introduce an efficient and reliable sidechain solution for a small-scale digital asset trading platform (DATP). To simplify the discussion, we denote the target DATP as M and the platform chain responsible for operating M as ${\mathbb{PC}}_M$.

As discussed in Section 1.2, this study proposes constructing the ${\mathbb{PC}}_M$ not as an independent blockchain but as a sidechain linked to well-established blockchains like Bitcoin and Ethereum. In this context, the blockchain serving as the mainchain is referred to as the reference chain, denoted by $\mathbb{RC}$.

The proposed approach supports the use of either fiat currency or the $\mathbb{RC}$’s cryptocurrency (denoted as $coin$) as the medium of exchange within the DATP M. This study does not consider creating a dedicated cryptocurrency within the ${\mathbb{PC}}_M$ for transactions, as this is deemed unsuitable for small-scale DATPs.

While fiat currency can be used as a medium of exchange, this study primarily focuses on utilizing the $\mathbb{RC}$’s cryptocurrency, $coin$, for transactions. The fiat-currency-based model requires financial institutions to mediate credit-related transactions, incurring intermediary fees. However, this paper does not discuss this model in detail, as it naturally follows from the cryptocurrency-based approach presented.

Table 1. A list of notations.

Notation	Description
M	a digital asset trading platform (DATP)
$t_M$	the entity operating DATP M
${\mathbb{PC}}_M$	the platform chain specifically designed to operate DATP M
$\mathbb{RC}$	the reference chain to which ${\mathbb{PC}}_M$ is linked as a sidechain
$P{A}_K$	a physical asset uniquely identified by K
$D_K$	a digital asset derived from $P{A}_K$
$s{c}_K$	the smart contract responsible for managing $D_K$ within ${\mathbb{PC}}_M$
$s{c}_M$	a set of gateway smart contracts connecting ${\mathbb{PC}}_M$ to $\mathbb{RC}$
$s{c}_P$	a set of smart contracts that define the rules of ${\mathbb{PC}}_M$
$coin$	the native cryptocurrency of $\mathbb{RC}$
${\widehat{\mathbb{PC}}}_M$	the dual platform chain associated with ${\mathbb{PC}}_M$ in $\mathbb{RC}$
A	the auditing entity responsible for detecting misconduct by $t_M$
D	the data warehouse that collects transactions for registration by $t_M$

summarizes the key symbolic notations used throughout the framework. All symbols listed in Table 1 are used to represent conceptual roles, smart contracts, blockchain entities, or their operational relationships, rather than referring to any experimentally derived data or adjustable parameters. Each symbol’s conceptual significance is briefly explained in the table caption or surrounding text to enhance the reader’s understanding.

3.2. Platform Chain as Sidechain

The proposed method assumes that ${\mathbb{PC}}_M$ is a private or consortium blockchain where block mining is restricted to a select group of entities. In this scenario, it is likely that the designated miner of ${\mathbb{PC}}_M$ and the operator of M are the same entity, or at least have aligned interests in the operation of M. Accordingly, we assume that the designated miner of ${\mathbb{PC}}_M$ and the manager of M are the same entity, denoted by $t_M$.

Since $t_M$ holds significant authority over both the platform chain ${\mathbb{PC}}_M$ and the operations of M, there is a risk that $t_M$ could arbitrarily manipulate transactions or enforce rules that disproportionately benefit itself. If left unchecked, such unilateral control may undermine user trust and discourage participation in M. To address this concern, the proposed method introduces a solution using a sidechain mechanism along with smart-contract-guided transaction registration (the details of which will be explained in the next section).

In the proposed method, $t_M$, acting as the platform manager, defines the interaction rules between ${\mathbb{PC}}_M$ and $\mathbb{RC}$ using smart contracts, collectively denoted as $s{c}_M$. Additionally, it specifies the operational rules of M through smart contracts, collectively denoted as $s{c}_P$, which are to be registered and used within ${\mathbb{PC}}_M$. These are submitted for registration on $\mathbb{RC}$ and ${\mathbb{PC}}_M$ as follows:

$$T{X}_0=\left\{\begin{array}{c}{t}_M\to add{r}_0:s{c}_M,\hfill \\ t_M\to add{r}_0^{*}:s{c}_P,\hfill \end{array}\right.$$

(6)

where $add{r}_0$ and $add{r}_0^{*}$ represent the designated addresses for smart contract registration requests on $\mathbb{RC}$ and ${\mathbb{PC}}_M$, respectively. Since $t_M$ is the designated miner of ${\mathbb{PC}}_M$, the transaction $t_M\to add{r}_0^{*}:s{c}_P$ serves to publicly announce and register $s{c}_P$ within ${\mathbb{PC}}_M$. The block containing transaction $T{X}_0$ in (6), denoted as $B^{\left[n_0\right]}$, is treated as the genesis block of ${\mathbb{PC}}_M$. Here, $s{c}_M$ functions as the gateway between ${\mathbb{PC}}_M$ and $\mathbb{RC}$, while $s{c}_P$ defines the operational rules governing ${\mathbb{PC}}_M$.

Using the transaction defined in (6), the platform operator $t_M$ establishes the operational rules of DATP M through the smart contracts $s{c}_M$ and $s{c}_P$, both of which are immutably recorded on $\mathbb{RC}$. This design aims to enhance user participation in DATP M. To achieve this, $s{c}_M$ and $s{c}_P$ must be designed to operate fairly and transparently to gain user trust.

It is also important to note that $t_M$ operates the platform for economic benefit, typically through fees or value captured from user participation. Therefore, the long-term sustainability of the platform depends heavily on maintaining user trust and ensuring that the operational logic encoded in $s{c}_M$ and $s{c}_P$ is both reliable and fair. If users suspect that the rules are biased or insecure, they may avoid participating, undermining both the platform’s integrity and $t_M$’s own incentives.

However, evaluating the technical adequacy of $s{c}_M$ and $s{c}_P$ solely by $t_M$ or general users presents challenges. Since $t_M$ has direct influence over these contracts, conflicts of interest may arise. On the other hand, general users often lack the expertise needed to assess the complexity of smart contracts. Thus, an impartial technical evaluation of $s{c}_M$ and $s{c}_P$ by external experts is essential. Accordingly, the platform manager $t_M$ is expected to rely on a neutral external entity to ensure a fair assessment of the validity of these smart contracts. The specific methods for obtaining this impartial evaluation are outside the scope of this paper, as it focuses on proposing a general framework rather than detailing external validation procedures.

As a sidechain of $\mathbb{RC}$, ${\mathbb{PC}}_M$ operates independently under normal conditions but periodically establishes connections to $\mathbb{RC}$ based on the rules immutably coded in $s{c}_M$. Let $B^{\left[n_1\right]},B^{\left[n_2\right]},\dots$ denote consecutive $\mathbb{RC}$ blocks connected to ${\mathbb{PC}}_M$ after $B^{\left[n_0\right]}$. We denote the sequence of consecutive blocks within ${\mathbb{PC}}_M$ from $B^{\left[n_i\right]}$ to $B^{\left[n_{i+1}\right]}$ as $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$ (hereafter referred to as the platform chain segment).

The platform chain segment $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$ starting at $B^{\left[n_i\right]}$ indicates that the header of $b^{[i,1]}$ includes the hash value of $B^{\left[n_i\right]}$:

$$H\left(B^{\left[n_i\right]}\right)\in \mathrm{header}\left(b^{[i,1]}\right).$$

(7)

Similarly, the fact that the platform chain segment $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$ ends at $B^{\left[n_{i+1}\right]}$ implies that the following transaction $T{X}_1$ is included in $B^{\left[n_{i+1}\right]}$:

$$T{X}_1=t_M\to s{c}_M:H\left(b^{[i,N_i]}\right).$$

(8)

Blocks within the platform chain segment $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$ also follow the standard hash value chaining rules. Once $B^{\left[n_{i+1}\right]}$ is securely recorded on $\mathbb{RC}$, modifying transactions within $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$ becomes virtually impossible, even for $t_M$. In this case, we say that $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$ are connected to $\mathbb{RC}$. This framework is autonomous, as $\mathbb{RC}$ does not need to perform explicit actions to initiate or finalize a ${\mathbb{PC}}_M$ segment within its own blocks. The operations on ${\mathbb{PC}}_M$ proceed automatically, following the predefined rules in $s{c}_M$.

Using a well-established blockchain such as Bitcoin or Ethereum as $\mathbb{RC}$ provides significant advantages, as it allows the system to inherit its stability and security without requiring active intervention from these well-known blockchains. Figure 1 illustrates these concepts; segment $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$ is finalized when its commitment is recorded in block $B^{\left[n_{i+1}\right]}$ on $\mathbb{RC}$, ensuring immutability and trust inheritance.

3.3. Smart Contract-Guided Transaction Registration

In the previous section, we proposed constructing ${\mathbb{PC}}_M$ as a sidechain of $\mathbb{RC}$, where $t_M$, the designated miner of the platform chain ${\mathbb{PC}}_M$, holds minimal influence. This design serves to mitigate arbitrary behavior by $t_M$. In this section, we introduce an additional safeguard against misuse: smart-contract-guided transaction registration.

To enhance clarity, we now present a concrete example. Assume that the digital asset traded in DATP M is derived from a specific type of physical asset. Specifically, let $D_K$ represent the digitized ownership of certain rights associated with a physical asset, denoted by $P{A}_K$, which is uniquely identified by K. Let $s{c}_K$ denote the smart contract deployed on ${\mathbb{PC}}_M$ to manage $D_K$.

Suppose user u owns $D_K$. This means that u can generate a valid digital signature using the private key corresponding to the public key linked to $D_K$. In this case, $D_K$ is uniquely represented by a blockchain token, and $s{c}_K$ ensures that u retains exclusive control over it.

The specific enforcement mechanism depends not only on the physical properties of $P{A}_K$ but also on the legal status of $D_K$. For instance, if $P{A}_K$ is an electric vehicle and $D_K$ represents the right to operate it, then $s{c}_K$ may enforce ownership by allowing only users with a valid digital signature linked to $D_K$ to start the engine of $P{A}_K$.

This paper does not elaborate on the exact mechanism through which $s{c}_K$ enforces the ownership of $D_K$. Furthermore, the process of blockchain tokenization for $D_K$ is beyond the scope of this work. For a detailed discussion on blockchain tokenization, see [21].

The proposed method restricts the transactions that can be registered on ${\mathbb{PC}}_M$ to those that request specific operations from $s{c}_P$, a set of predefined smart contracts announced in (6), as well as additional operation requests or public disclosures of results generated during the execution of these smart contracts. In other words, this approach limits the transactions registered on ${\mathbb{PC}}_M$ to predefined operations, thereby simplifying the procedures required to verify their validity.

For example, suppose that u agrees to transfer their ownership of $D_K$ to v in exchange for $coin\left(L\right)$, which represents L units of $coin$. To complete this transaction, u must execute a predefined smart contract $s{c}_P$ on ${\mathbb{PC}}_M$, which is designed to transfer ownership of the ${\mathbb{PC}}_M$ tokens, by submitting the following transaction for registration on ${\mathbb{PC}}_M$,

$$t{x}_1=u\to s{c}_P:\mathtt{Cond},n,r$$

(9)

where n is a nonce used to prevent $t{x}_1$ from being replayed, and r is a random number chosen by u to ensure that $t{x}_1$ cannot be predicted from its hash value. The reason for this will be explained in the next section. Here, recall that the digital signature $D{S}_u\left(t{x}_1\right)$ by u on $t{x}_1$ is omitted for simplicity. This transaction triggers the execution of $s{c}_P$ under the predefined conditions $\mathtt{Cond}$, which include details such as the digital asset $D_K$, the addresses of the seller u and the buyer v in both $\mathbb{RC}$ and ${\mathbb{PC}}_M$, the sale price $coin\left(L\right)$, and the time limit T. We represent these dependencies as follows:

$$\mathtt{Cond}=\mathtt{Cond}(D_K,u,v,u^{*},v^{*},L,T),$$

(10)

where, for clarity, u and v denote the addresses of the participants in $\mathbb{RC}$, while $u^{*}$ and $v^{*}$ represent their corresponding addresses in ${\mathbb{PC}}_M$. The procedures following the registration of $t{x}_1$ will be discussed in the next section.

Before concluding this subsection, we note that in (9), lowercase notation is used to indicate that $t{x}_1$ is a transaction on ${\mathbb{PC}}_M$, whereas in (6) and (8), uppercase notation indicates that $T{X}_0$ and $T{X}_1$ are transactions on $\mathbb{RC}$. Throughout this paper, we follow this convention to specify the blockchain associated with each transaction.

3.4. Dual Platform Chain

The subsequent actions for transaction $t{x}_1$ in (9) are sequentially executed by predetermined smart contracts once all conditions in (10) have been satisfied. However, for these actions to proceed, $t{x}_1$ must first be registered in ${\mathbb{PC}}_M$ by $t_M$. To prevent $t_M$ from selectively rejecting transactions for personal gain, the proposed method initially records only the hash value $H\left(t{x}_1\right)$ in ${\mathbb{PC}}_M$ at the request of its creator (in the case of $t{x}_1$, by u). Then, $t{x}_1$ is disclosed in the dual platform chain${\widehat{\mathbb{PC}}}_M$ immediately after the ${\mathbb{PC}}_M$ segment containing $H\left(t{x}_1\right)$ is connected to $\mathbb{RC}$. Here, the dual platform chain ${\widehat{\mathbb{PC}}}_M$ is defined as a sidechain of $\mathbb{RC}$ with the same structure as ${\mathbb{PC}}_M$, where the correspondence between ${\mathbb{PC}}_M$ and ${\widehat{\mathbb{PC}}}_M$ is established as follows: If a hash value $H\left(tx\right)$ is registered in block $b^{[i,j]}$ of ${\mathbb{PC}}_M$, then transaction $tx$ is disclosed in the corresponding block ${\widehat{b}}^{[i,j]}$ of ${\widehat{\mathbb{PC}}}_M$. Conversely, if transaction $tx$ is directly registered in block $b^{[i,j]}$ of ${\mathbb{PC}}_M$ without hashing, it is also placed in the corresponding block ${\widehat{b}}^{[i,j]}$ of ${\widehat{\mathbb{PC}}}_M$. Figure 2 illustrates this scenario; each block $b^{[i,j]}$ in ${\mathbb{PC}}_M$ corresponds to a block ${\widehat{b}}^{[i,j]}$ in ${\widehat{\mathbb{PC}}}_M$ that discloses the transaction content associated with the hash values recorded in ${\mathbb{PC}}_M$

To further explain how the proposed method prevents $t_M$ from selectively rejecting or delaying the registration of certain transactions, let $b^{[i,j]}$ be the ${\mathbb{PC}}_M$ block containing $H\left(t{x}_1\right)$ in (9), and let $B^{\left[n_{i+1}\right]}$ be the $\mathbb{RC}$ block at which the ${\mathbb{PC}}_M$ segment containing $b^{[i,j]}$ ends. Once this segment of ${\mathbb{PC}}_M$ is connected to $B^{\left[n_{i+1}\right]}$, modifying or removing $H\left(t{x}_1\right)$ becomes virtually impossible, as it would require altering $B^{\left[n_{i+1}\right]}$ and all subsequent blocks in $\mathbb{RC}$. Additionally, the use of the random number r in (9) ensures that $t_M$ cannot infer the content of $t{x}_1$ from $H\left(t{x}_1\right)$ alone, thus providing no basis for selectively rejecting or delaying its registration.

It is also worth noting that not all transactions are initially registered as hash values in ${\mathbb{PC}}_M$. For example, transactions explicitly requested by their creator to be directly registered in ${\mathbb{PC}}_M$, transactions generated by $t_M$, and transactions occurring between smart contracts must be disclosed. Furthermore, any transaction intended for public visibility from the outset can be directly registered in ${\mathbb{PC}}_M$.

To make the process of disclosing transactions in ${\widehat{\mathbb{PC}}}_M$ autonomous, the proposed method uses an independent entity D from $t_M$, whose role is to store hashed transactions $H\left(tx\right)$ and corresponding transactions $tx$ uploaded from users, and to disclose $tx$ in ${\widehat{\mathbb{PC}}}_M$, after the ${\mathbb{PC}}_M$ block containing $H\left(tx\right)$ is connect to $\mathbb{RC}$. Notice that the disclose of $tx$ does not need help from $t_M$. Anyone can provide the transaction, as long as its hash value matches the one in ${\mathbb{PC}}_M$. The data warehouse D can make itself independent from $t_M$ by providing a neutral mechanism that allows an anonymous uploading of $H\left(tx\right)$ and $E\left(tx\right)$ (the encryption of $tx$ by a user) and the conditional decryption of $E\left(tx\right)$ after the ${\mathbb{PC}}_M$ block containing $H\left(tx\right)$ is connected to $\mathbb{RC}$.

In this process, misconduct by $t_M$ (preventing D from disclosing transactions in ${\widehat{\mathbb{PC}}}_M$) or D (failing to promptly disclose transactions in ${\widehat{\mathbb{PC}}}_M$) is easily detectable. Users can report misconduct by $t_M$ or D to A, a designated auditing entity, using the information recorded in ${\mathbb{PC}}_M$ as evidence. Although $t_M$ could technically continue to resist allowing transactions to be disclosed in ${\widehat{\mathbb{PC}}}_M$, doing so would undermine the credibility of DATP M’s operations, an outcome that $t_M$ would likely seek to avoid. The same holds true for D.

Additionally, once DATP M is launched, the role of $t_M$ becomes limited to registering requested transactions and initiating predefined smart contracts under immutable operating rules. Consequently, the functions of $t_M$ within DATP M can be automated and are readily replaceable, serving as a deterrent against potential misconduct by $t_M$. Similarly, this concept of role automation also applies to entities D and A. Thus, the assumption that D and A will act neutrally in accordance with predefined rules is practical within the proposed method.

3.5. Subsequent Operations by Smart Contracts

Once $t{x}_1$ is disclosed in ${\widehat{b}}^{[i,j]}$ of ${\widehat{\mathbb{PC}}}_M$, $t_M$ checks its validity, if necessary, using the hash value recorded in $b^{[i,j]}$ of ${\mathbb{PC}}_M$. If the validity test fails, $t_M$ disregards $t{x}_1$, and no further actions are taken. This ensures that only valid transactions proceed, thereby maintaining the integrity of the system. On the other hand, if the validity test succeeds, $t_M$ instructs $s{c}_P$ (the smart contract specified in the output field of (9)) to request $s{c}_K$ to verify whether the ownership of $D_K$ belongs to u by executing the following transaction:

$$t{x}_2=s{c}_P\to s{c}_K:\mathtt{Check}(D_K\in u),$$

(11)

where the function $\mathtt{Check}$ returns ‘True’ if $D_K\in u$, and ‘False’ otherwise. This transaction instructs $s{c}_K$ to report the result of $\mathtt{Check}(D_K\in u)$ back to $s{c}_P$. If the return value of $t{x}_2$ in (11) is ‘True’, then $s{c}_P$ instructs one of the smart contracts in $s{c}_M$, which is designed to act as an escrow service, to check whether the buyer v has transferred $coin\left(L\right)$ to $s{c}_M$ by executing

$$t{x}_3=s{c}_P\to s{c}_M:\mathtt{Check}(v\to s{c}_M:coin\left(L\right)).$$

(12)

Conversely, if the return value of $t{x}_2$ is ‘False’, $t_M$ disregards $t{x}_1$ and no further actions are taken.

Now, consider the case where v sends $coin\left(L\right)$ to $s{c}_M$, which is verifiable by the following transaction on $\mathbb{RC}$:

$$T{X}_4=v\to s{c}_M:coin\left(L\right),\mathtt{Cond}$$

(13)

Through this transaction, v instructs $s{c}_M$ to hold $coin\left(L\right)$ under the conditions defined in $\mathtt{Cond}$.

Note that v could technically send $coin\left(L\right)$ directly to u without using $s{c}_M$. However, the proposed method enforces the use of $s{c}_M$ as in $T{X}_4$ to ensure the entire process remains visible in both ${\mathbb{PC}}_M$ and ${\widehat{\mathbb{PC}}}_M$.

The smart contract $s{c}_M$, specified in the output field of $t{x}_3$ in (12), scans newly added blocks in $\mathbb{RC}$ within a predefined time window to determine whether $T{X}_4$ has been recorded. If it finds $T{X}_4$, it returns ‘True’ to $s{c}_P$, as specified in $t{x}_3$. Otherwise, it returns ‘False’, and $t_M$ disregards $t{x}_1$, with no further action taken.

Recall that the goal of $t{x}_1$ is to transfer $D_K$ from u to v at a sale price of $coin\left(L\right)$. If both $t{x}_2$ and $t{x}_3$ return ‘True’ within the time period defined by T in $\mathtt{Cond}$ (see (10)), then $s{c}_P$ proceeds to request $s{c}_K$ to transfer $D_K$ from u to v, and $s{c}_M$ to release $coin\left(L\right)$ to u by executing

$$t{x}_5=s{c}_P\to s{c}_K:\mathtt{Execute}(u\to v:D_K)$$

(14)

$$t{x}_6=s{c}_P\to s{c}_M:\mathtt{Execute}(s{c}_M\to u:coin\left(L\right))$$

(15)

In response to $t{x}_5$, $s{c}_K$ updates the ownership of $D_K$ in its internal memory from $add{r}_u^{*}$ to $add{r}_v^{*}$, which are the ${\mathbb{PC}}_M$ addresses of u and v, respectively. Likewise, in response to $t{x}_6$, $s{c}_M$ sends $coin\left(L\right)$ to u by submitting the following transaction for registration in $\mathbb{RC}$:

$$T{X}_7=s{c}_M\to u:coin\left(L\right)$$

(16)

The execution of $t{x}_1$, and consequently the registration of $t{x}_2$, $t{x}_3$, $t{x}_5$, $t{x}_6$, and $T{X}_7$, can only occur after $t{x}_1$ is disclosed, i.e., only after $B^{\left[n_{i+1}\right]}$, the $\mathbb{RC}$ block finalizing the ${\mathbb{PC}}_M$ segment containing $t{x}_1$, has been mined.

Note that $B^{\left[n_{i+1}\right]}$ is also the starting point for the next ${\mathbb{PC}}_M$ segment, $b^{[i+1,1]}$, $b^{[i+1,2]}$, …, $b^{[i+1,N_{i+1}]}$. The proposed method enforces that the mining of $b^{[i+1,1]}$, $b^{[i+1,2]}$, …, $b^{[i+1,N_{i+1}]}$ begins only after the execution of all transactions registered as hash values in the prior segment $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$ is completed. This ensures that the sequential integrity across ${\mathbb{PC}}_M$ segments is preserved.

To better understand what it means for a transaction to be fully executed, consider $t{x}_1$ in (9), where user u sells digital asset $D_K$ to v. Suppose the hash of $t{x}_1$ is included in the ${\mathbb{PC}}_M$ segment $b^{[i,1]}$, $b^{[i,2]}$, …, $b^{[i,N_i]}$, which ends at the $\mathbb{RC}$ block $B^{\left[n_{i+1}\right]}$. The execution of $t{x}_1$ begins only after $B^{\left[n_{i+1}\right]}$ is anchored to $\mathbb{RC}$ and the full content of $t{x}_1$ is disclosed on ${\widehat{\mathbb{PC}}}_M$. This rule applies equally to all transactions registered as hash values in the segment, and only once all such executions are completed can the subsequent segment $b^{[i+1,1]}$, $b^{[i+1,2]}$, …, $b^{[i+1,N_{i+1}]}$ be created.

However, defining the execution of $t{x}_1$ as complete only after all of $t{x}_2$ in (11), $t{x}_3$ in (12), $T{X}_4$ in (13), $t{x}_5$ in (14), $t{x}_6$ in (15), and $T{X}_7$ in (16) have been completed is not practical. This is because $T{X}_4$ and $T{X}_7$ are executed on the reference chain $\mathbb{RC}$, and the platform has no mechanism to enforce their timely execution. To address this, the framework requires $T{X}_4$ to be pre-registered when $t{x}_1$ is created, and it is expected to be completed before $t{x}_3$ is triggered. As for $T{X}_7$, there is no need to wait for its completion to consider $t{x}_1$ finalized, since $T{X}_7$ is executed by the smart contract $s{c}_M$ and, by its deterministic nature, its successful execution is guaranteed once invoked. Accordingly, in this study, we define the execution of $t{x}_1$ as complete once $t{x}_6$ has been successfully processed.

Before closing this section, we emphasize that transactions $t{x}_2$, $t{x}_3$, $t{x}_5$, $t{x}_6$, and $T{X}_7$ are automatically derived from the registration of $t{x}_1$. Therefore, they do not require separate registration. In fact, $T{X}_7$ is not even recorded in $\mathbb{RC}$, as the reference chain does not store the outcomes of smart contract executions. Nonetheless, the proposed framework records all of these derived transactions in both ${\mathbb{PC}}_M$ and ${\widehat{\mathbb{PC}}}_M$, so that the results of the smart contract executions remain publicly verifiable without requiring users to re-execute the logic themselves.

3.6. Cost-Effective and Privacy-Preserving Transaction Registration

To prevent operator abuse of power, the proposed method only registers the hash values of transactions on the platform chain ${\mathbb{PC}}_M$, while their full content is disclosed later on the dual platform chain ${\widehat{\mathbb{PC}}}_M$. This enables a cost-effective and privacy-preserving approach to transaction registration.

One key feature of the proposed method is its ability to aggregate multiple transaction hashes into a Merkle tree. For example, the data warehouse D may collect transaction hashes $t{x}^{\prime }$ to be disclosed in ${\widehat{\mathbb{PC}}}_M$, construct a Merkle tree $MT$, and request that the root hash is recorded in ${\mathbb{PC}}_M$ via a smart contract $s{c}_P$. This allows a large number of transactions to be registered through a single root hash, optimizing storage and bandwidth. Figure 3 illustrates this scenario; Transaction hashes collected by D are aggregated into a Merkle tree, with the root hash recorded in ${\mathbb{PC}}_M$ and the corresponding transaction contents disclosed in ${\widehat{\mathbb{PC}}}_M$ after finalization.

To ensure the correctness of batch registration, the method requires that transactions grouped under the same Merkle tree be logically and temporally independent. If dependencies exist between transactions, such a grouping may result in erroneous or unpredictable execution outcomes. However, D has no access to transaction content at the time of Merkle tree construction and thus cannot assess such dependencies. Even if full transaction data were available, detecting interdependencies would require semantic understanding beyond the scope of D’s role. Therefore, the framework deliberately excludes D from responsibility for verifying transaction independence.

3.7. User Responsibility for Transaction Independence

To address the difficulty of system-level dependency analysis, the proposed method assigns the responsibility for verifying transaction independence to users during transaction creation. Although this may initially appear burdensome, in practice, users typically base new transactions on data that have already be confirmed and finalized.

Specifically, users are advised to reference only those transactions that are fully registered. A transaction is considered fully registered when its hash is included in a platform chain segment that has been finalized by anchoring to the reference chain $\mathbb{RC}$. For instance, if a user wishes to register transaction $tx$ in block $b^{[i,j]}$ of the segment $b^{[i,1]}$ to $b^{[i,N_i]}$, then other transactions in the same segment are not yet finalized at the time of $tx$’s creation. Finalization occurs only when the terminal block $B^{\left[n_{i+1}\right]}$ is recorded on $\mathbb{RC}$. See Section 3.5 for more details.

Failing to follow this guideline is risky. For example, suppose user w submits a transaction to buy asset $D_K$ from user v, assuming that transaction $t{x}_1$, in which u sells $D_K$ to v, will be successfully executed. If $t{x}_1$ is not finalized or fails execution, w’s transaction becomes invalid. In this framework, such risk is borne entirely by the user. By enforcing this design principle, the system preserves transactional integrity, while maintaining decentralized control over dependency validation.

4. Results: Threat Analysis

This section adopts a structured threat analysis to evaluate the robustness and trustworthiness of the proposed framework. This approach is particularly well suited to permissioned blockchain environments, where the effectiveness of the system depends on role separation, structural constraints, and cryptographic accountability, rather than stochastic performance metrics.

Rather than presenting empirical data or simulation results, this study conducts a structured threat analysis to evaluate how the proposed architectural design systematically mitigates adversarial behaviors. Since core system properties—such as post-anchoring immutability, confinement to predefined smart contracts, and content-obscured transaction registration—are enforced by structural design constraints rather than by probabilistic mechanisms, threat analysis provides an appropriate and focused evaluation framework for validating the proposed method.

The following subsections categorize and examine key adversarial scenarios and describe the mechanisms by which the proposed method neutralizes each threat.

4.1. Threat 1: Transaction Manipulation by $t_M$

A major threat in permissioned blockchain platforms is the possibility that the operator $t_M$ could exert discretionary control over transaction processing. This includes selectively rejecting, delaying, or reordering transactions for arbitrary or self-serving purposes. The proposed method systematically eliminates these threats through a combination of transaction hash commitment and dual-chain disclosure. We explain each aspect below:

• Rejection and Delay: Users submit only the hash value of their transaction for initial registration in ${\mathbb{PC}}_M$, which includes a random number r that conceals the transaction’s content. As $t_M$ cannot know what the transaction contains, it cannot selectively reject or delay it for content-based reasons. Any delay without justification becomes auditable once the segment is anchored to $\mathbb{RC}$.
• Reordering: Since all transaction hashes appear opaque at the time of registration, $t_M$ cannot prioritize or rearrange them meaningfully. For batch-registered transactions, their positions within the Merkle tree can be verified later, preventing order manipulation.
• Modification: In conventional blockchains, transaction content is safeguarded against tampering through the use of digital signatures. In the proposed method, an additional concern arises from the requirement to disclose the results of smart contract executions for the sake of user convenience and transparency. This introduces the risk that $t_M$ could manipulate the published results to distort the intended execution outcome. To counter this, the framework allows the auditor A to independently recompute the outputs of all contract executions based on the original transaction and the associated smart contract logic. By comparing the actual disclosures on the platform chain with the expected outputs, A can detect and report any inconsistencies. This verification process ensures the integrity of execution results and deters manipulation by $t_M$.

In summary, the proposed method mitigates operator manipulation through a combination of transaction hash commitment and dual-chain disclosure. By hiding transaction content during registration while ensuring cryptographic verifiability, it prevents content-based manipulation by the operator. This reduces discretionary control and reinforces trust in the fairness of transaction processing.

4.2. Threat 2: Intentional or Accidental Misconduct by Users

The framework gives users the flexibility to generate their own transactions, but it relies on their responsible behavior to maintain system integrity. Misconduct, whether intentional or accidental, can lead to inconsistencies, execution failures, or denial-of-service risks. The proposed framework addresses these concerns through the following mechanisms:

• Dependency Validation Responsibility: Users are required to construct transactions based only on data from finalized transactions whose hash values have been recorded in a platform chain segment already anchored to the main chain. If a user references unconfirmed transactions that later fail, the resulting transaction is invalid and the responsibility lies entirely with the user. This rule prevents accidental inconsistencies and protects the platform from reliance on unguaranteed outcomes.
• Double Selling: Double selling refers to an attempt by a user to sell the same digital asset to multiple recipients before the completion of the first transaction. Consider a case where a user u attempts to sell the same digital asset $D_K$ to both v and w, by submitting the transaction $t{x}_1$ as in (9) to transfer $D_K$ to v, while simultaneously initiating another transaction $\tilde{t}{x}_1$ to transfer $D_K$ to w, before $t{x}_1$ is finalized. In the proposed framework, both $t{x}_1$ and $\tilde{t}{x}_1$ can be registered successfully, since neither D nor $t_M$ checks transaction dependencies during the registration phase. However, transactions are executed one at a time in the order they were registered. For each transaction, the smart contract $s{c}_P$ first validates its inputs, such as ownership and predefined execution conditions. Only if the transaction is valid is it executed. Therefore, once $t{x}_1$ is successfully executed and $D_K$ is transferred to v, the subsequent transaction $\tilde{t}{x}_1$ fails the validity check because u no longer owns $D_K$.
  Since the invalid transaction originates from u’s misconduct, $s{c}_P$ does not refund the execution cost $\eta$ that u paid to invoke $\tilde{t}{x}_1$. Instead, the smart contract redirects this cost to compensate w, assuming w has already initiated a payment transfer as in (13) based on the expected receipt of $D_K$. To enable this compensation, the framework requires that $\eta \ge 2ϵ$, where $ϵ$ is the execution cost of the $coin$ transfer on the reference chain $\mathbb{RC}$. This design ensures that the fee collected from u’s invalid transaction is sufficient to cover the refund cost to w, while leaving no incentive for u to exploit the system. By setting the execution fee for asset transfer contracts higher than a standard $coin$ transfer, the framework effectively deters malicious users from attempting double selling.
• Replay Attack: A replay attack occurs when a malicious actor attempts to reuse a previously submitted and valid transaction in a different context or time, aiming to duplicate its effect. In blockchain systems, such attacks can lead to unauthorized asset transfers or contract invocations if proper safeguards are not put in place.
  In the proposed framework, replay attacks are prevented by including a unique nonce in each user-generated transaction, as shown in (9). This nonce ensures that each transaction is executed only once and cannot be validly replayed in the future. If a transaction with the same nonce is submitted again, it will be rejected by the smart contract as a duplicate. This mechanism guarantees transaction uniqueness and defends the system against replay-based exploits.
• Payment Refusal: A potential threat in digital asset transactions arises when a buyer refuses to complete payment after initiating or receiving a transaction. While refusing payment after receiving the asset would be a critical issue, such a scenario cannot occur in the proposed framework due to its sequential execution model.
  Consider a case where a user u attempts to sell the digital asset $D_K$ to v as in (9), by submitting $t{x}_1$ to transfer $D_K$, and v subsequently refuses to initiate the payment transaction $T{X}_4$ as described in (13). In this case, the smart contract $s{c}_P$ detects the missing payment step during execution. As a result, the intermediate effects of $t{x}_1$, including those from $t{x}_2$ in (11) and $t{x}_3$ in (12), are rolled back, keeping the asset $D_K$ in u’s ownership. Thus, u suffers only the loss of the transaction execution cost for $t{x}_1$, while v incurs no penalty.
  To discourage such opportunistic refusal, the framework introduces a deposit mechanism. Each participant is required to stake a small refundable security deposit when initiating asset-related transactions. If a user fails to complete a payment obligation after committing to a trade, the deposit can be partially or fully redirected to compensate the affected party. This mechanism aligns user incentives and prevents dishonest behavior such as strategic payment refusal.
• Smart Contract Confinement: All user-created transactions must only interact with predefined and registered smart contract interfaces. This restriction ensures standardized behavior, prevents arbitrary operations, and enables the platform to detect, reject, and recover from any invalid or unexpected transactions in a verifiable and controlled manner.
• Deterrence Against Malicious Behavior: Users who attempt to submit deliberately invalid transactions, such as flooding the system or triggering executions that are bound to fail, gain no advantage in the proposed framework. Every transaction is subject to validity checks by predefined smart contracts before execution, and any invalid transaction is immediately rejected without altering the system state. In addition, users must pay the execution fee regardless of whether the transaction succeeds, which makes repeated abuse financially unviable and discourages malicious attempts.

4.3. Threat 3: Transaction Manipulation by D

As the data warehouse responsible for handling user-submitted transactions, D plays a critical role in the proposed framework. It receives transaction hash values and encrypted transaction content from users, relays the hash values to $t_M$ for inclusion in ${\mathbb{PC}}_M$, and later discloses the actual transactions in ${\widehat{\mathbb{PC}}}_M$ after the corresponding segment is finalized. Given this central role, D may be tempted to manipulate the transaction flow in ways similar to $t_M$, such as selectively publishing, delaying, or reordering transaction content. The proposed framework prevents such behavior through the design features described below:

• Rejection, Delay, and Reordering: Since transactions are uploaded in encrypted form and anonymously, D cannot infer their content or origin, and is required to disclose them in the order of hash registration immediately after the corresponding ${\mathbb{PC}}_M$ segment is anchored to $\mathbb{RC}$, making any attempt to selectively delay, reorder, or omit transactions both auditable and easily detectable.
• Collusion with $t_M$: A potential threat is that D could collaborate with $t_M$ to selectively delay, reorder, or censor transactions. However, because users upload only hash values and encrypted transaction content anonymously, D cannot associate transactions with specific users or interpret their semantics prior to registration.

Although D performs a non-privileged and auditable role, further resilience could be achieved by designing the system to allow competition or redundancy among multiple candidate entities. Rather than relying on a single designated data warehouse, the platform could adopt a modular architecture where any qualified provider may fulfill D’s role as long as it conforms to the disclosure protocol. If any instance of D is found to be unreliable or malicious, another compatible provider can be deployed without disrupting the system. This approach enhances accountability through substitutability and aligns with the fault-tolerant principles used in decentralized infrastructure design.

4.4. Threat 4: Dishonest Behavior by Auditor A

In the proposed framework, the auditor A plays a crucial role in verifying transaction validity, detecting potential misconduct, and resolving disputes based on data from ${\mathbb{PC}}_M$ and ${\widehat{\mathbb{PC}}}_M$. However, this responsibility also introduces a risk: if A acts dishonestly, either by misreporting outcomes or by neglecting its verification duties, this could undermine the trust and credibility of the entire platform. The framework addresses this risk through the following safeguards:

• Issuing incorrect or misleading verification results: All evaluations by A are based on data that are immutably recorded on-chain, including transaction hashes, smart contract logic, and execution results. Because these data are publicly accessible and verifiable, any incorrect or dishonest report by A can be independently verified and, if necessary, refuted.
• Exercising exclusive control over validation: The framework ensures that A does not rely on private information or privileged access. All necessary verification inputs are available on-chain, allowing others to replicate A’s role using independent or automated tools. This design supports the development of decentralized or community-driven auditing models and reduces the dependency on a single authority.
• Legal accountability and institutional enforcement: To complement technical safeguards, the framework assumes that A operates under a legally binding agreement or regulatory oversight. This institutional structure clearly defines A’s obligations, grants it authority to act independently, and holds it accountable for negligence or willful misconduct through enforceable consequences. Given the auditor’s privileged role in verifying transaction validity and resolving disputes, assigning legal responsibility is not merely optional but practically indispensable to ensure trustworthy and reliable oversight.

In addition, because A performs a transparent and non-privileged function, any misconduct is readily detectable and remediable. If dishonesty is observed, A can be replaced without impacting the platform’s functionality.

4.5. Summary of Security Guarantees

The proposed method achieves a balanced division of trust and responsibility among key components of the system, supported by cryptographic guarantees and role-specific constraints:

• The operator $t_M$ only executes predefined operations through smart contracts, without knowledge of the underlying transaction content at the time of registration, ensuring that its actions remain limited, predictable, and verifiable.
• Users create transactions through predefined smart contracts, which ensures consistent interaction with the platform and protects against unintended behavior or execution failures.
• The data warehouse D is responsible for handling user requests to register transaction hash values, publishing the original transaction content to ${\widehat{\mathbb{PC}}}_M$ after the corresponding segment has been finalized, and providing mechanisms such as anonymous uploading and delayed decryption to ensure confidentiality until disclosure.
• The auditor A acts as a neutral third party, with access to all necessary information from ${\mathbb{PC}}_M$ and ${\widehat{\mathbb{PC}}}_M$ to resolve disputes and detect misconduct through verifiable evidence.

5. Discussion: Limitations and Future Work

While the proposed framework presents a robust and scalable approach to preventing operator abuse and enabling verifiable transaction processing, several limitations and open issues remain that warrant further investigation.

First, a fundamental limitation of the proposed method lies in the requirement that all permissible operations on the platform be encoded in advance as predefined smart contracts. While this ensures strict enforcement and transparency, it also introduces challenges in practice. Defining all relevant operations upfront may not be feasible for complex or rapidly evolving platforms. As business logic changes or new types of transactions are introduced, the system must support timely updates of smart contracts, while maintaining consistency, security, and auditability. Future research should explore mechanisms for managing contract evolution, including versioning, upgrade policies, and governance frameworks that allow controlled modification, without undermining trust.

Second, operational rules are typically authored by the platform operator or their commissioned experts, which raises concerns about fairness and legitimacy. While minor issues may be corrected post-launch, platforms intentionally designed to mislead users must be identified beforehand. In this study, we suggested oversight by neutral experts; however, such entities must not only be technically competent but also empowered to prevent or suspend harmful platforms. Future research should explore governance mechanisms for such oversight authorities.

Third, while users are assumed to be capable of verifying the logical and temporal independence of their transactions, mistakes may occur, leading to invalid transactions. Developing tools or user interfaces that support dependency analysis or provide transaction feedback could improve usability and reduce errors, especially for non-expert users.

Fourth, although the dual-chain architecture ensures that transaction content remains hidden from the platform operator until finalization, it introduces additional latency between the time of hash registration and the moment of full transaction execution. In time-sensitive applications such as financial settlement or interactive marketplaces, this delay may degrade system responsiveness. However, once the corresponding segment is finalized and anchored to the reference chain $\mathbb{RC}$, the execution of each transaction can proceed quickly within the private or consortium-based platform chain. Since all transactions are predefined smart contract invocations with deterministic logic and bounded input sizes, their execution latency is predictable and can be kept low when executed on sufficiently fast computing infrastructure. To mitigate this delay, the choice of reference chain $\mathbb{RC}$ is crucial. A chain with short inter-block intervals allows more frequent anchoring and faster segment finalization. Future deployments may benefit from using high-throughput blockchains with fast consensus cycles, or from designing a dedicated reference chain that aggregates multiple sidechains, while ensuring stable and predictable anchoring.

Fifth, the auditing mechanism depends on the presence of a neutral and trusted entity A. While this role is clearly defined and the verification process is based on publicly available on-chain data, the governance and accountability of A require further institutional support. In practical terms, A should operate within a legally enforceable framework, whether contractual or regulatory in nature, that explicitly outlines its responsibilities, grants it the authority to conduct impartial validation, and imposes accountability for negligence or misconduct. By assigning legal responsibility in this way, the framework ensures that A not only operates transparently but also reliably, with consequences that are enforceable in the event of failure. To reinforce this legal foundation, technical measures can serve as complementary safeguards that enhance the verifiability of A’s actions. For instance, publicly auditable logs, reproducible verification procedures, and fallback mechanisms such as multi-party or community-based dispute resolution can increase transparency and resilience. However, these technical features are most effective when embedded within a governance structure that prioritizes real-world accountability.

Sixth, although the framework supports anonymous submission of transaction hashes and encrypted content, the practical burden of this may lead some users to submit unencrypted data to D, enabling potential collusion with $t_M$. This could allow censorship or manipulation based on transaction content. Future research should consider user-friendly submission methods—such as automated encryption tools, independent relayers, or decentralized mixers—that reduce reliance on the honesty of D and $t_M$.

Seventh, in dynamic business environments, it may become necessary to introduce new operational rules or revise existing ones. In such cases, it is the responsibility of the platform manager $t_M$ to manage the registration of updated smart contracts, either by submitting new ones or replacing deprecated versions. As noted in Section 3.2, any contract submitted for registration should be reviewed by a neutral external expert to ensure platform reliability and user trust. When the economic benefits of platform operation are shared among multiple stakeholders, a governance mechanism may be required, to determine which contracts are adopted. For example, voting weights based on a predefined profit distribution ratio can be used to reflect stakeholder influence, while general users without economic stakes would not participate in such decisions. Although this model introduces additional complexity, it offers a flexible framework for contract-level adaptability and is proposed as a direction for future enhancement.

Another important limitation is the absence of an empirical or simulation-based evaluation. While this study focused on the architectural and security design of the framework, future work should include a proof-of-concept implementation and performance benchmarking under real-world conditions. Such efforts will help quantify the anchoring latency, transaction throughput, and operational costs, and will provide essential insights into the practical feasibility, scalability, and optimization potential of the proposed method.

In summary, while the proposed method lays a strong foundation for secure and transparent transaction execution in decentralized platforms, further research is needed to improve the usability, reduce latency, evolve smart contracts, enforce oversight, minimize trust dependencies, and validate real-world performance.

6. Conclusions

This study proposed a sidechain-based framework for building efficient, secure, and transparent digital asset trading platforms. The core idea lies in introducing a dedicated platform chain ${\mathbb{PC}}_M$ as a private or consortium blockchain functioning as a sidechain to a well-established mainchain $\mathbb{RC}$. This design allows the platform to inherit the stability and trustworthiness of the mainchain, without requiring any modifications to it, thereby significantly reducing the costs typically associated with establishing high levels of security and reliability.

Moreover, by adopting a private or consortium model for the platform chain, the system benefits from faster consensus and transaction processing, customized blockchain configurations tailored to the specific needs of the platform, and greater adaptability to rapidly evolving business requirements. These characteristics make the proposed framework especially well-suited for dynamic digital asset trading environments that demand both performance and flexibility, alongside trust and verifiability.

Controlling the behavior of the platform operator is a central concern in this study, particularly given the semi-centralized nature of private- or consortium-based blockchains. To ensure transparency and prevent operator misconduct, the proposed method introduces a dual-sidechain architecture. In this structure, only the hash values of transactions are initially recorded in ${\mathbb{PC}}_M$, while the full transaction contents are disclosed and executed later in a paired dual platform chain ${\widehat{\mathbb{PC}}}_M$, after the corresponding segment of ${\mathbb{PC}}_M$ is finalized and anchored to $\mathbb{RC}$.

This architecture ensures that the operator cannot make decisions based on transaction content at the time of registration, effectively mitigating risks such as semantic-based censorship or favoritism. Once anchored, all registered hash values become irreversibly bound to their corresponding transactions when disclosed in ${\widehat{\mathbb{PC}}}_M$, enabling transparent auditing.

All operations are executed according to predefined smart contracts, which strictly constrain the range of actions that the platform operator can perform. Rather than minimizing centralized control in a general sense, the system explicitly limits operator authority by ensuring that all behaviors adhere to the logic encoded in immutable contracts. This safeguard is especially critical in private- or consortium-based settings, where the operator (e.g., $t_M$) would otherwise retain significant control over the platform. Through this approach, the framework effectively mitigates the risk of arbitrary or self-serving actions by the operator.

To enhance scalability and efficiency, the method employs Merkle tree constructions that allow multiple transactions to be aggregated into a single root hash for registration. The framework defines the conditions under which such aggregation is valid, particularly when the transactions are logically and temporally independent. Since verifying such independence at the system level is inherently difficult, the framework delegates this responsibility to users. They are best positioned to judge whether their transaction depends on the outcome of another. To support this process, users are instructed to reference only transactions that have already been confirmed and finalized on the chain.

The responsibility for managing transaction dependencies is explicitly assigned to users at the time of transaction creation. They must ensure that their transactions do not rely on the outcomes of other transactions that have not yet been finalized. This rule is essential to preserve the integrity of the system and applies regardless of whether transactions are registered individually or aggregated using Merkle trees.

In addition, just as the platform operator is restricted to predefined smart contracts, users are also required to only create transactions through designated smart contract interfaces. This constraint prevents users from interfering with platform operations through arbitrary or unauthorized actions. Furthermore, because transaction creation is guided by smart contracts, the system can maintain an internal execution state that allows it to roll back or safely recover from partial executions in the event of a failure. This mechanism provides an additional layer of protection for users by ensuring transactional consistency and recoverability when problems occur.

A detailed threat analysis confirmed the robustness and practical soundness of the proposed framework. Potential vulnerabilities, including operator manipulation, user misconduct, data warehouse abuse, and auditor failure, were carefully examined and addressed through specific safeguards. These included hash-based transaction commitment, dual-chain disclosure, anonymous uploading, deterministic smart contract execution, and transparent auditing mechanisms. The system design constrains the actions of all participants and distributes responsibilities in a way that reduces reliance on trust. Overall, the proposed framework offers a reliable and resilient solution for secure, transparent, and tamper-resistant transaction processing in permissioned blockchain environments.

Despite its strengths, the proposed framework presents several open challenges. These include the difficulty of predefining all platform operations as smart contracts, the need for enforceable oversight prior to platform launch, and the burden on users in ensuring transaction independence and secure submission. Potential collusion among system actors also highlights the importance of practical mechanisms that preserve transparency and confidentiality. Future work should address these limitations to support reliable implementation and broader applicability.

In conclusion, this architecture offers a practical and cost-effective solution for digital asset trading platforms in semi-centralized environments. It combines mainchain-level trust with platform-level efficiency and enforces bounded operator control through smart contracts. By aligning transparency, automation, and role accountability, the system provides a solid foundation for scalable digital asset management and future innovations in decentralized platform design.