An Auditable and Trusted Lottery System in the Cloud

Abstract

Public blockchains offer transparency and tamper resistance, but implementing national-scale lotteries directly on-chain is impractical because each bet would require a separate transaction, incurring substantial gas costs and facing throughput limitations. This paper presents an auditable lottery architecture designed to address these scalability challenges and eliminate the reliance on trusted third parties. The proposed approach decouples high-volume bet recording from on-chain enforcement. Bets are recorded off-chain in a transaction-positioned Merkle tree (TP-Merkle tree), while the service provider commits only the per-round root hash and summary metadata to an Ethereum smart contract. Each player receives a signed receipt and a compact Merkle proof (Slice), enabling independent inclusion checks and third-party audits. A programmable appeal mechanism allows any participant to submit receipts and cryptographic evidence to the contract; if misbehavior is proven, compensation is executed automatically from a pre-deposited margin. A proof-of-concept implementation demonstrates the system’s feasibility, and extensive experiments evaluate collision behavior, storage overhead, proof size, and gas consumption, demonstrating that the proposed design can support national-scale betting volumes (tens of millions of bets per round) while occupying only a small fraction of on-chain resources.

1. Introduction

Lottery programs are widely used to fund public welfare and other government services. In Taiwan, for example, licensed institutions issue multiple lottery products (e.g., Lotto, Power Lottery, Bingo, and three-star/four-star games), and the core procedures include ticket purchase, drawing winning numbers, and prize redemption. Although operational rules are publicly announced, the drawing process is typically centralized, and the randomness underlying the winning numbers is difficult for the public to verify end to end. This “black-box” characteristic can foster skepticism about the fairness and integrity of the result.

Regulatory requirements for winner disclosure also vary across jurisdictions. In Taiwan, winners may collect prizes without publicly revealing their identities for personal safety reasons, which can further raise concerns about whether a claimed winner is an actual bettor and whether the payout process is fully accountable.

Blockchain technology provides decentralization, immutability, and public verifiability, and is therefore a natural fit for applications that demand auditability and non-repudiation. When combined with standard cryptographic primitives, blockchain-based systems can provide integrity, authenticity, and transparency for betting transactions recorded in a ledger.

Our approach integrates an off-chain transaction-positioned Merkle tree (TP-Merkle tree) [1,2] with an on-chain appeal mechanism, yielding a unified auditable architecture suitable for national-scale betting volumes. Unlike prior blockchain lotteries that either process all bets on-chain and suffer severe throughput bottlenecks, or rely on heavyweight randomness infrastructures that introduce additional deployment overhead, our design anchors a massive off-chain betting ledger with compact on-chain commitments and enforces accountability through programmable dispute handling. To the best of our knowledge, this is the first framework that (i) attests to a large off-chain betting ledger via a single per-round on-chain commitment and (ii) enables automatic compensation upon verifiable proof of service provider misbehavior.

The main contributions of this paper are as follows.

• Hybrid on-chain/off-chain architecture: We propose a scalable lottery system that stores millions of bets off-chain in a TP-Merkle tree, while committing only compact per-round Merkle roots to the public blockchain. This substantially reduces on-chain bandwidth and storage requirements without compromising auditability.
• Receipt-based verification protocol: We design a protocol in which each player receives a digitally signed receipt and a compact Merkle proof (Slice). This enables players and third-party auditors to verify inclusion of a bet and to check integrity of the committed ledger independently.
• Smart-contract-driven appeal mechanism: We introduce an automated appeal mechanism that accepts receipts and cryptographic evidence of service-provider misbehavior (e.g., data omission or manipulation). The smart contract adjudicates the claim and, when misconduct is proven, executes compensation automatically from a pre-deposited margin.
• Prototype implementation and evaluation: We implement a proof-of-concept prototype and conduct experiments on collision behavior, storage overhead, proof size, and gas consumption. The results indicate that the scheme can support tens of millions of bets per round with modest costs for both the service provider and players.

The remainder of this paper is organized as follows. Section 2 reviews related work, and Section 3 discusses the challenges faced by existing blockchain-based lotteries. Section 4 presents the proposed auditable architecture, Section 5 reports experimental results and performance analysis, and Section 6 provides the security analysis and discussion. Section 7 concludes the paper and outlines directions for future work.

2. Related Work

The application of blockchain technology to the gaming and lottery industries has evolved from simple cryptocurrency payments to complex, smart-contract-driven ecosystems. Early definitions established blockchain as a decentralized, immutable ledger secured by cryptographic primitives [3,4,5]. In the context of lotteries, these properties—specifically transparency and non-repudiation—promise to eliminate the “black box” nature of centralized drawing processes.

2.1. Blockchain-Based Lottery Implementations

Initial attempts to modernize lotteries focused on migrating traditional logic to decentralized platforms like Ethereum. Quanta [6], launched in 2018, represents one of the first licensed blockchain lotteries. It utilizes the ERC-20 standard [7] for token issuance and employs a commit-and-reveal scheme for random number generation (RNG). However, Quanta’s approach relies partly on a permissioned structure where only token holders participate in the RNG process, raising concerns about potential collusion and the centralization of authority.

Following commercial attempts, academic researchers proposed fully decentralized protocols to ensure fairness. Li et al. introduced BanFEL [8], a scheme that uses polynomial interpolation for RNG. In BanFEL, the winning number is derived from the coefficients of a polynomial constructed from players’ inputs. While theoretically fair, this method is computationally prohibitive for national-scale lotteries. The complexity of calculating the Lagrange polynomial is approximately O(n²), meaning that processing tens of thousands of bets would incur unacceptable latency and gas costs, rendering it impractical for high-frequency, high-volume scenarios like the Taiwan lottery.

2.2. Regional Applications and Security Analysis

Beyond protocol design, significant research has focused on adapting blockchain lotteries to specific jurisdictional requirements and security constraints. Regional adaptations often prioritize regulatory compliance and fraud prevention over pure decentralization. For instance, studies on Thailand’s government lottery [9,10] model the end-to-end flow from purchase to on-chain settlement, focusing on preventing ticket overpricing. Similarly, Liao and Wang [11] examined lotteries within a smart-city framework, emphasizing process openness and tamper-evident draws. From an engineering perspective, Jain and Shravan [12] introduced a practical automation pipeline to ensure immutable records for registration and payouts.

From a security perspective, researchers have scrutinized the vulnerabilities of existing decentralized applications. Long et al. [13] and Datta et al. [14] analyzed design patterns in Ethereum lottery DApps (e.g., Fomo3D), identifying common exploits to guide future hardening. On the theoretical front, alternative architectures such as Quantum Blockchain [15] have been proposed to provide unconditional security, though such implementations remain experimental and not yet deployable on a commodity scale.

2.3. Authoritative Randomness Primitives and Scalability

A core challenge in any blockchain lottery is generating unbiasable entropy. To address this, the cryptographic community has established several authoritative primitives. Verifiable Random Functions (VRFs), introduced by Micali et al. [16] and optimized by Dodis et al. [17], have become the industry standard for producing pseudorandom outputs with publicly verifiable proofs. Furthermore, distributed randomness beacons [18,19] and Verifiable Delay Functions (VDFs)—as formalized by Boneh et al. [20], Wesolowski [21], and Pietrzak [22]—have been introduced to prevent look-ahead attacks, ensuring that randomness cannot be manipulated by miners or participants.

In parallel, systems like DeLottery [23] and BlockLot [24] utilize these decentralized logic concepts for verifiability. However, while these approaches excel in generating transparent randomness, they typically incur high on-chain computational costs and inherit the throughput limitations of the underlying blockchain. They often rely on commit-and-reveal patterns that are difficult to scale to millions of bets. In contrast, our design prioritizes scalability for national-scale betting volumes. By decoupling the volume of bets (stored in an off-chain TP-Merkle tree) from the on-chain execution, we bypass the bottlenecks identified in previous works. It is worth noting that while general-purpose scaling solutions like Sparse Merkle Trees (SMTs) [25] and Rollups (e.g., ZK-Rollups) [26] address blockchain throughput, they are designed for general state transitions. In contrast, our TP-Merkle Tree is optimized specifically for lottery logic, incorporating a deterministic Index Function to enable efficient, client-side gap detection (censorship resistance) without the overhead of full state proofs.

3. Challenges in Current Blockchain-Based Lottery Games

While the related work indicates that blockchain technology theoretically addresses the issues of openness and fairness through immutable storage and automated payouts, significant practical barriers remain. Simply migrating traditional lottery logic to a public blockchain creates a mismatch between the technology’s current capabilities and the operational requirements of national-scale gaming. These challenges can be categorized into scalability bottlenecks, economic variability, and the lack of dispute resolution mechanisms.

The primary obstacle is the severe throughput limitation of public blockchains. Transaction performance is strictly constrained by network bandwidth and block confirmation times. For instance, Bitcoin [3] typically processes an average of 7 transactions per second (TPS), while Ethereum [4] ranges between 15 and 45 TPS. In stark contrast, national lotteries require processing capabilities that are orders of magnitude higher. The Taiwan Lottery [27], for example, issues approximately 2 million tickets per game session. Similarly, the Mega Millions Lottery [28] in the United States can exceed 10 million tickets per draw. Processing such massive volumes of betting data directly on Ethereum would not only be sluggish but would likely consume the majority of the network’s bandwidth, causing congestion for all other decentralized applications.

Closely related to this throughput bottleneck is the issue of prohibitive costs. Public blockchains operate on a fee market; when demand for block space exceeds supply, transaction fees (gas) skyrocket. Uploading millions of individual lottery receipts to the mainnet would incur astronomical handling fees, rendering the lottery business model economically unviable. Therefore, a practical solution must find a way to verify millions of bets without paying for millions of on-chain transactions.

Furthermore, a lack of dispute resolution mechanisms poses a critical governance risk. While the immutability of the blockchain is a core security feature, it becomes a liability when errors occur (e.g., oracle malfunctions or data unavailability). In a fully autonomous smart contract, if an execution anomaly arises, the result is typically irreversible. Without a designed “escape hatch” or appeal process, victims of system errors or malicious service provider omissions have no recourse. This rigidness contrasts with the need for a system that is both tamper-evident and capable of rectifying proven discrepancies.

In summary, current blockchain-based lotteries are unsuitable substitutes for existing games due to these performance, cost, and governance limitations. Consequently, the goal of this research is to devise an auditable scheme that retains the trust-minimizing properties of blockchain while solving the critical problems of throughput and dispute resolution.

4. The Proposed Auditable and Trusted Lottery System

4.1. System Architecture

This section presents an auditable universal lotto game mechanism combined with the public blockchain. The system architecture is shown in Figure 1. The proposed system involves the following entities: game service provider (SP), smart contract, and player. The game service provider and player have the following public and private key pairs: (Pri(SP), Pub(SP)) and (Pri(Player), Pub(Player)), respectively. [O]_Pri(x) is used to denote a digital signature of data object O that is generated by the private key of a subject x, and data objects within square brackets that are separated by commas are first connected and then have cryptographic operations performed on them.

Figure 1 depicts the high-level architecture and interaction flow among these entities. This design leverages the TP-Merkle tree to decouple high-volume betting data from the blockchain while maintaining auditability. The detailed operational workflow derived from this architecture is presented in Section 4.4, and the corresponding implementation-level message exchanges are documented in Appendix A.

4.2. Transaction Positioned Merkle Tree

The blockchain bandwidth problem can be tackled using a Transaction Positioned Merkle Tree (TP-Merkle tree) [1,2] to structure the data and store betting information. Structuring data this way allows a high volume of betting information to be compressed into a 32-byte format. Merkle tree type data structures employ unique signatures and sets of messages for authentication. An intended verifier can establish a single message’s authenticity while maintaining the secrecy of the other messages, which are not disclosed. Bottom-up recursive computation is used to construct the Merkle tree associated with a given set of messages M = {m₁, …, m_n}. To begin, every message m ∈ M sees a distinctive leaf containing the hash value of m added to the tree. Next, each internal node has a value associated with it that is equal to h(h_l||h_r), where h_l||h_r stands for the concatenation of all hash values associated with the left and right child nodes, respectively, where h() is a hash function. Thus resulting binary hash tree’s root node is therefore a digest of all the messages, which means it can be signed digitally via a standard signature technique.

In Figure 2 we have a TP-Merkle tree based on a Merkle tree [29] with a position function added to it. The tree’s height is set before any data is stored, with the leaf node being capable of storing multiple data in distinct key-value pairs (e.g., key, value). The positioning is handled by the “IndexValue” key parameter, with its value being the actual data. We call all key-value pairs beneath any leaf node its corresponding list of key-value pairs, with each pair’s leaf node position being easily obtainable if the IndexValue parameter is passed into the Index Function Γ, which is defined in Equation (1):

$$\mathsf{\Gamma }\left(IndexValue\right)=\mathrm{S}\mathrm{H}\mathrm{A}256\left(IndexValue\right) \mathrm{m}\mathrm{o}\mathrm{d} 2^{N-1}$$

(1)

where N is the tree height, such that 2^N−1 lets us obtain the tree’s total number of nodes. A modulus operation guarantees a pair’s leaf node position does not exceed the tree’s total number of nodes. It is possible to find the corresponding data through IndexValue when the data is stored in this fashion.

4.3. Merkle Proof: Slice

Looking at Figure 3, we see that Slice provides crucial evidence for verification in a TP-Merkle tree. More specifically, every leaf node has a corresponding Slice and assumes the form shown in the figure, with newly arrived betting information slotted into a leaf node with ‘X’, called Slice.

The Slice comprises not only the leaf node, but also the hash values associated with all the sibling and parent nodes. Verification of data only requires calculation of the Slice in a bottom-up direction. It is feasible to verify data correctness by recomputing the root hash from a Merkle proof (Slice) and comparing it with the committed root hash recorded previously. Put another way, there is no need to store all the hash values, since obtaining the Slice where the data in question is located for this purpose. Millions of lottery betting tickets can be stored on a TP-Merkle tree, and players of lottery betting tickets are able to confirm their locations via the Index Function. Once the location is obtained, the corresponding Slice can likewise be identified and audited. In particular, given the target leaf value and its Slice, any verifier can recompute the root and compare it against the on-chain commitment.

4.4. The System Workflow

Figure 1 summarizes the end-to-end workflow of the proposed auditable lottery system. The operation is organized into three logical phases: Phase I (Initialization and Betting), Phase II (Ledger Commitment and Data Availability), and Phase III (Verification, Appeals, and Settlement). This structure highlights how off-chain scalability is harmonized with on-chain accountability, where the betting ledger is recorded at scale in the TP-Merkle tree, while compact commitments and enforceable dispute handling are anchored to the public blockchain.

4.4.1. Phase I: Initialization and Betting

The process begins with the service provider (SP) deploying the required smart contracts on the public blockchain and publicly announcing the randomness source (or an externally verifiable drawing procedure) for the round. Before betting opens, the SP locks a margin in the contract to cover potential compensation in the event of a successful appeal.

During the betting window, each player submits a digitally signed betting request, M_request = {[Pub(Player), CO, IndexValue, Choose Number, Time Stamp]_Pri(Player)}. Upon receiving M_request, the SP verifies the player’s signature and validates acceptance conditions, including (i) the uniqueness of IndexValue, (ii) the validity of the round identifier CO, and (iii) the admissible range of Choose Number. If the request is accepted, the SP issues a digitally signed receipt, M_reply = {[M_request, Result, SN, Accumulate Bet, Time Stamp]_Pri(SP)}, which serves as non-repudiation evidence for subsequent verification and appeals. For clarity, we denote the signed receipt by SR (i.e., SR = M_reply). When a compact identifier is needed (e.g., for on-chain duplicate detection), we use ReceiptID = H(SR).

Concurrently, the SP records each accepted bet off-chain by inserting a signed key-value pair {[IndexValue, SR]_Pri(SP)} into the TP-Merkle tree at the deterministic leaf position defined by Γ(IndexValue). This ensures stable indexing for efficient later verification while keeping the ledger off-chain.

4.4.2. Phase II: Ledger Commitment and Data Availability

Once the betting window closes, the SP finalizes the TP-Merkle tree (bottom-up hashing) and derives the root hash for the entire ledger. To anchor the off-chain ledger immutably, the SP commits to the smart contract three round-critical items: (i) the root hash, (ii) the accumulated jackpot/bonus after rake, and (iii) the last receipt of the round. This on-chain commitment fixes the round state and provides a public reference for all subsequent verification.

To enable independent auditing without imposing prohibitive on-chain storage costs, the SP packages the complete TP-Merkle tree, signs the package, and publishes it to a decentralized storage network such as IPFS [30] (or an equivalent P2P file system). In addition, participants may obtain standardized cryptographic evidence from the SP for a given round CO in the following unified format: E = {[Slice, List of Key-Value Pairs, CO]_Pri(SP)}, where Slice is the Merkle proof information for the corresponding leaf, and List of Key-Value Pairs contains the leaf entries for the specified round CO. In the remainder of this section, we use E to denote this evidence package uniformly.

4.4.3. Phase III: Verification, Appeals, and Settlement

Within a predefined audit window, any participant (players or third-party auditors) can verify the round by downloading the published TP-Merkle tree and checking consistency against the on-chain root hash and associated round metadata. Implementation-level message exchanges and step-by-step operational details corresponding to Figure 1 are provided in Appendix A to facilitate independent reproduction. If irregularities are detected, the participant may invoke the automated appeal mechanism by submitting the signed receipt(s) SR and the corresponding evidence package E = {[Slice, List of Key-Value Pairs, CO]_Pri(SP)}, together with a deposit. The deposit is refunded upon a successful appeal and forfeited otherwise, which discourages spam and economically irrational challenges.

To avoid repetitive textual enumeration of appeal variants, we summarize the principal appeal categories and smart-contract adjudication logic in

Table 1. Classification of appeal scenarios and smart-contract adjudication logic.

Scenario (A–E)	Description of Inconsistency	Evidence Submitted by Appellant	Smart-Contract Adjudication Logic (High Level)
(A) Data omission (missing receipt in committed ledger)	A valid signed receipt exists but is missing from the committed TP-Merkle ledger for the round.	SR; E = {[Slice, List of Key-Value Pairs, CO]Pri(SP)}; and CO.	Verify signatures on SR and E; validate Slice against the on-chain root for CO; confirm that ReceiptID = H(SR) is not present in the corresponding List of Key-Value Pairs while the recomputed root matches the on-chain root; record ReceiptID on-chain to prevent duplicate appeals.
(B) SN discontinuity	Receipts show duplicated SNs or gaps (skipped SNs) within the round.	Two signed receipts SR(i−1) and SR(i) demonstrating the duplication/gap; and CO.	Verify signatures; check SN continuity/consistency between SR(i−1) and SR(i) under CO; enforce penalty/compensation if inconsistency is proven; record the involved ReceiptID values on-chain to prevent replay appeals.
(C) IndexValue duplication	Multiple receipts carry the same IndexValue within a round, violating the IndexValue uniqueness rule.	Conflicting signed receipts SR(i) and SR(j) with the same IndexValue; and CO.	Verify signatures; confirm duplicated IndexValue within CO; enforce the uniqueness rule and associated penalty/compensation; record the involved ReceiptID values on-chain to prevent repeated appeals.
(D) Insufficient bonus commitment	The on-chain committed bonus is inconsistent with the accumulated bet implied by signed receipts (e.g., the last receipt of the round).	Relevant signed receipt(s) SR (typically the last receipt); and CO.	Verify signatures; compare Accumulate Bet in SR with the bonus metadata committed on-chain for CO; accept the appeal if a discrepancy is demonstrated; record ReceiptID on-chain to prevent repeated submissions.
(E) Accumulated bet record error	Accumulate Bet values recorded in receipts violate the expected progression across adjacent receipts.	Two signed receipts SR(i−1) and SR(i) (adjacent context); and CO.	Verify signatures; validate Accumulate Bet progression/consistency constraints using SR(i−1) and SR(i) under CO; accept the appeal when the recorded value violates expected progression; record the involved ReceiptID values on-chain to prevent replay appeals.

, while adopting the same notation used in Appendix A (i.e., SR (=M_reply), ReceiptID = H(SR), and E).

After the audit/appeal period concludes, the SP uploads the winning numbers to the smart contract within the specified time window. Since the primary objective of this study is to minimize blockchain costs and accommodate massive betting volumes, rather than to propose a novel randomness generation protocol, our proposed architecture remains flexible to accommodate various established methods. We commit to selecting a method that is recognized as fair by the academic community and publicly announcing the chosen mechanism in advance. Examples of such credible methods include a physical public drawing witnessed by lawyers, fair randomness generation utilizing blockchain cryptographic primitives such as Verifiable Random Functions (VRFs) [16,17], decentralized randomness beacons [18,19], or Verifiable Delay Functions (VDFs) [20,21,22], or generation based on publicly verifiable external data like stock market information. Winners then submit their receipts SR together with the corresponding evidence package E for registration. The smart contract verifies (i) receipt authenticity, (ii) consistency of E with the committed root for round CO, and (iii) winner eligibility, and records ReceiptID on-chain to prevent double claims. Once the registration period ends, eligible winners can withdraw the prize according to the payout policy encoded in the contract.

5. Experiment Results and Performance Analysis

We evaluated the proposed system’s scalability and practicality through a series of experiments. The analysis focuses on three critical dimensions: tree collision behavior, storage overhead, and on-chain economic viability. All experiments were conducted on a desktop machine equipped with an Intel^® Core™ i5-7500 CPU @ 3.40 GHz and 32 GB RAM.

Collision Analysis and Scalability Verification: To verify that our TP-Merkle tree can handle national-scale traffic (10 million bets) without performance degradation, we simulated the mapping of 10 million betting receipts into trees of varying heights (N = 17 to 25). The “collision” metric—defined as the number of distinct tickets mapping to the same leaf index—is crucial because it directly impacts the size of the Merkle proof (Slice) a player must download.

Table 2. The number of collisions in TP-Merkle trees with different heights.

Height	Number of Leaf Nodes	The Average Number of Collisions	The Smallest Number of Collisions	The Largest Number of Collisions
17	65,536	152	107	209
18	131,072	76	44	120
19	262,144	38	14	72
20	524,288	19	3	43
21	1,048,576	10	0	30
22	2,097,152	5	0	19
23	4,194,304	3	0	13
24	8,388,608	2	0	10
25	16,777,216	1	0	8

presents the collision statistics. As expected, collisions decrease exponentially as tree height increases. The results confirm the effectiveness of the Index Function (Γ). Even with highly correlated input patterns (e.g., sequential ticket purchases), the SHA-256 hashing distributes bets uniformly across the leaf space. Crucially for scalability, at a tree height of 23, the maximum number of collisions is only 13 tickets per leaf. This finding proves that even with 10 million active bets, the “List of Key-Value Pairs” returned to a user remains extremely compact, ensuring low-bandwidth consumption on the client side and validating the system’s capability to support high-volume throughput.

Storage Overhead and Practicality: We analyzed the storage requirements to determine the practical feasibility of deploying this system on commodity hardware. We serialized the TP-Merkle tree structure using Java’s ObjectOutputStream to measure the actual footprint. Figure 4 visualizes the storage trade-off between the SP and the players across different tree heights. As the orange line indicates, the SP’s storage requirement grows exponentially with tree height due to the increasing number of leaf nodes. Conversely, the blue line shows that the player’s proof size (Slice and Key-Value pairs) decreases as the tree gets taller, owing to fewer collisions per leaf.

Table 3. Storage required for the player and SP according to TP-Merkle trees of different heights.

Height	Player	SP
17	24,199 Bytes	1519 MB
18	14,473 Bytes	1534 MB
19	9257 Bytes	1564 MB
20	6131 Bytes	1625 MB
21	4765 Bytes	1747 MB
22	3619 Bytes	1990 MB
23	3023 Bytes	2476 MB
24	2757 Bytes	3452 MB
25	2601 Bytes	5372 MB

provides the detailed numerical data corresponding to this trend. Based on the intersection of these factors, we identify Height 22 or 23 as the optimal configuration for practical deployment. At Height 23, the Service Provider requires approximately 2.5 GB of storage. This is negligible for modern enterprise servers, proving that the SP can easily maintain the entire state in RAM for high-speed access or on standard SSDs. Simultaneously, the player only needs to store approximately 3 KB of data. This minimal footprint confirms that the system is practical for mobile devices, removing entry barriers for general users.

Gas Cost and Economic Viability: Finally, we evaluated the system’s economic efficiency by measuring gas usage on the Ethereum Testnet.

Table 4. Gas use associated with deploying the contract and performing its basic functions (We assume that the price of Ether is $100).

Function	Gas Use	Gas Price (Gwei)		ETH	USD
Deploy	4,133,255	Max	10	0.04133255	4.133255
		Avg	4	0.01653302	1.653302
		Min	3	0.012399765	1.2399765
Upload bonus	25,900	Max	10	0.000259	0.0259
		Avg	4	0.0001036	0.01036
		Min	3	0.0000777	0.00777
Upload root hash	47,467	Max	10	0.00047467	0.047467
		Avg	4	0.000189868	0.0189868
		Min	3	0.000142401	0.0142401
Upload the winning numbers	129,535	Max	10	0.00129535	0.129535
		Avg	4	0.00051814	0.051814
		Min	3	0.000388605	0.0388605
Auditing announce	68,844	Max	10	0.00068844	0.068844
		Avg	4	0.000275376	0.0275376
		Min	3	0.000206532	0.0206532
Receive the award	39,832	Max	10	0.00039832	0.039832
		Avg	4	0.000159328	0.0159328
		Min	3	0.000119496	0.0119496

Wei is the smallest denomination of ether. 1 Wei = 10⁻¹⁸ Ether, 1 Gwei = 10⁻⁹ Ether.

and

Table 5. Gas use associated with performing appeal functions. (We assume that the price of Ether is $100).

Function	Gas Use	Gas Price (Gwei)		ETH	USD
The receipt disappears from the TP-Merkle tree	333,992	Max	10	0.00333992	0.333992
		Avg	4	0.001335968	0.1335968
		Min	3	0.001001976	0.1001976
Insufficient bonuses	70,480	Max	10	0.0007048	0.07048
		Avg	4	0.00028192	0.028192
		Min	3	0.00021144	0.021144
IndexValue duplicate	137,734	Max	10	0.00137734	0.137734
		Avg	4	0.000550936	0.0550936
		Min	3	0.000413202	0.0413202
IndexValue skips number	306,408	Max	10	0.00306408	0.306408
		Avg	4	0.001225632	0.1225632
		Min	3	0.000919224	0.0919224
SN duplicate	109,826	Max	10	0.00109826	0.109826
		Avg	4	0.000439304	0.0439304
		Min	3	0.000329478	0.0329478
SN skips number	114,967	Max	10	0.00114967	0.114967
		Avg	4	0.000459868	0.0459868
		Min	3	0.000344901	0.0344901
Accumulated bet record error	144,399	Max	10	0.00144399	0.144399
		Avg	4	0.000577596	0.0577596
		Min	3	0.000433197	0.0433197

Wei is the smallest denomination of ether. 1 Wei = 10⁻¹⁸ Ether, 1 Gwei = 10⁻⁹ Ether.

detail the costs for operational transactions and appeal functions, respectively. For the Service Provider, the cost to commit a round is dominated by uploading winning numbers (approx. $0.129 USD) and the root hash (approx. $0.047 USD). The significance of this result lies in the system’s O(1) on-chain complexity: unlike traditional blockchain lotteries where gas is paid per ticket, in our system, gas costs are incurred per round rather than per ticket. Whether the round has 100 bets or 10 million bets, the on-chain cost remains effectively constant, driving economic scalability. For players, the cost to launch an appeal is roughly $0.33 USD. This low barrier ensures that the “Trust but Verify” model is economically rational. Since the compensation for a valid claim exceeds the appeal cost, players are incentivized to audit the SP, creating a robust decentralized supervision mechanism without prohibitive fees.

Comparative Advantage and Scope of Comparison: To evaluate the efficiency of our hybrid architecture, we selected BanFEL [8] as the primary baseline, as it represents the standard “fully on-chain” paradigm. We excluded other related works mentioned in Section 2 from this quantitative analysis because they serve different purposes: VRFs and beacons are component-level primitives rather than full-stack betting architectures, while other systems lack reproducible metrics (e.g., Quanta), rely on theoretical hardware, or focus on regulatory frameworks rather than throughput. Consequently, BanFEL remains the most suitable representative for benchmarking operational efficiency.

Table 6. The number of interactions with the smart contract.

Function	Our Proposed Scheme	BanFEL [8]
Betting	X	1,000,000
Random number selection	X	1,000,000 + 1
Upload the margin	1	X
Upload the bonus	1	X
Upload the root hash	1	X
Upload the last receipt	1	X
Announce auditing the correctness of the game	1	X
Make appeals	0	X
Upload the winning numbers	1	X
Receive award	K	K
Total	K + 6	K + 2,000,000 + 1

‘X’ means unnecessary.

compares the interaction density of our architecture with BanFEL. While BanFEL requires over 1 million on-chain interactions for a similarly sized game (due to its O(n) complexity), our system requires only K + 6 interactions (where K is the number of winners). This drastic reduction in blockchain interaction density confirms that our hybrid architecture successfully eliminates the bottlenecks identified in previous full-stack designs.

6. Security Analysis and Discussion

In this section, we analyze the security properties of the proposed lottery architecture. We define the threat model and explicitly discuss how the integration of the TP-Merkle tree, digital signatures, and the smart-contract-based appeal mechanism ensures Integrity, Authenticity, Unpredictability, and Robustness against adversarial behaviors.

6.1. Threat Model and Trust Premises

We consider a threat model involving three primary actors. First, a Malicious Service Provider (SP) may attempt to maximize profit by forging fake winning tickets, selectively deleting valid user receipts (censorship), reordering transactions to alter the Merkle root, or manipulating the winning number generation. Second, Malicious Players may attempt to double-claim prizes, submit forged receipts, or perform replay attacks using tickets from previous rounds. Finally, Network Adversaries may attempt Denial-of-Service (DoS) attacks against the smart contract.

Our security analysis relies on two standard security premises. First, the underlying Ethereum blockchain provides immutable storage and deterministic execution of deployed smart contracts. Second, we rely on standard cryptographic properties: the SHA-256 hash function is collision-resistant and the digital signature scheme provides existential unforgeability.

6.2. Integrity and Authenticity of Betting Receipts

Formally, let L denote the valid ledger of bets, R represent the committed Merkle root, and π denote a Merkle proof path (referred to as a “Slice” in Section 4.3) consisting of the sibling hashes required for verification. We formally define Ledger Integrity as the guarantee that it is computationally infeasible to find a modified ledger L’ ≠ L such that its Merkle root Merkle(L’) equals the committed root R. Furthermore, regarding Authenticity, let SR be a receipt and σ be its corresponding digital signature. The property ensures that the verification function Verify_Pub(SP)(SR, σ) returns true only if the service provider actually signed SR.

The system satisfies these properties through a robust Commitment Scheme. The SP acts as a prover who commits to the entire dataset of millions of bets by uploading a single Root Hash to the smart contract (see Section 4.4.2 (Phase II)). Because the root is a cryptographic digest of the TP-Merkle tree, any modification to a leaf node—whether changing a bet’s content or its position—will propagate up to change the root. This provides Tamper Evidence; if the SP attempts to secretly alter a bet after the round closes, the new root hash will not match the immutable root stored on the blockchain. A player holding a signed receipt SR can detect this via Merkle proof (Slice) verification by proving that the path π_i satisfies Verify(R, SR, π_i) = true. Furthermore, Non-Repudiation is enforced via digital signatures. The receipt is explicitly structured as SR = {[M_request, Result, SN,…]_Pri(SP)}, which encapsulates the player’s original request signature. Thus, the SP cannot deny issuing a valid ticket, nor can they generate a valid ticket on behalf of a user without the user’s private key signature on the request. When a compact on-chain identifier is needed (e.g., to prevent duplicate claims), we use ReceiptID = H(SR). With ledger integrity anchored by an on-chain commitment, we next examine whether the service provider can selectively withhold valid receipts before commitment.

6.3. Protection Against Censorship and Data Withholding

Formally, let L be the committed ledger consisting of a sequence of receipts {r₁, r₂, …, r_N}. Censorship Resistance implies that for every valid index i, there must exist a receipt r_i in L such that its Serial Number, denoted as SN(r_i), equals i. Any omission in this sequence must be provable.

To enforce this, we implement strict Serial Number (SN) Continuity. Each receipt contains a sequential Serial Number (SN) and Clearance Order (CO). Since the full TP-Merkle tree (including the signed receipt SR in each leaf entry) is public on IPFS, auditors can directly inspect receipts and verify that the SNs form a continuous sequence 1, 2, ..., N for a given round. This transparency facilitates gap detection; if the SP deletes a winning receipt, it creates a verifiable “gap” in the sequence. Any user or auditor can submit adjacent receipts to the smart contract to prove that a number was skipped (“SN skips number” appeal), automatically triggering a penalty. Additionally, Inclusion Proofs protect against individual data withholding. If the SP issues a receipt but fails to record it in the Merkle tree, the user can execute a “Receipt not recorded” appeal by presenting the signed receipt, forcing the smart contract to compensate the user. Beyond completeness of recording, the system must also prevent adversaries from reusing valid receipts to claim rewards multiple times or across rounds.

6.4. Resistance to Replay and Double-Spending

Formally, let S_spent represent the set of receipts that have already been redeemed. Uniqueness requires that if a user attempts to claim a prize with a receipt r, two conditions must hold: first, the hash of the receipt H(r) must not be present in S_spent (Double-Spending Protection); and second, the receipt’s Round Identifier, denoted as CO_r, must match the current round identifier CO_current (Anti-Replay).

These properties are enforced via Unique Binding and Stateful Tracking. Each betting request contains a Time Stamp and a Round Identifier (CO) signed by the player. This specific binding prevents a malicious player from re-submitting an old winning ticket in a new round, as the CO will not match the current contract state. Furthermore, when a prize is claimed, the smart contract records the hash of the winning receipt. Any subsequent attempt to claim with the same receipt is automatically rejected by checking this on-chain state, effectively preventing double-claiming. Finally, we consider operational robustness and show how the design avoids denial-of-service amplification while keeping on-chain verification costs predictable.

6.5. Robustness Against Denial-of-Service (DoS)

Formally, let C_verify be the computational cost required for verification and C_attack be the cost incurred by an adversary to execute an attack. System Robustness ensures that C_verify remains significantly lower than C_attack (i.e., C_verify ≪ C_attack), thereby maintaining availability even under congestion.

The system prevents gas exhaustion through Off-Chain Computation. Heavy verification tasks, such as checking millions of leaf nodes, are performed off-chain by auditors. The smart contract only verifies short Merkle proofs (Slices) during an appeal, maintaining an on-chain verification cost of O(N), where the tree height N is a fixed system parameter, and low costs (approx. $0.10–$0.33 USD per appeal). This technical efficiency is reinforced by Economic Deterrence. Appellants must deposit a fee that is returned with a reward only if the appeal is valid. This mechanism makes large-scale DoS attacks financially unsustainable for attackers while keeping the system accessible for honest users.

6.6. Summary of Security Guarantees

In summary, our security analysis demonstrates that the proposed system effectively bridges the gap between centralized efficiency and decentralized trust. By securing the betting ledger with a compact TP-Merkle commitment, we eliminate single points of failure regarding data manipulation and unauthorized censorship. Furthermore, the integration of an automated, smart-contract-driven appeal mechanism transforms the Service Provider’s accountability from a mere promise into a cryptographically enforceable guarantee. The combination of cryptographic hardness (SHA-256, Merkle proofs) and economic deterrents ensures that malicious behaviors—whether by the SP or players—are not only technically detectable but also economically irrational. Collectively, these measures ensure that the system satisfies the rigorous requirements of Integrity, Authenticity, and Fairness, making it a viable and trusted solution for national-scale lottery operations.

7. Conclusions

For both traditional lotteries and online betting, the gaming industry has no choice but to rely on a centralized structure that is overseen by a unitary organization. Until now, blockchain-based lottery games were largely impracticable owing to the high-trust public blockchain being unable to handle the issuance of a large number of lottery betting tickets. We solve this problem by leveraging the TP-Merkle tree’s data structure. Specifically, a deposit system is set up via smart contracts with TP-Merkle trees to generate cryptographic evidence and provide an indemnification system that is fully automated. The end result is the smart contract constituting a trusted third party, which enables players to be able to verify the lottery games’ legitimacy.