## 3 Proposed Method
### 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 \begin{table}
\begin{tabular}{c l} \hline \hline
**Notation** & **Description** \\ \hline \(M\) & a digital asset trading platform (DATP) \\ \hline \(t_{M}\) & the entity operating DATP \(M\) \\ \hline \(\mathbb{PC}_{M}\) & the platform chain specifically designed to operate DATP \(M\) \\ \hline \(\mathbb{RC}\) & the reference chain to which \(\mathbb{PC}_{M}\) is linked as a sidechain \\ \hline \(PA_{K}\) & a physical asset uniquely identified by \(K\) \\ \hline \(D_{K}\) & a digital asset derived from \(PA_{K}\) \\ \hline \(sc_{K}\) & the smart contract responsible for managing \(D_{K}\) within \(\mathbb{PC}_{M}\) \\ \hline \(sc_{M}\) & a set of gateway smart contracts connecting \(\mathbb{PC}_{M}\) to \(\mathbb{RC}\) \\ \hline \(sc_{P}\) & a set of smart contracts that define the rules of \(\mathbb{PC}_{M}\) \\ \hline _coin_ & the native cryptocurrency of \(\mathbb{RC}\) \\ \hline \(\widehat{\mathbb{PC}}_{M}\) & the dual platform chain associated with \(\mathbb{PC}_{M}\) in \(\mathbb{RC}\) \\ \hline \(A\) & the auditing entity responsible for detecting misconduct by \(t_{M}\) \\ \hline \(D\) & the data warehouse that collects transactions for registration by \(t_{M}\) \\ \hline \hline \end{tabular}
\end{table} 
Table 1: A list of notations. 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 \(sc_{M}\). Additionally, it specifies the operational rules of \(M\) through smart contracts, collectively denoted as \(sc_{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:  
\[TX_{0}= \begin{cases}t_{M}\to addr_{0}:sc_{M},\\ t_{M}\to addr_{0}^{*}:sc_{P},\end{cases}  \tag{6}\]  
where \(addr_{0}\) and \(addr_{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 addr_{0}^{*}:sc_{P}\) serves to publicly announce and register \(sc_{P}\) within \(\mathbb{PC}_{M}\). The block containing transaction \(TX_{0}\) in (6), denoted as \(B^{[n_{0}]}\), is treated as the genesis block of \(\mathbb{PC}_{M}\). Here, \(sc_{M}\) functions as the gateway between \(\mathbb{PC}_{M}\) and \(\mathbb{RC}\), while \(sc_{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 \(sc_{M}\) and \(sc_{P}\), both of which are immutably recorded on \(\mathbb{RC}\). This design aims to enhance user participation in DATP \(M\). To achieve this, \(sc_{M}\) and \(sc_{P}\) must be designed to operate fairly and transparently to gain user trust.