Method and system for managing programmable currency-based transactions through nested smart contract-based wallet

Abstract

Methods and systems are disclosed for managing programmable currency-based transactions through a nested smart contract-based wallet. A method performed by a server system includes receiving a fund transfer of digital currency associated with a smart contract including a set of predefined instructions from a first wallet to a second wallet. The method includes determining a transaction category of the digital currency based on the set of predefined instructions. The transaction category indicates the purpose of fund transfer according to the smart contract. The method includes generating the digital currency based on a transaction category of the digital currency and depositing the digital currency into a new sub-wallet associated with the second wallet. Each of the new sub-wallets is eligible to hold the digital currency for a particular transaction category. Alternatively, the method includes depositing the digital currency into a pre-existing sub-wallet. Each of the pre-existing sub-wallets is eligible to hold the digital currency for the particular transaction category.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of Indian Patent Application No. 202341050828, filed on July 27, 2023. The entire disclosure of the above application is incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of blockchain-based digital currencies, and more particularly to methods and systems for managing transactions based on programmable digital currencies in a blockchain network via wallets based on nested smart contracts. Background Technology

[0004] With technological advancements, various countries have begun developing their own digital currencies. These digital currencies generally operate on permissioned blockchain networks or centralized blockchains. As can be understood, digital currencies offer various benefits, such as financial inclusion, enhanced security, traceability, reduced transaction fees, and improved tax administration. Several examples of existing digital currencies or central bank digital currencies (CBDCs) include the Reserve Bank of India's (RBI) e-Rupee, the People's Bank of China's (PBOC) e-RMB, the Central Bank of Nigeria's e-Naira, and Russia's digital ruble. The term "central bank digital currency" refers to a form of digital currency issued by a country's central government. It's important to note that CBDCs are similar to cryptocurrencies, except that their value is fixed by the central bank and equivalent to the country's legal tender. Generally, to execute payment transactions using CBDCs, users need a CBDC wallet that can hold, send, and receive CBDC funds going to and from various sources. Although CBDCs appear promising in experimental environments, their practical implementation still has many shortcomings. For example, existing CBDC wallets suffer from user experience issues, primarily in terms of accessibility, and lack the appropriate infrastructure for building them.

[0005] In this regard, it is understandable that current CBDC wallets are owned by banks. Therefore, such CBDC wallets are similar to wallets associated with an External Ownership Account (EOA), which requires users to have a combination of public and private keys (or a Personal Identification Number (PIN)) to access their wallets. This process is complex and difficult for users to understand in terms of its creation and use, thus limiting its adoption to tech enthusiasts and hindering widespread adoption. Furthermore, existing CBDC wallets provided by banking institutions fail to fully utilize the programmability benefits offered by digital currencies.

[0006] Therefore, there is a technological need for improved methods and systems for providing digital infrastructure that can be integrated with existing CBDC infrastructure, thereby providing a platform with a better user experience that fully leverages the programmability features of CBDC. Summary of the Invention

[0007] Various embodiments of this disclosure provide methods and systems for managing programmable currency-based transactions via a wallet based on nested smart contracts.

[0008] In one embodiment, a computer-implemented method is disclosed for managing transactions based on programmable currency through a wallet based on nested smart contracts. The computer-implemented method, executed by a server system, includes receiving a transfer of digital currency from a first wallet to a second wallet. The digital currency is associated with at least one smart contract. Herein, the smart contract includes a set of predefined instructions. Additionally, the computer-implemented method includes determining a transaction category of the digital currency based at least partially on the set of predefined instructions. Herein, the transaction category indicates the purpose of the fund transfer according to the smart contract. Furthermore, the computer-implemented method includes generating received digital currency based at least partially on the transaction category of the received digital currency and depositing the received digital currency into one or more new sub-wallets associated with the second wallet. Herein, each of the one or more new sub-wallets is eligible to hold digital currency for a specific transaction category. Alternatively, the computer-implemented method includes depositing the received digital currency into one or more pre-existing sub-wallets. Herein, each of the one or more pre-existing sub-wallets is eligible to hold digital currency for a specific transaction category.

[0009] In another embodiment, a computer-implemented method is disclosed. The computer-implemented method, executed by a server system, includes receiving a funds transfer request from the owner of a second wallet to transfer funds to a third wallet. Herein, the funds transfer request is associated with digital currency deposited in a pre-existing sub-wallet of the second wallet. The computer-implemented method includes accessing wallet category data from a database associated with the server system. Additionally, the computer-implemented method includes determining the wallet category of the third wallet, at least in part, based on the wallet category data. Furthermore, the computer-implemented method includes determining, at least in part, whether the pre-existing sub-wallet is eligible to transfer funds to the third wallet, based on the wallet category and the transaction category of the pre-existing sub-wallet. After determining that the pre-existing sub-wallet is eligible to transfer funds to the third wallet, the computer-implemented method further includes approving the funds transfer request and transferring the digital currency from the pre-existing sub-wallet to the third wallet. Alternatively, after determining that the pre-existing sub-wallet is not eligible to transfer funds to the third wallet, the computer-implemented method includes rejecting the funds transfer request.

[0010] In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicatively coupled to the memory. The processor is configured to execute instructions to at least partially cause the server system to receive a transfer of digital currency funds from a first wallet to a second wallet. The digital currency is associated with at least one smart contract. Additionally, the smart contract includes a set of predefined instructions. The server system is also caused to determine the transaction category of the digital currency based at least partially on the set of predefined instructions. Hereinafter, the transaction category indicates the purpose of the fund transfer according to the smart contract. Furthermore, the server system is caused to perform one of the following operations: One operation includes generating received digital currency based at least partially on the transaction category of the received digital currency and depositing the received digital currency into one or more new sub-wallets associated with the second wallet. Hereinafter, each of the one or more new sub-wallets is eligible to hold digital currency for a specific transaction category. Another operation includes depositing the received digital currency into one or more pre-existing sub-wallets. Hereinafter, each of the one or more pre-existing sub-wallets is eligible to hold digital currency for a specific transaction category.

[0011] In another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes receiving a transfer of digital currency from a first wallet to a second wallet. The digital currency is associated with at least one smart contract. Herein, the smart contract includes a set of predefined instructions. Additionally, the method includes determining a transaction category of the digital currency based at least in part on the set of predefined instructions. Herein, the transaction category indicates the purpose of the fund transfer according to the smart contract. Furthermore, the method includes generating received digital currency based at least in part on the transaction category of the received digital currency and depositing the received digital currency into one or more new sub-wallets associated with the second wallet. Herein, each of the one or more new sub-wallets is eligible to hold digital currency for a specific transaction category. Alternatively, the method includes depositing the received digital currency into one or more pre-existing sub-wallets. Herein, each of the one or more pre-existing sub-wallets is eligible to hold digital currency for a specific transaction category. Attached Figure Description

[0012] To gain a more complete understanding of exemplary embodiments of this technology, reference is now made to the following description taken in conjunction with the accompanying drawings, wherein:

[0013] Figure 1 The illustrations depict exemplary representations of environments relevant to at least some exemplary embodiments of this disclosure;

[0014] Figure 2 A simplified block diagram of a server system according to an embodiment of the present disclosure is shown;

[0015] Figure 3A The illustration shows a block diagram of a digital architecture associated with a server system according to an embodiment of the present disclosure;

[0016] Figure 3B The illustration depicts a schematic representation of a digital currency linked to a smart contract and a smart wallet contract according to embodiments of the present disclosure;

[0017] Figure 4 A block diagram of an example wallet having one or more sub-wallets according to an embodiment of the present disclosure is illustrated;

[0018] Figure 5 The illustration shows a block diagram of a fund transfer process from a source wallet to a destination wallet according to an embodiment of the present disclosure;

[0019] Figure 6 The illustration shows a process flowchart depicting a method for facilitating fund transfers from a first wallet to a second wallet according to embodiments of the present disclosure; and

[0020] Figure 7 The illustration shows a process flow diagram depicting a method for facilitating the transfer of funds from a second wallet to a third wallet according to an embodiment of the present disclosure.

[0021] The accompanying drawings referenced in this description should not be construed as being drawn to scale unless otherwise stated, and such drawings are merely illustrative in nature. Detailed Implementation

[0022] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of this disclosure. However, it will be apparent to those skilled in the art that this disclosure may be practiced without these specific details. Descriptions of well-known components and processing techniques have been omitted so as not to unnecessarily obscure the embodiments herein. The examples used herein are intended only to facilitate an understanding of how the embodiments herein may be practiced, and further to enable those skilled in the art to practice the embodiments herein. Therefore, the examples should not be construed as limiting the scope of the embodiments herein.

[0023] References to "an embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of this disclosure. The appearance of the phrase "in an embodiment" in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a single or alternative embodiment that is mutually exclusive with other embodiments. Furthermore, various features that may be embodied in some embodiments but not in others are described. Similarly, various requirements that may be requirements of some embodiments but not others are described.

[0024] Furthermore, although the following description contains many specific details for illustrative purposes, those skilled in the art will recognize that many variations and / or modifications to these details are within the scope of this disclosure. Similarly, although many features of this disclosure are described by way of or in combination with each other, those skilled in the art will recognize that many of these features may be provided independently of the others. Therefore, this description of the disclosure is set forth without loss of generality and without imposing limitation upon the disclosure.

[0025] The embodiments of this disclosure can be implemented as an apparatus, system, method, or computer program product. Therefore, embodiments of this disclosure can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects (all of which can generally be referred to herein as a "circuit," "engine," "module," or "system"). Furthermore, aspects of this disclosure can take the form of a computer program product embodied in one or more computer-readable storage media on which computer-readable program code is embodied.

[0026] For clarification purposes, the terms "digital currency," "digital money," "electronic money," or "electronic currency" are used interchangeably throughout the description and refer to a form of money that exists in digital form and is managed, stored, or exchanged primarily on digital computer systems, especially via the Internet. Examples of digital currencies include virtual currencies, cryptocurrencies (or cryptocoins), central bank digital currencies (CBDCs), etc. More specifically, cryptocurrencies are digital assets that operate on their own independent blockchains (i.e., distributed, immutable ledgers). Other digital assets include crypto tokens. The terms "crypto token," "cryptocurrency token," or "token" are used interchangeably throughout the description and refer to digital assets similar to cryptocurrencies but operating on existing blockchain networks. It is important to note that cryptocurrencies are primarily used as a medium of exchange, while crypto tokens can provide a wide range of functionalities within the ecosystem of a specific project.

[0027] The term "ledger" used throughout this description refers to a collection of accounts that record transactions. The term "central ledger," however, can refer to a ledger in which a central institution is responsible for storing and maintaining the financial transaction data. For example, a bank might use a centralized ledger to maintain customer account balances, transaction history, and other financial information. In the case of a CBDC, the central bank could be the central institution.

[0028] The terms "wallet," "digital wallet," or "electronic wallet," used interchangeably throughout this description, generally refer to a financial transaction application that runs on a connected device and facilitates electronic transactions for individuals. Wallets traditionally have an External Ownership Account (EOA) and securely store payment information and passwords in the cloud. More specifically, wallets are used for transactions of tokens or digital currencies on blockchain networks.

[0029] Additionally, the term "smart contract" used throughout this description refers to a simple program stored on a blockchain that runs when predetermined conditions are met. Accounts created on the blockchain to facilitate the deployment of smart contracts are called "contract accounts."

[0030] In a particular implementation, the terms "smart contract wallet," "smart wallet," or "smart contract-based wallet," used interchangeably throughout the description, refer to an Ethereum-based wallet managed by smart contracts rather than private keys. Alternatively, it can also refer to a wallet built on a new network with account abstraction capabilities.

[0031] The term "account abstraction," used throughout this description, generally refers to separating wallet control from its associated private key and utilizing smart contracts to perform its actions. Therefore, it can be understood that a user's digital assets are stored in a smart contract rather than in an EOA. The concept of account abstraction provides programmability to wallets, thus offering greater flexibility and security for transactions of digital assets (such as cryptocurrencies) between wallets (such as smart wallets). Cryptocurrencies that have applied account abstraction can also be called "programmable money." In other words, cryptocurrencies linked to smart contracts can be called "programmable money."

[0032] Overview

[0033] Various embodiments of this disclosure provide methods, systems, electronic devices, and computer program products for managing transactions based on programmable digital currencies in a blockchain network via wallets based on nested smart contracts. In a non-limiting implementation, a server system may be configured to receive transfers of digital currency funds from a first wallet to a second wallet. The digital currency may be associated with at least one smart contract. In this document, a smart contract may include a set of predefined instructions. Note that, in embodiments, the server system is also configured to facilitate the generation of at least one smart contract including a set of predefined instructions. Additionally, the at least one smart contract may be intended to execute a set of predefined instructions when predefined conditions are met. Furthermore, the server system may link at least one smart contract with the digital currency to be transferred from the first wallet to the second wallet. Moreover, the server system may transfer the digital currency linked to the at least one smart contract to the second wallet.

[0034] The server system can also be configured to determine the transaction category of the digital currency based at least in part on a set of predefined instructions. Here, the transaction category may indicate the purpose of a fund transfer according to a smart contract. In one embodiment, the server system is configured to generate received digital currency based at least in part on the transaction category of the received digital currency and deposit the received digital currency into one or more new sub-wallets associated with a second wallet. Here, each of the one or more new sub-wallets may be eligible to hold digital currency for a specific transaction category. In another embodiment, the server system is configured to deposit the received digital currency into one or more pre-existing sub-wallets. Here, each of the one or more pre-existing sub-wallets may be eligible to hold digital currency for a specific transaction category.

[0035] In a particular embodiment, the server system generates one or more wallets, including a first wallet, a second wallet, and a third wallet, at least in part based on funds to be transferred via digital currency. To generate wallets, the server system may generate one or more application programming interface (API) endpoints to facilitate the exchange of one or more API calls between one or more wallet providers and corresponding one or more financial institutions. Additionally, the server system may receive wallet generation requests from one or more wallet providers through one or more API endpoints. Furthermore, the server system may transmit wallet generation requests to corresponding one or more financial institutions through one or more API endpoints. In response to a wallet generation request, the server system may receive a wallet authorization response from one or more financial institutions. Herein, the wallet authorization response may indicate authorization for at least one of the one or more wallet providers, at least in part, based on one or more API calls. In response to authorization for at least one of the one or more wallet providers, the server system may facilitate the creation of one or more wallets by the corresponding wallet provider.

[0036] In a non-limiting implementation, the server system may link each of one or more new sub-wallets to at least one wallet smart contract indicating wallet eligibility criteria. As previously described, the server system may determine the eligibility of one or more new sub-wallets to hold cryptocurrency for a specific transaction category. To determine eligibility, the server system may execute at least one smart contract associated with the cryptocurrency and at least one wallet smart contract associated with each of the one or more new sub-wallets. Additionally, in one embodiment, the server system determines whether at least one of the one or more new sub-wallets is eligible to hold cryptocurrency based at least on the execution of at least one smart contract and at least one wallet smart contract. In such an embodiment, the server system determines that at least one of the one or more new sub-wallets is eligible to hold cryptocurrency when the execution of at least one smart contract and at least one wallet smart contract indicates that the purpose of the corresponding new sub-wallet matches the transaction category of the cryptocurrency. In such an alternative embodiment, the server system determines that at least one of the one or more new sub-wallets is not eligible to hold cryptocurrency when the execution of at least one smart contract and at least one wallet smart contract indicates that the purpose of the corresponding new sub-wallet does not match the transaction category of the cryptocurrency.

[0037] In another non-limiting implementation, the server system may link each of one or more pre-existing sub-wallets to at least one wallet smart contract indicating wallet eligibility criteria. As previously described, the server system may determine the eligibility of one or more pre-existing sub-wallets to hold digital currency for a specific transaction category. To determine eligibility, the server system may execute at least one smart contract associated with the digital currency and at least one wallet smart contract associated with each of the one or more pre-existing sub-wallets. Additionally, in one embodiment, the server system determines whether at least one of the one or more pre-existing sub-wallets is eligible to hold digital currency based at least on the execution of at least one smart contract and at least one wallet smart contract. In such an embodiment, the server system determines that at least one of the one or more pre-existing sub-wallets is eligible to hold digital currency when the execution of at least one smart contract and at least one wallet smart contract indicates that the purpose of the corresponding pre-existing sub-wallet matches the transaction category of the digital currency. In another such embodiment, the server system determines that at least one of the one or more pre-existing sub-wallets is not eligible to hold digital currency when the execution of at least one smart contract and at least one wallet smart contract indicates that the purpose of the corresponding pre-existing sub-wallet does not match the transaction category of the digital currency.

[0038] In a specific scenario, the owner of the second wallet needs to spend the cryptocurrency in the second wallet. Therefore, a funds transfer request can be generated, which can be received by the server system. The funds transfer request may include a request to transfer funds from the second wallet to a third wallet. In this document, the funds transfer request may be associated with cryptocurrency deposited into a pre-existing sub-wallet of the second wallet. Additionally, the server system can access wallet category data from a database associated with the server system. The server system can then determine the wallet category of the third wallet, at least in part, based on the wallet category data. Furthermore, the server system determines, at least in part, whether the pre-existing sub-wallet is eligible to transfer funds to the third wallet, based on the wallet category and the transaction categories of the pre-existing sub-wallet.

[0039] In one embodiment, after determining that a pre-existing sub-wallet is eligible to transfer funds to a third wallet, the server system approves the fund transfer request and transfers the digital currency from the pre-existing sub-wallet to the third wallet. In another embodiment, after determining that a pre-existing sub-wallet is not eligible to transfer funds to a third wallet, the server system rejects the fund transfer request. In a non-limiting implementation, the server system may link the third wallet to at least one wallet smart contract indicating wallet eligibility conditions. As previously described, the eligibility of a pre-existing sub-wallet to transfer funds to a third wallet is also determined. To determine eligibility, the server system may execute at least one smart contract associated with the digital currency of the funds and at least one wallet smart contract associated with each of the pre-existing sub-wallet and the third wallet. In one embodiment, the server system may determine that a pre-existing sub-wallet is eligible to transfer funds in the form of digital currency to the third wallet when the execution of at least one smart contract and at least one wallet smart contract indicates that the wallet category of the third wallet matches the transaction category of the pre-existing sub-wallet. In another embodiment, the server system determines that a pre-existing sub-wallet is not eligible to transfer funds in the form of digital currency to the third wallet when the execution of at least one smart contract and at least one wallet smart contract indicates that the wallet category of the third wallet does not match the transaction category of the pre-existing sub-wallet.

[0040] Various embodiments of this disclosure offer several advantages and technical effects. For example, the methods and systems proposed in this disclosure enable the customization of wallets through smart contracts, thereby supporting multiple use cases. In this document, a wallet can hold multiple sub-wallets, which can also be smart contracts, thus providing the wallet with a framework based on nested smart contracts. Additionally, some smart contracts can trigger smart contracts in other wallets, depending on the use case. For example, an individual may have a sub-wallet dedicated to rationed subsidies within their main wallet. A smart contract is linked to the sub-wallet, which is programmed such that the digital assets within that sub-wallet can only be used at ration stores in that region. Furthermore, the smart contract can also be programmed to execute only when the system facilitating the execution of the smart contract has access to the merchant's (such as a ration store in that region) data. Therefore, it is understood that such a framework regulates the flow of digital assets between different wallets according to a specific scheme (such as any government scheme, reimbursement scheme, etc.). Thus, the concept of having dedicated sub-wallets, nested smart contracts, or a framework based on nested smart contracts for each wallet is unique and advantageous.

[0041] In this regard, for example, the systems and methods proposed in this disclosure make it possible to easily distribute government subsidies without the risk of money leakage (e.g., due to corruption). Furthermore, the methods proposed in this disclosure contribute to the creation of a distributed ecosystem that emphasizes anonymity and trust. Moreover, it can be noted that smart contract wallets offer developers and third-party applications flexibility in setting their security protocols for user participation. And, compared to existing disbursement systems such as the Unified Payments Interface (UPI), ease of customization will give it a competitive advantage. Furthermore, the digital infrastructure proposed in this disclosure can be integrated with various technology stacks, such as Adhaar, UPI, the Open Network for Digital Commerce (ONDC), etc.

[0042] Additionally, if a user forgets their private key, their wallet can be recovered through a social recovery process, where the user can designate multiple trusted individuals as recovery proxies by creating a smart contract for this purpose. Furthermore, multi-signature wallets can be implemented, where accounts can be programmed to require multiple signatures before executing a transaction, effectively making each account a multi-signature wallet by default. This feature has many real-world use cases, such as public wallets. It is also understandable that, leveraging account abstraction, transactions can be scheduled with time delays or based on event-driven processes. This would allow users to set up recurring payments on self-custodial wallets.

[0043] The following text is for reference only. Figures 1 to 7 Various exemplary embodiments of this disclosure are described.

[0044] Figure 1 The illustration shows an example representation of an environment 100 in relation to at least some of the example embodiments of this disclosure. Although environment 100 is presented in one arrangement, other embodiments may include portions (or other portions) of environment 100 that rely on managing programmable currency-based transactions, for example, through a wallet based on nested smart contracts.

[0045] like Figure 1 An example of the environment 100 depicted includes a server system 102, a first user device 104 associated with a first user 106, a second user device 108 associated with a second user 110, a third user device 112 associated with a third user 114, and a database 116 connected to and communicating with (and / or accessible from) a wireless communication network (e.g., network 118).

[0046] It is noteworthy that banks currently offer digital currency wallets, such as central bank digital currency (CBDC) wallets, where users need to enter secret keys (such as personal identification numbers (PINs)) for specific transactions to occur. However, when compared to traditional banking applications, user experience (UX) has become a major factor in the widespread adoption of CBDCs (hereinafter, interchangeably referred to as "e-Rupee") and in giving the highly user-friendly Unified Payments Interface (UPI) a competitive advantage. Furthermore, existing CBDC wallets lack the appropriate infrastructure for their deployment and record keeping. Therefore, there is a possibility that funds from such wallets could be misused. For example, if a central government deposits funds into a specific user's CBDC wallet as rationing subsidies. In this context, rationing subsidies mean the purchase of rationed goods. However, since such transactions are not recorded, users could misuse these funds by spending them for other purposes, such as purchasing illicit goods instead of rationed items. Therefore, there is a need to establish methods that can facilitate seamless transactions and tracking (i.e., record keeping) of CBDCs between CBDC wallets without requiring secret keys.

[0047] Therefore, the aforementioned technical problems and other issues are solved through one or more embodiments implemented by the server system 102 and its methods provided in this disclosure. It should be noted that the server system 102 is intended to implement a method for introducing the concept of smart contract wallets for transactions of digital currencies such as CBDCs. These wallets are programmable, meaning that each wallet is a smart contract that can contain logic and implement specific processes.

[0048] More specifically, in a non-limiting implementation, this disclosure proposes methods and systems for managing programmable money-based transactions via a nested smart contract-based wallet. In other words, it can be noted that this disclosure provides digital currency payment providers (also referred to as "wallet providers") and / or developers with digital infrastructure to create and operate customized wallets using smart contract wallets for the use of programmable money or programmable currencies (such as CBDCs) for user-specific use cases or conditions. In this document, the term "programmable money-based transaction" refers to a transaction of funds in the form of programmable currency (such as digital currencies (e.g., CBDCs)). Similarly, the term "nested smart contract-based wallet" refers to a wallet linked to a smart contract and capable of having multiple sub-wallets. In this document, each sub-wallet may be further linked to another smart contract.

[0049] In a non-limiting example, the first user 106 may correspond to a user or entity that is the source of money or digital currency. In another non-limiting example, the first user 106 may be an entity that initiates a transfer of digital currency to a destination wallet (such as a wallet owned by the second user 110). It is noteworthy that the transfer of funds may use smart contracts attached to spending conditions. In this document, spending conditions indicate conditions under which the destination wallet is allowed to spend funds if a match is met. In one embodiment, the first user 106 may be a government agency or entity that wishes to transfer subsidies (or government incentives) to one or more wallets of the public. As can be noted herein, the government entity may restrict the subsidy funds to be used by the public receiving them for predefined purposes. In another embodiment, the first user 106 may be a parent transferring digital currency to a child's wallet. In this document, the digital currency may be programmed to be used only for paying school fees and not for any other purpose. Therefore, it is noteworthy that the first user 106 may be a government, individual, private company, bank, merchant, service provider, business owner, insurance company, employer, other financial institution, medical institution, etc.

[0050] Similarly, in a non-limiting example, the second user 110 could be a customer or individual dependent on the first user 106 for receiving funds. Hereinafter, funds correspond to programmable money programmed for use only for a specific purpose. Therefore, in embodiments, the second user 110 includes any individual, employee, employer, representative of a corporate entity, child, student, or any other person willing to receive funds from the first user 106 for several purposes.

[0051] In another embodiment, the third user 114 may be a user or entity that executes and terminates a smart contract linked to money or cryptocurrency. Therefore, the third user 114 can be referred to as the intended destination of funds transferred from a source. In embodiments, the third user 114 includes merchants, schools, retail stores, institutions, the first user 106, etc.

[0052] In various non-limiting examples, the first user device 104, the second user device 108, and the third user device 112 may include any suitable electronic device, such as a smartphone, personal computer, laptop, personal digital assistant (PDA), tablet, desktop computer, wearable device, smart device (such as a live camera, smart TV or smart home appliance, smartwatch), and other suitable electronic devices capable of hosting or operating a digital currency wallet.

[0053] Network 118 may include, but is not limited to, Li-Fi networks, local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), satellite networks, the Internet, fiber optic networks, coaxial cable networks, infrared (IR) networks, radio frequency (RF) networks, virtual networks, and / or networks capable of supporting... Figure 1 The communication between two or more of the portions or users shown in the diagram is another suitable public and / or private network, or any combination thereof.

[0054] Various entities in environment 100 can connect to network 118 according to various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), 2G, 3G, 4G, 5G, LTE, NR, any future communication protocols, or any combination thereof. In some cases, network 118 may utilize security protocols (e.g., Hypertext Transfer Protocol (HTTP), Secure Sockets Layer (SSL), and / or any other protocol or set of protocols) to communicate with... Figure 1 The various entities depicted communicate with each other.

[0055] In several embodiments, server system 102 may be deployed as a standalone application, client / server, website, or implemented as Software as a Service (SaaS) in the cloud. In a non-limiting implementation, server system 102 provides or hosts a website or application on first user device 104, enabling first user 106 to access features facilitated by server system 102, such as creating smart contracts, linking created smart contracts to digital currency, initiating fund transfers, executing or triggering smart contracts associated with received digital currency, etc. Similarly, an instance of the website or application may be accessible to second user 110, which is accessible on second user device 108. This enables second user 110 to receive digital currency linked to a smart contract and further use it for the purpose specified by the smart contract linked to the received digital currency. Additionally, in embodiments, an instance of the website or application is also accessible on third user device 112, enabling third user 114 to receive funds, execute smart contracts, and terminate them therein.

[0056] Additionally, it can be noted that in order for the first user 106, the second user 110, and the third user 114 to participate in the transfer of funds in digital currency linked to the smart contract, the first user 106, the second user 110, and the third user 114 may need to link their accounts to the first wallet 120, the second wallet 122, and the third wallet 124, respectively. In this document, each of the first wallet 120, the second wallet 122, and the third wallet 124 can refer to a smart contract-based digital currency wallet with account abstraction capabilities. Therefore, these wallets are capable of receiving and transferring digital currency linked to the smart contract, and also have the ability to trigger or execute the smart contract. In one embodiment, each of one or more wallets (such as the first wallet 120, the second wallet 122, and the third wallet 124) can also be linked to a smart contract (such as a wallet smart contract), thereby facilitating the wallet to perform multiple functions. One of these functions can be triggering or executing a smart contract linked to the digital currency. Other functions may include social recovery, fraud monitoring, multi-call functionality, etc.

[0057] It can be noted that during processing, database 116 can store wallet data 126 and pre-existing wallets 128 (which may also be interchangeably referred to below as "pre-existing sub-wallets 128" or "one or more pre-existing sub-wallets 128"), such as Figure 1 As shown in the environment 100. In various other non-limiting examples, database 116 may include one or more hard disk drive (HDD), solid-state drive (SSD), Advanced Technology Attachment (ATA) adapter, Serial ATA (SATA) adapter, Small Computer System Interface (SCSI) adapter, Redundant Array of Independent Disks (RAID) controller, Storage Area Network (SAN) adapter, network adapter, and / or any component that provides access to database 116 for server system 102. In one implementation, an administrator (not shown) associated with server system 102 can view, access, modify, update, and / or delete database 116 through a database management system (DBMS) or relational database management system (RDBMS) present within database 116.

[0058] In some embodiments, since the smart contracts are deployed on a blockchain, the server system 102 can be a node from a decentralized network of nodes. In this document, a node refers to a computer system that connects to the network in a peer-to-peer (P2P) manner to track a distributed ledger (e.g., a decentralized blockchain, a centralized blockchain, a permissioned blockchain, etc.) and serves as a communication hub for various network tasks. It can be noted that nodes are configured to run protocol software and can store partial or complete copies of the distributed ledger.

[0059] In some other embodiments, server system 102 may be a node from a centralized network of nodes. In this document, a node is an entity as defined above; however, the node network is controlled or managed by a single entity associated with the centralized ledger. In this document, the single entity may be a corporation, government agency, financial institution, etc. Furthermore, in certain embodiments, the blockchain may be used as a centralized ledger; however, the blockchain may be a permissioned (or private) blockchain that stores data on the blockchain upon receiving permission from the owner.

[0060] It should be understood that server system 102 is a separate part of environment 100 and can operate independently of (but still communicate with, for example, via network 118) any third-party external server (to access data to perform the various operations described herein). However, in other embodiments, server system 102 may be wholly or partially incorporated into one or more parts of environment 100.

[0061] In addition, in order to enable the management of transactions based on programmable currency through a wallet based on nested smart contracts, the server system 102 can be adapted to perform multiple operations, which will be explained in detail with reference to several example diagrams in a separate part of the description.

[0062] Therefore, initially, when the first user 106 initiates a fund transfer, since the first user 106 is using the functions provided by the server system 102 via the first user device 104, the server system 102 can receive the transfer of digital currency funds from the first wallet 120 to the second wallet 122. In this document, the digital currency is associated with at least one smart contract. Additionally, it can be noted that the smart contract may include a set of predefined instructions.

[0063] In one embodiment, the fund transfer may include information corresponding to the funds that should be transferred from the first wallet 120 to the second wallet 122. For example, the information may include the transaction amount, the purpose of the transaction, the timing of the transfer, details of the first user 106, details of the second user 110, etc. In another embodiment, a set of predefined instructions included in a smart contract may include all the information needed to complete the fund transfer from the first wallet 120 to the second wallet 122. Therefore, in some embodiments, the smart contract may include account details of the first user 106 and the second user 110, information associated with the fund transfer, the purpose of the transaction, etc.

[0064] Upon receiving a fund transfer, server system 102 is responsible for completing the transfer by checking certain predefined conditions. Therefore, server system 102 can also determine the transaction category of the digital currency based at least in part on a set of predefined instructions. In this document, the transaction category can indicate the purpose of the fund transfer according to the smart contract. For example, the transaction category can include transactions for government subsidies for a specific purpose, transactions related to school / university fees, transactions specific to groceries, transactions related to business travel, transactions related to health insurance, transactions related to coupons, etc. Therefore, it is understood that the transaction category is specific to a particular task and changes as the task changes.

[0065] Additionally, in one embodiment, server system 102 may generate received digital currency at least in part based on the transaction category of the received digital currency and deposit the received digital currency into one or more new sub-wallets associated with second wallet 122. Each of the one or more new sub-wallets is eligible to hold digital currency for a specific transaction category. The process of generating new sub-wallets is further explained in this disclosure.

[0066] In another embodiment, server system 102 may store received digital currency into one or more pre-existing sub-wallets (e.g., pre-existing wallet 128). Each of the one or more pre-existing sub-wallets 128 is eligible to hold digital currency for a specific transaction category. Additionally, it can be noted that when one or more new sub-wallets are created, these new sub-wallets can be considered, or referred to as, pre-existing sub-wallets for subsequent transactions. In other words, if a new sub-wallet is created for a specific transaction, then for subsequent transactions, that new sub-wallet will be included in one or more pre-existing sub-wallets 128.

[0067] Therefore, it is understandable that after receiving a fund transfer, server system 102 can check whether the second wallet 122 already has a specific pre-existing sub-wallet within one or more pre-existing sub-wallets 128 for receiving digital currency of the corresponding transaction category. If server system 102 fails to find such a specific pre-existing sub-wallet, then server system 102 will generate a new sub-wallet for the corresponding transaction category. Moreover, server system 102 generates a new sub-wallet in the second wallet 122 because it has the convenience of nested smart contract features. Nested smart contract features enable wallets that can receive and transfer digital currency linked to smart contracts to have sub-wallets. In this document, by linking a smart contract such as a wallet smart contract describing the purpose to the corresponding sub-wallet, the sub-wallet can be dedicated to a specific purpose. In this document, it should be noted that wallet smart contracts are similar to smart contracts linked to digital currency, the difference being the logic implemented and the link to the wallet or sub-wallet. More specifically, in order to deploy smart contracts on the blockchain, a contract account can be created on the blockchain for each smart contract linked to each digital currency, wallet, or sub-wallet. In this article, each contract account can be associated with a unique identity (ID) used to identify and access the smart contracts stored in the contract account.

[0068] Additionally, in some embodiments, the second user 110, who receives funds in the form of digital currency, can transfer the digital currency based on a smart contract linked to the corresponding digital currency. Furthermore, when the second user 110 initiates such a request, the request can be again received by the server system 102.

[0069] In this regard, server system 102 can receive a fund transfer request from the wallet owner (e.g., second user 110) of second wallet 124 to transfer funds to third wallet 124. In one embodiment, the fund transfer request is associated with digital currency deposited into a pre-existing sub-wallet of second wallet 122. In this document, the pre-existing sub-wallet is one of one or more pre-existing sub-wallets 128.

[0070] Additionally, server system 102 can access wallet category data from database 116 associated with the server system. In this document, in embodiments, wallet data 126 may include wallet category data corresponding to third wallet 124. Furthermore, server system 102 can determine the wallet category of third wallet 124 based at least in part on the wallet category data. In this document, wallet category may indicate the types of transactions the corresponding wallet is authorized or programmed to receive. Therefore, it is understood that third wallet 124 is also linked to smart contracts (such as wallet smart contracts).

[0071] After determining the wallet category of the third wallet 124, the server system 102 can determine, at least in part, whether the pre-existing sub-wallet is eligible to transfer funds to the third wallet based on the wallet category and the transaction category of the pre-existing sub-wallet. Subsequently, in one embodiment, after determining that the pre-existing sub-wallet is eligible to transfer funds to the third wallet 124, the server system 102 can approve the fund transfer request and transfer the digital currency from the pre-existing sub-wallet to the third wallet 124. In another embodiment, after determining that the pre-existing sub-wallet is not eligible to transfer funds to the third wallet 124, the server system 102 can reject the fund transfer request.

[0072] In some embodiments, one or more financial institutions or one or more third-party applications (such as wallet providers) may generate or create wallets based on specific use cases and event flows. In such embodiments, financial institutions and third-party applications may require approval from a central entity (such as the central bank of a country providing digital currencies such as CBDCs) to generate the corresponding wallets.

[0073] In some other embodiments, financial institutions and / or wallet providers may also offer credit / microloans to their users (e.g., second user 110) based on predefined logic that can be programmed (using smart contracts) within the CBDC itself. It is important to note that these benefits can also extend to offline environments. For example, suppose a payment transaction linked to a smart contract is initiated from one wallet to another. Upon receiving the transaction, if the receiving wallet disconnects from the internet, the smart contract is not executed. However, upon reconnecting to the internet, the smart contract executes, and the transaction is completed or rejected based on the execution of the smart contract in the receiving wallet. In some scenarios described herein, the receiving wallet may also be associated with a smart contract that executes to check its eligibility to receive the corresponding payment transaction.

[0074] Furthermore, the programmability of CBDCs can be implemented through nested smart contract wallets (i.e., wallets with nested smart contract features as described above). These smart contracts are fragments of code associated with the digital currency or wallet that can self-execute payments based on some predefined criteria or conditions. For example, one smart contract can trigger another smart contract based on some conditions defined by a user or a group of users. Examples of predefined criteria or conditions include fraud detection conditions, user authorization conditions, insurance coverage detection, discount eligibility and validity checks, etc. For example, a condition in a smart contract linked to the digital currency could be checking whether the receiving wallet is owned by a retailer providing rationing services. From this condition, the purpose of the smart contract is clear: the digital currency should only be used to purchase rations. Therefore, upon receiving the digital currency, the wallet smart contract linked to the receiving wallet triggers the execution of the smart contract linked to the received digital currency. Once the conditions are matched, the receiving wallet successfully receives the digital currency and uses it for the purpose mentioned in the smart contract. Through the method proposed in this disclosure, citizens / governments can use the programmability of digital currencies (such as CBDCs) according to their needs and easily and conveniently control the flow of funds in the intended direction.

[0075] Figure 1 The number and arrangement of systems, devices, and / or networks shown are provided as examples. Additional systems, devices, and / or networks may exist; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or networks with... Figure 1 The systems, devices, and / or networks shown are arranged differently. Furthermore, Figure 1 The two or more systems or devices shown can be implemented within a single system or device, or Figure 1 The single system or device shown can be implemented as multiple distributed systems or devices. Furthermore, server system 102 should be understood to be implemented in at least one computing device communicating with network 118, and / or in at least one non-transitory computer-readable medium, which can be specifically configured via executable instructions to perform the steps as described herein.

[0076] More specifically, it should be noted that the number of first users, first user devices, second users, second user devices, third users, third user devices, first wallets, second wallets, third wallets, and databases described herein are for illustrative purposes only and do not limit the scope of this disclosure. The primary purpose of this disclosure is to provide methods for developers and / or payment providers to generate digital infrastructure for creating their custom wallets using smart contract wallets for use with programmable money and user-specific use cases.

[0077] Figure 2A simplified block diagram of a server system 200 according to an embodiment of the present disclosure is illustrated. For example, the server system 200 is similar to... Figure 1 The server system 102 described herein. In some embodiments, the server system 200 is implemented as a stand-alone physical server and / or has a cloud-based and / or SaaS (Software as a Service)-based architecture.

[0078] Server system 200 includes computer system 202 and database 204. Computer system 202 includes at least one processor (such as processor 206 for executing instructions), memory 208, communication interface 210, user interface 212, and storage interface 214. One or more components of computer system 202 communicate with each other via bus 216. The components of server system 200 provided herein may not be exhaustive, and server system 200 may include more than […]. Figure 2 The more or fewer components depicted in the text. Additionally, Figure 2 Two or more components described herein can be implemented in a single component, and / or a component can be configured with multiple sub-components to achieve the desired functionality. Database 204 is... Figure 1 Example of database 116.

[0079] In some embodiments, database 204 is integrated into computer system 202. For example, computer system 202 may include one or more hard drives as database 204. In a non-limiting example, database 204 is configured to store wallet data 218 and pre-existing wallets 220. In this document, wallet data 218 and pre-existing wallets 220 are similar to... Figure 1 Wallet data 126 and pre-existing wallet 128.

[0080] Additionally, computer system 202 may include one or more hard drives as database 204. User interface 212 is an interface such as a human-machine interface (HMI) or software application that allows a user (such as an administrator) to interact with server system 200 and control server system 200 or one or more parameters associated with server system 200. It can be noted that user interface 212 may consist of several components that vary based on the complexity and purpose of the application. Examples of components for user interface 212 may include visual elements, controls, navigation, feedback and alerts, user input and interaction, responsive design, user assistance and help, accessibility features, etc. More specifically, these components may correspond to icons, layouts, color schemes, buttons, sliders, drop-down menus, tabs, links, error / success messages, mouse and touch interactions, keyboard shortcuts, tooltips, screen readers, etc.

[0081] Storage interface 214 is any component that provides processor 206 with access to database 204. Storage interface 214 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and / or any component that provides processor 206 with access to database 204.

[0082] It should be noted that although computer system 202 is depicted as including only one processor, computer system 202 may include a larger number of processors. Processor 206 includes suitable logic, circuitry, and / or interfaces to execute computer-readable instructions for performing one or more operations for managing transactions based on programmable digital currencies through a wallet based on nested smart contracts. Examples of processor 206 include, but are not limited to, application-specific integrated circuit (ASIC) processors, reduced instruction set computing (RISC) processors, complex instruction set computing (CISC) processors, field-programmable gate arrays (FPGAs), etc.

[0083] In one embodiment, memory 208 is capable of storing computer-readable instructions. Examples of memory 208 include random access memory (RAM), read-only memory (ROM), removable storage drives, hard disk drives (HDDs), etc. It will be apparent to those skilled in the art that the scope of this disclosure is not limited to implementing memory in server system 200 as described herein. In another embodiment, memory 208 may be implemented as a database server or cloud storage that works in conjunction with server system 200 without departing from the scope of this disclosure.

[0084] Processor 206 is operatively coupled to communication interface 210, enabling computer system 202 to communicate with remote device 222 (such as first user equipment 104, second user equipment 108, third user equipment 112) or with any entity connected to network 118 (such as...). Figure 1 (as shown in the diagram) to communicate. In one embodiment, processor 206 is configured to facilitate access to a URL associated with a website or application corresponding to server system 102 on a first user device 104, a second user device 108, and / or a third user device 112, or for remote access to the website or application. This enables multiple functions to be implemented through multiple entities described in this disclosure.

[0085] It should be noted that the server system 200 shown in the figures and described below merely illustrates apparatus that can benefit from embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Note that the server system 200 may include, but is not limited to, more advanced or less advanced methods. Figure 2 The fewer or more components described in the text.

[0086] Processor 206 is depicted as including smart contract module 224, sub-wallet module 226, and funds transfer module 228. It should be noted that the components described herein can be configured in a wide variety of ways, including combinations of electronic circuits, digital arithmetic, logic blocks, and memory systems with software, firmware, and embedded technologies.

[0087] Smart contract module 224 may include suitable logic and / or interfaces for facilitating the generation or creation of at least one smart contract comprising a set of predefined instructions, the at least one smart contract being intended to execute the set of predefined instructions when predefined conditions are met. In this document, the predefined conditions may be described in a set of predefined instructions. Smart contract module 224 may also be configured to link at least one smart contract to a digital currency. In this document, the digital currency is to be transferred from a first wallet (e.g., first wallet 120) to a second wallet (e.g., second wallet 122) and then to a third wallet (e.g., third wallet 124). Smart contract module 224 may also be configured to transfer the digital currency linked to at least one smart contract to second wallet 122.

[0088] Sub-wallet module 226 may include suitable logic and / or interfaces for generating digital currency at least in part based on digital currency transaction categories and depositing the digital currency into one or more new sub-wallets associated with second wallet 122. In this document, each of the one or more new sub-wallets is eligible to hold digital currency for a specific transaction category.

[0089] In certain embodiments, sub-wallet module 226 is configured to generate one or more wallets, such as first wallet 120, second wallet 122, third wallet 124, etc. Wallets may be created at least in part based on funds to be transferred via digital currency. Additionally, to generate wallets, sub-wallet module 226 may be configured to generate one or more application programming interface (API) endpoints to facilitate the exchange of one or more API calls between one or more wallet providers and corresponding one or more financial institutions. It is important to note that each wallet provider may have a financial account with a specific financial institution. In a non-limiting example, one or more wallet providers may include third-party platforms capable of creating wallets and providing them to wallet users (such as first user 106, second user 110, and third user 114). However, in some embodiments, wallet providers may be required to obtain permission from the corresponding financial institution.

[0090] Therefore, in one embodiment, the sub-wallet module 226 is configured to receive wallet generation requests from one or more wallet providers via one or more API endpoints. In another embodiment, the sub-wallet module 226 is configured to transmit wallet generation requests to one or more corresponding financial institutions via one or more API endpoints. In this document, wallet generation requests may be transmitted to financial institutions as API calls. Financial institutions may need to verify the identity of wallet providers before facilitating wallet generation for wallet users.

[0091] Therefore, in response to a wallet creation request, the sub-wallet module 226 can receive wallet authorization responses from one or more financial institutions. In this document, the wallet authorization response may indicate authorization, at least in part, based on one or more API calls to at least one of one or more wallet providers. Furthermore, in response to authorization to at least one of one or more wallet providers, the sub-wallet module 226 may facilitate the creation of one or more wallets by the corresponding wallet provider.

[0092] In a non-limiting example, each wallet may be associated with one or more sub-wallets. In one embodiment, one or more sub-wallets include one or more pre-existing wallets. In another embodiment, one or more sub-wallets include one or more new sub-wallets that can be created within a particular wallet.

[0093] When one or more new sub-wallets are being generated and used to deposit received digital currency, smart contract module 224 can be configured to link each of the one or more new sub-wallets to at least one wallet smart contract indicating wallet eligibility criteria. As previously stated, received digital currency can be deposited into one or more new sub-wallets based on transaction category and the eligibility of the corresponding one or more new sub-wallets. Therefore, in a non-limiting implementation, to determine the eligibility of a new sub-wallet, smart contract module 224 can be configured to execute at least one smart contract associated with the digital currency. Additionally, smart contract module 224 can execute at least one wallet smart contract associated with each of the one or more new sub-wallets.

[0094] Furthermore, in one embodiment, the smart contract module 224 can determine whether at least one of one or more new sub-wallets is eligible to hold digital currency based at least on the execution of at least one smart contract and at least one wallet smart contract. In one scenario, when the execution of at least one smart contract and at least one wallet smart contract indicates that the purpose of the corresponding new sub-wallet matches the transaction category of the digital currency, the smart contract module 224 determines that at least one of one or more new sub-wallets is eligible to hold digital currency. For example, if the smart contract linked to the digital currency is used for rationing subsidies and if the smart contract linked to the new sub-wallet also indicates that it accepts rationing subsidy payments, then the new sub-wallet is considered eligible.

[0095] In an alternative scenario, when the purpose of a new sub-wallet corresponding to the execution instructions of at least one smart contract and at least one wallet smart contract does not match the transaction category of the digital currency, the smart contract module 224 may determine that at least one of the one or more new sub-wallets is not eligible to hold digital currency.

[0096] In an embodiment, sub-wallet module 226 can be configured to deposit digital currency into one or more pre-existing sub-wallets (e.g., pre-existing sub-wallets 220). Each of the one or more pre-existing sub-wallets 220 is eligible to hold digital currency for a specific transaction category. In such an embodiment, smart contract module 224 can be configured to link each of the one or more pre-existing sub-wallets to at least one wallet smart contract indicating wallet eligibility criteria. Additionally, as previously stated, received digital currency can be deposited into a pre-existing sub-wallet 220 based on the eligibility of the corresponding pre-existing sub-wallet 220. Therefore, to determine the eligibility of a pre-existing sub-wallet, smart contract module 224 can execute at least one smart contract associated with the digital currency. Smart contract module 224 can also execute at least one wallet smart contract associated with each of the pre-existing sub-wallets 220.

[0097] Additionally, in one embodiment, the smart contract module 224 can determine whether at least one of the pre-existing sub-wallets 220 is eligible to hold digital currency based at least on the execution of at least one smart contract and at least one wallet smart contract. In one scenario, when the execution of at least one smart contract and at least one wallet smart contract indicates that the purpose of the corresponding pre-existing sub-wallet matches the transaction category of the digital currency, the smart contract module 224 can determine that at least one of the pre-existing sub-wallets 220 is eligible to hold digital currency.

[0098] In an alternative scenario, when the purpose of a pre-existing sub-wallet corresponding to the execution instructions of at least one smart contract and at least one wallet smart contract does not match the transaction category of the digital currency, the smart contract module 224 can determine that at least one of the pre-existing sub-wallets 220 is not eligible to hold digital currency.

[0099] The funds transfer module 228 may include suitable logic and / or interfaces for receiving digital currency transfers from the first wallet 120 to the second wallet 122. In this document, the digital currency is associated with at least one smart contract. The at least one smart contract includes a set of predefined instructions.

[0100] Additionally, the funds transfer module 228 can be configured to determine the transaction category of the digital currency based at least in part on a set of predefined instructions. In this document, the transaction category may indicate the purpose of the funds transfer according to the smart contract.

[0101] Furthermore, in this embodiment, the funds transfer module 228 can be configured to receive a funds transfer request from the wallet owner of the second wallet 122 to transfer funds to the third wallet 124. In this document, the funds transfer request is associated with digital currency deposited into a pre-existing sub-wallet of the second wallet 122.

[0102] Furthermore, the funds transfer module 228 can be configured to access wallet category data from a database 204 associated with the server system 200. In an embodiment, the funds transfer module 228 can be configured to determine the wallet category of the third wallet 124 based at least in part on the wallet category data. The funds transfer module 228 can determine whether a pre-existing sub-wallet is eligible to transfer funds to the third wallet 124 based at least in part on the wallet category and the transaction categories of pre-existing sub-wallets.

[0103] Additionally, in this embodiment, the funds transfer module 228 can be configured to approve the funds transfer request and transfer the digital currency from the pre-existing sub-wallet to the third wallet 124 after determining that the pre-existing sub-wallet is eligible to transfer funds to the third wallet 124.

[0104] In another embodiment, the funds transfer module 228 can be configured to reject a funds transfer request after determining that a pre-existing sub-wallet is not eligible to transfer funds to the third wallet 124.

[0105] In a particular embodiment, smart contract module 224 may be configured to link third wallet 124 to at least one wallet smart contract indicating wallet eligibility criteria. Therefore, in order to determine eligibility for a pre-existing sub-wallet to transfer funds to third wallet 124, smart contract module 224 may execute at least one smart contract associated with the digital currency of the funds, and at least one wallet smart contract associated with each of the pre-existing sub-wallets and third wallet 124.

[0106] In one embodiment, when the execution of at least one smart contract and at least one wallet smart contract instructs the wallet category of the third wallet 124 to match the transaction category of a pre-existing sub-wallet, the smart contract module 224 can determine that the pre-existing sub-wallet is eligible to transfer funds in the form of digital currency to the third wallet 124.

[0107] In an alternative embodiment, when the execution of at least one smart contract and at least one wallet smart contract instructs the wallet category of the third wallet 124 to not match the transaction category of a pre-existing sub-wallet, the smart contract module 224 may determine that the pre-existing sub-wallet is not eligible to transfer funds in the form of digital currency to the third wallet 124.

[0108] Figure 3A The illustration shows a block diagram of a digital architecture 300 associated with a server system 200 according to an embodiment of the present disclosure. (See also:) Figure 3A As can be understood from the configuration of the digital architecture 300 and server system 200 shown, the digital architecture 300 facilitates the creation of wallet 304 by a third-party wallet provider 302 using a wallet creation process (see 306). In this document, the third-party wallet provider 302 is an example of an entity that provides services of the server system 200 to wallet users. Additionally, it is noted that the wallet creation process is well-known to those skilled in the art and is therefore not described for brevity. In a non-limiting example, wallet 304 is suitable for a smart wallet. Thus, in one embodiment, wallet 304 may be associated with a smart contract (such as a wallet smart contract). Moreover, wallet 304 may be similar to, for example, a smart wallet. Figure 1 The first wallet 120, the second wallet 122, and the third wallet 124.

[0109] Wallet users (e.g., first user 106, second user 110, and third user 114) can access wallet 304, enabling them to initiate fund transfers between at least two wallets (e.g., first wallet 120 and second wallet 122). It may be noted in this paper that, in some non-limiting examples, an application programming interface (API) 308 provided by a commercial bank (see 310) may be used to facilitate wallet creation 306. In this paper, commercial bank 310 is an example of a financial institution with an account with third-party wallet provider 302.

[0110] In other words, it can be noted that wallet creation 306 is made possible by multiple API calls between the third-party wallet provider 302 and the commercial bank 310 via API 308. As previously mentioned, the server system 200 generates API endpoints that facilitate the exchange of API calls between the wallet provider 302 and financial institutions such as the commercial bank 310. Additionally, during this process, Know Your Customer (KYC) can also be performed to authorize the third-party wallet provider 302 to create or generate wallet 304 after seeking permission from the commercial bank 310.

[0111] Additionally, since wallet 304 is created for storing and transferring funds in the form of digital currency, the smart contract generation process can also be implemented via server system 200 (see 312). This process can be implemented as referenced. Figure 1 and Figure 2 The interpretation method is implemented to generate a smart contract (see 314). In this document, smart contract 314 can be generated after receiving an aggregated message from commercial bank 310 describing the purpose of the fund transfer. Additionally, it can be noted that the aggregated message that commercial bank 310 can transmit for smart contract generation 312 can be received and aggregated from a third-party wallet provider 302.

[0112] In this embodiment, smart contract 314 can bundle transactions within it based on aggregated messages; these transactions are programmed for a specific purpose. After smart contract 314 is generated, the bundled transactions can be updated to the ledger (e.g., blockchain 316), as shown in Figure 3. In a specific example, the digital currency can be a CBDC token that can be exchanged between wallets (such as CBDC smart wallets). In this document, a CBDC token corresponds to the token associated with CBDC when it is transferred from one wallet to another.

[0113] In a non-restricted example, the pseudocode for the smart contract implementation associated with the CBDC token when transferring the CBDC token from the second user 110 to the third user 114 is as follows:

[0114]

[0115] As can be understood, the token parameters of the CBDC token are initialized according to the smart contract linked to the corresponding CBDC token. Simultaneously, the total supply is allocated to the contract creator. Furthermore, tokens (such as CBDC tokens) are sent from a message sender (such as second user 110) to a designated recipient (such as third user 114). Subsequently, the designated spender (i.e., third user 114) is allowed to spend CBDC tokens. Because third user 114 is allowed to spend CBDC tokens, CBDC tokens can be sent to any account using an approved amount.

[0116] In a non-restricted example, the pseudocode for the smart contract implementation associated with the CBDC smart wallet is as follows:

[0117]

[0118] As can be understood, initially, a wallet (such as second wallet 122) is initialized using the CBDC token contract and the wallet type associated with the corresponding second wallet 122. In this document, the contract creator of the CBDC token contract is declared as the initial owner of the CBDC token contract. Additionally, for transactions involving CBDC tokens to a new wallet (such as third wallet 124), the new owner of third wallet 124 is made the wallet owner. Furthermore, a new wallet type is assigned to third wallet 124. Moreover, according to the smart contract linked to the CBDC smart wallet, automatic payment transactions, periodic payments, multi-signature (multi-signature) transactions, and allowing third parties to sponsor gas fees for transactions for specific recipients (such as third wallet 124) are implemented.

[0119] Figure 3B The illustration depicts a schematic representation 360 of a digital currency (e.g., digital currency 362 or CBDC token 362) linked to a smart contract (e.g., CBDC token contract 364) and a smart wallet contract (e.g., smart wallet contract 366) according to embodiments of the present disclosure. As will be understood, an example of digital currency may be CBDC token 362, which can be linked to both CBDC token contract 364 and smart wallet contract 366 during fund transfers. It is noteworthy herein that the digital currency is linked to smart wallet contract 366. Furthermore, smart wallet contract 366 may be linked to a wallet capable of receiving CBDC token 362. This aspect implies that the wallet transferring funds (e.g., digital currency 362) and the wallet receiving digital currency 362 can be smart wallets, or linked to smart contracts such as wallet smart contracts.

[0120] Additionally, as you may understand, here is a pseudocode reference for CBDC token contract 364 and smart wallet contract 366. Figure 3A The above has provided an explanation. In this article, refer to... Figure 3B The CBDC token contract 364 may include the following details:

[0121] • Transfer to: Recipient's address

[0122] • Transferred from: sender's address

[0123] • Approval Status: Has the transaction been completed?

[0124] • Token Type: Specifies the smart contract history to which the token is attached.

[0125] • Smart contract version: Specifies the version of the current smart contract to which it is attached.

[0126] As can be understood in this article, "token type" can facilitate the auditing of digital currencies. This, as a result, provides enhanced traceability for certain use cases. Additionally, "smart contract version" can facilitate updating attached smart contract versions when needed.

[0127] In addition, it can be noted that smart wallet contract 366 may include the following details:

[0128] • Set Owner: The address of the wallet owner.

[0129] • Set wallet type: Define the functionality of the created wallet.

[0130] • Function

[0131] o Set up automatic payment

[0132] o Set up scheduled periodic payments

[0133] o Setting up sponsored transactions: Setting up the payer for gas bills

[0134] o Set up multi-signature transactions

[0135] o Setting up P2P lending

[0136] o Set up a custody account

[0137] o Set funds to freeze

[0138] o Set cancellation conditions

[0139] It should be noted that the methods presented in this disclosure are not limited to the functions mentioned above. Therefore, in various non-limiting examples, functions may include any possible application of the smart contract, such as setting up automatic payments, setting up scheduled periodic payments, setting up sponsored transactions, setting up multi-signature transactions, setting up peer-to-peer (P2P) lending, setting up custodian accounts, setting up fund freezes, setting up transaction reversal conditions, etc. In this document, with reference to the details included in the smart wallet contract 366, it will be understood that, along with including owner details and wallet type, it may also include defining additional functions for the smart wallet that can be executed when the smart wallet contract 366 is executed during the transfer of funds from digital currency 362.

[0140] For example, CBDC token 362 needs to be transferred from a smart wallet (such as W1) to another smart wallet (such as W2). Assume W1 has an address "address1" and W2 has an address "address2". Therefore, a smart contract linked to CBDC token 362 (such as CBDC token contract 364) can mention both addresses "address1" and "address2". Additionally, CBDC token 362 may have been previously used by other users for other purposes. Therefore, CBDC token contract 364 can also publicly disclose the usage history of CBDC token 362. Furthermore, it's important to note that smart contracts generally have associated versions, meaning the contract has been iterated and updated to reflect changes, improvements, or bug fixes. Therefore, CBDC token contract 364 also mentions the corresponding CBDC token contract 364 smart contract version linked to CBDC token 362. After transferring CBDC token 362 from W1 to W2, CBDC token contract 364 can be executed at W2. After execution, the transaction can be approved or rejected based on the conditions described in CBDC Token Contract 364. The assumed condition is to check the address of the wallet to be "address2," and if the address matches, the transaction is completed; otherwise, it is rejected. The approval status in CBDC Token Contract 364 can be updated based on the execution result after execution. Assume the transaction is completed, and W2 has received CBDC Token 362. As can be understood, smart wallet W2 is also linked to smart wallet contract 366. According to this contract, W2's address is defined, and its type (i.e., the function facilitated by wallet W2 as described above) is specified. For example, if W2's function is to make periodic payments for loan repayments, then upon receiving funds as CBDC Token 362, those funds can be automatically spent from W2 according to the schedule of the periodic payments. In this context, W2 may have to continuously receive funds from W1 to make timely payments for the periodic payments; otherwise, the account may be frozen, and W1's user may have to pay penalties.

[0141] Figure 4 A block diagram 400 illustrating an example wallet (e.g., wallet 402) having one or more sub-wallets according to an embodiment of the present disclosure is shown. In this document, wallet 402 may be similar to... Figure 3A Wallet 304. It's worth noting that due to the flexibility of user authentication, wallet providers (e.g., third-party wallet providers 302) can engage a large segment of the population in using retail CBDCs. As a result, trust and security are enhanced. Furthermore, wallet providers can create use case-specific event flows, which will further drive the adoption of retail CBDCs.

[0142] Furthermore, as can be understood, programmable money or programmable currency has multiple use cases. One example includes decentralized government (govt.) subsidy schemes. In such an example, in a scenario where the government wants to provide a sum of money in the form of CBDC to subsidize any item (e.g., a public distribution system (PDS) for people below the poverty line (BPL)), the CBDC sent to the beneficiary would be programmed in such a way that this CBDC can only be spent at certain merchants (e.g., merchants selling rations in that area).

[0143] Another example involves parental control over family wallets. In such examples, it's noteworthy that wallets belonging to family members can be programmed directly or with the help of any third party. For instance, parents can program the currency to be used / not used at certain locations / merchants (e.g., only for school fees / not for use in liquor stores, etc.) when sending money to their children's wallets.

[0144] Another example includes the use of this feature in private companies (e.g., programming company funds to employees to be used solely for or redeemed for business travel). Another example includes the ability to grant small loans based on a generated credit history. In such examples, this history can be used to generate an individual's credit score when a bank has information about all transactions from a particular wallet. In this context, such information might be useful when people don't have any established credit history.

[0145] Another example includes automated loyalty programs. In such examples, merchants having a customer's transaction history at their stores helps them use this information for loyalty programs. Furthermore, in some examples where physical coupons given to customers by merchants can now be replaced by smart contracts (e.g., cash back, but unprogrammed cash back), customers can only use the smart contract at specific stores of the merchant (e.g., the currency can be programmed according to the merchant's needs, such as the location of use, one-time limit, and expiration date details can be pre-set). Another example includes improvements in peer-to-peer lending (e.g., custodian-based services for business owners).

[0146] In this regard, examples of sub-wallets that can be created within wallet 402 may include sub-wallet W1 (see 404) programmed to subsidize S1, sub-wallet W2 (see 406) programmed to subsidize S2, and sub-wallets W3, W4, W5, and any number of sub-wallets depending on their purpose or smart contract (see 408). In an embodiment, a sub-wallet may also include sub-wallet WG (see 410), which may be non-programmable and therefore may hold currency for general purposes.

[0147] Additionally, in a non-limiting example, the network 118 (such as a blockchain network) that can be used to implement server system 200 could be the Ethereum network. In another non-limiting example, network 118 could include a new network with account abstraction capabilities. For example, EIP-4337 could be used to introduce account abstraction without making any changes to the core blockchain network. Furthermore, it can be noted that architectural choices can play a major role in the adoption of this disclosure.

[0148] Figure 5 The diagram illustrates a block diagram of a fund transfer process 500 from a source wallet to a destination wallet according to an embodiment of this disclosure. It is assumed that the source wallet could be a government wallet willing to provide funds to the public to subsidize one or more projects. In this document, the source wallet and the public can be respectively connected to… Figure 1 The first wallet 120 and the second user 110 are essentially similar. Therefore, upon receiving a fund transfer and determining the transaction type, the server system 200 either generates a new sub-wallet or utilizes a pre-existing sub-wallet within the second user 110's main wallet. In this document, the second user 110's main wallet corresponds to the second wallet 122. Therefore, in either case, the sub-wallet may include, for example... Figure 5 The W1, W2, W3, ... WN, WG shown are referenced in section 502. In this document, sub-wallets are referred to as... Figure 4The explanation for the sub-wallet is similar. Moreover, "N" is a non-zero natural number, and "G" indicates a general wallet, which is a non-programmable wallet that can hold digital currency for general purposes.

[0149] Once people receive funds from the government for a specific subsidy, they are now free to use them; however, they are restricted to using the money solely for that subsidy. Previously, there was a possibility that people might use the money permitted by the government under a rationed subsidy for other purposes (such as purchasing alcohol or any other goods). Moreover, some people who did not actually need such subsidies might take it and use it for other personal benefits. This undermined the government's motivation to help vulnerable groups, because those above the poverty line could also abuse this function from the government, as there was no means to track the flow of money. With the introduction of this disclosure, the government can now easily track the money it permits and ensure that it has been used for the same previously permitted purpose.

[0150] Therefore, when individuals (such as the second user 110) such as Figure 5 When a transaction is initiated, as shown, server system 200 can check whether the selected sub-wallet is eligible for the expected subsidy that the second user 110 is willing to utilize (see 504). If so, then the merchant's eligibility to receive the transaction is checked (see 506). If not, then the transaction fails, and the processing initiated by the second user 110 is stopped (see 508).

[0151] Additionally, at point 506, during the merchant's eligibility check, if the merchant is qualified to receive funds, then the funds are transferred to the merchant's wallet (and...). Figure 1 (Similar to the explanation of third user 114's third wallet 124). Otherwise, the transaction fails and processing stops, as in step 508.

[0152] Furthermore, on the merchant side, server system 200 can check whether the destination wallet (i.e., the merchant's wallet) is associated with a smart contract (see 510). If so, and if the subsidy is S1, then the funds are transferred to a sub-wallet, such as W1 (see 512). Otherwise, the funds are transferred to a general sub-wallet (i.e., WG) that is not associated with any smart contract (see 514).

[0153] Additionally, if the fund transfer has already occurred in the sub-wallet W1 associated with the smart contract, processing can continue. In this document, the next transfer will be based on the smart contract for the execution of the corresponding smart contract and the processing will end (see 516). After this, if no further smart contract is linked to the transaction, the funds can flow out (see 518).

[0154] Alternatively, when funds are transferred to the general wallet as in step 514, the next transfer can again be a smart contract dependency if any smart contract is linked to the transaction (see 520). Subsequently, if no smart contract is further linked to the transaction, the funds can also flow out (see 522). To this end, the proposed method prevents the misappropriation of funds allocated to individuals.

[0155] Figure 6 The illustration depicts a process flow diagram of a method 600 for facilitating the transfer of funds from a first wallet (e.g., first wallet 120) to a second wallet (e.g., second wallet 122) according to embodiments of the present disclosure. The method 600 depicted in the flowchart can be performed by, for example, a server system 200. The sequence of operations of method 600 may not necessarily be performed in the same order as they are presented. Additionally, one or more operations may be grouped and performed as a single step, or an operation may have several sub-steps that can be performed in parallel or sequentially. The operations of method 600, and combinations of operations within method 600, can be implemented by, for example, hardware, firmware, processors, circuitry, and / or different devices associated with the execution of software including one or more computer program instructions. Multiple operations are depicted in the processing flow of method 600. The processing flow begins at operation 602.

[0156] At point 602, method 600 includes receiving a transfer of digital currency from a first wallet 120 to a second wallet 122 by a server system (e.g., server system 200). In this document, the digital currency is associated with at least one smart contract. In this document, the smart contract includes a set of predefined instructions.

[0157] At 604, method 600 includes determining, at least in part, the transaction category of the digital currency by server system 200 based on a set of predefined instructions. In this document, the transaction category indicates the purpose of a fund transfer according to a smart contract.

[0158] At 606, method 600 includes one of sub-steps 606(1) and 606(2) being performed by server system 200.

[0159] At 606(1), method 600 includes generating received digital currency at least in part based on the transaction category of the received digital currency and depositing the received digital currency into one or more new sub-wallets associated with the second wallet 122. In this document, each of the one or more new sub-wallets is eligible to hold digital currency for a specific transaction category.

[0160] At 606(2), method 600 includes depositing the received digital currency into one or more pre-existing sub-wallets. In this document, each of the one or more pre-existing sub-wallets is eligible to hold digital currency for a specific transaction category.

[0161] Figure 7 The illustration depicts a process flow diagram of a method 700 for facilitating the transfer of funds from a second wallet (e.g., second wallet 122) to a third wallet (e.g., third wallet 124) according to embodiments of the present disclosure. The method 700 depicted in the flowchart can be performed by, for example, a server system 200. The sequence of operations of method 700 may not necessarily be performed in the same order as they are presented. Additionally, one or more operations may be grouped and performed as a single step, or an operation may have several sub-steps that can be performed in parallel or sequentially. The operations of method 700, and combinations of operations within method 700, can be implemented by, for example, hardware, firmware, processors, circuitry, and / or different devices associated with the execution of software including one or more computer program instructions. Multiple operations are depicted in the processing flow of method 700. The processing flow begins at operation 702.

[0162] At point 702, method 700 includes receiving a funds transfer request from the wallet owner of second wallet 122 to transfer funds to third wallet 124 by a server system (e.g., server system 200). In this document, the funds transfer request is associated with digital currency deposited into a pre-existing sub-wallet of second wallet 122.

[0163] At 704, method 700 includes accessing wallet category data by server system 200 from a database (e.g., database 204) associated with server system 200.

[0164] At 706, method 700 includes determining the wallet category of the third wallet 124 by the server system 200 based at least in part on wallet category data.

[0165] At 708, method 700 includes determining, at least in part, by server system 200 whether a pre-existing sub-wallet is eligible to transfer funds to third wallet 124 based on wallet type and transaction type of a pre-existing sub-wallet.

[0166] At 710, method 700 includes one of sub-steps 710(1) and 710(2) being performed by server system 200.

[0167] At 710(1), method 700 includes, after determining that a pre-existing sub-wallet is eligible to transfer funds to a third wallet 124, approving the fund transfer request and transferring the digital currency from the pre-existing sub-wallet to the third wallet 124.

[0168] At 710(2), method 700 includes rejecting the fund transfer request after determining that the pre-existing sub-wallet is not eligible to transfer funds to the third wallet 124.

[0169] Various embodiments of the methods proposed in this disclosure as discussed above (i.e., the proposed methods) can be practiced using steps and / or operations in different sequences, and / or using hardware elements in configurations different from those disclosed. Therefore, although the proposed methods have been described based on these exemplary embodiments, it should be noted that certain modifications, variations, and alternative constructions may be apparent and are fully within the scope of the proposed methods.

[0170] Although various exemplary embodiments of the proposed method are described herein in language specific to structural features and / or methodological behavior, the subject matter defined in the appended claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and behaviors described above are disclosed as exemplary forms for implementing the claims.

Claims

1. A computer-implemented method, comprising: The server system receives the transfer of digital currency funds from a first wallet to a second wallet, the digital currency being associated with at least one smart contract, the smart contract including a set of predefined instructions; The server system determines the transaction category of the digital currency based at least in part on the set of predefined instructions, the transaction category indicating the purpose of the fund transfer according to the smart contract; as well as The server system shall perform one of the following: The received digital currency is generated at least in part based on the transaction category of the received digital currency and deposited into one or more new sub-wallets associated with the second wallet, wherein each of the one or more new sub-wallets is eligible to hold the digital currency for a specific transaction category, and The received digital currency is deposited into one or more pre-existing sub-wallets, each of which is eligible to hold the digital currency for the specific transaction category.

2. The computer-implemented method as described in claim 1, further comprising: The server system facilitates the generation of at least one smart contract comprising the set of predefined instructions, the at least one smart contract being intended to execute the set of predefined instructions when predefined conditions are met; The server system links the at least one smart contract with the digital currency; as well as The server system transfers the digital currency linked to the at least one smart contract to the second wallet.

3. The computer-implemented method as described in claim 1, further comprising: The server system generates one or more wallets, at least in part, based on the funds to be transferred through the digital currency, the one or more wallets including the first wallet, the second wallet, and the third wallet.

4. The computer-implemented method of claim 3, wherein generating the one or more wallets comprises: The server system generates one or more application programming interface (API) endpoints to facilitate the exchange of one or more API calls between one or more wallet providers and corresponding one or more financial institutions; The server system receives wallet generation requests from one or more wallet providers through one or more API endpoints; The server system transmits the wallet generation request to the corresponding one or more financial institutions through one or more API endpoints; In response to the wallet generation request, the server system receives wallet authorization responses from the one or more financial institutions, the wallet authorization responses indicating authorization for at least one of the one or more wallet providers based at least in part on the one or more API calls; as well as In response to authorization of at least one of the one or more wallet providers, the server system facilitates the creation of the one or more wallets by the corresponding wallet provider.

5. The computer-implemented method as described in claim 1, further comprising: The server system links each of the one or more new sub-wallets to at least one wallet smart contract that indicates the wallet's eligibility criteria.

6. The computer-implemented method as described in claim 5, further comprising: The server system determines the eligibility of the one or more new sub-wallets to hold the digital currency for the specific transaction category, wherein determining the eligibility includes: Execute the at least one smart contract associated with the digital currency and the at least one wallet smart contract associated with each of the one or more new sub-wallets; and The determination of whether at least one of the one or more new sub-wallets is eligible to hold the digital currency is based at least on the execution of the at least one smart contract and the at least one wallet smart contract.

7. The computer-implemented method of claim 6, wherein determining whether at least one of the one or more new sub-wallets is eligible to hold the digital currency comprises one of the following: When the purpose of the new sub-wallet corresponding to the execution instructions of the at least one smart contract and the at least one wallet smart contract matches the transaction category of the digital currency, it is determined that at least one of the one or more new sub-wallets is eligible to hold the digital currency. When the purpose of the new sub-wallet corresponding to the execution instruction of the at least one smart contract and the at least one wallet smart contract does not match the transaction category of the digital currency, it is determined that at least one of the one or more new sub-wallets is ineligible.

8. The computer-implemented method as described in claim 1, further comprising: The server system links each of the one or more pre-existing sub-wallets to at least one wallet smart contract that indicates the wallet's eligibility criteria.

9. The computer-implemented method as described in claim 8, further comprising: The server system determines the eligibility of the one or more pre-existing sub-wallets to hold the digital currency for the specific transaction category, wherein determining the eligibility includes: Execute the at least one smart contract associated with the digital currency and the at least one wallet smart contract associated with each of the one or more pre-existing sub-wallets; and The determination of whether at least one of the one or more pre-existing sub-wallets is eligible to hold the digital currency is based at least on the execution of the at least one smart contract and the at least one wallet smart contract.

10. The computer-implemented method of claim 9, wherein determining whether at least one of the one or more pre-existing sub-wallets is eligible to hold the digital currency comprises one of the following: When the purpose of a pre-existing sub-wallet corresponding to the execution instructions of the at least one smart contract and the at least one wallet smart contract matches the transaction category of the digital currency, it is determined that at least one of the one or more pre-existing sub-wallets is eligible to hold the digital currency. When the purpose of a pre-existing sub-wallet corresponding to the execution instructions of the at least one smart contract and the at least one wallet smart contract does not match the transaction category of the digital currency, it is determined that at least one of the one or more pre-existing sub-wallets is not eligible to hold the digital currency.

11. The computer-implemented method of claim 1, further comprising: The server system receives a fund transfer request from the wallet owner of the second wallet to transfer funds to a third wallet, wherein the fund transfer request is associated with the digital currency deposited into a pre-existing sub-wallet of the second wallet; The server system accesses wallet category data from a database associated with the server system; The server system determines the wallet category of the third wallet based at least in part on the wallet category data; The server system determines, at least in part, whether the pre-existing sub-wallet is eligible to transfer funds to the third wallet based on the wallet category and the transaction category of the pre-existing sub-wallet; and The server system shall perform one of the following: After determining that the pre-existing sub-wallet is eligible to transfer funds to the third wallet, the digital currency is transferred from the pre-existing sub-wallet to the third wallet based on the fund transfer request. After determining that the pre-existing sub-wallet is not eligible to transfer funds to the third wallet, the fund transfer request is rejected.

12. A computer-implemented method, comprising: The server system receives a fund transfer request from the wallet owner of the second wallet to transfer funds to the third wallet, wherein the fund transfer request is associated with digital currency deposited into a pre-existing sub-wallet of the second wallet; The server system accesses wallet category data from a database associated with the server system; The server system determines the wallet category of the third wallet based at least in part on the wallet category data; The server system determines, at least in part, whether the pre-existing sub-wallet is eligible to transfer funds to the third wallet based on the wallet category and the transaction category of the pre-existing sub-wallet; and The server system shall perform one of the following: After determining that the pre-existing sub-wallet is eligible to transfer funds to the third wallet, the digital currency is transferred from the pre-existing sub-wallet to the third wallet based on the fund transfer request. After determining that the pre-existing sub-wallet is not eligible to transfer funds to the third wallet, the fund transfer request is rejected.

13. The computer-implemented method of claim 12, further comprising: The server system links the third wallet to at least one wallet smart contract that indicates the wallet's eligibility criteria.

14. The computer-implemented method of claim 13, further comprising: The server system determines the eligibility of the pre-existing sub-wallet to transfer funds to the third wallet, wherein determining the eligibility includes: Execute the at least one smart contract associated with the digital currency of the funds, and the at least one wallet smart contract associated with each of the pre-existing sub-wallets and the third wallet; and When the execution of the at least one smart contract and the at least one wallet smart contract instructs the wallet category of the third wallet to match the transaction category of the pre-existing sub-wallet, it is determined that the pre-existing sub-wallet is eligible to transfer funds in the form of digital currency to the third wallet.

15. The computer-implemented method of claim 14, further comprising: When the execution of the at least one smart contract and the at least one wallet smart contract indicates that the wallet category of the third wallet does not match the transaction category of the pre-existing sub-wallet, the server system determines that the pre-existing sub-wallet is not eligible to transfer funds in the form of digital currency to the third wallet.

16. A server system, comprising: Communication interface; The memory includes executable instructions; as well as A processor, communicatively coupled to the communication interface and the memory, is configured to cause the server system to at least: Receives transfers of digital currency from a first wallet to a second wallet, the digital currency being associated with at least one smart contract, the smart contract comprising a set of predefined instructions; The transaction category of the digital currency is determined at least in part based on the set of predefined instructions, the transaction category indicating the purpose of the fund transfer according to the smart contract; as well as Perform one of the following: The received digital currency is generated at least in part based on the transaction category of the received digital currency and deposited into one or more new sub-wallets associated with the second wallet, wherein each of the one or more new sub-wallets is eligible to hold the digital currency for a specific transaction category, and The received digital currency is deposited into one or more pre-existing sub-wallets, each of which is eligible to hold the digital currency for the specific transaction category.

17. The server system of claim 16, wherein the server system is further configured such that: Facilitating the generation of at least one smart contract comprising the set of predefined instructions, the at least one smart contract being intended to execute the set of predefined instructions when predefined conditions are met; Link the at least one smart contract with the digital currency to be transferred from the first wallet to the second wallet; as well as The digital currency linked to the at least one smart contract is transferred to the second wallet.

18. The server system of claim 16, wherein the server system is further configured to generate one or more wallets at least partially based on funds to be transferred via the digital currency, the one or more wallets including the first wallet, the second wallet, and the third wallet.

19. The server system of claim 16, wherein the server system is further configured, at least in part, to link each of the one or more new sub-wallets to at least one wallet smart contract indicating wallet eligibility criteria.

20. The server system of claim 16, wherein the server system is further configured, at least in part, to link each of the one or more pre-existing sub-wallets to at least one wallet smart contract indicating wallet eligibility criteria.

21. A non-transitory computer-readable storage medium comprising computer-executable instructions, wherein the computer-executable instructions, when executed by at least a processor of a server system, cause the server system to perform a method, the method comprising: Receives transfers of digital currency from a first wallet to a second wallet, the digital currency being associated with at least one smart contract, the smart contract comprising a set of predefined instructions; The transaction category of the digital currency is determined at least in part based on the set of predefined instructions, the transaction category indicating the purpose of the fund transfer according to the smart contract; as well as Perform one of the following: The received digital currency is generated at least in part based on the transaction category of the received digital currency and deposited into one or more new sub-wallets associated with the second wallet, wherein each of the one or more new sub-wallets is eligible to hold the digital currency for a specific transaction category, and The received digital currency is deposited into one or more pre-existing sub-wallets, each of which is eligible to hold the digital currency for the specific transaction category.

Images