## 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.