Method, device, equipment and system for verifying token asset issuing risk

Abstract

The embodiment of the invention discloses a token asset issuing risk verification method, device, equipment and system, and the method comprises the steps: carrying out the main risk scanning of an issuer corresponding to a token asset which is uploaded to a block chain and is to be issued, and obtaining a first risk scanning result corresponding to the issuer; if the first risk scanning result meets a first preset condition, allowing the issuer to issue corresponding digital assets to the token assets; and in response to an issuing request of the issuer for the digital assets by using a target account on the block chain, performing security verification on the target account, and if the verification is passed, issuing the digital assets on the block chain.

Description

Technical Field

[0001] This invention relates to computer technology, and more particularly to a method, apparatus, equipment, and system for verifying the risks of token asset issuance. Background Technology

[0002] Tokenized assets are financial application projects based on blockchain technology. Their core concept is the process of transforming real-world physical or financial assets into digital tokens (i.e., digital assets) using blockchain technology. This process is called "asset tokenization," and its purpose is to enable these assets, which were originally illiquid and had high barriers to entry, to be traded, settled, and have their ownership transferred more conveniently and efficiently on the blockchain. Currently, there are no risk control solutions specifically for tokenized asset projects, either domestically or internationally. In corporate financial innovation scenarios, there is an urgent need for adaptable risk control solutions to ensure project risks are manageable. There are no publicly available standards or guidelines for risk management of tokenized asset projects, and existing industry standards are insufficient to support the ability to discover and monitor risks across the entire tokenized asset project lifecycle. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to provide a method, apparatus, device, and system for verifying the risks of token asset issuance.

[0004] This specification provides a method for verifying the risks of token asset issuance. By addressing risk types such as issuer entity risk and issuer account risk involved in the issuance, circulation, transfer, and liquidation of digital assets on a token asset project issuance platform, a risk management solution adapted to token asset projects is constructed. An innovative account security control solution for blockchain issuance platforms is built, ensuring the real-time security of institutions and users at each stage of platform operation. This guarantees account security, transaction security, and platform stability, preventing various risks such as fraud, theft, and phishing websites. A risk control mechanism for the trading platform is constructed, covering all dimensions of token asset project risk management through control capabilities for entity risk and platform account risk. It integrates traditional financial risk management and blockchain innovative business risk management solutions, addressing industry-specific issues and adapting to the risk control needs of multiple asset classes. It combines traditional risk management and blockchain innovative industry risk control capabilities, constructing a risk management solution more adapted to the domestic compliance regulatory system and business needs. It is adaptable to the differentiated industries and multiple scenarios of token assets, and can adapt to the risk management needs of domestic green assets. The risk control solution has universality and can adapt to risk point analysis and usage capabilities in differentiated scenarios. The method includes: For token assets that have been uploaded to the blockchain and are yet to be issued, a risk scan is performed on the issuer corresponding to the token asset to obtain the first risk scan result corresponding to the issuer. If the first risk scan result meets the first preset condition, the issuer is allowed to issue corresponding digital assets for the token asset; In response to the issuer's request to issue the digital asset using a target account on the blockchain, the target account is securely verified. If the verification is successful, the digital asset is issued on the blockchain.

[0005] Furthermore, the step of allowing the issuer to issue corresponding digital assets for the token asset if the first risk scan result meets the first preset condition includes: Based on the asset pool corresponding to the token asset, the asset risk classification corresponding to the token asset is obtained; If the first risk scan result meets the first preset condition and the asset risk classification meets the second preset condition, the issuer is allowed to issue corresponding digital assets for the token asset.

[0006] Furthermore, the method also includes: Receive relevant information about the entity corresponding to the financing party from the first device; Receive asset link information related to the token asset from the second device; The asset pool is established based on the entity-related information and the asset link-related information.

[0007] Furthermore, allowing the issuer to issue corresponding digital assets for the tokenized asset includes: Obtain the professional level rating information corresponding to the issuer; Based on the aforementioned professional level rating information, the issuer's authority to issue the aforementioned token assets is determined; If the issuance authority meets the third preset condition, the issuer is allowed to issue corresponding digital assets for the token asset.

[0008] Furthermore, allowing the issuer to issue corresponding digital assets for the tokenized asset includes: The issuer is permitted to issue corresponding digital assets based on the issuance authority for the token asset.

[0009] Furthermore, the issuance of the digital asset on the blockchain includes: Determine the on-chain issuance structure and / or revenue distribution mechanism corresponding to the token asset; The digital assets are issued on the blockchain in accordance with the on-chain issuance structure and / or the revenue distribution mechanism.

[0010] Furthermore, the entity risk scan of the issuer corresponding to the token asset includes: Obtain the first entity information corresponding to the issuer, and perform risk scanning on the first entity information using multiple risk tags to obtain the first risk scanning result corresponding to the issuer.

[0011] Furthermore, the method also includes: During the issuance of the digital asset, the first entity information is subject to risk inspection based on multiple risk dimensions, and the issuer's issuance authority regarding the token asset is dynamically adjusted based on the corresponding risk inspection results.

[0012] Furthermore, the security verification of the target account includes: Detect whether the login environment corresponding to the target account is one commonly used by the issuer; If not, perform a trusted security verification on the target account.

[0013] Furthermore, the trusted security verification of the target account includes: The target account is verified as a trusted account, and the login device corresponding to the target account is verified as a trusted device.

[0014] Furthermore, the method also includes: In response to an investor's transaction request for the digital asset, the transaction request is subject to risk verification regarding WEB3 elements. If the verification is successful, the investor is allowed to trade the digital asset with the issuer.

[0015] Furthermore, the risk verification of the transaction request regarding WEB3 elements includes: Obtain at least one WEB3 element corresponding to the transaction request, and perform risk verification on the WEB3 element.

[0016] Furthermore, the WEB3 elements include at least one of the following: The first WEB3 element corresponding to the transaction asset in the transaction request; The second WEB3 element corresponding to the two parties in the transaction request; The third Web3 element corresponding to the blockchain.

[0017] Furthermore, in response to an investor's transaction request for the digital asset, the risk verification of the transaction request regarding WEB3 elements includes: In response to an investor's transaction request for the digital asset based on the risk assessment results corresponding to the token asset, the transaction request is subject to risk verification regarding WEB3 elements. The method further includes: After the token asset is uploaded to the blockchain, a risk assessment is performed on the token asset according to multiple preset risk assessment dimensions to obtain the risk assessment result, and the risk assessment result is provided to the investor.

[0018] Furthermore, the method also includes: In response to the access requests of multiple entities corresponding to the token asset, a risk scan is performed on the entities based on the second entity information submitted by the entities to obtain the second risk scan result corresponding to the entities; If the second risk scan result meets the second preset condition, the subject party is allowed access to the token asset.

[0019] Furthermore, the plurality of parties include the asset holders corresponding to the token assets; The method further includes: If the asset holder has been granted access, in response to the asset holder's upload request for the token asset, the token asset uploaded by the asset holder to the blockchain is obtained.

[0020] Furthermore, the method also includes: During the duration of the business corresponding to the token asset, the entity will be subject to periodic risk inspections, and the entity's permissions regarding the token asset will be dynamically adjusted based on the corresponding risk inspection results.

[0021] This specification also provides an apparatus for verifying the issuance risk of tokenized assets, comprising: The entity risk scanning module is used to perform entity risk scanning on the issuer corresponding to the token asset that has been uploaded to the blockchain and is to obtain the first risk scanning result corresponding to the issuer. The asset issuance module is used to allow the issuer to issue corresponding digital assets for the token asset if the first risk scan result meets the first preset condition. The account security verification module is used to respond to the issuer's request to issue the digital asset using the target account on the blockchain, perform security verification on the target account, and if the verification is successful, issue the digital asset on the blockchain.

[0022] This specification also provides a storage medium storing a computer program adapted to be loaded by a processor and to execute the steps of the method described above.

[0023] This specification also provides an electronic device, including a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the method described above.

[0024] This specification also provides a system including a first device, a second device, and the electronic device described in this specification embodiment. The first device is used for risk management of the financing party, and the second device is used for risk management of the token asset chain.

[0025] This specification also provides a computer program product that stores at least one instruction, characterized in that the at least one instruction, when executed by a processor, implements the steps of the above-described method.

[0026] According to the embodiments of this specification, a risk management solution adapted to token asset projects is constructed by addressing risk types such as issuer entity risk and issuer account risk involved in the issuance, circulation, transfer, and liquidation of digital assets on a token asset project issuance platform. An innovative account security control solution for blockchain issuance platforms is also built, ensuring the real-time security of institutions and users at all stages of platform operation. This guarantees account security, transaction security, and platform stability, preventing various risks such as fraud, theft, and phishing websites. A risk control mechanism for the trading platform is constructed, covering all dimensions of token asset project risk management through control capabilities for entity risk and platform account risk. It integrates traditional financial risk management and blockchain innovative business risk management solutions, addressing industry-specific issues and adapting to the risk control needs of multiple asset classes. It combines traditional risk management and blockchain innovative industry risk control capabilities, constructing a risk management solution more adapted to the domestic compliance regulatory system and business needs. It is adaptable to the differentiated industries and multiple scenarios of token assets, and can meet the risk management needs of domestic green assets. The risk control solution is universal and adaptable to risk point analysis and usage capabilities in differentiated scenarios. Attached Figure Description

[0027] Figure 1 A flowchart illustrating a method for verifying the issuance risk of tokenized assets, provided as an embodiment of this specification; Figure 2 A schematic diagram of a device for verifying the issuance risk of tokenized assets, provided as an embodiment of this specification; Figure 3 This is a schematic diagram of the structure of a system for verifying the issuance risks of tokenized assets, which is an example of this specification. Figure 4 A schematic diagram of an architecture for verifying the issuance risk of tokenized assets, provided as an embodiment of this specification; Figure 5This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0029] Please see Figure 1 This is a flowchart illustrating a method for verifying the issuance risk of tokenized assets, provided in an embodiment of this specification. In this embodiment, the method is applied to an apparatus for verifying issuance risk (hereinafter referred to as an "issuance risk verification apparatus") or an electronic device equipped with an issuance risk verification apparatus. The following will focus on... Figure 1 The process shown will be described in detail. The method for verifying issuance risks may specifically include the following steps: S102, for token assets that have been uploaded to the blockchain and are yet to be issued, perform a principal risk scan on the issuer corresponding to the token assets to obtain the first risk scan result corresponding to the issuer.

[0030] In some embodiments, token assets in a token asset project refer to data resources that originate from the real world, have economic value, and have clear ownership. For token assets to be issued that have been uploaded to the blockchain by the asset holder (i.e., the financing party), a principal risk scan is performed on the issuer corresponding to the token asset to obtain the first risk scan result corresponding to the issuer. The issuer may be the asset holder, or the issuer may be a financial institution (e.g., a bank, investment bank, asset management company, etc.) entrusted by the asset holder or an emerging platform (e.g., a fintech company specializing in tokenization of token assets). In some embodiments, conducting a risk scan of the issuer refers to completing due diligence on the issuer's main risks, verifying its qualifications, and scanning for operational risks, internal and external risks, etc., to obtain the first risk scan result corresponding to the issuer. Specifically, this can be done by taking a risk scan snapshot of the issuer. The purpose of risk scanning is to minimize information asymmetry between the issuer and investors. Risk scanning refers to scanning the issuer from multiple dimensions, such as credit risk (scanning the issuer's willingness and ability to repay), legal and compliance risk (scanning whether the issuer operates legally and compliantly, whether there are legal disputes, and whether it has the qualifications to issue), operational and management risk (scanning whether the issuer's daily operations are stable and sustainable), technology and smart contract risk (scanning whether the technology of the token issued by the issuer itself is secure), and associated risk (scanning whether there are risks in other entities associated with the issuer), thereby forming a complete "risk profile". Here, a snapshot refers to capturing a complete and structured risk view of the issuer at a specific point in time after the token assets are uploaded to the blockchain, since the issuer's risk status is dynamic. The first risk scan result corresponding to the issuer is obtained by scanning this risk view.

[0031] S104, if the first risk scan result meets the first preset condition, the issuer is allowed to issue corresponding digital assets for the token asset.

[0032] In some embodiments, the first risk scan result may be a piece of text describing the issuer's risk situation, or it may be a risk level characterizing the issuer's risk level. For example, the risk level may be a specific numerical value, or it may be a string (e.g., "no risk", "low risk", "medium risk", "high risk", etc.). In some embodiments, the issuer is only allowed to issue corresponding digital assets for the tokenized assets if the first risk scan result meets a first preset condition. Here, digital assets refer to digital certificates (tokens, i.e., digital tokens) created by the issuer on the blockchain to represent the tokenized assets. For example, if the first risk scan result is a numerical risk level, the corresponding first preset condition may be that the risk level is greater than or equal to a preset threshold; or, if the first risk scan result is a string-type risk level, the corresponding first preset condition may be that the risk level is one of at least one preset string; or, if the first risk scan result is a piece of text, the corresponding first preset condition may be that the semantic recognition result obtained by performing semantic recognition on the text meets a preset risk expectation.

[0033] S106, in response to the issuer's request to issue the digital asset using the target account on the blockchain, the target account is securely verified, and if the verification is successful, the digital asset is issued on the blockchain.

[0034] In some embodiments, in response to an issuer's issuance request for digital assets using a target account on the blockchain, a security verification is performed on the target account. This security verification includes checking for security issues such as spam registration, misuse, and fraudulent transactions. In some embodiments, if the target account has security issues, the security verification also includes verifying whether the login IP address or MAC address of the login device corresponding to the target account is a commonly used IP address or device of the issuer. In some embodiments, if it is not a commonly used IP address or device of the issuer, the security verification also includes verifying the identity of the mobile phone number or email address bound to the target account, or verifying the identity of the real name bound to the target account. In some embodiments, the digital asset is only issued on the blockchain if the target account passes the security verification. The solutions in this specification are applied to the prevention and control of spam registration and misuse risks on token asset issuance platforms. Through risk strategies and anomaly monitoring, real-time prevention and control of misuse is achieved, ensuring the security of issuers and investors in the issuance and trading stages of the platform.

[0035] According to the embodiments of this specification, a risk management solution adapted to token asset projects is constructed by addressing risk types such as issuer entity risk and issuer account risk involved in the issuance, circulation, transfer, and liquidation of digital assets on a token asset project issuance platform. An innovative account security control solution for blockchain issuance platforms is also built, ensuring the real-time security of institutions and users at all stages of platform operation. This guarantees account security, transaction security, and platform stability, preventing various risks such as fraud, theft, and phishing websites. A risk control mechanism for the trading platform is constructed, covering all dimensions of token asset project risk management through control capabilities for entity risk and platform account risk. It integrates traditional financial risk management and blockchain innovative business risk management solutions, addressing industry-specific issues and adapting to the risk control needs of multiple asset classes. It combines traditional risk management and blockchain innovative industry risk control capabilities, constructing a risk management solution more adapted to the domestic compliance regulatory system and business needs. It is adaptable to the differentiated industries and multiple scenarios of token assets, and can meet the risk management needs of domestic green assets. The risk control solution is universal and adaptable to risk point analysis and usage capabilities in differentiated scenarios.

[0036] In some embodiments, allowing the issuer to issue corresponding digital assets for the token asset if the first risk scan result meets a first preset condition includes: obtaining the asset risk rating corresponding to the token asset based on the asset pool corresponding to the token asset; and allowing the issuer to issue corresponding digital assets for the token asset if the first risk scan result meets the first preset condition and the asset risk rating meets a second preset condition. In some embodiments, the asset pool corresponding to the token asset refers to a list of real-world asset information corresponding to the token asset to be issued. The list of real-world asset information includes, but is not limited to, basic information of real-world financing targets (i.e., project introduction), regulatory review conclusions, third-party audit conclusions, etc. The basic information includes, but is not limited to, asset type, source of income description, credit enhancement mechanism, financing method, financing term, and all types of rights. This example embodiment does not impose any special limitations on this. In some embodiments, the corresponding asset risk level is determined based on the asset pool corresponding to the token asset. This can be achieved by inputting various information from the asset pool into a trained model to obtain the asset risk level output by the model. Alternatively, the asset risk level can be obtained by performing semantic analysis and summarization on the various information from the asset pool. This example embodiment does not impose any special limitations on this approach. The asset risk level is used to characterize the risk level of the token asset. For example, the asset risk level can be a specific numerical value or a string (e.g., "no risk," "low risk," "medium risk," "high risk," etc.). In some embodiments, the issuer is only allowed to issue corresponding digital assets for the token asset if the first risk scan result meets a first preset condition and the asset risk level meets a second preset condition.

[0037] In some embodiments, the method further includes: receiving entity-related information corresponding to the financing party from a first device; receiving asset-linked information corresponding to the token asset from a second device; and establishing the asset pool based on the entity-related information and the asset-linked information. The first device (which may also be referred to in this context as an "entity security platform") is used for financing party risk management, and the second device (which may also be referred to in this context as an "asset-linked security platform") is used for token asset-linked risk management. The entity-related information includes any information related to the financing party, such as the financing party's entity data, operational data, related party data, credit data, risk scan results, risk level, etc. The asset-linked information includes any information related to the token asset-linked asset, such as asset registration information, data fraud identification results, data risk probe information, data risk warning information, etc.

[0038] In some embodiments, allowing the issuer to issue corresponding digital assets for the token asset includes: obtaining the issuer's professional level rating information; determining the issuer's issuance authority for the token asset based on the professional level rating information; and allowing the issuer to issue corresponding digital assets for the token asset if the issuance authority meets a third preset condition. In some embodiments, the professional level rating information is used to characterize the issuer's level of professionalism. This information can be obtained by searching a search engine or by calling a preset interface; this example embodiment does not impose any special limitations on this. In some embodiments, the professional level rating information can be a specific numerical value or a string (e.g., "beginner," "junior," "intermediate," "advanced," "expert," etc.); this example embodiment does not impose any special limitations on this. In some embodiments, the issuer's authority to issue token assets can be determined based on professional level rating information. For example, the issuance authority mapped to the range where the professional level rating information falls can be used as the issuer's issuance authority for token assets according to a mapping relationship in a preset rule. Alternatively, the professional level rating information can be input into a trained model to obtain the issuer's issuance authority for token assets output by the model. In some embodiments, issuance authority includes, but is not limited to, whether the issuer can issue the digital asset, the maximum issuance quantity of the digital asset (e.g., the maximum number of digital assets that can be issued), and the type of issuance target (e.g., the digital asset can only be issued to individual investors, or only to investment institutions, or can be issued to both individual investors and investment institutions simultaneously). This example embodiment does not impose any special limitations on these aspects. In some embodiments, the issuer is only allowed to issue the corresponding digital asset for the token asset if the issuance authority meets a third preset condition. For example, the issuer is only allowed to issue the digital asset if the issuance authority indicates that the issuer can issue the digital asset corresponding to the token asset.

[0039] In some embodiments, allowing the issuer to issue corresponding digital assets for the token asset includes: allowing the issuer to issue corresponding digital assets for the token asset based on the issuance authority. For example, if the issuance authority includes the maximum issuance quantity of the digital asset (e.g., the maximum number of digital assets that can be issued), then the issuer is only allowed to issue the maximum issuance quantity of digital assets for the token asset. As another example, if the issuance authority includes the type of target audience (e.g., the digital asset can only be issued to individual investors, or only to investment institutions, or can be issued to both individual investors and investment institutions simultaneously), then the issuer is only allowed to issue the digital assets corresponding to the token asset to investors corresponding to that type of target audience.

[0040] In some embodiments, issuing the digital asset on the blockchain includes: determining the on-chain issuance structure and / or revenue distribution mechanism corresponding to the token asset; and issuing the digital asset on the blockchain according to the on-chain issuance structure and / or the revenue distribution mechanism. In some embodiments, the on-chain issuance structure includes, but is not limited to, on-chain token name, mapping method, token custody structure, main purpose, collateral mechanism, liquidation method, etc., and the revenue distribution mechanism includes, but is not limited to, annualized rate of return, user profit method, settlement cycle, distribution execution mechanism, etc., which are not specifically limited in this example embodiment. In some embodiments, the corresponding on-chain issuance structure and / or revenue distribution mechanism can be determined based on the first risk scan result corresponding to the issuer, or the corresponding on-chain issuance structure and / or revenue distribution mechanism can be determined based on the asset risk classification corresponding to the token asset, or the corresponding on-chain issuance structure and / or revenue distribution mechanism can be determined based on the issuer's issuance authority regarding the token asset, which are not specifically limited in this example embodiment. In some embodiments, when issuing the digital asset corresponding to the token asset on the blockchain, the issuance needs to be carried out according to the on-chain issuance structure and / or the revenue distribution mechanism.

[0041] In some embodiments, the risk scanning of the issuer corresponding to the token asset includes: obtaining first entity information corresponding to the issuer; performing risk scanning on the first entity information using multiple risk tags sequentially; and obtaining a first risk scanning result corresponding to the issuer. In some embodiments, the first entity information submitted by the issuer is obtained, and the first entity information is then subjected to risk scanning using multiple different risk tags sequentially. That is, each time, one of the multiple different risk tags is used to scan the first entity information, obtaining a risk scanning result corresponding to each risk tag. Then, the first risk scanning result corresponding to the issuer is determined based on the multiple risk scanning results corresponding to the multiple risk tags. In some embodiments, the first entity information is first scanned using the first risk tag (e.g., risk tag T1) among the multiple risk tags, then the first entity information is scanned using the second risk tag (e.g., risk tag T2) among the multiple risk tags, and so on, until the first entity information is scanned using the last risk tag among the multiple risk tags. In some embodiments, the first entity information is first scanned using the first risk label (e.g., risk label T1) among multiple risk labels. Then, based on the risk scan result corresponding to the first risk label, it is determined whether the first entity information needs to be further scanned using the second risk label (e.g., risk label T2) among multiple risk labels. If so, the first entity information is further scanned using the second risk label, and so on. For example, the first risk scan result corresponding to the issuer can be obtained by semantic analysis and summarization of the multiple risk scan results using a preset algorithm. Alternatively, the multiple risk scan results can be input into a trained model to obtain the first risk scan result corresponding to the issuer output by the model. If the multiple risk scan results are numerical, they can be input into a preset functional relation to obtain the first risk scan result corresponding to the issuer output by the functional relation. Furthermore, since each risk label corresponds to different weight information, the first risk scan result corresponding to the issuer can be determined based on the risk scan result corresponding to each risk label and the weight information corresponding to that risk label. In some embodiments, the issuer's issuance authority regarding the token asset can also be determined based on the first risk scan result.

[0042] In some embodiments, the multiple risk labels include a blacklist, a whitelist, risk control rules, and a risk control model. In some embodiments, a blacklist is a list of addresses or entities explicitly prohibited from participating in specific activities (such as buying, selling, or holding specific token assets), a whitelist is a verified list of addresses or entities explicitly authorized to participate in specific activities (such as subscribing to or trading token assets), risk control rules are a series of predefined, specific, condition-based logical judgments used to automate risk management and compliance operations; for example, these rules can be binary ("if...then..."). A risk control model is a more complex, dynamic model involving data analysis than risk control rules, used to assess, quantify, and predict risk. The input to the risk control model is the primary entity information corresponding to the issuer, and the output is the corresponding risk scan results. The trained risk control model can be obtained by training the model using market information, public opinion information, asset performance information, penalty records, complaint records, fraud records, and other information from various issuers as training data.

[0043] In some embodiments, the method further includes: during the issuance of the digital asset, performing risk inspections on the first entity information based on multiple risk dimensions, and dynamically adjusting the issuer's issuance authority regarding the token asset based on the corresponding risk inspection results. In some embodiments, during the issuance of the digital asset, since the first entity information may change, it is necessary to continuously and periodically perform dynamic risk inspections on the latest first entity information based on multiple risk dimensions, establish an inspection and early warning system, provide real-time early warnings for risks, and promptly assess and handle risk points. These multiple risk dimensions include, but are not limited to, entity risk, operational risk, related party risk, credit risk, internal risk, external risk, public opinion risk, and industry-specific risk. This example embodiment does not specifically limit these. In some embodiments, the issuer's issuance authority regarding the token asset will be dynamically adjusted in real time based on the corresponding risk inspection results. For example, the maximum issuance quantity of the digital asset by the issuer may be reduced or increased, or the issuance target type of the digital asset may be adjusted.

[0044] In some embodiments, the security verification of the target account includes: detecting whether the login environment corresponding to the target account is commonly used by the issuer; if not, performing trusted security verification on the target account. In some embodiments, it is first detected whether the login environment corresponding to the target account is commonly used by the issuer. If it is commonly used by the issuer, the target account can be directly determined to have passed security verification; otherwise, trusted security verification is required for the target account. Trusted security verification refers to confirming, through one or more methods, that the "issuer attempting to log in or operate the account" is indeed the "true owner of this account," and not another user who has stolen the password. Specific methods of trusted security verification include, but are not limited to, SMS / email verification code verification, push notification verification, biometric verification, security key verification, etc. This example embodiment does not impose any special limitations on these methods.

[0045] In some embodiments, the trusted security verification of the target account includes: trusted account verification of the target account and trusted device verification of the login device corresponding to the target account. In some embodiments, trusted account verification of the target account refers to the process of verifying whether the issuer has the legal right to use the account. The blockchain needs to confirm "you are the true owner of this account," specifically, this can be done through password verification, security question verification, SMS / email verification code verification, biometric verification, manual review, etc. In some embodiments, trusted device verification of the login device corresponding to the target account refers to verifying whether the device being used by the issuer is recognized by the blockchain as a "frequently used, secure device belonging to the account owner," specifically, this can be done through a combination of device fingerprinting and a trusted device list.

[0046] In some embodiments, the method further includes: in response to an investor's transaction request for the digital asset, performing a risk verification of the transaction request regarding WEB3 elements; if the verification passes, allowing the investor to trade the digital asset with the issuer. In some embodiments, in response to an investor's transaction request for the digital asset, a risk verification of WEB3 elements is performed on associated information related to the transaction request. This associated information includes, but is not limited to, the transaction assets in the transaction request (e.g., risk verification of WEB3 elements for assets the investor intends to buy and / or pay in the transaction request, and risk verification of WEB3 elements for assets the issuer intends to sell and / or acquire in the transaction request), the parties to the transaction request (e.g., risk verification of WEB3 elements for the investor and the issuer), and the blockchain itself (risk verification of WEB3 elements for the blockchain itself). This example embodiment does not specifically limit this, i.e., [the method is not limited to] [the specific details of the transaction]. The transaction involves risk verification of Web3 elements by the trading assets, the trading parties, and the blockchain itself. Web3 elements refer to technological elements related to the Web3 ecosystem, such as blockchain, stablecoins and tokens, smart contracts, public chain wallets, and decentralized storage. These technologies form the foundation of decentralized finance and digital asset trading. This involves verifying the Web3 elements in the associated information related to the transaction request to determine if any risks exist. Only when the Web3 elements pass the risk verification will investors and issuers be allowed to trade the digital asset on the blockchain. The focus is on monitoring the risks of Web3 elements associated with token asset circulation, such as stablecoin risks and blockchain risks. These risks are strictly controlled in accordance with domestic regulatory requirements and business and industry standards. The solutions in this specification focus on the risk types involved in the issuance platform, including issuer entity risks, account risks, and transaction risks. It builds platform transaction risk control capabilities to ensure issuer entity risks, account security, transaction security, and platform stability. Risks such as spam registration, theft, and fraudulent transactions are prevented through the deployment of security strategies.

[0047] This specification provides a method for verifying risks associated with token asset issuance. By addressing risk types such as issuer entity risk, issuer account risk, and WEB3 element transaction risk involved in the issuance, circulation, transfer, and liquidation of digital assets on a token asset issuance platform, a risk management solution adapted to token asset projects is constructed. An innovative account security control solution for blockchain issuance platforms is also developed, ensuring real-time security for institutions and users at all stages of platform operation. This guarantees account security, transaction security, and platform stability, preventing numerous risks such as fraud, theft, and phishing websites, thus establishing a risk control mechanism for the trading platform. Through its risk control capabilities, including entity risk, platform account risk, and WEB3 element transaction risk, it covers all dimensions of token asset project risk management. It integrates traditional financial risk management and blockchain innovative business risk management solutions, which can solve industry-specific problems and adapt to the risk control needs of multiple asset classes. It combines traditional risk management and blockchain innovative industry risk control capabilities to build a risk management solution that is more adapted to the domestic compliance regulatory system and business needs. It can adapt to the differentiated industries and multiple scenarios of token assets and can adapt to the risk management needs of domestic green assets. The risk control solution has universality and can be adapted to risk point analysis and usage capabilities in differentiated scenarios.

[0048] In some embodiments, the risk verification of the transaction request regarding Web3 elements includes: obtaining at least one Web3 element corresponding to the transaction request and performing risk verification on the Web3 element. In some embodiments, since a token asset project connects two worlds, it faces both the risks of traditional finance and the inherent risks of cryptocurrencies. Failure in either direction can lead to investor losses. Therefore, it is necessary to extract the corresponding Web3 element from the associated information related to the transaction request, and then perform risk verification on the Web3 element to identify, analyze, and assess the potential risks present in the Web3 element. The risk verification of the Web3 element includes, but is not limited to, technical risk verification, real-world asset risk verification, financial risk verification, compliance and regulatory risk verification, and operational and governance risk verification. This example embodiment does not impose any special limitations on this. To ensure the security and reliability of a token asset project, it is necessary to conduct comprehensive and in-depth risk verification of its blockchain-level technical implementation and its associated real-world structure to identify all risk points that may lead to asset losses.

[0049] In some embodiments, the WEB3 element includes at least one of the following: a first WEB3 element corresponding to the transaction asset of the transaction request; a second WEB3 element corresponding to the two parties to the transaction request; and a third WEB3 element corresponding to the blockchain. In some embodiments, the at least one WEB3 element includes a first WEB3 element extracted from first association information (e.g., similar assets of the digital asset, the price of the stablecoin, etc.) associated with the transaction asset (including digital assets, stablecoins, etc.), a second WEB3 element extracted from second association information (e.g., the public chain account of the investor) associated with the two parties to the transaction request (including investors, issuers, asset holders, etc.), and a third WEB3 element extracted from third association information (original data left on the blockchain by the blockchain project, such as transaction records, smart contract code, etc.) associated with the blockchain itself.

[0050] In some embodiments, the step of performing risk verification on the transaction request regarding the digital asset in response to an investor's transaction request for the digital asset, based on a risk assessment result corresponding to the token asset, includes: performing risk verification on the transaction request regarding the WEB3 element in response to an investor's transaction request for the digital asset; wherein, the method further includes: after the token asset is uploaded to the blockchain, performing a risk assessment on the token asset according to multiple preset risk assessment dimensions to obtain the risk assessment result, and providing the risk assessment result to the investor. In some embodiments, after the tokenized assets are uploaded to the blockchain, standardized tokenized asset risk measurement indicators are established to prevent and control tokenized asset risks (such as data fraud and data tampering) involved in the tokenized asset project. This involves full-chain control of tokenized assets from data hardware collection to data operation, conducting risk assessments on the data risks involved in the tokenized asset project during data collection, transmission to the blockchain, data operation, and the entire tokenization process. Automated verification of tokenized assets on the blockchain is implemented, ensuring the authenticity and trustworthiness of the underlying tokenized assets in real time throughout the project's operational cycle. In some embodiments, the tokenized assets are risk-assessed based on multiple preset risk assessment dimensions. These multiple risk assessment dimensions include, but are not limited to, at least one of the following: integrity assessment, accuracy assessment, validity assessment, consistency assessment, and timeliness assessment. This example embodiment does not impose any special limitations on these dimensions. In some embodiments, each risk assessment dimension predefines its own distinct indicator rules. For a token asset uploaded to the blockchain, the indicator rules corresponding to each risk assessment dimension can be used to determine the token asset's indicators for each risk assessment dimension. Then, based on these indicators, the risk assessment result for the token asset is obtained. This result is then provided to the investors of the token asset for reference. For example, the indicators of each risk assessment dimension can be input into a pre-defined function formula or a trained model to obtain the risk assessment result for the token asset. Alternatively, the indicators of each risk assessment dimension can be multiplied by a pre-defined weight coefficient corresponding to each risk assessment dimension and summed to obtain the final risk assessment result for the token asset. In some embodiments, investors can use the reference provided by the risk assessment result for the token asset to conduct a pre-transaction assessment, evaluating whether to purchase the digital asset corresponding to the token asset and / or the quantity of the digital asset to purchase. Then, based on the assessment result, they can initiate a transaction request for the digital asset.In some embodiments, for token assets uploaded to the blockchain, the indicators of the token asset in relation to the value assessment dimension will be determined according to the indicator rules corresponding to the value assessment dimension. Then, the value assessment result corresponding to the token asset will be further determined and provided to the investors corresponding to the token asset, so that the investors can initiate transaction requests for the digital asset based on the risk assessment result and value assessment result corresponding to the token asset.

[0051] In some embodiments, the method further includes: responding to access requests from multiple entities corresponding to the token asset, performing a risk scan on the entity based on the second entity information submitted by the entity, and obtaining a second risk scan result corresponding to the entity; if the second risk scan result meets a second preset condition, allowing the entity to access the token asset. In some embodiments, responding to access requests initiated by multiple entities corresponding to the token asset, performing a subject risk scan on each entity means completing subject risk due diligence, subject qualification verification, and scanning for operational risks, internal and external risks, etc., to obtain a second risk scan result corresponding to the entity. Specifically, this can be done by taking a risk scan snapshot of the entity. "Risk scan" and "snapshot" have been detailed above and will not be repeated here. In some embodiments, the multiple entities include, but are not limited to, asset holders (i.e., financing parties), operators, issuers, custodians, etc. This example embodiment does not make special limitations on this, covering multiple upstream and downstream cooperative entities of the token asset business. By performing risk scans on each entity and focusing on the subject risk, operational risk, credit risk, public opinion risk, etc., of each entity, the safety and stability of all related entities of the token asset are ensured. In some embodiments, a subject will only be allowed access to the token asset if the second risk scan result of a subject meets the second preset condition. That is, the subject will be allowed access to the token asset business corresponding to the token asset. The second risk scan result is similar to the first risk scan result described above, and the second preset condition is similar to the first preset condition described above, so it will not be repeated here.

[0052] In some embodiments, the plurality of principal parties include the asset holders corresponding to the token assets; wherein, the method further includes: if the asset holder has been granted access, in response to the asset holder's upload request for the token assets, obtaining the token assets uploaded to the blockchain by the asset holder. In some embodiments, if the asset holder has been granted access to the corresponding token asset, in response to the asset holder's upload request for the token asset, the token asset uploaded to the blockchain by the asset holder can be obtained. Specifically, the asset device owned by the asset holder may upload the generated token asset to the blockchain. The token asset includes at least one object model, and each object model includes variables corresponding to multiple fields pre-defined for that object model. The object model is also called the token asset model, which is a virtual representation of the token asset in the digital world. The object model refers to the detailed attributes and functions of the asset device in the token asset project down to the data acquisition device, defining the device's state and state data interaction model attribute fields. The object model is a functional abstraction and standardized description of the asset device in the digital world. By providing a unified and standardized data description standard for the same type of asset (such as a specific model of wind turbine, a commercial building, or a car), the object model ensures consistent data format, ease of management and interaction, and comprehensively describes the state, behavior, and function of the token asset in the digital world. In some embodiments, an object model is a standardized set of fields, including multiple fields pre-defined for the object model and corresponding variables (i.e., field values). Variables are the values ​​of fields in the object model used to describe the real-time, continuously changing state data of the token asset. This data is typically automatically collected and generated by sensors (such as temperature sensors, pressure sensors, GPS, electricity meters, etc.) installed on the token asset. In some embodiments, an asset device may correspond to one or more object models. Each type of asset device typically corresponds to a different object model; for example, the object model corresponding to a photovoltaic asset device differs from that corresponding to a car asset device, and object models for each type of asset device are pre-defined. In some embodiments, each object model typically corresponds to different fields, and the fields corresponding to each object model are pre-defined. For example, the object model for a car asset device corresponds to fields such as temperature, remaining power, latitude and longitude, and vehicle speed. The asset device determines the variables (i.e., values) of each field corresponding to the object model based on the raw data it generates or collects. Based on the multiple fields corresponding to the object model and the variables corresponding to each field, the corresponding token asset is generated and uploaded to the blockchain.

[0053] In some embodiments, the method further includes: periodically conducting risk inspections on the entity during the business life corresponding to the token asset, and dynamically adjusting the entity's rights and interests in the token asset based on the corresponding risk inspection results. In some embodiments, during the business life corresponding to the token asset, periodically conducting continuous risk inspections on entities that have been approved for the token asset business based on multiple risk dimensions, covering multiple upstream and downstream cooperative entities of the token asset business, continuously inspecting to ensure that the entity's risks are controllable, ensuring the safety and stability of all related entities of the token asset business, and ensuring the safe, stable, healthy and sustainable development of the token asset project. By establishing a dynamic inspection and early warning system, real-time early warning of risks is achieved. The multiple risk dimensions include, but are not limited to, entity risk, operational risk, related party risk, credit risk, internal risk, external risk, public opinion risk, industry-specific risk, etc., which are not specifically limited in this example embodiment. In some embodiments, the rights of a subject to the token asset are dynamically adjusted based on the risk inspection results of a subject. These rights include, but are not limited to, the subject's corresponding permissions to the digital asset corresponding to the token asset (e.g., whether it can discover the digital asset, whether it can buy the digital asset, whether it can sell the digital asset, etc.) and the maximum number of digital assets that the subject can control (e.g., the maximum number of digital assets that can be issued, the maximum number of digital assets that can be sold, the maximum number of digital assets that can be bought, etc.). This example embodiment does not impose any special limitations on these aspects.

[0054] Figure 2 This specification provides a schematic diagram of a device for verifying the issuance risk of tokenized assets, which can be implemented as all or part of an electronic device through software, hardware, or a combination of both. According to some embodiments, the issuance risk verification device 1 includes a subject risk scanning module 11, an asset issuance module 12, and an account security verification module 13.

[0055] The entity risk scanning module 11 is used to perform entity risk scanning on the issuer corresponding to the token asset that has been uploaded to the blockchain and is to obtain the first risk scanning result corresponding to the issuer. Asset issuance module 12 is used to allow the issuer to issue corresponding digital assets for the token asset if the first risk scan result meets the first preset condition. The account security verification module 13 is used to perform security verification on the target account in response to the issuer's request to issue the digital asset using the target account on the blockchain. If the verification is successful, the digital asset is issued on the blockchain.

[0056] In some embodiments, if the first risk scan result meets a first preset condition, allowing the issuer to issue a corresponding digital asset for the token asset includes: Based on the asset pool corresponding to the token asset, the asset risk classification corresponding to the token asset is obtained; If the first risk scan result meets the first preset condition and the asset risk classification meets the second preset condition, the issuer is allowed to issue corresponding digital assets for the token asset.

[0057] In some embodiments, the issuance risk verification device 1 is further configured to: Receive relevant information about the entity corresponding to the financing party from the first device; Receive asset link information related to the token asset from the second device; The asset pool is established based on the entity-related information and the asset link-related information.

[0058] In some embodiments, allowing the issuer to issue corresponding digital assets for the token asset includes: Obtain the professional level rating information corresponding to the issuer; Based on the aforementioned professional level rating information, the issuer's authority to issue the aforementioned token assets is determined; If the issuance authority meets the third preset condition, the issuer is allowed to issue corresponding digital assets for the token asset.

[0059] In some embodiments, allowing the issuer to issue corresponding digital assets for the token asset includes: The issuer is permitted to issue corresponding digital assets based on the issuance authority for the token asset.

[0060] In some embodiments, issuing the digital asset on the blockchain includes: Determine the on-chain issuance structure and / or revenue distribution mechanism corresponding to the token asset; The digital assets are issued on the blockchain in accordance with the on-chain issuance structure and / or the revenue distribution mechanism.

[0061] In some embodiments, the entity risk scan of the issuer corresponding to the token asset includes: Obtain the first entity information corresponding to the issuer, and perform risk scanning on the first entity information using multiple risk tags to obtain the first risk scanning result corresponding to the issuer.

[0062] In some embodiments, the issuance risk verification device 1 is further used for: During the issuance of the digital asset, the first entity information is subject to risk inspection based on multiple risk dimensions, and the issuer's issuance authority regarding the token asset is dynamically adjusted based on the corresponding risk inspection results.

[0063] In some embodiments, the security verification of the target account includes: Detect whether the login environment corresponding to the target account is one commonly used by the issuer; If not, perform a trusted security verification on the target account.

[0064] In some embodiments, the trusted security verification of the target account includes: The target account is verified as a trusted account, and the login device corresponding to the target account is verified as a trusted device.

[0065] In some embodiments, the issuance risk verification device 1 is further used for: In response to an investor's transaction request for the digital asset, the transaction request is subject to risk verification regarding WEB3 elements. If the verification is successful, the investor is allowed to trade the digital asset with the issuer.

[0066] In some embodiments, the risk verification of the transaction request regarding WEB3 elements includes: Obtain at least one WEB3 element corresponding to the transaction request, and perform risk verification on the WEB3 element.

[0067] In some embodiments, the WEB3 element includes at least one of the following: The first WEB3 element corresponding to the transaction asset in the transaction request; The second WEB3 element corresponding to the two parties in the transaction request; The third Web3 element corresponding to the blockchain.

[0068] In some embodiments, the step of responding to an investor's transaction request for the digital asset by performing risk verification on the transaction request regarding WEB3 elements includes: In response to an investor's transaction request for the digital asset based on the risk assessment results corresponding to the token asset, the transaction request is subject to risk verification regarding WEB3 elements. The issuance risk verification device 1 is also used for: After the token asset is uploaded to the blockchain, a risk assessment is performed on the token asset according to multiple preset risk assessment dimensions to obtain the risk assessment result, and the risk assessment result is provided to the investor.

[0069] In some embodiments, the issuance risk verification device 1 is further used for: In response to the access requests of multiple entities corresponding to the token asset, a risk scan is performed on the entities based on the second entity information submitted by the entities to obtain the second risk scan result corresponding to the entities; If the second risk scan result meets the second preset condition, the subject party is allowed access to the token asset.

[0070] In some embodiments, the plurality of principal parties include the asset holders corresponding to the token assets; The issuance risk verification device 1 is also used for: If the asset holder has been granted access, in response to the asset holder's upload request for the token asset, the token asset uploaded by the asset holder to the blockchain is obtained.

[0071] In some embodiments, the issuance risk verification device 1 is further used for: During the duration of the business corresponding to the token asset, the entity will be subject to periodic risk inspections, and the entity's permissions regarding the token asset will be dynamically adjusted based on the corresponding risk inspection results.

[0072] The above-described apparatus embodiments correspond to the method embodiments, and detailed descriptions can be found in the description of the method embodiments section, which will not be repeated here. The apparatus embodiments are derived based on the corresponding method embodiments and have the same technical effects as the corresponding method embodiments; detailed descriptions can be found in the corresponding method embodiments.

[0073] This specification also provides a system including a first device, a second device, and the electronic device described in this specification embodiment. The first device is used for risk management of the financing party, and the second device is used for risk management of the token asset chain. Figure 3 This is a schematic diagram of a system for verifying the risks of token asset issuance, as exemplified in this specification. The system includes a first device, a second device, and a third device (i.e., the electronic device for verifying the risks of token asset issuance described in the embodiments of this specification, which may also be referred to in the context as a "transaction link security platform"). The third device is used to execute the method for verifying the risks of token asset issuance described in the embodiments of this specification. The third device includes a token asset pool, which is established based on entity-related information from the first device and asset link-related information from the second device. Based on the interaction between the first, second, and third devices, the third device can construct a risk management solution with universality and better adaptability to domestic compliance and regulatory systems and business needs based on the established asset pool.

[0074] Figure 4 This specification provides an architectural diagram of a system for verifying the issuance risks of tokenized assets, as illustrated in an embodiment. The first device is used for entity risk warning and management for entities seeking financing; the second device is used for data risk warning and management across the asset chain; and the third device is used for security management of the tokenized asset trading chain (including warning and management of issuance and trading risks). The operations performed by the first device include, but are not limited to: scanning for entity risks related to financing needs, implementing hierarchical control based on the scan results, and then providing entity risk warnings. The operations performed by the second device include, but are not limited to: identifying data fraud, performing data risk probes, and providing data risk warnings for tokenized assets. The third device includes a token asset pool, which is created based on data from the first and second devices. Specifically, the token asset pool contains basic information about real-world financing targets (i.e., a complete project introduction), regulatory review information, third-party asset audit information, and asset risk classification information. The third device also performs operations such as issuer risk scanning, issuer professionalism classification, and issuance account permission management for asset issuing institutions. Subsequently, based on the risk scanning results and account permission management for asset issuing institutions, and combined with information from the token asset pool, the third device selects the token assets to be issued, and then further determines the on-chain issuance structure and profit distribution mechanism. After the third device creates investor accounts and completes the on-chain element risk confirmation, the token issuance of the token assets can be completed.

[0075] In some embodiments, the first, second, and third devices can all be divided into four layers: a data layer, a product layer, a capability layer, and a risk layer. The data layer provides data support for the product layer, the product layer provides system support for the capability layer, and the capability layer provides capability support for the risk layer. For the first device: the data layer includes various entity-related data such as entity data, operational data, related party data, credit data, and public opinion data. The product layer is equipped with an entity security platform for entity risk perception and dynamic inspection, thereby enabling the capability layer to possess three capabilities: domestic entity risk scanning, entity hierarchical management, and entity risk early warning. Based on these capabilities, the risk layer can conduct risk prevention and control for entity risk, credit risk, operational risk, and public opinion risk. When an entity related to the token asset passes the risk prevention and control measures related to entity security, the token asset is allowed to be listed on the blockchain. For the second device: the data layer includes various data related to the tokenized assets on the blockchain, such as asset registration information, object model information, device-collected data, platform-transmitted data, and manual maintenance data. The product layer is equipped with an asset link security platform, which is used for automated verification, data probes, and asset monitoring. Based on the support of this platform, the capability layer has the ability to identify data fraud, probe data risks, and provide data risk warnings. Thus, the risk layer can prevent and control risks such as data authenticity risks, asset operation risks, asset return risks, data security risks, technical compliance risks, and blockchain technology risks. The tokenized assets pass the asset link security control. If there are no risks, the tokenized assets enter the tokenized asset issuance stage, that is, the tokenized asset issuance risk verification method described in the embodiments of this specification is executed by the third device.

[0076] This specification also provides a computer storage medium that can store multiple instructions adapted for loading by a processor and executing the methods described in this specification.

[0077] This specification also provides a computer program product that stores at least one instruction, which is loaded by the processor and executes the method described in this specification embodiment.

[0078] The embodiments in this specification also provide Figure 5 The diagram shows the structure of the electronic device. Figure 5 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile storage, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile storage into memory and then runs it to implement the above-described method. The electronic device is used to execute the functions of the aforementioned transaction link security platform.

[0079] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0080] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0081] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0082] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0083] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0084] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0085] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0086] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0087] The embodiments described are merely examples in this specification and are not intended to limit the scope of this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for token asset issuance risk verification, comprising: performing subject risk scanning on an issuer corresponding to a token asset uploaded to a blockchain and to be issued, to obtain a first risk scanning result corresponding to the issuer; if the first risk scanning result meets a first preset condition, allowing the issuer to issue a corresponding digital asset for the token asset; in response to a request of the issuer to issue the digital asset using a target account on the blockchain, performing security verification on the target account, and if the verification is passed, issuing the digital asset on the blockchain.

2. The method of claim 1, wherein if the first risk scanning result meets a first preset condition, allowing the issuer to issue a corresponding digital asset for the token asset, comprises: obtaining an asset risk classification corresponding to the token asset according to an asset pool corresponding to the token asset; if the first risk scanning result meets a first preset condition and the asset risk classification meets a second preset condition, allowing the issuer to issue a corresponding digital asset for the token asset.

3. The method of claim 2, further comprising: receiving subject-related information corresponding to a financing party from a first device; receiving asset link-related information corresponding to the token asset from a second device; establishing the asset pool according to the subject-related information and the asset link-related information.

4. The method of any one of claims 1 to 3, wherein allowing the issuer to issue a corresponding digital asset for the token asset comprises: obtaining professional level information corresponding to the issuer; determining issuance authority of the issuer with respect to the token asset according to the professional level information; if the issuance authority meets a third preset condition, allowing the issuer to issue a corresponding digital asset for the token asset.

5. The method of claim 4, wherein allowing the issuer to issue a corresponding digital asset for the token asset comprises: allowing the issuer to issue a corresponding digital asset for the token asset based on the issuance authority.

6. The method of claim 1, wherein issuing the digital asset on the blockchain comprises: determining an on-chain issuance structure and / or a revenue distribution mechanism corresponding to the token asset; issuing the digital asset on the blockchain according to the on-chain issuance structure and / or the revenue distribution mechanism.

7. The method of claim 1, wherein performing subject risk scanning on the issuer corresponding to the token asset comprises: obtaining first subject information corresponding to the issuer, and performing risk scanning on the first subject information using a plurality of risk labels in sequence, to obtain the first risk scanning result corresponding to the issuer.

8. The method of claim 7, further comprising: during the issuance of the digital asset, performing risk inspection on the first subject information according to a plurality of risk dimensions, and dynamically adjusting issuance authority of the issuer with respect to the token asset according to a corresponding risk inspection result. 9.The method of claim 1, wherein the security verification of the target account comprises: detecting whether a login environment corresponding to the target account is commonly used by the issuer; and performing a trusted security verification of the target account if the login environment is not commonly used by the issuer. 10.The method of claim 9, wherein the trusted security verification of the target account comprises: performing a trusted account verification of the target account and a trusted device verification of a login device corresponding to the target account. 11.The method of claim 1, further comprising: performing a risk verification of a WEB3 element in response to a transaction request of an investor for the digital asset, and allowing the investor to trade the digital asset with the issuer if the risk verification is passed. 12.The method of claim 11, wherein the risk verification of the WEB3 element comprises: obtaining at least one WEB3 element corresponding to the transaction request, and performing a risk verification of the WEB3 element. 13.The method of claim 12, wherein the WEB3 element comprises at least one of: a first WEB3 element corresponding to a transaction asset of the transaction request; a second WEB3 element corresponding to a transaction party of the transaction request; and a third WEB3 element corresponding to the blockchain. 14.The method of claim 11, wherein the risk verification of the WEB3 element in response to the transaction request of the investor for the digital asset comprises: the risk verification of the WEB3 element in response to the transaction request of the investor for the digital asset based on a risk assessment result of the token asset; and wherein the method further comprises: performing a risk assessment of the token asset according to a plurality of risk assessment dimensions after the token asset is uploaded to the blockchain, and providing the risk assessment result to the investor. 15.The method of claim 1, further comprising: performing a risk scan of a plurality of subject parties according to second subject information submitted by the subject parties in response to an access request of the subject parties for the token asset, and obtaining a second risk scan result corresponding to the subject parties; and allowing the subject parties to access the token asset if the second risk scan result satisfies a second preset condition. 16.The method of claim 15, wherein the plurality of subject parties comprises an asset holder corresponding to the token asset; and the method further comprises: obtaining the token asset uploaded to the blockchain by the asset holder in response to an upload request of the asset holder for the token asset if the asset holder is allowed to access. 17.The method of claim 15, further comprising: periodically performing a risk inspection of the subject parties during a business duration of the token asset, and dynamically adjusting a permission of the subject parties for the token asset according to a corresponding risk inspection result. 18.A device for token asset issuance risk verification, comprising: ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ wherein ​ ​ ​ ​ ​ The subject risk scanning module is configured to perform subject risk scanning on an issuer corresponding to a token asset to be issued and uploaded to the blockchain, and obtain a first risk scanning result corresponding to the issuer. The asset issuing module is configured to allow the issuer to issue a corresponding digital asset for the token asset if the first risk scanning result satisfies a first preset condition. The account security verification module is configured to perform security verification on a target account on the blockchain in response to a request of the issuer for issuance of the digital asset using the target account, and issue the digital asset on the blockchain if the verification is passed.

19. A storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the steps of the method of any one of claims 1-17.

20. An electronic device for token asset issuance risk verification, comprising: The computer program is executed by the processor to implement the steps of the method of any one of claims 1-17.

21. A system comprising a first device for performing financing party risk management, a second device for performing token asset link risk management, and the electronic device of claim 20. The at least one instruction is executed by the processor to implement the steps of the method of any one of claims 1-17.

22. A computer program product having stored thereon at least one instruction, the computer program product comprising: The computer program is executed by the processor to implement the steps of the method of any one of claims 1-17.

Images