System and method for administering and managing blockchain in a regulated environment
Patent Information
- Application Number
- PCT/CA2026/050311
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-02-26
- Filing Date
- 2026-02-26
- Publication Date
- 2026-09-03
Smart Images
Figure CA2026050311_03092026_PF_FP_ABST
Abstract
Description
SYSTEM AND METHOD FOR ADMINISTERING AND MANAGING BLOCKCHAIN IN A REGULATED ENVIRONMENT FIELD OF INVENTION
[0001] The present invention relates generally to a system and method for administering and managing a blockchain in a regulated environment. More specifically, the present invention relates to a system and method for administering and managing a blockchain and enforcing actions upon the blockchain.BACKGROUND OF THE INVENTION
[0002] Stablecoins can be defined as cryptocurrencies that aim to maintain a stable value relative to a specified asset, or a pool or basket of assets. One mechanism consists of backing stablecoins with liquid assets, such as U.S. dollars. Under this approach, the value of the stablecoin is guaranteed by the issuer, who fully collateralizes the claim and commits to redeeming coins at par value. The underlying assets is held at a custodian for safe keeping.
[0003] However, in order to keep the commitment of redeeming coins at value and to continue the backing of the stablecoins with liquid assets, the stablecoin needs to operate within a regulated environment. Accordingly there is a need for a system that allows for currency backed stablecoins to be regulated to avoid illegal transactions.SUMMARY OF INVENTION
[0004] According to an aspect of the present disclosure, a method for minting a token comprises receiving a token value; creating a transaction for minting, the transaction including a Satoshi, the token value, a partially signed contract, and a network fee; determining whether the transaction is validated; if the transaction is validated, signing the partially signed contract to create a complete signed contract in the transaction; and providing the transaction to a miner, the miner being configured to mine the transaction to create a minted Satoshi with the token value.
[0005] According to some embodiments, the method may further comprise verifying the identity of two administrators for approval of the transaction prior to creating the transaction forminting. In some embodiments, the method may further comprise receiving the minted Satoshi from the miner.
[0006] According to some embodiments, the method may further comprise verifying the token value on the minted Satoshi. In some embodiments, the network fee may be received from a network fee wallet.
[0007] According to some embodiments, the method may further comprise depositing the minted Satoshi into a treasury wallet. In some embodiments, the treasury wallet and the network fee wallet may be the same digital wallet.
[0008] According to some embodiments, the token may be an Unspent Transaction Output (UTXO) based cryptocurrency. In some embodiments, the step of determining whether the transaction is validated may include determining whether an enforcement action is present, where if an enforcement action is present, the transaction is not validated.
[0009] According to some embodiments, the enforcement action may be selected from the group consisting of at least one of the source address or the destination address being blacklisted, the source address being frozen, and the token being paused.
[0010] In some embodiments, the network fee may be Bitcoin Satoshi Vision (BSV) currency.
[0011] According to some embodiments, the miner may be a BSV miner.
[0012] In some embodiments, the step of signing the partially signed contract to create the complete signed contract in the transaction may be performed by a cosigner module.
[0013] According to some embodiments, the method may further comprise verifying the conformance of the transaction to a schema prior to signing the partially signed contract to create a complete signed contract. In some embodiments, the schema may include the Satoshi, the token value, the partially signed contract, and the network fee.
[0014] According to some embodiments, the step of determining whether the transaction is validated may include determining the transaction is not validated if the transaction fails to conform to the schema.
[0015] In some embodiments, the step of determining whether the transaction is validated may include sending an error message to a graphical user interface if the transaction is not validated.
[0016] According to some embodiments, the minted Satoshi with the token value may be the token value inscribed as part of a Satoshi payload in accordance with a ISatOrdinals protocol.
[0017] According to an aspect of the present disclosure, a method for transferring a token comprises creating a transaction, the transaction including a source address, a destination address, a token value being sent from the source address to the destination address, a transaction fee and a first Satoshi with a token balance inscribed from the source address; determining whether the transaction is validated; if the transaction is validated, signing the partially signed contract to create a complete signed contract in the transaction; inscribing the token value being sent from the source address to the destination address onto a second Satoshi, the transaction including the second Satoshi; inscribing the transaction fee onto a third Satoshi, the transaction including the third Satoshi; attaching a network fee to the transaction; re-inscribing the return balance onto the first Satoshi in the transaction, wherein the return balance is the token balance on the first Satoshi prior to re-inscribing after the token value and the transaction fee have been removed; and providing the transaction to a miner, the miner being configured to broadcast the transaction to a network.
[0018] According to some embodiments, the transaction fee and the token value may be the same currency.
[0019] In some embodiments, the method may further comprise sending the first Satoshi to the source address; sending the second Satoshi to the destination address; and sending the third Satoshi to a treasury wallet.
[0020] According to an aspect of the present disclosure, a method for burning a token comprises receiving a token value from a source address; creating a transaction for burning, the transaction including a first Satoshi inscribed with the token value, a second Satoshi, a partiallysigned contract, and a network fee; determining whether the transaction is validated; if the transaction is validated, signing the partially signed contract to create a complete signed contract in the transaction; re-inscribing a zero token value onto the first Satoshi, the transaction including the first Satoshi; inscribing the token value onto the second Satoshi, the transaction including the second Satoshi; and providing the transaction to a miner, the miner being configured to mine the transaction.
[0021] According to some embodiments, the method may further comprise sending the first Satoshi to the source address and sending the second Satoshi to a holding wallet. In some embodiments, the method may further comprise verifying whether a wallet at the source address includes the Satoshi inscribed with the token value prior to creating the transaction for burning.
[0022] According to an aspect of the present disclosure, a computer-implemented method for managing a blockchain comprises receiving a user confirmed request for the transferring of a data package from a source address to a destination address, the data package to include at least the source address, the destination address, and a partially signed contract; determining whether the source address and the destination address is authorized; if the source address and the destination address is authorized, signing the partially signed contract to create a complete signed contract; broadcasting the data package to a network for the completion of the user confirmed request; and logging the data package and the complete signed contract to a centralized database; if at least one of the source address or the destination address is not authorized, flagging the partially signed contract as incomplete; and logging the data package and the partially signed contract to the centralized database.BRIEF DESCRIPTION OF THE DRAWINGS
[0023] The embodiments of the present invention shall be more clearly understood with reference to the following detailed description of the embodiments of the invention taken in conjunction with the accompanying drawings, in which:
[0024] FIG. 1 is a schematic diagram depicting an operating environment of an example embodiment of a system for administering and managing a blockchain in a regulated environment;
[0025] FIG. 2 is a schematic diagram showing components of an embodiment of a server from the system of FIG. 1;
[0026] FIG. 3 is a schematic diagram depicting an embodiment of a client terminal from the system in FIG. 1;
[0027] FIG. 4 is a schematic diagram depicting components of the system in FIG. 1;
[0028] FIG. 5 is a schematic diagram depicting the roles of the users of the system in FIG.1;
[0029] FIG. 6 is a flowchart showing an embodiment of the minting operation performed by the server from the system of FIG. 1;
[0030] FIG. 7 is a flowchart showing an alternate embodiment of the minting operation performed by the server from the system of FIG. 1;
[0031] FIGS. 8A and 8B are flowcharts showing another embodiment of the minting operation performed by the server from the system of FIG. 1;
[0032] FIG. 9 is a flowchart showing yet another embodiment of the minting operation performed by the server from the system of FIG. 1;
[0033] FIG. 10 is a flowchart showing an alternate embodiment of the transaction operation performed by the server from the system of FIG. 1;
[0034] FIG. 11 is a flowchart showing an embodiment of a partial transfer operation performed by the server from the system of FIG. 1;
[0035] FIG. 12 is a flowchart showing an embodiment of a complete transfer operation performed by the server from the system of FIG. 1;
[0036] FIG. 13 is an example screenshot showing the transfer operation on a client terminal from the system of FIG. 1;
[0037] FIGS. 14A and 14B are flowcharts showing an embodiment of a send transfer operation performed by the system of FIG. 1;
[0038] FIGS. 15A and 15B are flowcharts showing an embodiment of a receive transfer operation performed by the system of FIG. 1;
[0039] FIG. 16 is a flowchart showing an embodiment of the bum operation performed by the server from the system of FIG. 1;
[0040] FIG. 17 is a flowchart showing an alternate embodiment of the bum operation performed by the server from the system of FIG. 1;
[0041] FIGS. 18A and 18B are flowcharts showing another embodiment of the bum operation performed by the server from the system of FIG. 1;
[0042] FIG. 19 is a flowchart showing yet another embodiment of the burn operation performed by the server from the system of FIG. 1;
[0043] FIGS. 20A, 20B and 20C are flowcharts showing the buying operation via ACH performed by the server from the system of FIG. 1;
[0044] FIGS. 21A, 21B and 21C are flowcharts showing the buying operation using credit card or debit card from the system of FIG. 1;
[0045] FIGS. 22A, 22B and 22C are flowcharts showing the selling operation from the system of FIG. 1; and
[0046] FIGS. 23A and 23B are flowcharts showing the swapping operation from the system of FIG. 1.DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE INVENTION
[0047] The description, which follows, and the embodiments described therein are provided by way of illustration of an example, or examples of particular embodiments of principles and aspects of the present invention. These examples are provided for the purposes of explanation and not of limitation, of those principles of the invention. In the description that follows, like partsare marked throughout the specification and the drawings with the same respective reference numerals.
[0048] Aspects and features of the present application will be understood by those of ordinary skill in the art from a review of the following description of examples in conjunction with the accompanying figures.
[0049] In the present application, the term “and / or” is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the listed elements alone, any sub -combination, or all the elements, and without necessarily excluding additional elements.
[0050] In the present application, the phrase “at least one of... and...” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements.
[0051] By way of general overview, there is provided a system for administering and managing a blockchain, specifically UTXO based cryptocurrencies. In at least some embodiments, the advantage of the system described allows for UTXO based cryptocurrencies to be managed or administered so as to conform to government regulations or industry specific anti-money laundering (AML) practices. Specifically, UTXO based cryptocurrencies may be subjected to enforcement actions, and may be prevented from being minted, transacted or burned to prevent illegal activities or fraud. Furthermore, the system allows for the centralization of transactions, which may increase visibility for approved third parties. In addition, UTXO based cryptocurrencies are known for issues in scalability with regards to calculating balance. The system described below may increase the speed of calculating a UTXO based cryptocurrency balance.
[0052] The system provides the abovementioned advantages by creating a contract associated with the minting, transaction or burning of the UTXO based cryptocurrency automatically reviewed by a cosigner module. Upon verification that there are no enforcementactions against said minting, transaction or burning of the UTXO based cryptocurrency, the cosigner module may sign the contract, and log the contract with a centralized database.
[0053] FIG. 1 depicts system 100 for administering and managing UTXO based cryptocurrencies in a regulated environment. Specifically, server 104 of system 100 communicates with client terminals 108-1, 108-2... 108-n via network 112. Client terminals 108 are referred to herein generically as client terminal 108 and collectively as client terminals 108. This nomenclature is used elsewhere herein. Components of system 100 will be discussed further in detail below.
[0054] Server 104 is a computer server system. A computer server system may, for example, be a mainframe computer, a minicomputer, or the like. In some implementations thereof, a computer server system may be formed of or may include one or more computing devices. A computer server system may include and / or may communicate with multiple computing devices such as, for example, database servers, computer servers, and the like. Multiple computing devices such as these may be in communication using a computer network and may communicate to act in cooperation as a computer server system. For example, such computing devices may communicate using a local-area network (LAN). In some embodiments, a computer server system may include multiple computing devices organized in a tiered arrangement. For example, a computer server system may include middle tier and back-end computing devices. In some embodiments, a computer server system may be a cluster formed of a plurality of interoperating computing devices.
[0055] Server 104 is where at least one of the minting, transacting and burning of a UTXO based cryptocurrency occurs. Furthermore, the verification, cosigning and logging of said minting, transacting and burning of UTXO based cryptocurrencies may also occur on server 104.
[0056] FIG. 2 is a high-level schematic diagram of server 104. Server 104 includes a variety of modules. More specifically, server 104 includes a processor 204 interconnecting a memory 208 and a communications interface 212. The processor 204 is a hardware processor. The processor 204 may, for example, be one or more ARM, Intel x86, Intel x64, AMD, PowerPC processors or the like. The processor may include a central-processing unit (CPU), a graphics processing unit (GPU), a microcontroller, a microprocessor, a processing core, a field-programmable gate array (FPGA), or similar. In some embodiments, the processor 204 can includemultiple cooperating processors. The processor 204 can cooperate with non-transitory computer readable medium, such as the memory 208 to execute instructions to realize the functionality discussed herein.
[0057] Memory 208 can include a combination of volatile memory (e.g. Random Access Emmory or RAM) and non-volatile memory (e.g. non-volatile random-access memory, read only memory or ROM, Electrically Erasable Programmable Read Only memory or EEPROM, flash memory, solid state drives, hard disk drives). All or some of the memory 208 can be integrated with processor 204. Memory 208 stores computer reasonable instructions for execution by processor 204.
[0058] It will now be apparent that each element of memory 208 can be carried out by the processor 204 executing operations. In other words, functionality described below as being carried out by a module of memory 208 or a module of server 104 can be based on any known server environment.
[0059] In some embodiments, memory 208 stores a plurality of computer-readable data and programming instructions, accessible by processor 204, in the form of software objects, such as various applications, queries or types of data for use during the execution of those applications. In particular, the execution of the instructions in memory 208 by processor 204 allow for the creation of a contract through the contract module 216, the review and signing of the contract through cosigner module 220, and logging the contract on database 224. The person skilled in the art will recognize the various forms of computer readable programming instructions stored in memory 208 that can be executed by processor 204 as software objects or application software.
[0060] Memory 208 may also include an operating system. The operating system is software. The operating system allows the aforementioned application software to access processor 204, memory 208 and communications interface 212 of server 104. The operating system may be, for example, Google™ Android™, Apple™ iOS™, UNIX™, Linux™, Microsoft™ Windows™, Apple™ macOS™ or the like.
[0061] In at least some embodiments, memory 208 stores database 224. Database 224 includes an audit log, which may include at least bibliographic information about the contractbeing logged. In the current embodiment, the bibliographic information associated with the contract being logged may include contract creation time, the time of signing by the cosigner module 220, the type of event, such as whether it is the minting, transaction or burning of the UTXO cryptocurrency, and the value of the UTXO cryptocurrency associated with the event. The database 224 may also include additional event-specific data. For example, if there is a minting of a UTXO cryptocurrency, the additional event-specific data that may be logged, may include the network fee or amount required as a gas token. Alternatively, if there is a transaction of a UTXO cryptocurrency, the additional event-specific data that mya be logged may include the change that is to be returned to the original sending wallet or user. A person skilled in the art will recognize that the contract bibliographic information and the associated event-specific data is not limited to the aforementioned, and may include additional types of information or data to be stored in database 224.
[0062] Database 224 may further include enforcement data, such as whether or not cosigner module 220 approved of the contract, and if the contract was not approved, the reasoning behind the lack of approval. In some embodiments, the UTXO cryptocurrency may be regulated and / or backed by governments. In said scenarios, certain fraud prevention or AML features may need to be present in order to ensure that the UTXO cryptocurrency is not being used for illegal activities. As will be further explained below, in the current embodiment, cosigner module 220 provides the ability to review and verify whether an event is to be rejected. By logging the aforementioned enforcement data in database 224, database 224 may act as a log and / or a source of information for blockchain explorers. A person skilled in the art will recognize that there may be differences between industry standards and regulation requirements between different jurisdictions, which may then lead to different enforcement data being stored for each event in database 224. Database 224 may also be considered a centralized repository for the calculation of balances for UTXO based cryptocurrencies, which may be advantageous as the number of events and / or transactions grow, a centralized database 224 of transactions may aid in the processing speed of calculating balance.
[0063] In yet some other embodiments, memory 208 may further include schemas or reference tables (not shown) providing lists of the different event types, the different enforcementactions and lists of variables for the contract of each event type. In the current embodiment, the different event types / processes may include token minting, token burning, and token transactions.
[0064] Token Minting may be performed via the portal by an administrator. The minting process includes creating a specified number of tokens or UTXO cryptocurrency via an approval threshold, and transferring the newly minted tokens or UTXO cryptocurrency to user wallets 416.
[0065] Token Burning may be performed through a multiple signatory process, or via the approval of at least two administrators or owners, where a specified number of tokens or UTXO cryptocurrency are burned and removed from circulation. Burning token or UTXO cryptocurrency may include moving said tokens or UTXO cryptocurrency to be burned to a holding wallet. Any collateral may be returned to user wallet 416 through a manual process once the tokens or UTXO cryptocurrency are burnt.
[0066] Token transactions may be performed by request of the user from client terminal 108, specifically the process may be initiated from wallet 416. The user may specify an amount of UTXO cryptocurrency to be transferred to a destination wallet of another user.
[0067] In the current embodiment, the different enforcement actions may include token freezing / unfreezing, blacklisting / un-blacklisting, and token pausing.
[0068] Token freezing / un-freezing may include security measures to prevent specific flag addresses of wallets 416 from sending UTXO cryptocurrency. However, wallet 416 may still receive additional UTXO cryptocurrency. More specifically, token freezing / un-freezing prevents the sending from specifically identified wallets 416 but allows wallet 416 to continue acting as a receiver of UTXO cryptocurrency. A signature threshold may be required to freeze or unfreeze wallet 416.
[0069] Blacklisting / Un-blacklisting may include security measures to prevent a destination wallet 416 from receiving. A signature threshold may be required to blacklist or remove unblacklist a destination wallet 416.
[0070] Token pausing may include a security measure to halt all transactions that may be in progress or to decline any new transactions associated with all of the UTXO cryptocurrency.The paused state may remain in effect until a approved multi-signatory transaction is executed, upon which the UTXO cryptocurrency may resume all transactions.
[0071] For example, the schema associated with the contract accompanying the minting process may include the amount of a UTXO cryptocurrency to mint, the transaction fee associated with the minting process, and the signature from the cosigner module. The schema associated with the contract accompanying the transaction process may include the amount of a UTXO cryptocurrency to send, the transaction fee associated with the transaction process, the transaction fee in the UTXO cryptocurrency, and the return balance from the transaction. The schema associated with the contract accompanying the burning process may include the amount of a UTXO cryptocurrency to burn, the accompanying UTXO cryptocurrency itself, and the transaction fee associated with the burning process. A person skilled in the art will recognize the different potential variables that may be used in the schemas for the contracts of different processes.
[0072] In at least some embodiments, memory 208 stores contract module 216. Contract module 216 creates a contract based on the schema for contracts. Specifically, the contract may include the variables and logic provided from the schema. In the current embodiment, as will be further described below in an example, contract module 216 may follow a BSV21 token standard, which may include a ticket, a potential token supply, the precision of the number of decimal places associated with the token, and an icon. Furthermore, contract module 216 may include locking scripts in the contract which prevent any unit of the UTXO cryptocurrency from being spent to ensure that the contract associated with the UTXO cryptocurrency is not spent or lost. This will be further described below.
[0073] Contract module 216 may further create the partially signed contract upon approval from a user. Specifically, when a user, via a graphical user interface on client terminal 108, accepts a transaction fee and / or approves of the performance an event, such as the transfer of UTXO cryptocurrency, contract module 216 may partially sign the contract that was created. The partial signature is reflective of the user approving of the event and / or transaction to proceed.
[0074] In at least some embodiments, memory 208 stores cosigner module 220. Cosigner module 220. In a preferred embodiment, the execution of cosigner module 220 allows for the review and verification of the contract created associated with the event. For example, in an eventwhere it is a minting process, the cosigner module 220 may verify whether the contract associated with the minting process has all the variables as indicated in the schema for contracts associated with he minting process. The cosigner module 220 may further verify whether the minting process has been approved or whether the minting process has been blacklisted. Individual events, such as a minting process that is requested by a user, may be blacklisted for various reasons, including, but not limited to, the source of the request, the amount or value of the UTXO cryptocurrency that is being minted, or the destination of the UTXO cryptocurrency. A person skilled in the art will recognize the different potential reasons and variables that may lead to a UTXO cryptocurrency to have enforcement actions, such as being blacklisted, subjected to the event or transaction.
[0075] If the event is approved by the cosigner module 220, cosigner module 220 will then sign the partially signed contract, to create a complete signed contract (also referred to herein as a fully signed contract), and allow the event to proceed. If the event is not approved by the cosigner module 220, then cosigner module 220 will reject the contract, cosigner module 220 will not sign the partially signed contract, and the event or transaction will not proceed. For clarity, the cosigner module 220 is configured as a gateway to determine whether or not an event or transaction may proceed. The signing of the contract by cosigner module 220 allows for verification of the review and the decision to allow the event or transaction to proceed. Whether cosigner module 220 approves of an event and / or transaction is logged in database 224 for audit purposes, and will be further described below.
[0076] In some embodiments, cosigner module 220 may attach a network fee / gas token to the contract to allow for the event or transaction to occur. A person skilled in the art will recognize that a transaction will not occur without a gas token. In some other embodiments, cosigner module 220 may not sign the contract, but rather may attach the gas token to the contract in lieu of signing the contract. Specifically, if the event or transaction is verified to proceed by cosigner module 220, cosigner module 220 may attach the gas token to allow the event or transaction to proceed. Once the cosigner module 220 allows the event or transaction to proceed, either cosigner 220 or processor 204 may broadcast the event or transaction to the network for it to proceed. A person skilled in the art will recognize other actions that may be performed as verification of approval of the event or transaction.
[0077] Gas tokens may be retrieved from any wallet containing a native token. Specifically, a treasury or a pointer towards a treasury may be present in memory 208. The treasury may either reside in memory 208, or may be on a separate device or system connected via network 112. The treasure may include at least one wallet, from which minting, burning and or the retrieval of gas tokens may be performed. A person skilled in the art will recognize the different configurations of a treasury and the different wallets that the treasury may include.
[0078] Turning now to communications interface 212, it allows for processor 204 to communicate with network 112. Communications interface 212 includes suitable hardware (e.g. transmitters, receivers, network interface controllers and the like) allowing server 104 to send or receive communication signals and communicate with other components in system 100, such as client terminals 108. The specific components of communications interface 108 may be selected based on the type of network or other links server 104 may be required to communicate over. Specifically, communication signals may be sent or received according to one or more protocols according to one or more standards. The communications interface 212 may allow server 104 to communicate via a cellular data network, such as for example, according to one or more standards such as, for example, Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Evolution Data Optimized (EVDO), Long-term Evolution (LTE) or the like. Additionally or alternatively, the communications interface 212 may allow the server 104 to communicate using near-field communication (NFC), via Wi-Fi™, using Bluetooth™ or via some combination of one or more networks or protocols. In some embodiments, all or a portion of the communications interface 212 may be integrated into a component of server 104. For example, the communications interface 212 may be integrated into a communications chipset.
[0079] Server 104 may also include an I / O module (not shown) (input / output module). The I / O module allows server 104 to receive input from and / or to provide input to components of server 104 such as, for example, various input modules and output modules. For example, the EO module may allow server 104 to receive input from and / or provide output to a display. Other input devices that may connect to processor 204 via the EO module, may include a keyboard and mouse. Alternatively, or in addition, the input and output devices can be connected to processor 204 via a communications interface 212 via another computer device. In other words, input and output devices can be local to server 104 or remote.
[0080] In the preferred embodiment, network 112 is the Internet but a person skilled in the art will recognize that network 112 is not particularly limited in its configuration. Network 112 may be any form of network, including a local area network (LAN), or a wireless area network (WAN), and may be accessed by computers, mobile devices or the components of system 100. Computers, such as server 104 and client terminals 108 can operate in a networked environment using logical connections to one or more remote computers or other devices, such as a server, a router, a network personal computer, a personal computer, a peer device or other common network node, a wireless telephone or wireless personal digital assistant. The standards or protocols used for the network may include any form of transmission, such as Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol / Intemet Protocol (UDP / IP), Hyper Text Markup Language (HTML) and Hyper Text Transfer Protocol (HTTP). In addition, any desired levels and types of security and encryption protocols are contemplated and can be implemented over network 112. A person skilled in the art will recognize the different potential network types and different potential network configurations that may be used, along with the different standards and protocols of transmission within the network, and the different forms of security and encryption protocols available. Furthermore, as the data being transmitted between components of system 100, including between server 104 and client terminals 108 may include sensitive personal information and monetary values, industry standards for encryption in flight and encryption at rest may be applied or used.
[0081] Referring to FIG. 3, client terminals 108 may each be a computer device such as, but not limited to, a desktop computer, a laptop computer, another server, a kiosk, a cell phone, a tablet, a mobile device, a monitor or other suitable device. In a preferred embodiment, client terminals 108 are desktop computers or laptop computers. A person skilled in the art will also appreciate that other, different configurations of client terminals 108 are contemplated.
[0082] Each client terminal 108 includes a variety of modules. More specifically, client terminal 108 includes a processor 404 interconnecting a memory 408 and a communications interface 412. The processor 404 is a hardware processor. The processor 404 may, for example, be one or more ARM, Intel x86, Intel x64, AMD, PowerPC processors or the like. The processor may include a central-processing unit (CPU), a graphics processing unit (GPU), a microcontroller, a microprocessor, a processing core, a field-programmable gate array (FPGA), or similar. In someembodiments, the processor 404 can include multiple cooperating processors. The processor 404 can cooperate with non-transitory computer readable medium, such as the memory 408 to execute instructions to realize the functionality discussed herein.
[0083] Memory 408 can include a combination of volatile memory (e.g. Random Access Emmory or RAM) and non-volatile memory (e.g. non-volatile random-access memory, read only memory or ROM, Electrically Erasable Programmable Read Only memory or EEPROM, flash memory, solid state drives, hard disk drives). All or some of the memory 408 can be integrated with processor 404. Memory 408 stores computer reasonable instructions for execution by processor 404.
[0084] It will now be apparent that each element of memory 408 can be carried out by the processor 404 executing operations. In other words, functionality described below as being carried out by a module of memory 408 or a module of client terminal 108 can be based on any known computer environment.
[0085] In some embodiments, memory 408 stores a plurality of computer-readable data and programming instructions, accessible by processor 404, in the form of software objects, such as various applications, queries or types of data for use during the execution of those applications.
[0086] Memory 408 may also include an operating system. The operating system is software. The operating system allows the aforementioned application software to access processor 404, memory 408 and communications interface 412 of client terminal 108. The operating system may be, for example, Google™ Android™, Apple™ iOS™, UNIX™, Linux™, Microsoft™ Windows™, Apple™ macOS™ or the like.
[0087] In at least some embodiments, memory 408 stores wallet 416. Wallet 416 is a cryptocurrency wallet in which cryptocurrency may be stored. In the current embodiment, wallet 416 may store the UTXO cryptocurrency. A person skilled in the art will recognize the potential configuration and permutations of wallet 416 on client terminal 108.
[0088] Turning now to communications interface 412, it allows for processor 404 to communicate with network 112. Communications interface 412 includes suitable hardware (e.g. transmitters, receivers, network interface controllers and the like) allowing client terminal 108 tosend or receive communication signals and communicate with other components in system 100, such as server 104. The specific components of communications interface 108 may be selected based on the type of network or other links client terminal 108 may be required to communicate over. Specifically, communication signals may be sent or received according to one or more protocols according to one or more standards. The communications interface 412 may allow client terminal 108 to communicate via a cellular data network, such as for example, according to one or more standards such as, for example, Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Evolution Data Optimized (EVDO), Long-term Evolution (LTE) or the like. Additionally or alternatively, the communications interface 412 may allow the client terminal 108 to communicate using near-field communication (NFC), via Wi-Fi™, using Bluetooth™ or via some combination of one or more networks or protocols. In some embodiments, all or a portion of the communications interface 412 may be integrated into a component of client terminal 108. For example, the communications interface 412 may be integrated into a communications chipset.
[0089] Client terminal 108 may also include an I / O module (not shown) (input / output module). The EO module allows client terminal 108 to receive input from and / or to provide input to components of client terminal 108 such as, for example, various input modules and output modules. For example, the EO module may allow client terminal 108 to receive input from and / or provide output to a display. Other input devices that may connect to processor 404 via the EO module, may include a keyboard and mouse. Alternatively, or in addition, the input and output devices can be connected to processor 404 via a communications interface 412 via another computer device. In other words, input and output devices can be local to client terminal 108 or remote.
[0090] FIG. 4 is an alternate embodiment depicting components of memory 212 and memory 414 in a UTXO cryptocurrency ecosystem and their interactions. For further clarity, the cosigner module 220 is the main processing unit that receives the partially signed contract from the wallet 416. Upon receipt, it validates that the wallet 416 initiating the transaction is not blacklisted. After successful validation, the cosigner module 220 completes the transaction by fully signing it and then submits it to the UTXO cryptocurrency network for the completion of the transaction or event. A person skilled in the art will recognize the different potential configurationsand layouts of the different modules and / or application software and how they interact with each other.
[0091] FIG. 5 depicts the roles of each user with respect to each component or associated GUI. In a preferred embodiment, users may be part of a business entity and may be assigned roles, including, but not limited to, owner, administrator, auditor and a wallet user. For example, the owner role may refer to a position in an organization and may be assigned to an individual / group of individuals who owns and manage the UTXO cryptocurrency portal. The owner role permits the actor to have elevated privileges that allows him / her to configure, monitor, and control various aspects of the portal. The responsibilities and capabilities of the owner role may include having access to user management, system settings, access control and monitoring & reporting.
[0092] The administrator role may refer to a position in an organization and may be assigned to an individual and / or group of individuals who manage and oversee the functionality and settings within the UTXO cryptocurrency portal.
[0093] The auditor role may refer to a position in an organization and may be assigned to the user with read-only access or limited access to the portal. The auditor role is for the finance and / or accounting team to download read only information.
[0094] The wallet user role may refer to a position in the UTXO cryptocurrency ecosystem assigned to the end user of the UTXO cryptocurrency who via wallet 416 can send, receive, buy, sell and / or swap the UTXO cryptocurrency.
[0095] The portal is a graphical user interface on server 104 that allows the aforementioned designated users to perform functions related to the minting, management and enforcement of the UTXO cryptocurrency. The portal may be protected by VPN and accounts may have two-factor authentication enabled. A person skilled in the art will recognize the different industry standard security measures that may be in place to access and secure the portal. The portal may also have access management to provide permissions to different users and roles. The portal may also provide interface for multiple signatory control and / or enforcement. For example, the portal may provide administrators the ability to provide multiple signatory approval to black-list or unblacklist destination wallets 416.
[0096] The portal may also allow administrators to initiate certain token or UTXO cryptocurrency functions, including but not limited to, the minting process, the burning process, and other enforcement actions, such as pausing tokens, freezing address, and / or blacklisting destination wallet addresses. The portal may also allow for the setting or changing of the transaction fee to be charged from user wallets 416.
[0097] The portal may also allow administrators or owners to view audit logs from database 224 or activity logs of any actions taken by users who have access to the portal. The portal may also display any pending actions that require approval and may also allow the viewing of the satoshi index. The Satoshi index provides a log of all satoshi ordinal inscriptions, as will be explained in the below example embodiments. The portal may also act as or provide access to API endpoints to access any data from database 224 or to view the status of transactions.
[0098] Referring to FIGS. 6 to 18, different embodiments of events or transactions are depicted. Specifically, FIGS. 6 to 9 depict different embodiments of the minting process, FIGS.10 to 16 depict different embodiments of the transaction or transfer process, and FIGS. 17 to 20 depict different embodiments of the burning process. For clarity, each of said embodiments uses an example implementation or embodiment of the UTXO cryptocurrency. Specifically, and as will be described below, a stablecoin on the Bitcoin Satoshi Vision (BSV) blockchain is provided, where the ISatOrdinals protocol is used to carry the BSV21 payload. The stablecoin is further subjected to the cosigner module 220 to allow for enforcement actions and the logging of events or transactions.
[0099] More specifically, on the BSV blockchain, a satoshi with ordinal inscriptions is provided. A person skilled in the art will recognize that ordinal inscriptions have been used previously to inscribe artwork in a similar manner to non-fungible tokens as part of a Satoshi. In the present embodiment, the payload of the satoshi is the BSV21 payload, or the currency / value of the stablecoin itself.
[0100] Specifically, upon request of a event or transaction by a user, administrator or any other user in any role, a contract is created. The contract will need to be verified and signed by the cosigner module 220 prior to the event or transaction proceeding.
[0101] As part of the process of compiling the contract associated with the event or transaction, a transaction fee may be included within the contract. The transaction fee is a fee in the same currency as that of the stablecoin. The transaction fee may be variable, but may include both an equivalent value of the network fees / gas token (i.e. BSV) for the event and / or transaction, and may further include a service fee for the stablecoin operator. By using a single transaction fee, the wallet 416 user is not subjected to the requirement of having two currencies. For example, if a user wished to transfer from wallet 416 a value of 100 stablecoins, then a transaction fee of 1 stablecoin may be further charged to wallet 416. A BSV gas token is not pulled from wallet 416, but is rather taken from the wallet of server 104. As such, from a user perspective, wallet 416 on client terminal 108 only needs to have a single currency of stablecoin, rather than having the stablecoin currency and BSV in their wallet 416.
[0102] After packaging the contract based on the variables provided in the relevant schema, the contract is then provided to cosigner module 220 for verification and approval. The cosigner module 220 verifies the contract, and will either approve or rej ection the transaction. The cosigner module 220 will also log the event or transaction, whether approved or rejected, into database 224.
[0103] Upon approval, the event or transaction proceeds, which allows server 104 to inscribe the BSV21 or value of the stablecoin as part of the payload on the ISatOrdinals protocol. The network fee or gas token is also provided, allowing the event or transaction to proceed.
[0104] Referring to FIGS. 6 to 9, different embodiments of the minting operation are depicted. Specifically in FIG. 7, in or around block 704, the minting transaction is created. The transaction is verified by cosigner module 220 after which the cosigner module 220 attaches a signature to allow for the minting process to continue.
[0105] As part of the minting process, contracts module 216 may execute a locking script. The locking script prevents the satoshi with the inscription ordinal carrying the BSV21 payload or the stablecoin value, from being spent. Specifically, the locking script locks the satoshi from being spent and allows the satoshi to be merely used as a vehicle to carry the aforementioned payload.
[0106] Referring to FIGS. 10 to 15B, different embodiments of the transaction operation are depicted. Specifically in FIG. 10, in or around block 1104, the outputs from the transaction as requested from a user wallet 416 is depicted. The outputs include the stablecoin to be sent from wallet 416, the transaction fee in the stablecoin currency, and the stablecoin change to be returned to user wallet 416.
[0107] At block 1108, cosigner module 220 will check for any enforcement actions that may be pending against said transaction. As previously indicated, this may include checking for backlisting, freezing and / or pausing. Other checks that cosigner module 220 may perform include checking for invalid BSV21, checking that output 1104 includes a cosigning script, whether or not wallet 416 or the destination wallet address is frozen, whether wallet 416 or the destination wallet is blacklisted, whether a BSV21 input is present, or whether the wallet 416 is lacking funds or currency for the transaction itself. A person skilled in the art will recognize the different checks that cosigner module 220 may perform to determine whether or not a transaction may proceed.
[0108] Continuing at block 1108, cosigner module 220 may either reject the transaction or approve the transaction. In the current embodiment, if one of the aforementioned checks fail, cosigner module 220 may reject the transaction. If all the checks passed, cosigner module 220 may approve the transaction. In other embodiments (not shown), other checks may be non-compul sory or non-mandatory. In cases where checks may be non-mandatory, co-signor module 220 may still approve of the transaction as long as the mandatory checks are passed. A person skilled in the art will recognize the different logic that may be used to determine whether or not a transaction is approved or rejected.
[0109] At block 1112, after approval of the transaction, the transaction is prepared by inscribing the stablecoin balance on the new satoshi using the ISatordinal protocol, inscribing the transaction fee as part of the stablecoin balance on a separate satoshi using the ISatordinal protocol, re-inscribing the return balance on the original satoshi from wallet 416, and attaching a BSV network fee. The cosigner module 220 may then approve of the transaction to proceed.
[0110] The transaction is then logged as part of an audit log at database 224. A person skilled in the art will recognize the different variables that are stored as part of the audit log in database 224. The transaction is also broadcast to the network for the transaction to occur.
[0111] As part of the request to initiate a transaction from wallet 416 or the receipt of a stablecoin at a destination wallet 416, wallet 416 may include protocols to decrypt the ISatordinal protocol. For example, a destination wallet 416 may need the ISatordinal protocol to determine the BSV21 or stablecoin payload of the satoshi received.
[0112] Referring to FIGS. 16 to 19, different embodiments of the burning operation are depicted. Specifically, in FIG 17, in or around block 1604, the burning transaction is created. The transaction is verified by cosigner module 220 after which cosigner module 220 attaches a signature to allow for the burning process to continue.
[0113] It will be understood that the applications, modules, routines, processes, threads, or other software components implementing the described method / process may be realized using standard programming techniques and languages. The present application is not limited to particular processors, computer languages, computer programming conventions, data structures, or other such implementation details. Those skilled in the art will recognize that the described processes may be implemented as part of computer-executable code stored in volatile or nonvolatile memory, as part of an application-specific integrated chip (ASIC), etc.
[0114] Referring to FIGS. 20A, 20B and 20C, an embodiment showing the buying operation via ACH is depicted. This process includes the treasury receiving a request to send UTXO cryptocurrency to customer’s wallet. The treasury or contract module 216 may then prepare the transaction with UTXOs containing the amount and partially sign the UTXO or contract. The partially signed contract or UTXO may then be sent to cosigner module 220. The cosigner module 220 may then authorize or validate the request. If the request is valid or approved, then the cosigner module 220 may add the transaction fee in the native token. The cosigner module 220 may then proceed to send the transaction to the network. Cosigner module 220 may then return the transaction hash to the treasury.
[0115] Referring to FIGS. 21A, 21B and 21C, an embodiment showing the buying operation using credit card or debit card is depicted. Referring to FIGS. 22A, 22B and 22C, an embodiment of the selling operation is depicted. Referring to FIGS. 23 A and 23B, an embodiment of a swapping operation is depicted.
[0116] A person skilled in the art will recognize that similar operations may apply towards the conversion or transfer of UXTO cryptocurrency towards other types of cryptocurrency, such as Etherium.
[0117] As noted, certain adaptations and modifications of the described embodiments can be made. Therefore the above discussed embodiments are considered to be illustrative and not restrictive.
[0118] Although the foregoing description and accompanying drawings to specific preferred embodiments of the present invention as presently contemplated by the inventor, it will be understood that various changes, modifications and adaptations, may be made without departing from the spirit of the invention.
Claims
WHAT IS CLAIMED IS:
1. A method for minting a token, the method comprising:receiving a token value;creating a transaction for minting, the transaction including a Satoshi, the token value, a partially signed contract, and a network fee;determining whether the transaction is validated;if the transaction is validated:signing the partially signed contract to create a complete signed contract in the transaction; andproviding the transaction to a miner, the miner being configured to mine the transaction to create a minted Satoshi with the token value.
2. The method of claim 1 further comprising verifying the identity of two administrators for approval of the transaction prior to creating the transaction for minting.
3. The method of claim 1 or 2 further comprising receiving the minted Satoshi from the miner.
4. The method of claim 3 further comprising verifying the token value on the minted Satoshi.
5. The method according to any one of claims 1 to 4, wherein the network fee is received from a network fee wallet.
6. The method according to claim 5 further comprising depositing the minted Satoshi into a treasury wallet.
7. The method according to claim 6, wherein the treasury wallet and the network fee wallet are the same digital wallet.
8. The method according to any one of claims 1 to 7, wherein the token is an Unspent Transaction Output (UTXO) based cryptocurrency.
9. The method according to any one of claims 1 to 8, wherein the step of determining whether the transaction is validated includes determining whether an enforcement action is present, where if an enforcement action is present, the transaction is not validated.
10. The method of claim 9, wherein the enforcement action is selected from the group consisting of at least one of the source address or the destination address being blacklisted, the source address being frozen, and the token being paused.
11. The method according to any one of claims 1 to 10, wherein the network fee is Bitcoin Satoshi Vision (BSV) currency.
12. The method of claim 11, wherein the miner is a BSV miner.
13. The method according to any one of claims 1 to 12, wherein the step of signing the partially signed contract to create the complete signed contract in the transaction, is performed by a cosigner module.
14. The method according to any one of claims 1 to 13 further comprising verifying the conformance of the transaction to a schema prior to signing the partially signed contract to create a complete signed contract.
15. The method according to claim 14, wherein the schema includes the Satoshi, the token value, the partially signed contract, and the network fee.
16. The method of claim 14, wherein the step of determining whether the transaction is validated includes determining the transaction is not validated if the transaction fails to conform to the schema.
17. The method according to any one of claims 1 to 16 wherein the step of determining whether the transaction is validated includes sending an error message to a graphical user interface if the transaction is not validated.
18. The method according to any one of claims 1 to 17, wherein the minted Satoshi with the token value is the token value inscribed as part of a Satoshi payload in accordance with a 1 SatOrdinales protocol.
19. A method for transferring a token, the method comprising:creating a transaction, the transaction including a source address, a destination address, a token value being sent from the source address to the destination address, a transaction fee and a first Satoshi with a token balance inscribed from the source address;determining whether the transaction is validated;if the transaction is validated:signing the partially signed contract to create a complete signed contract in the transaction;inscribing the token value being sent from the source address to the destination address onto a second Satoshi, the transaction including the second Satoshi;inscribing the transaction fee onto a third Satoshi, the transaction including the third Satoshi;attaching a network fee to the transaction;re-inscribing the return balance onto the first Satoshi in the transaction, wherein the return balance is the token balance on the first Satoshi prior to re-inscribing after the token value and the transaction fee have been removed; andproviding the transaction to a miner, the miner being configured to broadcast the transaction to a network.
20. The method of claim 19, wherein the transaction fee and the token value are the same currency.
21. The method of claim 19 or 20 further comprising:sending the first Satoshi to the source address;sending the second Satoshi to the destination address; andsending the third Satoshi to a treasury wallet.
22. A method for burning a token, the method comprising:receiving a token value from a source address;creating a transaction for burning, the transaction including a first Satoshi inscribed with the token value, a second Satoshi, a partially signed contract, and a network fee;determining whether the transaction is validated;if the transaction is validated:signing the partially signed contract to create a complete signed contract in the transaction;re-inscribing a zero token value onto the first Satoshi, the transaction including the first Satoshi;inscribing the token value onto the second Satoshi, the transaction including the second Satoshi; andproviding the transaction to a miner, the miner being configured to mine the transaction.
23. The method of claim 22 further comprising:sending the first Satoshi to the source address; andsending the second Satoshi to a holding wallet.
24. The method of claim 21 or 22 further comprising verifying whether a wallet at the source address includes the Satoshi inscribed with the token value prior to creating the transaction for burning.
25. A computer-implemented method for managing a blockchain, the method comprising:receiving a user confirmed request for the transferring of a data package from a source address to a destination address, the data package to include at least the source address, the destination address, and a partially signed contract;determining whether the source address and the destination address is authorized;if the source address and the destination address is authorized:signing the partially signed contract to create a complete signed contract;broadcasting the data package to a network for the completion of the user confirmed request; andlogging the data package and the complete signed contract to a centralized database;if at least one of the source address or the destination address is not authorized: flagging the partially signed contract as incomplete; andlogging the data package and the partially signed contract to the centralized database.