Fund supervision method and equipment for digital currency, and medium

Abstract

The invention relates to the technical field of smart contracts, and discloses a fund supervision method and equipment for digital currency, and a medium. The method is applied to the electronic equipment and comprises the steps of obtaining a first service request of a first user; the first business request is completed by adopting a first supervising sub-user of the public account, wherein the first supervising sub-user is in butt joint with the first intelligent contract; acquiring a second service request of a second user; and completing a second service request by adopting a second supervising sub-user of the public account, wherein the second supervising sub-user is connected with the second smart contract. According to the method and the device, the supervision sub-households are divided for the public account, and the one-to-one relationship between the supervision sub-households and the smart contracts is established, so that the same smart contract type butted with the public account can simultaneously perform a plurality of activities, the characteristics of consistency, mandatory, verifiability and the like of the digital currency smart contract are shown, and the use scene of the digital currency is enriched.

Description

Technical Field

[0001] The present application relates to the field of smart contract technology, and in particular to a method, device and medium for digital currency fund supervision. Background Art

[0002] Digital currency, which is equivalent to cash banknotes, is used to achieve the cross-integration of the digital society and the real society. It can be a completely closed currency that has nothing to do with the real economy and can only be used in a specific virtual community, such as game coins in the virtual world; it can also be a currency that can be purchased with real currency but cannot be exchanged back into real currency, and can be used to purchase virtual goods and services, such as Libra launched by Facebook; it can also be exchanged and redeemed with real currency at a certain rate, and can be used to purchase both virtual goods and services, as well as real goods and services, such as the legal digital currency issued by the central bank.

[0003] In the scenario where large enterprises use digital currency to open a public wallet through a member unit for multi-scenario and multi-customer payment collection, the parent-child wallet is generally used to manage the standardized funds of digital currency for large group customers, that is, the relationship between the parent-child wallet is stored in a tree structure, in which each child wallet has normal payment and collection functions, so that it can distinguish the settlement channels and machine payment behaviors. In the scenario where the parent-child wallet is connected to the smart contract, such as the "smart C card", the public parent wallet opened by the merchant is used as the counterparty, and the funds purchased by the customer are stored in the customer's private wallet in the form of business freezing.

[0004] However, under the tree structure of the parent-child wallet in the existing technology, when a merchant uses the parent-child wallet system to connect to a smart contract, the parent-child wallet system can only perform unified and standardized supervision, and the same smart contract type cannot carry out multiple activities at the same time, which greatly limits the application and promotion of digital currency. Summary of the invention

[0005] In order to solve the above-mentioned technical problem that when funds are supervised based on smart contracts, the same public account can only be connected to one smart contract and carry out multiple activities, the first aspect of the embodiment of the present application provides a digital currency funds supervision method, including:

[0006] Obtaining a first business request from a first user; using a first regulatory sub-account of a public account to complete the first business request, wherein the first regulatory sub-account is connected to a first smart contract;

[0007] Obtaining a second service request of a second user;

[0008] The second business request is completed using a second regulatory sub-account of the public account, wherein the second regulatory sub-account is connected to a second smart contract.

[0009] The method for fund supervision provided in the embodiment of the present application, through the setting of a supervision sub-account system, is to divide the public account into multiple supervision sub-accounts, establish a one-to-one relationship between the supervision sub-accounts and the smart contract, and then the same smart contract type connected to the public account can carry out multiple activities at the same time, and the merchant corresponding to the public account can implement customized fund supervision for each user, demonstrating the consistency, mandatory, verifiability and other characteristic functions of the digital currency smart contract, and enriching the usage scenarios of digital currency.

[0010] In an implementable manner of the first aspect, using a first supervision sub-account of a public account to complete the first business request includes:

[0011] Obtain the card number information of the first smart contract;

[0012] Determine the product type of the first smart contract according to the card number information of the first smart contract;

[0013] Construct or activate the operating environment of the first smart contract according to the type of the first smart contract product;

[0014] Based on the operating environment, the first regulatory sub-account is used to complete the first business request.

[0015] The product type of the first smart contract can be understood as a smart contract product with different performance or functions, such as smart IC cards, smart E cards, gift cards, etc. Although the transactions of the three also belong to the category of digital currency transactions, due to the differences in their forms of expression, working principles, etc., the operating environments of the smart contracts they connect to are different. Determining the product type of the first smart contract can help the processor quickly and accurately build or activate the operating environment.

[0016] In an implementation manner of the first aspect, completing the second business request using the second supervision sub-account of the public account includes:

[0017] Obtain the card number information of the second smart contract;

[0018] Determine the product type of the second smart contract according to the card number information of the second smart contract;

[0019] Construct or activate the operating environment of the second smart contract according to the type of the second smart contract product;

[0020] Based on the operating environment, the second regulatory account is used to complete the second business request.

[0021] In an implementation manner of the first aspect above, the product type is determined according to a coding rule of the card number information.

[0022] In an implementation manner of the first aspect, the first service request and / or the second service request includes at least one of the following:

[0023] Based on the subscription logic of the smart contract connected to any one of the regulated sub-accounts, after a first preset period of time, any one of the regulated sub-accounts flows funds for the subscription of the wealth management product into the public account;

[0024] Based on the balance correction logic of the smart contract connected to any one of the regulatory sub-accounts, when the balance of any one of the regulatory sub-accounts is lower than the preset balance threshold during the end-of-day fund check, the target funds are redeemed from the public account.

[0025] It can be understood that the subscription logic of the first smart contract and the second smart contract is to subscribe to the selected financial products from multiple financial products in a timely and quantitative manner, and the balance correction logic of the first smart contract and the second smart contract is that when the balance of the regulated sub-account is lower than the regulated balance threshold, the processor will automatically trigger the redemption of funds. It can be seen that in the subscription logic of the first smart contract and the second smart contract, merchants can be allowed to temporarily overdraw funds in the regulated sub-account on the same business day, as long as the balance of the regulated sub-account is greater than or equal to the balance threshold at the end of the day.

[0026] In some embodiments, the subscription logic and balance correction logic of the target smart contracts of different customers may be different.

[0027] In an implementation manner of the first aspect above, the method further includes:

[0028] A first transaction details table is generated according to the first business request and the second business request; the first details table represents the transaction details between the first regulatory sub-account and the second regulatory sub-account and the public account.

[0029] In some embodiments, the first transaction details table may include the first user, the second user, the content of the business request, the amount of the business request, the time of the business request, etc. The first transaction details may also include the balance of the first user's first regulatory sub-account, the balance of the second user's second regulatory sub-account, etc.

[0030] In an implementation manner of the first aspect above, the public account is a public wallet, and the first regulatory sub-account and the second regulatory sub-account are sub-wallets obtained by dividing the public wallet.

[0031] In an implementation manner of the first aspect above, the method further includes:

[0032] Obtaining a third business request of the first user; the third business request includes a first smart contract product purchased by the first user;

[0033] The third service request is completed using a first personal account of the first user, where the first personal account corresponds to the first regulatory sub-account; the third service request includes a second smart contract product purchased by the second user;

[0034] Obtaining a fourth business request of the second user; the fourth business request includes a second smart contract product purchased by the second user;

[0035] The fourth business request is completed using the second personal account of the second user, and the second personal account corresponds to the second regulatory sub-account.

[0036] In an implementation manner of the first aspect above, the method further includes:

[0037] A second transaction details table is generated according to the third business request and the fourth business request, wherein the second transaction details table represents the transaction details between the first personal account and the second personal account and the corresponding regulatory sub-accounts.

[0038] A second aspect of an embodiment of the present application provides an electronic device, including:

[0039] A first acquisition module, used to acquire a first service request of a first user;

[0040] A first execution module, configured to complete the first business request using a first regulatory sub-account of a public account, wherein the first regulatory sub-account is connected to the first smart contract;

[0041] A second acquisition module, used to acquire a second service request of a second user;

[0042] The second execution module is used to complete the second business request using a second regulatory sub-account of the public account, wherein the second regulatory sub-account is connected to the second smart contract.

[0043] A third aspect of the embodiments of the present application provides an electronic device, including:

[0044] a memory for storing instructions to be executed by one or more processors of the electronic device, and

[0045] The processor is one of the one or more processors of the electronic device, and is used to execute the digital currency fund supervision method described in the first aspect above.

[0046] The fourth aspect of the embodiments of the present application provides a computer-readable storage medium, on which instructions are stored, which, when executed, enable a computer to execute the digital currency fund supervision method described in the first aspect above.

[0047] The fifth aspect of the embodiments of the present application provides a computer program product, which includes instructions that, when executed, cause a computer to execute the digital currency fund supervision method described in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1A According to some embodiments of the prior art, an application scenario diagram of fund supervision is shown;

[0049] Figure 1B According to some embodiments of the present application, an application scenario diagram of fund supervision is shown;

[0050] Figure 2 According to some embodiments of the present application, a flowchart of a method for supervising funds of digital currency is shown;

[0051] Figure 3A According to some embodiments of the present application, a partial flow diagram of a method for supervising funds of digital currency is shown;

[0052] Figure 3B According to some embodiments of the present application, a partial flow diagram of a method for supervising funds of digital currency is shown;

[0053] Figure 4 According to some embodiments of the present application, a flowchart of a method for supervising funds of digital currency is shown;

[0055] Figure 5 According to some embodiments of the present application, a flowchart of a method for supervising funds of digital currency is shown;

[0056] Figure 6 According to some embodiments of the present application, a flowchart of a method for supervising funds of digital currency is shown;

[0057] Figure 7 According to some embodiments of the present application, a schematic diagram of a program module of an electronic device is shown;

[0058] Figure 8 According to some embodiments of the present application, a schematic structural diagram of an electronic device is shown. DETAILED DESCRIPTION

[0059] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0060] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0061] The acquisition, storage, use, and processing of data in the technical solution of this application comply with the relevant provisions of national laws and regulations.

[0062] As mentioned above, in the current application scenario where the parent-child wallet connects to the smart contract to supervise funds, the parent-child wallet system can only perform unified and standardized supervision, and the same smart contract type cannot carry out multiple activities at the same time, which greatly limits the application and promotion of digital currency.

[0063] In order to solve the above problems, the embodiment of the present application proposes a method for fund supervision of digital currency, which divides the public account of the second user, i.e., the merchant, into multiple supervision sub-accounts, each first user, i.e., the customer, corresponds to a supervision sub-account, each supervision sub-account is connected to a target smart contract, and the supervision sub-account and the public account are supervised based on the target smart contract. The merchants may be, for example, banks, financial management companies, companies with financial products (such as listed companies with stocks), etc., and the users may be understood as people who purchase merchant products, such as bank customers, shareholders who purchase stocks, etc. Fund supervision can be understood as a business request generated according to a smart contract, which can be, for example, the purchase of financial products such as funds, stocks, bonds, etc., or the redemption of financial products, etc.

[0064] The embodiment of the present application can establish a one-to-one relationship between the supervision sub-account and the smart contract through the setting of the supervision sub-account system, so that the same smart contract type of the merchant's public account docking can carry out multiple activities at the same time, and the merchant can implement customized fund supervision for each customer, showing the consistency, mandatory, verifiability and other characteristics of the digital RMB smart contract, and enriching the use scenarios of the digital RMB. For example, in the application scenario of the fund supervision of the smart contract docking smart contract product, the merchant's public wallet, that is, the public account, is divided into multiple supervision sub-accounts, wherein the public wallet can be docked with a variety of smart contract products, such as smart IC cards, smart E cards, gift cards, etc., and each supervision sub-account can be docked with a smart contract. Then, when the user purchases the smart contract product, the funds will flow into the user's corresponding supervision sub-account, and the target smart contract docked by the supervision sub-account will start to run, and the subscription and other fund supervision can be carried out. Different users can choose different smart contract products and target smart contracts. Since the processor docks the target smart contract through the supervision sub-account, the public wallet of the same merchant can carry out multiple activities without affecting each other.

[0065] Smart contracts can be understood as a computer protocol designed to disseminate, verify or execute contracts in an information-based manner, which has the characteristics of traceability, difficulty in tampering, network decentralization, digital signatures, digital certificates, etc. The smart contract in the embodiment of the present application can be understood as a customer purchasing a smart contract product from a merchant and signing a smart contract with the merchant. The smart contract product will supervise the funds between the customer and the merchant in accordance with the signed smart contract, that is, the funds flow between the customer account and the merchant account under the preset trigger conditions.

[0066] The following will take the application scenario of funds supervision of smart contract products between merchants and customers as an example to introduce the technical solution of this application in detail. It should be noted that the method of funds supervision in this application can be used between any two users, not limited to between merchants and customers.

[0067] Please refer to Figure 1A , which is an application scenario of fund supervision in the prior art. The merchant opens a merchant public account 1, which will be connected to the preset smart contract. Then, customer 1, customer 2, and customer 3 purchase the merchant's smart contract products respectively. The smart contract products will be connected to the preset smart contract, that is, the business transactions between customer account 1, customer account 2, and customer account 3 depend on the preset smart contract. Among them, business transactions can be understood as the circulation of digital currency. It can be understood that the fund supervision between multiple customers and merchants is carried out by the same smart contract. The smart contract of the same merchant can only carry out unified and standardized supervision, and cannot carry out multiple activities, that is, it is impossible to customize fund supervision, which limits the application of digital currency.

[0068] Please refer to Figure 1B , the application scenario of funds supervision provided by the embodiment of the present application, the merchant opens a merchant public account 1, and the merchant public account can be divided into multiple supervision sub-accounts, such as supervision sub-account 11, supervision sub-account 12 and supervision sub-account 13. After each customer purchases the merchant's smart contract product, the funds, that is, the digital currency, will flow into the supervision sub-account corresponding to the customer. For example, after the first customer purchases the smart contract product, the funds will flow from the customer account 1 into the first supervision sub-account 11. The smart contract product purchased by customer 1 corresponds to the first smart contract, that is, the first supervision sub-account 11 will be connected to the first smart contract. The second customer and the third customer are the same. It can be understood that the smart contract connected to each supervision sub-account can be different, breaking the limitation that a merchant can only connect to one smart contract. After the funds flow into the supervision sub-account, the smart contract connected to the supervision sub-account will start to run, and can automatically purchase financial products based on the preset operation logic of the smart contract, or perform other fund supervision on transactions between the supervision sub-account and the public account.

[0069] The following is a further description of the digital currency fund supervision method, device and medium in the embodiments of the present application in conjunction with the drawings in the specification.

[0070] Please refer to Figure 2 , is a flow chart of the method for supervising funds of digital currency in the embodiment of the present application. It can be understood that in some embodiments, each step in the method can be Figure 8 The processor 401 in the electronic device 400 shown is executed. Specifically, the method includes:

[0071] S201: Obtaining a first service request of a first user;

[0072] S202: using the first supervision sub-account of the public account to complete the first business request;

[0073] The first regulatory sub-account is connected to the first smart contract;

[0074] S203: Obtaining a second service request of a second user;

[0075] 204: Use a second regulatory sub-account of the public account to complete the second business request, wherein the second regulatory sub-account is connected to the second smart contract.

[0076] The business request can be understood as a business request generated according to the content of the smart contract signed between the user and the public account. For example, the first user signs the first smart contract with the public account, and the first regulatory sub-account connects to the first smart contract. When the first smart contract is running, the processor generates the first business request according to the content of the first smart contract, and the processor uses the first regulatory sub-account to complete the first business request. It can be seen that the public account can connect to multiple smart contracts, such as the first smart contract and the second smart contract.

[0077] The first smart contract can be understood as the smart contract corresponding to the first smart contract product purchased by the first user, and the second smart contract can be understood as the smart contract corresponding to the second smart contract product purchased by the second user. The operation logic of the smart contracts connected to different regulatory sub-accounts can be different. In the application environment where the smart contract product is a financial product, the operation logic of the smart contract can be, for example, different times for subscribing to financial products. For example, if customer A is the first user, the first smart contract connected to the first regulatory sub-account corresponding to the smart contract is to purchase financial product A every three days, and customer B is the second user, and the second smart contract connected to the second regulatory sub-account corresponding to the smart contract is to purchase financial product A every week. The operation logic of the smart contract can also be, for example, different financial products are subscribed. For example, if customer A is the first user, the first smart contract connected to the first regulatory sub-account corresponding to the smart contract is to purchase financial product A every three days, and customer B is the second user, and the second smart contract connected to the second regulatory sub-account corresponding to the smart contract is to purchase financial product B every three days. The operation logic of the smart contract can be different, for example, the logic of triggering fund redemption is different. For example, if customer A is the first user and the balance of the first regulatory sub-account corresponding to the customer A is lower than the first threshold, fund redemption will be triggered, that is, part of the funds will be redeemed from the public account to the first regulatory sub-account corresponding to customer A, so that the first regulatory sub-account corresponding to customer A is equal to or greater than the first threshold. If customer B is the first user and the balance of the second regulatory sub-account corresponding to the customer B is lower than the second threshold, fund redemption will be triggered, that is, part of the funds will be redeemed from the public account to the second regulatory sub-account corresponding to customer B, so that the second regulatory sub-account corresponding to customer B is equal to or greater than the second threshold. It can be seen that different smart contracts can be formulated according to the customer's choice, so that the smart contract product connected to the same public account can carry out multiple activities.

[0078] In some embodiments, the first user and the second user may be the same customer, such as the same bank customer, and the bank customer may have two supervisory sub-accounts for the same public account.

[0079] In some embodiments, the first user and the second user may be different customers, such as two bank customers, and different bank customers may have different regulatory sub-accounts for the same corporate account.

[0080] The digital currency fund supervision method provided in the embodiment of the present application, through the setting of a supervision sub-account system, is to divide the public account into multiple supervision sub-accounts, establish a one-to-one relationship between the supervision sub-accounts and the smart contract, and then the same smart contract type connected to the public account can carry out multiple activities at the same time, and the merchant corresponding to the public account can implement customized fund supervision for each user, demonstrating the consistency, mandatory, verifiability and other characteristic functions of the digital currency smart contract, and enriching the use scenarios of digital currency.

[0081] In some embodiments, the corporate account is a corporate wallet that can receive and pay in multiple scenarios and for multiple customers. The first regulatory sub-account and the second regulatory sub-account are sub-wallets obtained by dividing the corporate wallet, and correspond to different customers respectively.

[0082] Please refer to Figure 3A , is a flow chart of S202 in an embodiment of the present application. In some embodiments, S202 in the above text includes:

[0083] S2021: Obtain the card number information of the first smart contract;

[0084] S2022: Determine the product type of the first smart contract according to the card number information of the first smart contract;

[0085] Among them, the product type of the first smart contract can be understood as a smart contract product with different performance or functions, such as smart IC cards, smart E cards, gift cards, etc. Although the transactions of the three also belong to the transaction category of digital currency, due to the differences in the expression forms and working principles of the three, the operating environments of the smart contracts they connect to are different. Determining the product type of the first smart contract can help the processor quickly and accurately build or activate the operating environment.

[0086] S2023: Construct or activate a first operating environment for the first smart contract according to the type of the first smart contract product;

[0087] S2024: Based on the first operating environment, use the first regulatory account to complete the first business request.

[0088] Please refer to Figure 3B , is a flow chart of S204 in an embodiment of the present application. In some embodiments, S204 in the above text includes:

[0089] S2041: Obtain the card number information of the second smart contract;

[0090] S2042: Determine the product type of the second smart contract according to the card number information of the second smart contract;

[0091] S2043: Construct or activate a second operating environment of the second smart contract according to the type of the second smart contract product;

[0092] S2044: Based on the second operating environment, the second regulatory account is used to complete the second business request.

[0093] S204 in this embodiment and S203 in the above text can be understood as the same type of execution steps of the processor for different users, and will not be described in detail here.

[0094] In some embodiments, the product type is determined according to a coding rule of the card number information.

[0095] It can be understood that after purchasing a smart contract product, a corresponding card number will be generated based on the product type of the purchased smart contract. Furthermore, before building or activating the operating environment of the smart contract, the processor will parse the product type of the target smart contract according to the encoding rules of the card number, and then build or activate it according to the product type.

[0096] The encoding rules may be, for example, one or more digits of the card number, using three numbers, letters, or a combination of numbers and letters to represent smart IC cards, smart E cards, and gift cards respectively. The one or more digits in the card number representing the product type of the smart contract may be the first digit of the card number, the middle digit of the card number, or the last digit of the card number.

[0097] The first business request and the second business request mentioned above may be transactions with actual fund flows, such as funds flowing from the regulatory sub-account to the public account, or may be virtual fund flows, such as freezing the amount corresponding to the first business request of the first regulatory sub-account in the first regulatory sub-account. The frozen funds no longer belong to the first regulatory sub-account, and the first regulatory sub-account has no right to use the frozen funds.

[0098] In some embodiments, the first service request and / or the second service request includes at least one of the following:

[0099] Based on the subscription logic of the smart contract connected to any one of the regulated sub-accounts, after a first preset period of time, any one of the regulated sub-accounts will flow funds for the subscription of wealth management products into the public account;

[0100] Based on the balance correction logic of the smart contract connected to any one of the regulatory sub-accounts, when the balance of any one of the regulatory sub-accounts is lower than the preset balance threshold during the end-of-day fund check, the target funds will be redeemed from the public account.

[0101] It can be understood that the subscription logic of the first smart contract and the second smart contract is to subscribe to the selected financial products from multiple financial products in a timely and quantitative manner, and the balance correction logic of the first smart contract and the second smart contract is that when the balance of the regulated sub-account is lower than the regulated balance threshold, the processor will automatically trigger the redemption of funds. It can be seen that in the subscription logic of the first smart contract and the second smart contract, merchants can be allowed to temporarily overdraw funds in the regulated sub-account on the same business day, as long as the balance of the regulated sub-account is greater than or equal to the balance threshold at the end of the day.

[0102] The end-of-day fund check can be understood as the processor, under the constraints of the first smart contract and the second smart contract, will check the balance of the regulatory sub-account after the end of the same business day. Allowing merchants to temporarily overdraw the balance of the regulatory sub-account on the same business day and make balance corrections to the regulatory sub-account based on the end-of-day fund check can enrich the use scenarios of digital currency and fully release the service performance of digital currency.

[0103] Furthermore, the balance threshold in the balance correction logic of the first smart contract and the second smart contract can be zero, that is, during the end-of-day fund check, when the balance of the regulatory sub-account is lower than zero, the processor will redeem the target funds from the corporate account to the regulatory sub-account, so that the balance of the regulatory sub-account is greater than or equal to zero.

[0104] It can be understood that in the subscription logic of the first smart contract and the second smart contract, merchants can be allowed to temporarily overdraw funds in the regulatory sub-account on the same business day, as long as the balance of the regulatory sub-account is greater than or equal to zero when the funds are checked at the end of the day.

[0105] In some embodiments, the subscription logic and balance correction logic of the target smart contract of different customers may be different, such as the examples in the previous article, which will not be repeated here.

[0106] Please refer to Figure 4 , is a flow chart of a method for supervising funds of digital currency in an embodiment of the present application, the method further comprising:

[0107] S205: Generate a second transaction details table according to the third business request and the fourth business request;

[0108] The second transaction details table represents the transaction details between the first personal account, the second personal account and the corresponding regulatory sub-accounts.

[0109] In some embodiments, the first transaction details table may include the first user, the second user, the content of the business request, the amount of the business request, the time of the business request, etc. The first transaction details may also include the balance of the first user's first regulatory sub-account, the balance of the second user's second regulatory sub-account, etc.

[0110] Please refer to Figure 5 , is a flow chart of a method for supervising funds of digital currency in an embodiment of the present application, the method further comprising:

[0111] S206: Obtaining a third service request of the first user;

[0112] The third business request includes the first smart contract product purchased by the first user;

[0113] S207: Using the first personal account of the first user to complete the third service request;

[0114] The first personal account corresponds to the first regulatory sub-account; the third business request includes a second smart contract product purchased by the second user;

[0115] S208: Obtaining a fourth service request of the second user;

[0116] The fourth business request includes the second smart contract product purchased by the second user;

[0117] S209: using the second personal account of the second user to complete the fourth service request;

[0118] The second personal account corresponds to the second regulatory sub-account.

[0119] The third business request and the fourth business request may be transactions with actual fund flows, such as funds flowing from a personal account to a regulatory sub-account, or may be virtual fund flows, such as freezing the amounts corresponding to the third business request and the fourth business request in the personal account in the personal account. The frozen funds no longer belong to the personal account, and the first user and the second user cannot use the frozen funds.

[0120] It should be noted that the execution order of the above S206, S207, S208 and S209 has no precedence relationship with the execution order of S201, S202, S203 and S204 in the foregoing text, and S201, S202, S203 and S204 may be executed first, and then S206, S207, S208 and S209 may be executed, or S206, S207, S208 and S209 may be executed first, and then S201, S202, S203 and S204 may be executed. This application does not impose any restriction on this.

[0121] In some embodiments, the method of fund supervision further includes:

[0122] S210: Generate a second transaction details table according to the third business request and the fourth business request;

[0123] The second transaction details table represents the transaction details between the first personal account and the second personal account and the corresponding supervision sub-account;

[0124] In some embodiments, the second transaction details table may include the first user, the second user, the content of the business request, the amount of the business request, the time of the business request, the purchased smart contract product, etc. The second transaction details may also include the balance of the first user's personal account, the balance of the second user's personal account, etc.

[0125] In some embodiments, the first transaction details table and / or the second transaction details table can be displayed based on the requests of the first user and the second user, or directly displayed after the transaction. The relationship between the regulatory sub-account and the public account, and the relationship between the personal account and the regulatory sub-account do not need to be obtained through outbound transactions, but can be directly displayed in a unified manner to achieve higher performance transaction queries.

[0126] In some embodiments, the smart contract product includes at least two of the following: a smart IC card, a smart E card, and a gift card. The smart IC card can be understood as a hardware structure on which digital currency is stored. Through the interaction between the smart IC card and other electronic devices, functions such as fund settlement can be realized. The smart E card can be understood as a smart electronic card that carries the identity information of its owner and the digital currency stored in the smart electronic card. Through the information interaction between the two smart electronic cards, functions such as fund settlement can be realized. The gift card can be understood as storing digital currency for specific goods or specific merchants. The digital currency can be in the form of digital currency or in the form of currency defined by the merchant.

[0127] Please refer to Figure 6 , which is a flow chart of the digital currency fund supervision method in the embodiment of the present application. In conjunction with this chart, the digital currency fund supervision method provided in the embodiment of the present application is further explained below.

[0128] In the application scenario of connecting smart contracts to smart contract products and supervising funds between merchants and users, the user will first sign a contract with the merchant and purchase a prepaid card, that is, choose a smart contract product, and then recharge the prepaid card.

[0129] After purchasing a prepaid card, the user can make purchases based on the prepaid card. At this time, the processor will obtain the smart contract signed between the user and the merchant. The smart contract can be selected by the customer from multiple smart contracts provided by the merchant, or it can be customized between the merchant and the user. At this time, the merchant's public wallet will open a regulatory sub-account and flow the assets in the user's prepaid card into the regulatory sub-account.

[0130] After confirming the smart contract, the processor will subscribe to the wealth management product regularly according to the subscription logic of the smart contract, that is, investment subscription transfer. At the same time, the processor will control the balance of the regulatory sub-account during the end-of-day fund check according to the balance correction logic of the smart contract, that is, when the balance of the regulatory sub-account is lower than the balance threshold, the investment redemption transfer will be triggered.

[0131] The processor can also generate two transaction details according to the fund flow between the merchant and the user, namely, a first transaction details table representing the transaction details between the supervision sub-account and the public wallet, and a second transaction details table representing the transaction details between the prepaid card of the personal wallet and the supervision sub-account, wherein the first transaction details table corresponds to Figure 6 The public wallet account details table in the table records the actual transaction details. The second transaction details table corresponds to Figure 6 The personal advance payment transaction details table in the , which records the virtual transaction details.

[0132] In the embodiment of the present application, one regulatory account is connected to one smart contract, that is, one user signs a smart contract with a merchant. The smart contract connected to the public wallet of the same merchant can carry out multiple activities at the same time, which greatly enriches the application scenarios of digital currency, fully releases the service efficiency of digital currency, and facilitates the application and promotion of digital currency.

[0133] Please refer to Figure 7 , is a schematic diagram of a program module of an electronic device provided in an embodiment of the present application, the electronic device 300 includes:

[0134] A first acquisition module 301 is used to acquire a first service request of a first user;

[0135] A first execution module 302, configured to complete the first business request using a first regulatory sub-account of a public account, wherein the first regulatory sub-account is connected to the first smart contract;

[0136] A second acquisition module 301 is used to acquire a second service request of a second user;

[0137] The second execution module 302 is used to complete the second business request using a second regulatory sub-account of the public account, wherein the second regulatory sub-account is connected to the second smart contract.

[0138] Please refer to Figure 8 , is a schematic diagram of the structure of an electronic device 400 provided in an embodiment of the present application, and the electronic device 800 includes:

[0139] A processor 401 and a memory 402, wherein the memory 402 stores computer program instructions, wherein when the computer program instructions are executed by the processor, the processor 401 executes the method for fund supervision of digital currency as described above.

[0140] Furthermore, the electronic device also includes a network interface 403 , an input device 404 , a hard disk 405 , and a display device 406 .

[0141] The above-mentioned interfaces and devices can be interconnected through a bus architecture. The bus architecture can be a bus and bridge that can include any number of interconnected buses. Specifically, one or more central processing units (CPUs) represented by processor 401 and various circuits of one or more memories represented by memory 402 are connected together. The bus architecture can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits together. It can be understood that the bus architecture is used to achieve connection and communication between these components. In addition to the data bus, the bus architecture also includes a power bus, a control bus, and a status signal bus, which are all well known in the art, so they are not described in detail herein.

[0142] The network interface 403 can be connected to a network (such as the Internet, a local area network, etc.), obtain relevant data from the network, and save it in the hard disk 405.

[0143] The input device 404 can receive various instructions input by the operator and send them to the processor 401 for execution. The input device 404 can include a keyboard or a pointing device (eg, a mouse, a trackball, a touch pad or a touch screen).

[0144] The display device 406 can display the result obtained by the processor 401 executing the instruction.

[0145] The memory 402 is used to store programs and data necessary for the operation of the operating system, as well as data such as intermediate results during the calculation process of the processor 401.

[0146] It is understood that the memory 402 in the embodiment of the present invention may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. The memory 402 of the apparatus and method described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0147] In some implementations, the memory 402 stores the following elements, executable modules or data structures, or a subset thereof, or an extended set thereof: an operating system 4021 and an application 4022 .

[0148] The operating system 4021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks. The application 4022 includes various application programs, such as a browser, etc., which are used to implement various application services. The program for implementing the method of the embodiment of the present invention can be included in the application 4022.

[0149] The above-mentioned processor 401, when calling and executing the application and data stored in the memory 402, specifically, the program or instruction stored in the application 4022, first obtains the first business request of the first user and the second business request of the second user, and then uses the first regulatory sub-account of the public account to complete the first business request, and uses the second regulatory sub-account of the public account to complete the second business request.

[0150] The method disclosed in the above embodiment of the present invention can be applied to the processor 401, or implemented by the processor 401. The processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 401 or the instruction in the form of software. The above processor 401 can be a general processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, and can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present invention. The general processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the present invention can be directly embodied as a hardware decoding processor to be executed, or the hardware and software modules in the decoding processor are combined to be executed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 402, and the processor 401 reads the information in the memory 402 and completes the steps of the above method in combination with its hardware.

[0151] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the present application or a combination thereof.

[0152] For software implementation, the techniques described herein can be implemented by modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0153] In addition, an embodiment of the present invention further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor executes the digital currency fund supervision method described above.

[0154] In the several embodiments provided in the present application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0155] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may be physically included separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0156] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform some steps of the sending and receiving method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0157] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for supervising funds of digital currency, characterized in that: include: Obtaining a first service request of a first user; The first business request is completed using a first regulatory sub-account of a public account, wherein the first regulatory sub-account is connected to a first smart contract; Obtaining a second service request of a second user; The second business request is completed using a second regulatory sub-account of the public account, wherein the second regulatory sub-account is connected to a second smart contract.

2. The method for digital currency fund supervision according to claim 1, characterized in that: The first business request is completed using the first supervision sub-account of the public account, including: Obtain the card number information of the first smart contract; Determine the product type of the first smart contract according to the card number information of the first smart contract; Construct or activate the operating environment of the first smart contract according to the type of the first smart contract product; Based on the operating environment, the first regulatory sub-account is used to complete the first business request.

3. The method for digital currency fund supervision according to claim 1, characterized in that: The second business request is completed using the second supervision sub-account of the public account, including: Obtain the card number information of the second smart contract; Determine the product type of the second smart contract according to the card number information of the second smart contract; Construct or activate the operating environment of the second smart contract according to the type of the second smart contract product; Based on the operating environment, the second regulatory account is used to complete the second business request.

4. The method for digital currency fund supervision according to claim 2 or 3, characterized in that: The product type is determined according to the encoding rule of the card number information.

5. The method for digital currency fund supervision according to claim 1, wherein the first service request and / or the second service request comprises at least one of the following: Based on the subscription logic of the smart contract connected to any one of the regulated sub-accounts, after a first preset period of time, any one of the regulated sub-accounts flows funds for the subscription of the wealth management product into the public account; Based on the balance correction logic of the smart contract connected to any one of the regulatory sub-accounts, when the balance of any one of the regulatory sub-accounts is lower than the preset balance threshold during the end-of-day fund check, the target funds are redeemed from the public account.

6. The method for supervising digital currency funds according to claim 1, Its characteristics include: Generate a first transaction details table according to the first business request and the second business request; The first detailed list represents the transaction details between the first regulatory sub-account, the second regulatory sub-account and the public account.

7. The method for digital currency fund supervision according to claim 1, characterized in that: The public account is a public wallet, and the first regulatory sub-account and the second regulatory sub-account are sub-wallets obtained by dividing the public wallet.

8. The method for digital currency fund supervision according to claim 1, characterized in that: Also includes: Obtaining a third business request of the first user; the third business request includes a first smart contract product purchased by the first user; The third service request is completed using a first personal account of the first user, where the first personal account corresponds to the first regulatory sub-account; the third service request includes a second smart contract product purchased by the second user; Obtaining a fourth business request of the second user; the fourth business request includes a second smart contract product purchased by the second user; The fourth business request is completed using the second personal account of the second user, and the second personal account corresponds to the second regulatory sub-account.

9. The method for digital currency fund supervision according to claim 8, characterized in that: Also includes: A second transaction details table is generated according to the third business request and the fourth business request, wherein the second transaction details table represents the transaction details between the first personal account and the second personal account and the corresponding regulatory sub-accounts.

10. An electronic device, characterized in that: include: A first acquisition module, used to acquire a first service request of a first user; A first execution module, configured to complete the first business request using a first regulatory sub-account of a public account, wherein the first regulatory sub-account is connected to the first smart contract; A second acquisition module, used to acquire a second service request of a second user; The second execution module is used to complete the second business request by using a second regulatory sub-account of the public account, wherein the second regulatory sub-account is connected to the second smart contract.

11. An electronic device, characterized in that: include: a memory for storing instructions to be executed by one or more processors of the electronic device, and The processor is one of the one or more processors of the electronic device, and is used to execute the digital currency fund supervision method described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions which, when executed, cause a computer to execute the digital currency fund supervision method described in any one of claims 1 to 9.

13. A computer program product, characterized in that The computer program product includes instructions which, when executed, cause a computer to execute the digital currency fund supervision method described in any one of claims 1 to 9.

Images