System and method for implementing a blockchain-based lottery and betting system using digital transactions

Abstract

This invention discloses a decentralized system and method for lottery and betting events using single-transaction participation on a distributed ledger network (e.g., a blockchain). Each participant merges payment and selections into a single on-chain record, either a Lottery Ticket Transaction (LTT) or a Betting Ticket Transaction (BTT), thereby reducing complexity. Outcomes can be determined on-chain via a random generator or off-chain via external oracles or AI-based processes, with authorized wallets submitting verified results. The system automatically allocates multi-tiered prizes and can be configured with fixed or dynamic pricing, bridging, token swapping, or fallback scenarios. A pseudonymous mechanism preserves user privacy while maintaining transparent, immutable records. By eliminating separate payment and selection steps, the invention streamlines lottery and wagering operations, supports cross-chain interoperability, and scales effectively for both large- and small-scale game businesses. Optional AI modules, compliance interfaces, and zero-knowledge proofs further enhance fairness, security, and adaptability across diverse commercial contexts.

Description

System and Method for Implementing a Blockchain-Based Lottery and Betting System Using Digital Transactions

[0001] The present invention provides a comprehensive system and method for implementing lottery, betting, and other wagering events on a distributed ledger technology (DLT) network (for example, a blockchain). At its foundation, the system comprises several core components. First, one or more distributed ledger networks record transactions immutably, preserving transparency and security for all participants. Second, the invention leverages “single-transaction mechanisms”, referred to as a Lottery Ticket Transaction (LTT) for lottery-type games or a Betting Ticket Transaction (BTT) for betting-type games, to merge both a participant’s monetary stake (ticket price or wager) and game-specific data (for example, selected lottery numbers, betting options) in a single on-chain record. These transactions include all ticket details, such as ticket price, selected numbers, and wager amounts, and are publicly visible in real-time. Third, decoding and validation modules (for example, smart contracts or network-level protocols) parse the encoded transactions, enforce the game rules, and confirm each participant’s entry. Fourth, one or more draw processes determine or generate outcomes, whether through on-chain random number generators (RNG), external oracles or APIs, or AI-assisted physical draws, and transmit the winning result to the smart contract. Finally, an automated or semi-automated prize distribution process disburses winnings according to predefined rules, ensuring swift and auditable payouts. On top of these fundamental components, the invention supports dynamic pricing (where ticket costs may vary), partial-match structures (tiered prizes), fallback scenarios (for example, no-winner or oracle malfunctions), cross-chain bridging (enabling tokens and participants to operate across multiple blockchains), AI integrations, and token swapping functionalities. By consolidating all critical functionalities, ticket encoding, outcome generation, and prize distribution, into an immutable, decentralized ledger, the system minimizes administrative overhead, preserves participant anonymity, and achieves high scalability, thus modernizing and extending traditional lottery and betting processes in a manner that is secure, transparent, and adaptable to various regulatory and commercial requirements.

[0002] The present invention relates generally to decentralized gaming platforms implemented using distributed ledger technology (DLT), such as blockchain networks. More specifically, it pertains to systems and methods for conducting lottery and betting events, broadly encompassing wagering, gambling, promotional raffles, and other related games, using cryptographic and programmable transactions for improved transparency, security, user privacy, flexible compliance measures, complex encoding schemes, and simplified participant engagement.

[0003] Lottery and online gambling industries are intricate ecosystems involving multiple stakeholders, processes, and systems that aim to ensure fairness, efficiency, and profitability. Traditional lottery and gambling platforms, such as those used by Powerball, Mega Millions, or Bet365, often rely on centrally managed databases, proprietary ticketing systems, and trusted intermediaries. These centralized structures can introduce security vulnerabilities, lack of transparency, operational bottlenecks, and privacy concerns for participants. Large prize winners may face unwanted publicity or safety risks, and compliance with various regional and legal frameworks can be cumbersome or inconsistent. Additionally, complex payouts, multi-tiered prize splits, or referral-based rewards can become difficult to administer under purely centralized designs.

[0004] Prior attempts at incorporating blockchain into lottery or betting systems typically record on-chain the purchase of tickets or wagers in multiple transactions, track random draws using smart contracts or oracle services, and automate prize payouts. These approaches often involve multiple steps: participants submit a payment in one transaction and then separately provide their selected numbers or betting choices. Although these older systems improve transparency by registering tickets on a blockchain, they generally retain separate processes (for payment versus user picks) and do not address dynamic pricing or partial payouts within a single round.

[0005] By contrast, the present invention adopts a single-transaction mechanism that merges the participant’s stake (token amount) with the user’s numeric selections or betting parameters in a single token transfer (LTT / BTT). This integration avoids the multi-step nature of traditional systems by encoding both the monetary cost and the participant’s choices in the integer part, decimal part, or metadata fields of the same transaction. Furthermore, unlike prior blockchain lottery systems that fix the cost per ticket or do not incorporate user selections into the price, the disclosed invention supports dynamic or variable ticket pricing. Under this approach, the participant’s numeric choices, such as encoding “4657” in the integer portion, can determine the ticket’s cost, enabling proportional payouts and strategic decision-making. In addition, the disclosed encoding methods permit a single token transfer to carry multiple lottery or betting entries across different games simultaneously, letting a user participate in numerous events with one blockchain transaction. Prior approaches generally concentrate on a single game at a time, thereby missing the convenience of simultaneous multi-game entries.

[0006] Moreover, the disclosed system can be fully or partially integrated with existing traditional lottery and betting frameworks, preserving retailers and other third-party channels for sales and compliance. This hybrid approach, which retains the mechanical draw process or on-site ticket sales if desired, ensures local businesses and authorized entities remain engaged in the game flow. Unlike older DLT-based methods that often replace or bypass retailers entirely, the disclosed invention aligns on-chain transparency and automation with the proven benefits of established retail networks, making it adaptable to both large-scale lotteries and small-scale or specialized betting contexts. By combining a single-transaction model, dynamic pricing, partial-match payouts in one round, and multi-game encoding capability, all within a framework that can coexist with conventional systems, this invention solves the multi-step, multi-round burdens that characterize prior art, offering a more versatile and user-friendly solution.

[0007] The present invention provides a decentralized, blockchain-based system and method for conducting lotteries, betting events, and other wagering activities using a single-transaction mechanism. Participants initiate entries, referred to herein as Lottery Ticket Transactions (LTTs) or Betting Ticket Transactions (BTTs), that encode both the payment for entry and their selections or bets in one unified step, creating a streamlined, secure, and transparent environment. The system supports various pricing models, fallback scenarios, privacy measures, and cross-chain interoperability. By integrating smart contracts, flexible encoding techniques, cryptographic features, and compliance options, this invention substantially improves the efficiency, fairness, and scalability of traditional lottery and betting systems while preserving participants’ privacy.

[0008] A smart contract or underlying DLT logic validates participants’ entries, obtains outcome data via authorized entities, AI, oracles, or blockchain-based RNG methods, and automatically distributes prizes proportionally based on individual contributions and game rules. The invention supports both fixed and dynamic pricing models, multi-tiered prize structures (partial matches), multi-game aggregation within single transactions, fallback scenarios (for example, no winner or oracle malfunction), token swapping to other digital assets for flexible prize settlement, and compatibility with popular token standards and existing wallets.

[0009] Key Features of the Invention include, but are not limited to:Single Transaction Participation: Users enter lottery or betting games by initiating a single digital transaction on the blockchain network. This transaction encodes both the stake (ticket cost, wager amount) and the participant’s chosen numbers or betting options. By merging payment and selection into one step, the invention eliminates the need for separate processes and enhances overall efficiency.Flexible Encoding Methods: The system allows for multiple ways to embed a participant’s selections: in the integer part of the token amount, the decimal part of the token amount, the metadata of the transaction, or any combination of these fields.Fixed and Dynamic Ticket Pricing Models: Under a fixed pricing model, all participants pay the same amount for entry (for example, a lottery ticket fee). In a dynamic pricing model, ticket costs vary based on factors such as the chosen numbers, encoded value, or promotional strategies. This approach enables strategic participation, where certain selections may cost more but offer a potentially higher share of winnings.Prize Distribution Mechanism: A smart contract automatically calculates and distributes prizes to winners’ wallet addresses. This includes managing partial matches and fractional payouts to intermediaries or retail partners if desired. The prize allocation process is transparent and recorded on the blockchain, facilitating auditing and eliminating manual intervention.Compatibility with Traditional and Blockchain-Based Draws: The system supports draws conducted by traditional methods (for example, a mechanical or physical draw submitted via an authorized wallet) or blockchain-based RNG processes. Multiple RNG sources can be combined to enhance randomness, and switching between different draw mechanisms is facilitated by the same underlying platform.Enhanced Privacy and Security: All transactions are recorded on the blockchain, providing an immutable audit trail while preserving pseudonymity. Advanced cryptographic techniques, such as zero-knowledge proofs, can be employed to maintain confidentiality of winners’ identities, ensuring that jackpot or large-amount prizes can be claimed without requiring personal disclosures.Scalability, Adaptability, and Interoperability: The invention operates on public, private, or hybrid blockchains and integrates seamlessly with cross-chain bridges, external APIs or oracles, and AI modules. Compliance checks and regulatory requirements are optional and can be dynamically enabled or disabled, allowing platform owners to tailor the system to various jurisdictions. Encoding schemes and game configurations are also adjustable, catering to both large-scale lotteries and smaller, specialized games.Fallback and Recovery Procedures: Predefined fallback rules ensure business continuity and fair outcomes under abnormal conditions, such as no-winner scenarios, oracle malfunctions, partial refunds, or rules for invalid LTTs / BTTs (for example, those initiated LTTs or BTTs that do not meet the game’s encoding method). These rules may include rollovers or automated backup draws, all coordinated by the same smart contract logic.Significant Improvement in Transparency: By storing every participant’s ticket data (including selected numbers, betting options, and corresponding wagers) on the blockchain, the system allows existing and prospective players to review past entries. Moreover, the public can confirm whether the prize recipients are indeed the participants who submitted winning selections. This high level of transparency fosters user trust, aids in strategy development, and enables independent verification of the system’s overall accuracy and fairness.

[0010] Traditional lottery and betting ecosystems often rely on separate steps for payment and participant selection, creating inefficiencies and potential data mismatches. Centralized databases may compromise transparency, exposing the process to fraud, manipulation, or disputes. Moreover, participant anonymity can be difficult to preserve if winners must publicly claim prizes. In many existing systems, only the total prize pool is visible, and there is no way to inspect individual participant tickets, their chosen numbers, bets, or historical engagement across multiple games, thus limiting strategic insights for new or existing participants. Furthermore, conventional platforms often involve complex administrative or regulatory overhead, making it challenging for small businesses to launch or manage their own lottery or betting operations. Collectively, these issues diminish trust, limit the diversity of game designs, and reduce overall accessibility to both large-scale and smaller-scale operators.

[0011] The present invention leverages distributed ledger technology (DLT) to unify both the payment of entry fees and the participant’s number (or bet) selection into a single transaction, an LTT (Lottery Ticket Transaction) or BTT (Betting Ticket Transaction). This single-transaction approach ensures that all critical data, including ticket cost and chosen numbers or bets, is permanently and immutably recorded on-chain. By assigning each participant a pseudonymous wallet address, the system preserves real-world anonymity while allowing any observer to review that wallet’s historical tickets and strategies if they so choose. This enhanced visibility fosters transparency and strategic analysis, as participants can study previous entries, bet patterns, or lottery picks without revealing personal identities.

[0012] Smart contracts further automate prize distribution according to configurable rules set by game owners before a game commences. These rules can define fixed or dynamic pricing models, handle fallback scenarios (for example, no winners or oracle failures), and distribute rewards in multi-tier arrangements or to multiple recipients (such as retailers or third parties). Because everything is programmable at the smart contract level, the same invention can be adapted easily for large-scale businesses (for example, national lotteries or bets) or smaller-scale promotions run by cafés, retailers, or local businesses, eliminating the heavy bureaucratic burdens typically associated with traditional lottery licenses. The system also accommodates cross-chain bridging, AI-driven or oracle-driven outcome verification, advanced privacy measures (for example, zero-knowledge proofs), and flexible compliance modules. By consolidating data and processes into one secure, transparent ledger, the invention fundamentally upgrades both the operational and strategic potentials of modern lottery and betting platforms..

[0013] The following figures present various illustrative configurations and embodiments, in which like reference numerals indicate like elements. These drawings are not intended to limit the invention, but rather to show potential architectures and workflows consistent with the principles described herein.

[0014] presents a high-level schematic view of a distributed ledger network 101 hosting a lottery or betting system, including core elements such as a single-transaction mechanism (LTT / BTT) 102, smart contract / network logic 103, encoding / decoding components 104, outcome determination 105, and prize distribution 106. Optional modules 107-116 may be incorporated to enhance functionality without constraining the fundamental single-transaction architecture.

[0015] illustrates a sample operational flow in which a game owner 200 configures the platform 201-204, announces availability 205, and receives participant entries 207 via digital single-transaction submissions. A Game Explorer 211 logs these entries 212, after which participation ends 213, transitioning to an outcome determination phase 214 and subsequent prize payout 215.

[0016] continues fromat the conclusion of participation 213, depicting various outcome-determination methods 216-226, including AI-based real-world events or on-chain random draws, and culminating in an outcome transaction 223. This transaction activates prize distribution 215, wherein the system allocates tokens or coins to winners according to predefined rules. Transparency is maintained through the Game Explorer 211 and data fields 239-241, ensuring verifiable recordkeeping of participant information and prize assignments.Detailed Description

[0017] The following detailed description is presented to enable those skilled in the art to make and use the invention as contemplated by the inventors. This disclosure, including the accompanying drawings and examples, is provided for illustrative purposes and does not limit the scope, applicability, or configurations of the invention in any manner. Any reference to particular components, techniques, or embodiments is made only by way of example and should not be interpreted to impose limitations on the disclosure. Indeed, the features and principles described herein can be combined, separated, or arranged in different ways without departing from the essence of the invention as defined by the appended claims. References to “exemplary” or “illustrative” mean that a given feature or embodiment is intended only as a non-limiting example; such references do not imply that one implementation is preferred or more advantageous over another.

[0018] The invention is not bound by any theory presented in the background, summary, or detailed description. Those skilled in the art will readily recognize that various modifications, substitutions, and improvements may be made to the disclosed embodiments without departing from the spirit or scope of the invention. The appended claims, and any equivalents thereof, are intended to cover all such embodiments, variations, and modifications consistent with the broadest interpretation of the invention.

[0019] illustrates, in a high-level schematic form, a representative architecture of the disclosed lottery or betting system operating on a distributed ledger network 101. Within the DLT network boundary, the invention’s core components, such as a single-transaction mechanism (LTT / BTT) 102, network logic / smart contract 103, encoding and decoding functionality 104, outcome determination 105, and prize distribution 106, collectively enable even the most basic implementation to receive participant entries, verify selections and stakes, and automatically allocate rewards. The DLT network 101 and these in-network components constitute the fundamental elements of the invention. Every implementation of the invention is built upon the single-transaction mechanism (LTT / BTT) at the core 102, ensuring that all data and payment aspects are merged in one unified blockchain transaction. Surrounding these components are a series of optional modules, which can include, for example, interfaces for draw processes (physical 107 and / or DLT-based one 115), fallback scenarios, oracles, AI integrations, compliance checks, or retailer / referral logic. These small circles 107-116 reflect additional features and advantages that may be enabled as needed, but they are not strictly required for a minimal deployment. In addition, for simplicity,omits certain features that may nonetheless be implemented within the same architectural framework. Accordingly, the figure should be understood as a conceptual illustration only, rather than a precise or exhaustive depiction of all possible elements. Various alternative or additional configurations are possible, as will be described in the following paragraphs, and the invention is not limited to the particular arrangement of components or modules shown in.

[0020] In Physical Draw Process 107, the system receives real-world draw results, such as those generated by mechanical lottery equipment, through an authorized wallet address. This authorized wallet address may be controlled by an AI integration module 110, an oracle 111 or the platform owner. All transactions initiated from this wallet are recorded on-chain immutably for public monitoring or verification, this module ensures that traditional lottery methods can seamlessly feed outcomes 105 into the smart contract 103 for prize allocation. The Fallback Scenarios 109 module addresses any abnormal or unforeseen event, no-winner results, invalid entries, or external data feed interruptions, and enforces predetermined rules (for example, rolling over prize pools or issuing refunds). For flexible economic strategies, the Pricing Logic 108 module can switch between a fixed price for every ticket or bet and a dynamic price that adjusts based on user selections, promotions, or external variables.

[0021] Other modules enable further customization. Oracles 111 deliver off-chain or real-time data, such as sports scores, exchange rates, or randomized seeds, onto the blockchain, while AI Integrations 110 assist in tasks like validating physically drawn numbers (for example by using advanced event-based vision mechanisms). The APIs / External Interfaces 112 module allows third-party applications or partner systems to retrieve game data and participant records, enhancing accessibility and integration. Compliance Checks 113 support optional geolocation, age-verification, or know your customer (KYC) protocols using zero-knowledge proofs or external identity solutions. Retailer / Referral Logic 114 automates commissions or bonuses for third-party sellers or partners, and Token Swapping 116 gives the platform flexibility in managing prize tokens, permitting conversions into stable assets or other cryptocurrencies.

[0022] In practice, many different combinations of these modules are possible, and platform owners may enable or disable them based on regulatory constraints, commercial objectives, or technical preferences. This invention is therefore not restricted to a single or special implementation where only certain modules are included. The paragraphs and embodiments that follow provide more concrete examples, scenarios, and use cases, illustrating both core components and main features of the invention in greater detail.

[0023] Indepicts a simplified operational flow in which a game owner 200 initiates a blockchain-based lottery or betting platform by performing a Game Setup 201, which involves configuring the underlying hardware, software, and network infrastructure 202, deploying or customizing smart contracts 203 on a chosen distributed ledger protocol, and preparing any APIs or applications 204 necessary for participant access. Once the system is ready, the owner makes a public announcement 205 to inform potential users (participants, shown as 206) that the lottery or betting event is live. Each participant sends a digital single-transaction, an LTT (Lottery Ticket Transaction) or a BTT (Betting Ticket Transaction) 207, to the smart contract 208 for entry. Upon receiving these transactions, the smart contract performs decoding and validation 209 to confirm both the required stake (for example, tokens) and any participant-chosen data (such as lottery numbers or betting options). Real-time updates 210 enable observers to track how many transactions have been submitted, building transparency and trust in the ongoing game.

[0024] Below the validation process, a Game Explorer 211 displays these transactions, indicating, for example, “LTT1 / BTT1” or “LTT2 / BTT2,” each mapping to a distinct “Ticket” or game entry data 212. At the end of the participation phase 213, no further entries are accepted, and the system transitions into outcome determination 214, whether through a blockchain-based random process, a physical draw, or an authorized oracle feed, followed by prize payout 215 according to the rules predefined in the smart contract logic. This figure depicts a simple, minimal embodiment of the invention, showing how participants can seamlessly join the lottery or betting system through a single transaction, while the platform owner retains control over game setup, configurations, and compliance with any applicable regulations or business policies.

[0025] Beginning at the end of participation phase 213 carried over from,shows how the system moves into outcome determination 214 and ultimately prize distribution 215. Three primary approaches are available for determining the outcome: (1) an AI integration 216 that leverages real-world events 217 (for example, traditional drawing process of a lottery game or a sport match event) captured by a camera or video feed 218 and processed by AI-based methods 219, (2) a smart contract integration 220 relying on a DLT-based draw 221 and other verified blockchain-based solutions 222, or (3) a manual approach where the game owner 200 obtains results (for instance, watching a sports match at 225) and then submits an outcome transaction (226 to 223) from an authorized wallet address. Regardless of which path is taken, an outcome transaction 223 is generated, then forwarded 227 to the Smart Contract / Network Logic 230, which correlates the new outcome with the existing participant data 228 referencing LTT / BTT entries 212. This design allows the owner or authorized entities to inject off-chain or real-world results as needed, while still supporting fully on-chain or AI-assisted draws for maximum flexibility.

[0026] Once the outcome is recognized, the system initiates prize distribution 215, during which the smart contract automatically searches over recorded LTTs / BTTs to find winners, calculates and allocates tokens to them based on the game rules and any further settings from additional modules 231. As indicated by the transactions at 237, each participant’s entry (Transaction1, Transaction2, etc.) yields a corresponding prize (Prize1, Prize2, …) if they exist among the winners (winner1, winner2,..). The process is entirely transparent: the Game Explorer 211 displays ticket information 239 (for example, participant’s chosen numbers or betting parameters), participant wallet addresses 240, and the resulting winner wallet addresses 241. By matching those three data sets, any observer, be it the public or a third-party auditor, can verify precisely which participant choices led to which outcome and track the resulting token transfers on-chain. This final phase 215 thus ensures that payouts occur trustlessly and are permanently recorded, reflecting the unified combination of on-chain logic, optional AI or oracle feeds, and any manual inputs from the game owner or authorized entities.

[0027] This invention broadly comprises a distributed ledger network, such as a blockchain, on which one or more smart contracts facilitate lottery or betting events. Participants make use of single-transaction submissions, referred to here as LTT (Lottery Ticket Transaction) or BTT (Betting Ticket Transaction), which encode both the participant’s stake (for example, a token amount) and any chosen numbers or betting parameters. A validation module (often implemented as part of the smart contract) parses these submissions, confirms that the required stake has been transferred, and records the entries on-chain. Outcome determination can occur through various draw mechanisms or RNG sources, potentially assisted by oracles or AI-based modules that feed the result data into the contract. Once outcomes are recognized, a prize distribution module automatically calculates rewards, redistributing tokens to winners’ wallet addresses, and optionally allocating commissions or referral bonuses as configured. Fallback logic (for example, rollovers or refunds) and dynamic pricing features are also supported. The paragraphs that follow define key terms and concepts, such as “LTT / BTT,” “smart contract,” “token amount,” and “DLT”, and illustrate how these elements interrelate within the invention’s technical framework, including details on token standards, encoding methods, and error-handling strategies

[0028] Lottery Ticket Transaction (LTT) and Betting Ticket Transaction (BTT) are terms used throughout this disclosure to describe a special type of digital single-transaction submitted on a distributed ledger network (for example, a blockchain) for purposes of entering a lottery, betting, or analogous wagering event. In an LTT, the participant encodes lottery-specific selections (for example, chosen numbers) and any associated ticket cost directly into the transaction parameters, whereas in a BTT, the participant encodes betting-related data (for example, wager amount, outcome choices, or betting option codes). Both LTTs and BTTs typically include a “transaction amount,” which denotes the token or coin value transferred from the participant’s wallet address (or from retailer’s wallet address) to the designated game contract or operator’s address. This transaction amount may also be referred to as the “game token” value, insofar as it represents the stake or contribution made by the participant to enter the relevant lottery or betting game.

[0029] By “transaction amount,” this specification broadly includes any numeric value recognized by the blockchain or DLT system as the token or coin quantity transferred in a single transaction. For example, if a participant chooses four lottery numbers and must pay ten tokens to enter, that participant might send 10.05122338 tokens in one transaction, with “10” indicating the mandatory cost (or fixed ticket price) and “.05122338” encoding the chosen numbers. This single transaction is deemed an LTT. Similarly, a betting scenario might use 50.1 tokens for a wager on an outcome code “.1,” thus creating a BTT. In these examples, “10.05122338,” “50.1,” and analogous formats all constitute a “transaction amount,” the numeric value of tokens or coins transferred in the transaction, which simultaneously carries game data in the integer, decimal, or metadata fields. Further details on how token standards, dynamic pricing, or promotional logic can influence the transaction amount are discussed in following descriptions.

[0030] In some implementations, “game token” or “token” references a digital asset specifically issued or recognized for participation in the disclosed games (for example, a lottery token, a betting token, or a utility token conforming to blockchain standards such as ERC-20). The “transaction amount” in each LTT or BTT is not limited to any particular token standard or currency type; it may include cryptocurrencies, stablecoins, or other digital assets acceptable to the platform or recognized within the DLT environment. Moreover, the participant’s chosen “transaction amount” may be influenced by dynamic pricing logic, promotional discounts, or real-time exchange rates provided by oracles. These details ensure that both the stake (ticket cost or wager) and any encoded selections can be adjusted to reflect diverse economic models, while remaining consistent with the single-transaction encoding principle. For a broader discussion of the various token names and network types that can be used, please refer to the following paragraph.

[0031] As used in this disclosure, the terms “token,” “coin,” “game token,” “game coin,” “token of game,” or any similar expressions are employed interchangeably to describe digital assets recognized by the system for participating in lottery, betting, or analogous wagering events. The invention does not limit these assets to a specific blockchain standard or network protocol; they may operate on Ethereum (ERC-20 or ERC-721), Solana, Tron (TRC-20), Bitcoin, Ripple, sidechains or Layer-2 solutions, or any other DLT infrastructure, including private, consortium, or hybrid blockchains. They may also take the form of non-fungible tokens (NFTs) if configured by the platform owner. Regardless of the standard or network type, participants must hold a sufficient balance of the relevant asset, fungible or non-fungible, to meet the game’s entry requirements (for instance, paying a fixed ticket price or placing a wager). The system remains network-agnostic and asset-agnostic, provided the underlying DLT can securely identify, transfer, and record these tokens or coins for use in single-transaction mechanisms (LTTs or BTTs). This flexibility allows platform owners to define, issue, or integrate different token types and standards based on technical capabilities, regulatory considerations, and business strategies, without departing from the spirit or scope of the invention. As described herein, whenever the terms “blockchain,” “blockchain technology,” or “blockchain network” are used, they are intended merely as examples of “distributed ledger technology (DLT),” and the invention may employ any form of DLT capable of providing the desired transparency, security, and immutability.

[0032] Thus, the terms LTT and BTT herein collectively refer to a participant’s single, encoded transaction, incorporating both the required stake and any game-specific selections or parameters (lottery numbers, betting options, etc.). By merging the numeric token value (the “transaction amount”) with game data in one transmission, the system achieves a streamlined, user-friendly, and transparent approach to entering and managing lotteries, betting events, and other wagering activities on a distributed ledger network.

[0033] As used herein, an “invalid LTT” (Lottery Ticket Transaction) or “invalid BTT” (Betting Ticket Transaction) refers broadly to any transaction that does not meet the specific encoding method requirements or game rules set forth by the platform owner. This may include transactions in a fixed-price model that fail to encode the exact number of required token amount (for instance, exactly 10 tokens), or transactions that use an invalid or out-of-range code for betting options or transactions with incorrect format of metadata field. While such transactions fall outside the defined parameters and are therefore labeled “invalid,” the invention does not mandate that smart contracts automatically reject all invalid LTT / BTT entries. Instead, acceptance or rejection depends on configurations and pre-configured logic determined by a platform owner’s business model, compliance needs, or promotional strategies. For instance, in some embodiments, LTTs encoding more than the required token amount (for example, 11 or more tokens) may still be accepted and counted as valid tickets, whereas LTTs encoding less than 10 tokens might be rejected or left unconfirmed. The examples provided here are merely illustrative, and the scope of this patent is not limited to these particular rules or outcomes. Platform owners retain the flexibility to define or modify such rules, whether to accept, reject, partially confirm, or apply any alternative procedure, so long as the chosen configurations remain consistent with the invention’s overarching single-transaction framework and decentralized operational logic

[0034] As used herein, the terms “betting game,” “bet game,” “gambling event,” or similar expressions refer broadly to any type of wager-based or gambling-related activity that may occur within the scope of the invention. This includes, but is not limited to, lotteries, sports betting, prediction markets, casino-style games (poker, blackjack, roulette), skill-based competitions, raffles, sweepstakes, and any other scenario where participants risk something of value (tokens, coins, digital assets) in hopes of winning a prize. The invention is not limited to traditional lottery or betting formats; it encompasses all types of online gambling and wagering events, whether chance-based, skill-based, or a combination thereof, and applies to current and future variations of such games.

[0035] As used herein, the term “RNG” (Random Number Generation) or “RNG methods” refers broadly to any mechanism, algorithm, process, or system capable of producing random or pseudo-random values that are used to determine outcomes, winning numbers, or other events within the invention’s lottery, betting, or gambling contexts. RNG methods may include on-chain algorithms that leverage block hashes or other blockchain-derived randomness, off-chain services verified via oracles, hardware-based random number sources, cryptographic techniques, threshold signatures, verifiable delay functions (VDFs), or any other approach ensuring unpredictability and fairness. The invention is not limited to a particular RNG technique and encompasses current and future methods of generating randomness suitable for ensuring impartial and tamper-resistant outcome determination in DLT-based gaming environments.

[0036] As used herein, the term “AI” (Artificial Intelligence) refers to any computer-based system, software, algorithm, or technique capable of performing tasks that typically require human intelligence, such as interpreting visual inputs, analyzing data patterns, making predictions, or autonomously verifying information. AI may encompass machine learning models, computer vision systems, natural language processing engines, pattern recognition algorithms, neural networks, or other technology capable of enhancing the decision-making, outcome verification, regulatory compliance checks, or security assessments associated with the invention. The use of “AI” is not limited to a particular approach, library, or platform, and includes both current and future developments in AI methodologies and tools. AI may operate off-chain or on-chain, interface with oracles and APIs, integrate with smart contracts, and contribute to various functionalities of the system, such as extracting winning numbers from a real-word event (for example a traditional draw or wagering event), verifying participant eligibility, or analyzing token flow patterns.

[0037] As used herein, the term “smart contract” refers broadly to any programmable, automated, or self-executing logic deployed on a distributed ledger technology (DLT) network or compatible infrastructure. While the term “smart contract” is commonly associated with platforms like Ethereum and their native contract languages (for example, Solidity), the present invention is not limited to a particular blockchain, language, or standard. “Smart contract” encompasses any on-chain logic, protocol-level code, chaincode, or equivalent mechanism that can validate transactions, implement game rules, enforce compliance, manage prize distributions, integrate with oracles, and perform related functions automatically and transparently. This definition also includes implementations on custom DLT networks, hybrid configurations that split logic between contract code and network-level code, as well as future developments or variations of on-chain logic and execution frameworks that serve equivalent purposes.

[0038] As used herein, terms such as “pool amount,” “stake amount,” “prize pool,” “wager contribution,” or other similar expressions refer broadly to the financial contributions made by participants into the collective fund from which prizes are allocated. While one term (for example, “pool amount”) may be used for simplicity, the invention is not limited to a specific term or payment model. These terms are intended to encompass various configurations, including but not limited to fixed-price entries, dynamic pricing models, pooled contributions from multiple participants, proportional allocations based on individual stakes, or hybrid approaches. The choice of terminology does not restrict the invention’s scope; rather, it provides a flexible framework that supports numerous implementations and interpretations consistent with the core principles disclosed herein.

[0039] As used herein, the terms “oracle” or “oracle-based” refer to a trusted data feed, service, or mechanism that supplies external information or computations to the distributed ledger (DLT) environment. An oracle may obtain data from off-chain sources, verify its authenticity and correctness, and deliver it on-chain for use by smart contracts or network logic. Oracles can handle various types of data, such as event outcomes, exchange rates, regulatory compliance indicators, geolocation data, random seeds for RNG mechanisms, or cross-chain proofs. They may employ cryptographic proofs, multi-signature validation, or reputation-based systems to ensure reliability and security. By interfacing with oracles, the invention can integrate real-world information, support compliance checks, enable cross-chain interoperability, and enhance functionality beyond the native capabilities of the DLT network.

[0040] In the context of the present invention, the terms “authorized entities,” “authorized wallet,” or any similar expressions refer to any individual, organization, or system that has been granted explicit permission or recognition by the platform’s governance rules, administrative functions, or smart contract logic to submit, sign, or verify data relevant to the lottery or betting process. This permission may be implemented via cryptographic whitelisting, digital certificates, private keys, or other secure identification mechanisms. For example, an authorized entity may be a designated lottery official, a trusted operator wallet address, an AI-based system whitelisted through a cryptographic signature, or an external oracle service that the smart contract recognizes as valid for providing outcome data. By limiting certain critical inputs (such as winning numbers or event results) to these authorized entities, the invention prevents malicious or unverified parties from injecting false information into the system. Any references in the claims or description to “authorized entities,” “equivalent authorized entity,” “authorized transaction,”or “pre-approved wallet address” should be interpreted in accordance with this definition.

[0041] As used in this disclosure, the terms “API,” “application programming interface,” “user interface,” “digital interface,” “game application,” “external interface,” “participant application,” “monitoring application,” or any similar expressions are employed interchangeably to describe any software-based or digital tool that enables users, whether participants, game owners, or third-party observers, to interact with the disclosed lottery or betting system. Such tools may be web applications, mobile applications, desktop clients, command-line utilities, or other accessible interfaces. Their functionalities can include (but are not limited to) providing user-friendly methods for participants to create or manage wallet addresses on the relevant distributed ledger network, submit single-transaction entries (for example, LTTs or BTTs), monitor game progress and final outcomes, retrieve statistics (including total stakes, real-time transaction counts, or winning numbers), and verify prize distributions recorded on-chain. These applications may also offer advanced features, such as swapping or trading tokens via external verified exchanges, performing compliance checks, displaying other participants’ public ticket data, or facilitating integration with third-party services. Although many of these capabilities can greatly simplify user engagement and visibility into the on-chain process, their inclusion remains optional and may be selectively enabled, disabled, or modified based on game rules, regulatory requirements, or the platform owner’s specific business goals.

[0042] The disclosed system covers a unified inventive concept wherein each feature, such as single-transaction participation, flexible encoding methods, oracle integration, AI-based verification, and fallback processes, contributes to a cohesive technical architecture. The same core mechanism, encoding participant selections within a single blockchain transaction and verifying these selections against a provable, on-chain or off-chain source of random or real-world data, underlies each embodiment. Even though certain embodiments may emphasize additional features, such as cross-chain bridging, dynamic pricing models, or compliance integrations, these functionalities enhance or extend the same foundational mechanism of secure, automated lottery and betting events. Thus, the system remains directed to a single overarching inventive principle: employing decentralized ledger technology to streamline, secure, and verify participation and payout processes in wagering contexts. Each optional feature (for example, cross-chain bridging) interacts seamlessly with the core invention and serves to refine or augment its technical operation rather than constituting a separate or unrelated invention.

[0043] To ensure that those skilled in the art can reproduce and implement the invention without undue experimentation, the specification provides detailed examples and explanations of how to construct and decode the single-transaction entries (LTTs or BTTs), configure authorized wallet addresses for outcome submission, and integrate oracles or AI services for reliable result data. For instance, when using a cross-chain bridge, the present system leverages cryptographic proofs or hashed time-lock contracts to verify token flows and outcomes across distinct blockchain networks. This level of detail demonstrates that standard cryptographic techniques are applied in a manner consistent with best practices for blockchain interoperability, thereby enabling a practitioner to adapt existing bridging solutions or code libraries to the disclosed architecture. Similarly, the disclosure outlines typical parameters (such as token decimal precision, data validation formats, outcome authentication steps, and potential fallback conditions) that demonstrate how each subsystem (smart contract, wallet interface, oracle feed, AI module) should be configured. These disclosures collectively ensure enablement by illustrating suitable protocols, algorithms, and procedures to replicate the invention’s functionalities in various implementations.

[0044] The system architecture often includes a blockchain or similar DLT network that stores every participant’s transaction (LTT or BTT) in an immutable ledger. Smart contracts or protocol-level code (collectively referred to as decoding and validation modules) parse the encoded data, extract chosen numbers or betting options, and verify compliance with game rules. These rules can incorporate fixed or dynamic ticket pricing, partial-match thresholds, fallback triggers, and optional compliance measures. Once validated, each participant’s entry is permanently recorded on the ledger, accessible for auditing and transparency. Users remain pseudonymous, as wallet addresses indicate participation without revealing personal data, although advanced cryptographic proofs (for example, zero-knowledge) or geolocation checks may be integrated if compliance is activated.

[0045] In a typical implementation, participants submit a single digital transaction, an LTT or BTT, to enter the game. Each transaction comprises a “transaction amount,” sometimes called “game token” value, transferred from the participant’s wallet address to a designated smart contract or operator address on the blockchain. This transaction amount carries not only the stake (that is, the cost of entering the event) but also encodes the participant’s specific selections (for example, chosen lottery numbers or betting options) in the integer portion, decimal portion, or metadata fields. As an example, a lottery participant paying a fixed ten-token entry fee might send “10.05122338” tokens to indicate a ten-token cost plus four chosen numbers (05, 12, 23, 38) in the decimal part. In a betting scenario, a participant could send “50.1” tokens, interpreting “50” as the wager amount and “.1” as the betting code (Team A to win). This single-transaction mechanism, whether labeled LTT or BTT, simplifies participant engagement and allows the system’s logic to decode and validate entries in an automated manner.

[0046] Encoding methods within each single transaction support integer part encoding, decimal part encoding, metadata encoding, or a combination thereof. In integer part encoding, a participant could incorporate both the selected numbers and the cost directly as a large integer (for example, “1234.00 tokens” for a dynamic lottery game where 1234 represents both a numeric string of chosen digits and the participant’s ticket price). Decimal part encoding is often preferred for fixed-price lotteries or encoding betting options, where the integer portion remains constant (for example, 10 tokens) and the decimal portion (for example, .05122338) stores participants’ selections. Metadata encoding can store additional data (for example, additional wallet address data or participants’ selection parameters), allow for complex multi-game references as well as develop complex LTTs / BTTs, though it may require more steps for the participant. In some instances, the system allows both integer and decimal portions plus metadata to be used together, facilitating customizable entries or simultaneous engagement in multiple events.

[0047] Ticket pricing can be either fixed or dynamic. In a fixed-price model, every participant pays the same amount (for example, 10 tokens), simplifying entry for traditional lottery formats. Conversely, dynamic pricing may vary the ticket cost based on factors such as the probability of chosen numbers, promotional strategies, or external data (for example, oracles providing exchange rates or event probabilities). Some embodiments grant participants who pay higher ticket prices proportionally larger shares of the prize pool. Such dynamic approaches encourage strategic thinking and a more engaging user experience. This concept extends to betting events, where the stake (bet amount) may be combined with an encoded betting option code.

[0048] The participation process differs slightly for lotteries versus betting events, though both rely on LTT / BTT transactions. In a lottery, participants typically select numbers according to predefined rules (for example, pick four numbers between 1 and 50) and encode them in the transaction. After submission, the smart contract or protocol logic validates the entry. For betting, participants choose from available outcomes (Team A, Team B, total points) and encode their bet along with the code for the chosen outcome. In either case, the system immutably records all entries. This transparency, plus the optional feature to view other participants’ entries, fosters trust and allows users to reference prior game history. Retailers or small businesses can adopt the same methods; for example, a café might let customers encode random ticket selections in a single transaction, with a portion of café loyalty tokens serving as entry. Larger conventional lotteries can implement hybrid solutions, retaining their mechanical draws while using blockchain for ticket recording and automated prize distributions.

[0049] Draw processes and prize distribution are crucial. The system may rely on a traditional mechanical draw, with winning numbers submitted to the smart contract by an authorized wallet address. Alternatively, blockchain-based RNG, external oracles and APIs, or AI-run cameras verifying physical draws can determine outcomes. Once the outcome is recognized, the prize distribution mechanism calculates winners and enforces any partial-match tiers. In dynamic pricing or betting scenarios, the system allocates prizes proportionally to participants’ paid amounts. Prizes transfer automatically to winners’ addresses and are recorded on the ledger for auditability. Token-swapping logic may convert game tokens into other assets (Bitcoin, Ethereum, stablecoins) if so defined, or revert them back to the original token as needed.

[0050] In certain implementations, the invention relies on one or more oracle services to obtain trustworthy, off-chain information relevant to lottery or betting outcomes. By way of example, if a sports match or similar real-world event determines the result, a trusted oracle (such as a decentralized network of data providers) retrieves official final scores or outcomes from recognized data feeds and then posts verifiable proof of such results to the blockchain. The smart contract is configured to accept only data signed or otherwise authenticated by these oracle services, ensuring integrity, security, and verifiability of the outcome. In scenarios where AI modules are employed, such as interpreting live video of a physically drawn lottery, these modules integrate with the oracle layer by packaging the interpreted or detected winning numbers into an authenticated transaction before submission to the smart contract. By defining strict authorization criteria for which wallet addresses or oracle feeds are trusted, the invention prevents tampering or manipulation. This disclosure clarifies how each system component (including AI, oracles, and the smart contract logic) works together to enforce game rules, store records on-chain, and maintain participant privacy, while reducing any ambiguity about roles, data flow, or the scope of the invention.

[0051] Security and authorization measures typically prevent unauthorized wallet addresses from injecting winning numbers. Only pre-approved addresses or AI / oracle-based systems may send outcome data recognized as valid by the contract. Additionally, participant privacy is preserved by storing only wallet addresses, though advanced cryptographic methods (for example, zero-knowledge proofs) may further shield personal information. Scalability and flexibility allow small businesses or large enterprises to customize game rules, encoding schemes, prize models, fallback conditions, and compliance thresholds. Multiple token standards or cryptocurrencies can be accepted, with external oracles handling exchange rates. If local regulations demand it, the system can integrate geolocation or age checks without fundamentally altering game flow. The invention’s modular design also enables partial or full integration with existing lottery infrastructures (for example, physically drawn numbers remain, but tickets and prize distribution become blockchain-based).

[0052] In brief, the disclosed system and method enable single-transaction entries (LTTs or BTTs) that combine stake and participant selections, a decentralized ledger that immutably records every action, outcome determination via traditional or blockchain-based draws, flexible or dynamic pricing, potential fallback for no-winner or oracle failures, token swapping for asset management, optional compliance layers, and user-friendly interfaces. These features can be freely combined, omitted, or scaled as needed. By blending these elements, the invention facilitates an efficient, modern, and secure approach to lottery and betting operations, promoting transparency, user engagement, privacy, and fairness within a variety of regulatory and commercial contexts.Detailed Description of Embodiments

[0053] The following detailed description sets forth various embodiments and illustrative examples of the present invention. It is not intended to limit the scope, functionality, or possible implementations of the disclosed system and method, and those skilled in the art may make changes, substitutions, or modifications without departing from the essence of the invention. References to “in one embodiment,” “an embodiment,” “at least one embodiment,” or similar language do not necessarily refer to the same embodiment or limit the invention to those specific features. Instead, features described in different embodiments may be combined, separated, or practiced independently as required by particular use cases and regulatory requirements.

[0054] The present invention encompasses various embodiments of a decentralized lottery and betting system utilizing distributed ledger technology (DLT). These embodiments illustrate the system's adaptability to different scenarios, encoding methods, ticket pricing models, prize distribution mechanisms, and integration with traditional systems. The system leverages smart contracts or equivalent programmable mechanisms on the DLT platform to ensure transparency, security, and efficiency.

[0055] The following are more detailed descriptions of various related concepts and embodiments of systems and methods according to the present disclosure. It should be appreciated that various aspects of the subject matter introduced above and discussed in greater detail below may be implemented in any of numerous ways, as the subject matter is not limited to any particular manner of implementation. Examples of specific implementations and applications are provided primarily for illustrative purposes. It is to be understood that those embodiments are example implementations of the disclosed inventions and that alternative embodiments are possible. Such alternative embodiments include hybrid embodiments that include features from different disclosed embodiments. All such embodiments are intended to fall within the scope of this disclosure.

[0056] In every embodiment described herein, the disclosed system and methods incorporate a set of common rules for handling any invalid LTT(s) or invalid BTT(s). For instance, if a participant attempts to initiate an LTT / BTT that includes overpayment or underpayment relative to the predefined cost, or if a transaction only partially meets the applicable lottery or betting rules, the system automatically applies one or more preconfigured operations according to platform-specific business policies. Examples of these operations include rejecting and leaving the transaction unconfirmed, confirming the transaction but excluding its associated selections from the game pool, adding any transferred tokens to the prize pool despite ignoring the selections, refunding some or all of the transferred tokens (potentially minus network fees), or combining these actions. These rules are stored immutably in the smart contract or DLT-level logic, ensuring that no party can alter them once the game has started. Consequently, all game-related decisions, such as whether to accept or reject a particular LTT / BTT, or how to handle misaligned token amounts, are executed automatically and transparently without the possibility of manual manipulation.

[0057] Additionally, certain fundamental concepts remain consistent across all embodiments of the invention. For instance, every participant’s LTT / BTT transaction details and transactions from authorized entities, including the number of tokens transferred, any encoded selections or betting options, and any associated ticket price or stake, are publicly visible on the distributed ledger for reference by other participants, new users, or any third-party observer. This transparent, on-chain recordkeeping fosters trust, simplifies auditing, and allows users to analyze prior game activity if desired. However, although some embodiments or examples explicitly mention one or more of these shared rules or operations, such references are made primarily for illustrative simplicity and do not limit the scope of a given embodiment. Indeed, these standardized features automatic handling of invalid transactions, transparent recording of participant entries, and immutability of rule enforcement, apply broadly throughout the invention.

[0058] In one embodiment, a blockchain-based lottery system is established in which participants pay a fixed amount in game tokens to acquire a lottery ticket, referred to as an LTT. The encoding method for this embodiment assigns the integer part of the LTT’s transaction amount as the ticket price, while the decimal part (or metadata) encodes the participant’s selected numbers. In this fixed-price embodiment, overpayment is still accepted. Participants select their lottery numbers according to the game rules (for example, choosing four numbers between 1 and 50) and initiate their LTTs based on the prescribed encoding method.

[0059] For instance, if each token is valued at 0.10 USD, a ticket costing ten tokens corresponds to 1.00 USD. Suppose a participant wishes to select four numbers - 05, 12, 23, and 38. They send “10.05122338” tokens (equivalent to 1.005122338 USD) in a single transaction, where “10” represents the fixed ticket price and “.05122338” encodes the four chosen numbers.

[0060] Upon receiving the LTT, the smart contract confirms that the exact required number of tokens (for example, ten tokens) was transferred and decodes the participant’s selections from the decimal portion. If the integer part of the LTT exceeds the required ticket price (for example, more than ten tokens), the smart contract may still confirm and treat the transaction as a valid LTT. Conversely, if the integer part falls below the required amount (for example, fewer than ten tokens), the smart contract may reject the transaction, leaving such LTTs unconfirmed.

[0061] At the designated draw time, winning numbers are determined either via a traditional draw (submitted on-chain by an authorized wallet) or a blockchain-based random number generator (RNG). Once the winning numbers are recognized, the smart contract checks each recorded LTT to identify any matches. If a participant’s chosen numbers match the draw result under the predefined prize tiers, the smart contract automatically allocates the appropriate share of the prize pool and transfers it to the participant’s wallet address. Because no additional steps or submissions are required from the participant, the entire process, from ticket purchase to prize payout, remains both streamlined and transparent.

[0062] In another embodiment, a betting platform where participants place wagers on particular events (for example, sports matches) by sending a single transaction, known as a Betting Ticket Transaction (BTT) is presented. The integer portion of the transferred tokens represents the wager amount, and the decimal portion (or metadata) encodes the participant’s chosen outcome or betting code. For instance, assume one game token is again valued at 0.10 USD, and a bettor wants to wager 50 tokens (equivalent to 5.00 USD) on Team A to win a soccer match. The bettor sends “50.1” tokens to the smart contract, where “50” indicates the wager and “.1” encodes the bet selection “Team A to win.”

[0063] Once the BTT is received, the smart contract decodes the decimal portion for the chosen outcome (betting options), and stores these details on the blockchain. It validates the transaction (BTTs) and ensures the bet amount meets any minimum or maximum limit (for example, it verifies that 50 tokens have been transferred). After the match concludes, an authorized oracle or AI-based module submits the verified final score to the smart contract. If the outcome matches the bettor’s selection, the smart contract calculates the winnings based on the bet amount, odds and predetermined payout rules. Winnings are proportionally distributed to the winners. For example, if the bet is doubled upon success, the participant automatically receives 100 tokens (10.00 USD) in their wallet. By merging payment and selection into one blockchain transaction, the system eliminates the need for multiple processes (such as separate bet submissions) and ensures tamper-evident recordkeeping and automated payouts.

[0064] In another embodiment, participants pay different amounts of game tokens for their Lottery Ticket Transactions (LTTs) based on their selected numbers, creating a dynamic ticket price. The integer portion of each LTT represents both the cost of entry and the participant’s numerical selection, while the decimal part (or metadata) may optionally hold additional parameters (encoding method). Participants select their lottery numbers according to the game rules (for example, choosing four numbers between 1 and 50) and initiate their LTTs based on the prescribed encoding method. In this implementation, participants’ choices affect the cost of their tickets. Therefore, selecting different numbers to engage the game may lead to different ticket costs paid as part of the LTTs. Suppose two participants each choose the same four numbers” 4, 5, 6, and 7” but in different orders, such that the first participant’s chosen string is “4657” and the second participant’s chosen string is “7456.”

[0065] When the draw occurs, if the winning combination is “5, 7, 4, and 6” (regardless of order, depending on the predefined matching rules), both participants have selected the same four digits in some order and therefore qualify as winners. However, the smart contract automatically allocates prizes based on the proportion of each participant’s stake. Since the second participant (7456 tokens) contributed more to the pool than the first (4657 tokens), the second participant receives a larger share of the overall prize. This dynamic approach incentivizes participants to select potentially costlier (or less popular) combinations, as they might command a higher payout if they match the winning result.

[0066] By combining the numeric selection and monetary cost into a single transaction, this embodiment preserves the core advantage of the system, eliminating multi-step processes, while introducing a flexible pricing model that accommodates varied levels of risk, strategy, and reward. The entire process is managed by a smart contract on the blockchain, enabling transparent validation of both the participant’s stake and the chosen numbers, as well as immediate distribution of prizes upon determining the outcome.

[0067] In another embodiment, a café, bar or restaurant employs the disclosed system and method (using LTT or BTT) to create a controlled lottery or betting game for its customers. The business can either deploy a private DLT network (for example, a permissioned blockchain) or leverage a public blockchain, while still restricting participation to authorized users. This ensures that only customers who complete certain tasks, such as making a purchase, gain access to the game.

[0068] In the “private DLT network” scenario, the café owner establishes a permissioned blockchain accessible only to specific users under predefined conditions. Each prospective participant becomes eligible to join once they meet the café’s requirements (for instance, buying a coffee or meal). The owner or an authorized module grants them access credentials to the permissioned network. From there, each qualified customer can submit an LTT (for lottery) or BTT (for betting) encoding both the ticket price (or stake) and their chosen numbers or bets. The smart contract running on the private DLT validates these transactions, records them immutably, and later processes the draw or event outcome, much like in the previously described embodiments. Prize distribution proceeds automatically via the same private network, allowing the café to keep all records within a trusted, limited-access ledger.

[0069] In the “public blockchain” scenario, the system is hosted on a widely accessible DLT (for example, Ethereum, Solana), but the smart contract is configured to accept only LTTs / BTTs originating from the café owner’s wallet address. After a customer completes a purchase or any other required task, they provide two data points to the owner: (1) their blockchain wallet address and (2) their chosen lottery numbers or betting options. The café owner then initiates a single LTT / BTT on behalf of the customer, specifically, sending tokens from the owner’s on-chain balance. This transaction includes the customer’s address within the metadata or decimal portion of the token amount, ensuring that if the ticket wins, the prize is awarded to the correct customer’s wallet. All subsequent phases, validation, outcome submission (from an oracle or authorized entity), and payout, unfold as detailed in earlier embodiments.

[0070] In an alternative extension of the public blockchain scenario, the business owner can allow any participant, whether they have completed a purchase or not, to enter the game directly from their own wallet address. In this case, participants simply send an LTT or BTT from their personal wallets without relying on the business owner’s address. Nevertheless, to incentivize actual customers, the business owner may provide the necessary game tokens to those who have made a purchase, either for free or at a steep discount, thus offering them a practical advantage. Meanwhile, participants from outside the café or restaurant can still join by acquiring tokens on the open market, making the game accessible to a broader audience yet preserving exclusive benefits for loyal patrons who meet the business’s requirements

[0071] Although this embodiment describes a café, bar or restaurant integrating lottery or betting functionality for promotional purposes, the same approach can be adopted by businesses of any size or industry. Whether it is a small local enterprise, a large retail chain, or even a multinational corporation, the disclosed system supports flexible access rules, transparent ledger-based recordkeeping, and automated payouts. By selecting either a private DLT network for restricted access or configuring a public blockchain smart contract to accept transactions solely from authorized addresses, organizations can scale and adapt the invention to suit their specific operational requirements while preserving security, transparency, and efficiency.

[0072] In some embodiments, disclosed systems and methods may be integrated with conventional lottery systems (for example, Euro Millions or Powerball) fully or partially. In this embodiment, an existing lottery owner preserves two core elements of its traditional system, the physically administered or mechanical draw method, and the retailer-based selling infrastructure, while adopting a blockchain-based module to handle ticket issuance and automated prize distribution. A retailer (for instance, a convenience store or authorized lottery outlet) sells a physical or electronic ticket to the participant and collects payment in any acceptable manner, performing whatever local compliance checks (age verification, location requirements) are mandated by regional regulations. Once the retailer receives the entry fee, it leverages the blockchain module to initiate a single Lottery Ticket Transaction (LTT) on behalf of the participant.

[0073] In this LTT, the retailer encodes both the monetary aspect (the integer part of the token amount) and the participant’s chosen numbers (decimal part or metadata), following the predefined encoding scheme. The participant’s on-chain wallet address is placed in the transaction metadata (or in a designated decimal field), signifying which wallet should receive the prize. The retailer’s own wallet serves as the sender address of the LTT, using its blockchain token balance to fund the required token amount.

[0074] Upon confirmation of the LTT on the blockchain, the smart contract immutably records the retailer wallet address (sender), participant wallet address (metadata), chosen numbers, and transferred token count (transaction amount), all in a single transaction. The draw itself remains traditionally run: a physical or mechanical draw is conducted at the scheduled time, and the resulting winning numbers are submitted on-chain through an authorized wallet address(or any authorized entities such as verified Oracles / AI-based modules). The smart contract automatically cross-checks every recorded LTT to determine if any selections match the winning outcome and calculates payouts based on predefined distribution rules. These rules may allocate a certain percentage of the prize directly to the participant’s wallet and another percentage to the retailer’s wallet, thus incentivizing the retailer to engage in the process. For example, the contract might specify that 95% of the prize goes to the participant (winner) address embedded in the metadata, while 5% goes to the sender wallet (the retailer) as a commission or incentive. All such percentages or referral relationships are configured by the lottery owner in the smart contract before launch. The contract then disburses the respective portions of the prize on-chain, finalizing the transaction and logging the entire payout process in a publicly verifiable ledger. By retaining the mechanical draw and retailer compliance checks while integrating a single-transaction blockchain ticket mechanism, this embodiment seamlessly merges the transparency, security, and automation of distributed ledger technology with the familiar user experience of traditional lottery or betting systems.

[0075] In some embodiments, disclosed systems and methods utilize automated outcome determination via oracles. This focuses on using oracles to automatically input external event results (for example, a sport match) into the smart contract for betting systems. The smart contract is linked to an authorized and trusted oracle service that fetches real-world data. Participants place bets on external events by sending transactions encoding their choices (initiating BTTs). After the event concludes, the oracle retrieves the official results and inputs them into the smart contract. The smart contract automatically processes the results and distributes winnings accordingly, eliminating manual input of results and reducing delays or errors.

[0076] In some embodiments, the disclosed system and methods address compliance with legal requirements by incorporating decentralized identity solutions (for example, verifiable credentials) and cryptographic proofs (such as zero-knowledge proofs). This embodiment solves common age verification or regional regulatory challenges by allowing the platform to integrate geolocation services or require proof of location. Participants obtain a verifiable credential from a trusted issuer confirming that they are of legal age or located in a permissible region. They then generate a zero-knowledge proof of compliance, which can be included in their LTT or BTT without revealing personal data. The smart contract verifies these proofs and accepts valid transactions that meet the configured compliance rules. This feature is optional, and the game owner may enable, disable, or modify the compliance checks at any time based on business or regulatory needs.

[0077] In some embodiments, the system supports cross-chain bridging to allow tokens and participants to operate across multiple blockchains. One or more authorized oracles provide cryptographic proofs of token flow and verify wallet histories among different chains, thereby ensuring authenticity and preventing inconsistent transactions across networks.

[0078] In some embodiments, the system can model referral chains or indirect sponsorship structures, stacked with other game configurations, promotional strategies, multi-level marketing plans, and encoding methods.

[0079] The above embodiments illustrate various ways in which the invention may be implemented and refined, providing non-limiting examples of features, configurations, and operational workflows. Although each embodiment may include unique elements or emphasize particular functionalities, such features should not be construed as limiting the scope of the overall invention. Rather, these embodiments demonstrate how different components and modules, such as smart contracts, encoding schemes, drawing methods, compliance checks, and fallback rules, can be arranged, combined, or adapted according to the technical requirements and regulatory contexts in which the invention may be deployed. Those skilled in the art will recognize that numerous modifications, substitutions, and enhancements could be made to any individual embodiment while remaining within the spirit and scope of the appended claims.Examples

[0080] Herein we describe some examples to illustrate and clarify the disclosed system and methods in which users participate in lottery or betting games via a single digital transaction (LTT or BTT).

[0081] In the first example, a blockchain-based lottery system using LTT is described in detail. A lottery platform owner sets up a game where participants must select four numbers, each from 1 to 50. Participants enter the lottery by sending tokens to a smart contract address, encoding their chosen numbers in the integer and decimal parts of a token amount. The platform owner defines an encoding scheme in which the integer part represents a fixed ticket price (for instance, 10 tokens), while the decimal part encodes the participant’s selected numbers. The decimal part encodes the selected numbers in a concatenated two-digit format for each number. Thereby each selected numbers format is like “N1N2N3N4”, wherein each N represents a two-digit number corresponding to the participant's selected numbers. If a number is below 10, a leading zero is used (for example, 7 becomes 07). This means that to participate, each participant constructs a single transaction amount reflecting both the fixed ticket price in the integer portion and the selected numbers in the decimal portion.

[0082] For illustrative purposes, consider three participants: Alice, Bob, and Charlie. Alice selects numbers 5, 12, 23, and 38, then sends a transaction of 10.05122338 tokens. Bob selects 7, 12, 28, and 35, sending 10.07122835 tokens. Charlie selects 10, 20, 30, and 40, sending 10.10203040 tokens. These transactions are each deemed an LTT. Upon receiving them, the smart contract automatically decodes the participant’s chosen numbers from the decimal portion, confirms that 10 tokens represent the fixed cost. All ticket details are stored on the blockchain for transparency and immutability. When the draw takes place (either via a traditional mechanical process or a blockchain-based RNG), the winning numbers are provided to the smart contract by an authorized entity. If, for example, the winning numbers are 07, 12, 23, and 35, the contract will check each participant’s selections, calculate the number of matches, and allocate prizes in accordance with predefined tiers.

[0083] For illustrative completeness, assume the total prize pool is composed of 30 tokens (10 tokens from each of Alice, Bob, and Charlie). The platform allocates these tokens across three tiers according to the game rules and predefined percentages: a Jackpot Prize (50% of the pool), a Second Prize (30%), and a Third Prize (20%). Since no participant matches all four winning numbers, the 50% allocated to the jackpot (15 tokens) is unclaimed and handled according to the game’s fallback or rollover rules. Bob, with three matches, qualifies for the second prize tier (30% of 30 tokens), so he receives 9 tokens. Alice, with two matches, qualifies for the third prize tier (20% of 30 tokens), so she receives 6 tokens. Charlie, with no matches, does not receive any prize. The smart contract then automatically disburses 9 tokens to Bob and 6 tokens to Alice, recording these transactions on-chain to ensure transparency and security. By unifying ticket entries (via LTTs) and automated prize allocation in this manner, the system delivers both operational efficiency and robust integrity for lottery operations.

[0084] This example demonstrates how the LTT process allows participants to engage in lottery games by sending a single transaction that encodes their ticket’s cost and selected numbers in the integer and decimal parts of the token amount. The system ensures simplicity, transparency, immutability, and automated processing, all while preserving participant privacy.

[0085] In the second example, a simple blockchain-based betting system using BTT on a sports event with decentralized oracles is described.

[0086] In this example, the sports betting platform owner hosts a basketball wager on a match between Team X and Team Y. The encoding scheme for the Betting Ticket Transaction (BTT) defines the integer part of the token amount as the wager, while the decimal part encodes a predefined betting option code. For simplicity, the platform sets up four basic codes: “.1” for Team X to win, “.2” for Team Y to win, “.3” for total points over 200, and “.4” for total points under 200. If participants want to place multiple bets, they can simply initiate separate transactions to the smart contract, one for each wager. Alternatively, the system can support multi-code entries if the token’s decimal precision allows. For instance, “.5” might represent a combined bet on “Team X to win” and “total points over 200,” effectively merging two conditions into one decimal code.

[0087] Three participants, Alice, Bob, and Charlie, decide to enter. Alice bets 20 tokens on “Team X to win,” sending a transaction of “20.1” tokens. Bob bets 60 tokens on “total points over 200,” sending “60.3” tokens. Charlie bets 20 tokens on “Team Y to win,” sending “20.2” tokens. If either participant wished to combine, say, “Team X to win” and “total points under 200” in a single transaction, they could do so by using a custom combined code (for example, “.5”), assuming the encoding scheme and decimal precision accommodate multi-condition bets. All participant transactions are validated and recorded by the smart contract, which decodes each integer part (the wager amount) and decimal part (the betting option code).

[0088] After the match finishes, an authorized oracle or AI module feeds the final score on-chain. Suppose Team Y wins, and the total points scored are 205. Under these conditions, Charlie’s bet (Team Y to win) and Bob’s bet (total points over 200) both qualify for a share of the total prize pool. Meanwhile, Alice, who bet on Team X, does not win. If the system collects 100 tokens in total wagers (20 + 60 + 20) as the game prize pool, and the betting platform opts for a proportional payout among winning bets (based on prize distribution rules of the game), Bob and Charlie share the 100 tokens in proportion to their stakes (60 tokens for Bob vs. 20 tokens for Charlie). Bob thus receives 75 tokens and Charlie receives 25 tokens.

[0089] Alternatively, the betting-platform owner might configure different payout methods (for example, different prize distribution rules) based on odds or other commercial strategies (for example, by following their business plans). One approach might simply double a winning participant’s wager (for example, 2:1 odds), meaning a bet of 60 tokens might yield 120 tokens upon success. Another might incorporate varying odds for each betting option and split the remaining prize pool among multiple winners. These parameters are stored in the smart contract, which executes payouts automatically once the final outcome is confirmed, preventing human error or manipulation.

[0090] All transactions, from initial BTT submissions to final prize distributions, are logged immutably on the blockchain, enabling transparent oversight and user-friendly verification. Participants need only a wallet address to join, preserving privacy and eliminating extra steps. By unifying payment and bet selection in a single transaction, the disclosed system and method simplify user engagement, reduce administrative overhead, and offer a secure, scalable platform for a broad range of betting and wagering scenarios.

[0091] The foregoing examples illustrate various embodiments and use cases of the invention, demonstrating how participants can engage in lottery, betting, or other wagering events through single-transaction mechanisms. Each example highlights particular features, such as encoding methods, pricing models, or payout structures, without limiting the invention to these specific scenarios. Those skilled in the art will appreciate that numerous variations, substitutions, and additional functionalities may be introduced to adapt the invention for different regulatory requirements, token standards, business strategies, or technical constraints, while remaining within the spirit and scope of the appended claims.

[0092] The disclosed system and methods apply to various industries including national lotteries, sports betting, casino-style games, promotional raffles, skill-based competitions, and other wagering events. The invention’s flexibility in pricing, compliance, draw methods, partial matches, fallback procedures, cross-chain integration, and dynamic token management caters to a wide range of business models, regulatory environments, and participant preferences. This adaptability ensures that platform owners can choose their desired configurations, ranging from simple traditional lotteries to highly complex, multi-tiered, multi-game, and globally accessible gambling ecosystems, while preserving users privacy and maintaining transparency, security, fairness, and operational integrity.

Claims

A method of conducting a lottery or betting event on a distributed ledger technology (DLT) network using digital single-transaction entries, the method comprising:receiving, by at least one smart contract hosted on the distributed ledger network, a plurality of digital transactions, each digital transaction containing both:a monetary stake in the form of a token amount transferred from a participant’s wallet, andgame-specific data, including one or more numeric selections, betting options or other payload data encoded in at least one of:an integer portion of the token amount,a decimal portion of the token amount, ora metadata field of the transaction;validating, by the at least one smart contract, the digital single-transactions against predetermined lottery or betting rules, said validation including:verifying that each participant’s token transfer meets a required cost or wager criterion, andparsing the encoded data to extract the participant’s selected numbers or betting parameters;recording, immutably, each validated digital single-transaction onto the distributed ledger, thereby providing a permanent, transparent record of each participant’s stake and selections;obtaining an outcome for the lottery or betting event through at least one outcome-determination process selected from a group consisting of:a DLT-based random number generator (RNG) mechanism,an external oracle providing real-world results (including sports scores or physically drawn numbers),an AI-assisted module that processes a real-world feed and posts an authenticated winning result on-chain; ormanual submission of at least one outcome-determination transaction from an authorized wallet address recognized by the at least one smart contract initiated from the game owner.matching each participant’s selections or wagers, decoded from the digital single-transaction, against the obtained outcome to identify one or more winning entries; anddistributing, by automated or semi-automated logic of the smart contract, a prize or payout to each winner, wherein the prize distribution comprises transferring tokens from a designated DLT-based pool to a wallet address associated with each winning entry, and updating the distributed ledger to reflect completion of the event.The method of claim 1, wherein each digital single transaction constitutes a distinct “Ticket” for the lottery or betting event, and is labeled as a Lottery Ticket Transaction (LTT) for lottery-style games or a Betting Ticket Transaction (BTT) for betting-style games, such that each LTT / BTT merges both the required payment and participant-chosen parameters (numbers, wagers, or other game data) into a single token transfer from the participant’s wallet address to the at least one smart contract.The method of claim 1 or 2, wherein said token amount can be denominated in any form of digital asset including fungible or non-fungible digital asset, stablecoin, utility token, or similar digital currency recognized within a DLT network.The method of any one of claims 1-3, further comprising supporting fixed or dynamic ticket pricing, wherein in a dynamic pricing model the numeric selections encoded in the integer or decimal part of each LTT or BTT determine the stake or ticket cost, allowing participants who pick certain numbers or options to pay proportionally different amounts and in a fixed pricing model the tickets’ price is fixed and independent to participants’ selections.The method of any one of claims 1-4, further comprising a partial-match payout mechanism, wherein the at least one smart contract calculates multiple prize tiers based on how many numbers (or parameters) match the determined outcome, and allocates proportionate shares of a prize pool according to the predefined game rules.The method of any one of claims 1-5, wherein the outcome is periodically determined at one or more scheduled times, with the at least one smart contract:preventing further LTT / BTT submissions once participation is closed,verifying each participant’s LTT / BTT as valid or invalid based on rules stored on-chain, andtransitioning to a prize-allocation phase when a winning outcome is obtained.The method of any one of claims 1-6, further comprising a fallback scenario process, wherein if no valid winning entry is found or if an outcome-determination process malfunctions, the smart contract automatically executes at least one predefined corrective action selected from:rolling over an unclaimed prize pool to a subsequent round,issuing partial or full refunds to participants,triggering a backup draw, orswitching to a different oracle or verified random source.The method of any one of claims 1-7, further comprising employing compliance checks (for example, age verification, geolocation verification, know-your-customer checks) that are optionally enforced by the smart contract, DLT network logic or an off-chain service, wherein only participants who pass said checks are permitted to enter the game and execute their LTT / BTT.The method of any one of claims 1-8, further comprising cross-chain bridging, enabling participants to pay or receive prizes in different token standards or on different DLT networks, with at least one oracle or bridging module verifying token flows and final outcomes across chains.The method of any one of claims 1-9, wherein the prize distribution includes token swapping logic, allowing the system to convert a participant’s stake from a first type of token to a second type of token prior to awarding payouts, if so configured.The method of any one of claims 1-10, further comprising preserving participant anonymity by mapping real-world identities to pseudonymous wallet addresses and optionally using zero-knowledge proofs to conceal sensitive winner data while still confirming eligibility and payoutA system for conducting lottery or betting events via digital single transactions on a distributed ledger technology (DLT) network, the system comprising:one or more distributed ledger nodes configured to process and record digital token transactions that merge participant stakes and game-specific data in a single token transfer;at least one smart contract or network protocol stored in the distributed ledger, the at least one smart contract or network logic being operable to:parse each digital single transaction to decode an integer part, a decimal part, or a metadata field containing participant selections or betting parameters,validate that each transaction meets one or more rules regarding cost, stake amount, or numeric ranges for selections, andstore a reference linking each validated digital single transaction to a unique participant entry;an outcome determination mechanism that includes at least one of:a DLT-based RNG module integrated with block data,an external oracle retrieving real-world results and posting them on-chain, oran AI-driven process delivering authenticated draw outcomes to said smart contract or network logic;A manual process of submitting at least one outcome-determination transaction from an authorized wallet address recognized by the at least one smart contract initiated from the game owner.a prize allocation logic implemented by said at least one smart contract, configured to:identify one or more winning entries based on comparing each participant’s encoded selection to the determined outcome,proportionally calculate a reward from a prize pool or operator fund, andautomatically distribute tokens to winning participants’ wallet addresses on the distributed ledger; andan optional set of modules, including at least one from:a fallback scenario module for no-winner or error conditions,a compliance interface for participant geolocation or identity checks,a retailer / referral logic for partial payouts to third parties,token-swapping or bridging functionality, andAI or machine learning integration for event verification,Wherein each participant can engage in the lottery or betting event by transmitting the at least one digital single-transaction that merges both payment and game data according to the at least one encoding method and event rules.The system of claim 12, wherein each digital single transaction constitutes a distinct “Ticket” in the lottery or betting event and is classified as a Lottery Ticket Transaction (LTT) for lottery-style games or a Betting Ticket Transaction (BTT) for betting-style games, such that each LTT or BTT merges both a required payment and participant-chosen parameters (including numbers, wagers, or other game data) into one token transfer from the participant’s wallet address to the at least one smart contract.The system of claim 12 or 13, wherein the DLT network is an existing blockchain (for example, Ethereum, Solana, Bitcoin) or a custom-built distributed ledger infrastructure established by a platform owner or operator.The system of any one of claims 12-14, wherein the system is configured to operate on public blockchain, private, or hybrid blockchain networks, and the at least one smart contract enforces immutability and transparency of each LTT / BTT submitted by participants.The system of any one of claims 12-15, wherein certain validation, stake enforcement, or compliance checks are implemented partly or wholly at the DLT protocol layer rather than exclusively by a smart contract, such that predefined protocol-level logic accepts or rejects participant transactions (LTT / BTT).The system of any one of claims 12-16, further comprising a pricing logic that supports fixed pricing or dynamic pricing, wherein the dynamic pricing is derived from participant-chosen data inserted into the integer or decimal portion of each transaction.The system of any one of claims 12-17, wherein the at least one smart contract supports multi-game entries within a LTT / BTT, allowing a participant to encode multiple sets of game parameters and entry details for different lottery or betting events in a single LTT / BTT.The system of any one of claims 12-18, wherein the prize allocation logic further comprises a partial-match payout mechanism for generating multiple prize tiers if participants’ encoded selections partially match the determined outcome, each tier allocating a corresponding share of the prize pool.The system of any one of claims 12-19, configured to preserve participant anonymity by mapping each participant to a pseudonymous wallet address, and optionally employing zero-knowledge proofs or cryptographic anonymization techniques to confirm eligibility and execute prize distribution without revealing personal identities.The system of any one of claims 12-20, further comprising a graphical user interface or API that:constructs the LTT / BTT with an encoded stake and user selections,displays real-time data of participants, based on recorded LTTs / BTTs,displays real-time data of game information and statistics,provides educational resources, tutorials, or step-by-step instructions for wallet setup, lottery / betting entry, and regulatory processes,enables external or third-party services (for example, token swapping or trading, bridging, or data analytics), andafter the outcome is determined, highlights winners’ wallet addresses and allocated prizes.The system of any one of claims 12-21, wherein the fallback scenario module triggers rollover rules if no valid winners are found or if the outcome data feed fails.The system of any one of claims 12-22, wherein the token-swapping functionality is driven by smart contract integrations with decentralized exchanges, enabling automatic conversion of stake tokens into stablecoins or alternative cryptocurrencies prior to awarding a prize.A non-transitory computer-readable medium storing instructions that, when executed by one or more processors in a distributed ledger environment, cause performance of a method for implementing single-transaction lottery or betting events, the method comprising:receiving from a plurality of participants a series of digital token transactions (LTTs or BTTs), each transaction encoding:a stake component representing the payment or wager, andparticipant-defined data in at least one of an integer, decimal, or metadata field specifying lottery numbers or betting selections;validating said digital token transactions to confirm each adheres to one or more stake and selection rules stored in a smart contract;storing, in an immutable data structure on the distributed ledger, a record of each validated transaction, including the participant’s wallet address, the stake amount, and the decoded game selection;determining a winning outcome through at least one authorized approach selected from:a verifiable on-chain random generator that finalizes random output,an external verified oracle providing an event-based result, oran AI module analyzing, confirming an providing physical or real-world event results including draw data;manual process of generating at least one outcome-determination transaction initiated from an authorized wallet address by the game owner.comparing each participant’s stored selection to the winning outcome to identify any winning entries, calculating partial-match or tiered payouts if so configured; anddisbursing corresponding prizes in digital tokens to each winning participant’s wallet address and updating the smart contract state to reflect final settlement of the lottery or betting eventThe non-transitory computer-readable medium of claim 24, wherein the instructions further include logic for enforcing a fixed or dynamic pricing model.The non-transitory computer-readable medium of claim 24 or 25, wherein the instructions include fallback features for handling system malfunctions including outcome-determination process disruption or network failure.The non-transitory computer-readable medium of any one of claims 24-26, wherein the instructions enable cross-chain interoperability by accepting bridging mechanisms for sending / receiving tokens in different standards to / from different blockchain over variety of DLT networks.The non-transitory computer-readable medium of any one of claims 24-27, wherein the instructions incorporate referral or commission logic that allocates a fraction of the prize pool or stake tokens to a retailer or third-party wallet if indicated in the digital single-transaction’s metadata fields or decimal part of token amount.The non-transitory computer-readable medium of any one of claims 24-28, wherein the instructions preserve user pseudonymity on-chain by referencing only a wallet address, but optionally integrate with off-chain compliance checks (for example, age or location verifications) required before the single transaction is accepted.The non-transitory computer-readable medium of any one of claims 24-29, wherein the instructions implement cryptographic or zero-knowledge proof mechanisms to preserve participant anonymity on-chain while validating stakes, verifying winners, and disbursing prizes.

Images