KR102286473B1 - Virtual asset verification module, virtual asset transaction system including the same, and method thereof - Google Patents

Abstract

Disclosed are a virtual asset verification module, a virtual asset transaction system comprising the same, and a method thereof. The virtual asset transaction system comprises: a blockchain that receives deposit/withdrawal transaction from an individual blockchain account and stores thereof as blockchain-type data; a virtual asset service system that receives the deposit/withdrawal transaction and a wallet address linked to the deposit/withdrawal transaction, and performs a deposit or a withdrawal according to the deposit/withdrawal transaction; and a virtual asset verification module that filters the deposit/withdrawal transaction received by the blockchain, verifies the deposit/withdrawal transaction and the wallet address of the deposit/withdrawal transaction to the virtual asset service system, and transmits the verification result. Therefore, the present invention is capable of blocking fraudulent transactions and abnormal transactions.

Description

Virtual asset verification module, virtual asset transaction system including the same, and method thereof

The present invention relates to a virtual asset verification module, a virtual asset trading system including the same, and a method therefor. Specifically, the present invention relates to a virtual asset verification module, a virtual asset trading system, and a method for automatically collecting and analyzing data of participating entities to prevent illegal transactions and foreign currency outflow.

Virtual asset transactions can be made through each customer’s account on the blockchain. At this time, this block chain account can store all digital assets issued on the block chain. Each of these blockchain accounts can have an individual address, and is sometimes called a wallet in the sense of storing digital assets. Transactions of virtual assets can be performed using the addresses of these blockchain accounts.

Conventional technologies for preventing illegal virtual asset transactions have been limitedly utilized only in virtual asset exchanges that can issue real-name confirmed deposit and withdrawal accounts. In addition, when converting most virtual assets and fiat currency, the customer information registered with the real-name verification deposit and withdrawal account is matched between the bank and the virtual asset exchange, or transactions are made possible only for customers who have been issued a real-name verification deposit and withdrawal account to prevent fraudulent transactions in virtual assets. did.

However, virtual asset fraud is occurring not only within the virtual asset exchange, but also outside the virtual asset exchange. Currently, there are four exchanges that have issued real-name confirmation deposit and withdrawal accounts in the blockchain ecosystem, and there is a limit to preventing illegal transactions of virtual assets without borders by controlling transactions that occur in a small number of exchanges in Korea.

In addition, as the number of services available in the decentralized ecosystem increases, the frequency of deposits and withdrawals between virtual asset exchanges and customers’ blockchain accounts will increase, and the limitations of the existing method may become clearer.

As a representative example, in order to use decentralized financial services as a decentralized financial service, a customer needs a customer's blockchain account with virtual assets, and for this, a virtual asset exchange is used. Furthermore, customers use virtual asset exchanges to exchange profits generated through decentralized financial services.

At this time, the virtual asset exchange only understands the status of the real-name verification deposit and withdrawal accounts, and does not analyze transactions that occur in decentralized financial services. If currency exchange is performed by generating profits through fraudulent transactions in a decentralized financial service, damage to the virtual asset exchange may occur as well as foreign currency outflow.

Therefore, in order to overcome the limitations of the conventional method, a new technology capable of verifying abnormal transactions is required.
[Patent Document 1] Patent Publication No. 10-2020-0094366

An object of the present invention is to provide a virtual asset trading system that can provide recommendations on fraudulent transactions and abnormal transactions by verifying data on a customer's blockchain account.

In addition, another object of the present invention is to provide a virtual asset verification module that can provide recommendations for fraudulent transactions and abnormal transactions by verifying data on a customer's blockchain account.

In addition, another object of the present invention is to provide a virtual asset transaction method that can provide recommendations on fraudulent transactions and abnormal transactions by verifying data on a customer's block chain account.

The objects of the present invention are not limited to the above-mentioned objects, and other objects and advantages of the present invention not mentioned may be understood by the following description, and will be more clearly understood by the examples of the present invention. Moreover, it will be readily apparent that the objects and advantages of the present invention may be realized by the means and combinations thereof indicated in the claims.

A virtual asset transaction system according to some embodiments of the present invention for solving the above problems is linked to a block chain that receives deposit and withdrawal transactions from a customer's block chain account and stores them as block chain data, the deposit and withdrawal transactions, and the deposit and withdrawal transactions The virtual asset service system that receives the wallet address and performs deposit or withdrawal according to the deposit/withdrawal transaction and filters the deposit/withdrawal transaction received by the block chain, and the wallet address of the deposit/withdrawal transaction and the deposit/withdrawal transaction to the virtual asset service system It includes a virtual asset verification module that verifies and transmits the verification result.

In addition, the deposit/withdrawal transaction may include a deposit transaction and a withdrawal transaction, and the wallet address may be a wallet address for sending a virtual asset for the deposit transaction, and a wallet address for receiving a virtual asset for the withdrawal transaction.

Also, the virtual asset verification module may classify the wallet address by dividing it into a plurality of levels, and may recommend allowing or rejecting deposits and withdrawals to the virtual asset service system according to the plurality of levels.

In addition, the plurality of levels are given when the wallet address is a whitelist registered by a preset first procedure, and when the wallet address is a blacklist registered by a preset second procedure. It may include a second level of being

Also, the second procedure may include determining that the address is an abnormal transaction or a hacker address.

The virtual asset verification module according to some embodiments of the present invention for solving the other problems collects deposit and withdrawal transactions and wallet addresses from a block chain, verifies the deposit and withdrawal transactions and the wallet address to generate a verification result, and the verification A first service module that performs filtering of the deposit/withdrawal transaction according to a result, and at least one of the deposit/withdrawal transaction, the wallet address, and the verification result from the first service module are received and stored, and the first service module can inquire later and a first database for transmitting the verification result when.

In addition, the first service module may include a job store that generates a check result by checking a transaction verification and a hacker address, and a task manager that receives the check result and performs the filtering.

The job store includes a pending checker that checks a pending deposit/withdrawal transaction transmitted by the block chain to the virtual asset service system, a Proud transaction checker that checks abnormal transactions among the deposit/withdrawal transactions, and checks the amount of the deposit/withdrawal transaction It may include a price checker and a hacker checker that checks whether the wallet address is a hacker address.

A virtual asset transaction method according to some embodiments of the present invention for solving the another problem includes the steps of receiving a block chain wallet address and a transaction, verifying the block chain wallet address and the transaction to generate a verification result; and transmitting the verification result to a virtual asset service system.

In addition, the generating of the verification result includes the steps of determining whether the wallet address is a white list registered address, determining whether the wallet address is a black list registered address, and whether the wallet address is an abnormal transaction detection address It may include the steps of determining, and determining whether the transactions of the wallet address show an abnormal investment pattern form.

The virtual asset verification module of the present invention, a virtual asset trading system including the same, and a method therefor, can block fraudulent and abnormal transactions by verifying not only the data of the virtual asset service system including the exchange but also the data of the customer's block chain account. can

In addition, by verifying an individual's blockchain account address, it can be subdivided into multiple levels to precisely determine the risk and derive a response accordingly.

In addition, by operating a whitelist and blacklist of individual blockchain account addresses, transaction judgment can be performed more quickly.

The specific effects of the present invention in addition to the above will be described together while describing specific details for carrying out the invention below.

1 is a conceptual diagram illustrating a deposit transaction processing of a virtual asset trading system according to some embodiments of the present invention.
2 is a conceptual diagram illustrating a withdrawal transaction processing of a virtual asset trading system according to some embodiments of the present invention.
3 is a block diagram for explaining in detail the structure of the virtual asset verification module of FIGS. 1 and 2 .
FIG. 4 is a block diagram for explaining in detail the structure of the job store of FIG. 3 .
5 to 7 are intermediate views for explaining a method of determining a hacker address of a virtual asset verification module according to some embodiments of the present invention.
8 is a block diagram illustrating the virtual asset service system of FIGS. 1 and 2 .
9 is a flowchart illustrating a whitelist registration procedure of a virtual asset trading system according to some embodiments of the present invention.
10 is a flowchart illustrating in detail a whitelist registration procedure of a virtual asset verification module according to some embodiments of the present invention.
11 is a flowchart illustrating in detail a procedure for registering a blacklist and transmitting a verification result of a virtual asset verification module according to some embodiments of the present invention.
12 is a flowchart illustrating a deposit transaction processing sequence of a virtual asset transaction method according to some embodiments of the present invention.
13 is a table for explaining a deposit processing policy according to the level of a wallet address of a virtual asset transaction method according to some embodiments of the present invention.
14 is a flowchart for explaining a method for calculating the level of a wallet address in a virtual asset transaction method according to some embodiments of the present invention.
15 is a table for explaining a step-by-step deposit processing policy of a method for trading virtual assets according to some embodiments of the present invention.
16 is a flowchart illustrating a withdrawal transaction processing sequence of a virtual asset transaction method according to some embodiments of the present invention.
17 is a table for explaining a step-by-step withdrawal processing policy of a virtual asset transaction method according to some embodiments of the present invention.
18 is a conceptual diagram for explaining a security scenario of a virtual asset transaction method according to some embodiments of the present invention.

The terms or words used in this specification and claims should not be construed as being limited to a general or dictionary meaning. In accordance with the principle that the inventor can define a term or concept of a word in order to best describe his invention, it should be interpreted as meaning and concept consistent with the technical idea of the present invention. In addition, the embodiments described in the present specification and the configurations shown in the drawings are only one embodiment in which the present invention is realized, and do not represent all the technical spirit of the present invention, so they can be substituted at the time of the present application. It should be understood that there may be various equivalents and modifications and applicable examples.

Terms such as first, second, A, B, etc. used in this specification and claims may be used to describe various elements, but the elements should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component. The term 'and/or' includes a combination of a plurality of related listed items or any of a plurality of related listed items.

The terms used in this specification and claims are used only to describe specific embodiments, and are not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly dictates otherwise. It should be understood that terms such as “comprise” or “have” in the present application do not preclude the possibility of addition or existence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification in advance. .

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related art, and should not be interpreted in an ideal or excessively formal meaning unless explicitly defined in the present application. does not

In addition, each configuration, process, process, or method included in each embodiment of the present invention may be shared within a range that does not technically contradict each other.

1 is a conceptual diagram illustrating a deposit transaction processing of a virtual asset trading system according to some embodiments of the present invention.

Referring to FIG. 1 , a virtual asset trading system according to some embodiments of the present invention includes a customer 100 , a blockchain 200 , a virtual asset verification module 300 , and a virtual asset service system 400 .

The customer 100 may conduct virtual asset transactions. The customer 100 may have a blockchain account to use the blockchain. At this time, the blockchain account of the customer 100 may store all digital assets issued on the blockchain. For example, a blockchain account may include a wallet of the blockchain.

The address of the customer 100's blockchain account may be the first address (Add1). The customer 100 may transmit a deposit transaction to the blockchain 200 . In this case, the deposit transaction may be the first transaction Tr1. The first address Add1 may be a sending address of a deposit transaction.

The blockchain 200 may store transactions in the form of a block chain. The block chain 200 may include a plurality of nodes and store the block chain 200 in each of the plurality of nodes. Through this, the blockchain 200 can prevent forgery of the transaction.

The blockchain 200 may receive the first transaction Tr1 and the first address Add1 from the customer 100 . The block chain 200 transfers the first transaction Tr1, which is a deposit transaction, to the virtual asset service system 400. At this time, in order to prevent a transaction defect, the virtual asset service system 400 immediately transmits the first transaction Tr1. You can wait without processing.

Alternatively, the block chain 200 may not immediately process the first transaction Tr1, which is a deposit transaction, but may wait. In the blockchain 200 , the virtual asset verification module 300 filters the first transaction Tr1 and when the first transaction Tr1 is confirmed, the first transaction Tr1 is then transferred to the virtual asset service system 400 . can be transmitted

The virtual asset verification module 300 may collect and filter all deposit transactions queued by the block chain 200 delivered to the virtual asset service system 400 (transaction filtering, TF). The virtual asset verification module 300 may filter transactions having a wallet address registered in the white list among transactions transmitted from the block chain 200 to the virtual asset service system 400 through transaction filtering. That is, when the wallet address deposited in the deposit transaction is registered in the whitelist by the virtual asset verification module 300 , the virtual asset verification module 300 transmits the blockchain 200 to the virtual asset service system 400 . Provides whitelist result values for one deposit transaction.

In addition, for a deposit transaction having a wallet address not registered in the whitelist by the virtual asset verification module 300 , the wallet address and transaction are verified by the virtual asset verification module 300 , and the verification result is returned to the virtual asset service system 400 . ) can be transmitted.

If the wallet address is not registered in the whitelist among the deposit transactions accumulated in the block chain 200, the virtual asset verification module 300 verifies the deposit transaction and the wallet address, and checks the verification result for the deposit transaction and the wallet address. may be transmitted to the virtual asset service system 400 . That is, in any case, the deposit transaction and wallet transmitted from the block chain 200 to the virtual asset service system 400 are filtered by the virtual asset verification module 300 , and the result is sent to the virtual asset service system 400 . can be transmitted.

The virtual asset service system 400 may receive the first transaction Tr1 and the first address Add1 from the block chain 200 . In this case, the first transaction Tr1 and the first address Add1 may be transactions and addresses that have been filtered by the virtual asset verification module 300 . That is, the virtual asset verification module 300 must complete transaction filtering (TF) and verification until the first transaction Tr1 completely reaches the virtual asset service system 400 (confirmation complete), and returns the result to the virtual asset may be transmitted to the service system 400 .

The virtual asset service system 400 may receive the first verification result V1 from the virtual asset verification module 300 . The first verification result V1 may be a verification result for the first transaction Tr1 and the first address Add1.

The virtual asset service system 400 may serve as an exchange. However, the present embodiment is not limited thereto. The virtual asset service system 400 may receive the first verification result V1 and, accordingly, may transmit the first approval Res1 to the customer 100 . In this case, the first approval Res1 may include whether the customer 100's first transaction Tr1, ie, whether to approve the deposit for the deposit transaction.

2 is a conceptual diagram illustrating a withdrawal transaction processing of a virtual asset trading system according to some embodiments of the present invention.

Referring to FIG. 2 , the customer 100 may transmit a second request transaction Req_Tr2 and a second address Add2 to the virtual asset service system 400 . In this case, the second request transaction Req_Tr2 may be a withdrawal transaction. The second address Add2 may be a wallet address to which the virtual asset is deposited by the second request transaction Req_Tr2. The customer 100 may request a withdrawal through the second request transaction Req_Tr2 and the second address Add2 to the virtual asset service system 400 .

The blockchain 200 can record, receive, and queue various transactions. Among the transactions recorded by the block chain 200, an abnormal transaction (Tr_ab) may be included. The wallet address of the abnormal transaction (Tr_ab) may be the abnormal transaction address (Add_ab).

The virtual asset verification module 300 may receive an abnormal transaction Tr_ab and an abnormal transaction address Add_ab while performing transaction filtering TF. The virtual asset verification module 300 may verify the abnormal transaction (Tr_ab) and the abnormal transaction address (Add_ab). The virtual asset verification module 300 may store verification results for the abnormal transaction (Tr_ab) and the abnormal transaction address (Add_ab) in an internal database. Of course, the virtual asset verification module 300 may also store verification results for transactions other than the abnormal transaction Tr_ab.

The virtual asset service system 400 may transmit the second address Add2 to the virtual asset verification module 300 for verification of the second request transaction Req_Tr2 and the second address Add2 received from the customer 100 . there is. The virtual asset verification module 300 may transmit the corresponding second verification result V2 to the virtual asset service system 400 by inquiring the second address Add2 . In this case, the second verification result V2 may be the verification result of the second address Add2.

The virtual asset service system 400 may receive the second verification result V2 and propagate or non-propagate the second withdrawal transaction Tr2 according to the second verification result V2 to the block chain 200 . In this case, the second withdrawal transaction Tr2 may be the same as the second request transaction Req_Tr2, but may be a transaction whose propagation to the block chain 200 is determined. In addition, the virtual asset service system 400 may provide the customer 100 with the second approval Res2 . In this case, the second approval Res2 may include whether the customer 100 approves the withdrawal of the second request transaction Req_Tr2 , that is, the withdrawal transaction. In this embodiment, when withdrawal of withdrawal is not approved according to the second verification result V2, the second request transaction Req_Tr2 is also not propagated to the block chain, and withdrawal can be controlled.

3 is a block diagram for explaining in detail the structure of the virtual asset verification module of FIGS. 1 and 2 .

Referring to FIG. 3 , the virtual asset verification module 300 may include a first service module 310 and a first database 320 .

The first service module 310 may collect a transaction and a wallet address, and perform verification. The first service module 310 may generate a verification result and store it in the first database 320 .

Specifically, the first service module 310 may perform transaction filtering (TF) on the pending transactions in the block chain 200 and the virtual asset service system 400 . Accordingly, the first service module 310 may collect the first transaction Tr1 that is a deposit transaction and the first address Add1 that is the wallet address from the block chain 200 . Also, the first service module 310 may receive an abnormal transaction (Tr_ab) and an abnormal transaction address (Add_ab) from the block chain 200 .

Also, the first service module 310 may receive the second address Add2 from the virtual asset service system 400 . The first service module 310 may internally generate a first verification result V1 and a second verification result V2 and transmit them to the virtual asset service system 400 .

The first service module 310 may include a job store 311 and a task manager 312 . The job store 311 may verify the transaction and the wallet address and generate a check result (Ch) for this. The job store 311 may transmit the check result Ch to the task manager 312 .

The task manager 312 may verify the check result Ch and record the result in the database 320 .

The first database 320 receives and stores the first transaction Tr1 and the first address verification result Va1 from the first service module 310, and later transmits the first verification result V1 to the first service module (310) can be provided. The first address verification result Va1 may be a verification result for the first address Add1 , and the first verification result V1 may include a first address verification result Va1 and a first transaction Tr1 .

Also, the first database 320 may receive and store the abnormal transaction Tr_ab, the abnormal transaction address Add_ab, and the abnormal transaction verification result V_ab from the first service module 310 . Thereafter, the first database 320 may transmit the abnormal transaction Tr_ab to the first service module 310 and receive the second address verification result Va2 from the first service module 310 . The second address verification result Va2 may be a verification result for the abnormal transaction address Add_ab.

The first database 320 may transmit the second verification result V2 for the second address Add2 to the first service module 310 .

FIG. 4 is a block diagram for explaining in detail the structure of the job store of FIG. 3 .

Referring to FIG. 4 , the job store 311 may include a pending checker 311_1 , a proud transaction checker 311_2 , a price checker 311_3 , a currency transaction checker 311_4 , and a hacker checker 311_5 . .

The pending checker 311_1 may check a pending transaction transmitted by the block chain 200 to the virtual asset service system 400 . The first service module 310 may perform transaction filtering (TF) of the block chain 200 by the pending checker 311_1 .

The Proud transaction checker 311_2 may detect an abnormal transaction of the transaction. Proud transaction checker (311_2) can detect abnormal transactions by determining the transaction in the block chain account of the customer 100, that is, the transaction in the block chain account of the customer 100, that the block chain 200 transmits to the virtual asset system 400. there is.

The price checker 311_3 may check the amount of deposit or withdrawal of a transaction. The price checker 311_3 may determine an abnormal transaction according to the amount of the transaction. Through this, transactions and addresses can be verified.

The currency transaction checker 311_4 may check the currency of the transaction. That is, it is possible to determine what currency is used in the transaction. However, the present embodiment is not limited thereto.

The hacker checker 311_5 may determine whether the wallet address of the transaction is the hacker address. When the hacker checker 311_5 finds the hacker address, the first service module 310 may register the hacker address in the blacklist.

5 to 7 are intermediate views for explaining a method of determining a hacker address of a virtual asset verification module according to some embodiments of the present invention. 5 may be a transaction structure of a general blockchain.

4 to 7 , in a situation where transactions are connected in a tree form, one of the intermediate wallet addresses may be detected as a hacker address or a suspicious address. It is assumed that the address (expressed by different hatching) of (0xAm1...ne2) in FIG. 6 is exemplarily a hacker address.

In this case, the hacker checker 311_5 may register an address detected as a hacker address and all addresses connected before and after it as a blacklist. However, the present embodiment is not limited thereto.

8 is a block diagram illustrating the virtual asset service system of FIGS. 1 and 2 .

Referring to FIG. 8 , the virtual asset service system 400 may include a second service module 410 and a second database 420 .

The second service module 410 may receive a transaction and a wallet address, and receive a verification result thereof. The second service module 410 may transmit to the customer 100 whether or not to approve corresponding to the verification result.

Specifically, the second service module 410 may receive the first transaction Tr1 confirmed in the block chain 200 and the first address Add1, which is the wallet address thereof. Also, the second service module 410 may directly receive the second request transaction Req_Tr2 and the second address Add2 from the customer 100 . The second service module 410 may transmit the second address Add2 to the virtual asset verification module 300 .

Also, the second service module 410 may receive the first verification result V1 and the second verification result V2 from the virtual asset verification module 300 . Accordingly, the second service module 410 may or may not propagate the second withdrawal transaction Tr2 to the block chain 200 . In this case, the second withdrawal transaction Tr2 may be the same as the second request transaction Req_Tr2, but may be a transaction whose propagation to the block chain 200 is determined.

Accordingly, the second service module 410 may generate the first approval status Res1 and the second approval status Res2. The second service module 410 may transmit the first approval status Res1 and the second approval status Res2 to the customer 100 .

The second database 420 may receive and store the first verification result V1 from the second service module 410 . The second database 420 may receive the first transaction Tr1 and the first address Add1 from the second service module 410 . In response, the second database 420 may transmit the first verification result V1 to the second service module 410 .

The second database 420 may receive the second request transaction Req_Tr2 and the second address Add2 from the second service module 410 . Also, the second database 420 may receive and store the second approval status Res2 from the second service module 410 . The second approval status Res2 may be inquired later.

9 is a flowchart illustrating a whitelist registration procedure of a virtual asset trading system according to some embodiments of the present invention.

Referring to FIG. 9 , the second service module 410 performs an address inquiry (Add_chk) with the second database 420 (S1).

In this case, the searched address may be a wallet address transmitted from the block chain 200 or a wallet address transmitted from the customer 100 . However, the present embodiment is not limited thereto.

Next, the second database 420 transmits the address inquiry result Chk to the second service module 410 in response to the address inquiry Add_chk (S2).

In this case, the address inquiry result Chk may include information on whether the address is registered in the whitelist.

If the address is not registered in the whitelist, the second service module 410 transmits an address registration request Req_reg_WL to the first service module 310 (S3).

The address registration request (Req_reg_WL) may be a request to register an address in the whitelist.

Next, the first service module 310 inquires whether the address is registered (Reg_add) in the first database 320 (S4).

The first database 320 may store the blacklist and determine whether the received address is included in the blacklist. If an address is included in the blacklist, it cannot be registered as a whitelist. Conversely, if the address is not included in the blacklist, the address may be registered in the whitelist. Accordingly, the first database 320 may generate an address registration response Res_reg.

Next, the first database 320 transmits an address registration response (Res_reg) indicating whether the address registration succeeds or fails to the first service module 310 (S5).

Next, the first service module 310 transmits an address registration response (Res_reg) to the second service module 410 (S6).

Through the above-described procedure, the virtual asset verification module 300 and the virtual asset service system 400 may register a whitelist for a wallet address.

10 is a flowchart illustrating in detail a whitelist registration procedure of a virtual asset verification module according to some embodiments of the present invention.

9 and 10, a whitelist registration request is received (S110).

The first service module 310 may receive a whitelist registration request. The whitelist registration request may include an address as an address registration request (Req_reg_WL).

Next, the address is inquired (S120). The first service module 310 may inquire the address included in the address registration request Req_reg_WL in the first database 320 .

Next, it is determined whether the address is a blacklist registered address (S130). That is, it is determined whether the searched address is included in the blacklist stored in the first database 320 . If the inquired address is not included in the blacklist, the whitelist is registered (S150), and if the inquired address is included in the blacklist, exposition data can be received (S140).

If there is an appropriate explanatory data, the address searched as a whitelist can be registered (S150).

11 is a flowchart illustrating in detail a procedure for registering a blacklist and transmitting a verification result of a virtual asset verification module according to some embodiments of the present invention.

Referring to FIG. 11 , a suspicious address and a transaction inquiry request are received ( S210 ).

Specifically, referring to FIG. 2 , the virtual asset service system 400 transmits the second address Add2 to the virtual asset for verification of the second request transaction Req_Tr2 and the second address Add2 received from the customer 100 . may be transmitted to the verification module 300 . In this case, the virtual asset service system 400 may transmit a transaction inquiry request together with the second address Add2.

Again, referring to FIG. 11, an address or transaction is inquired (S220).

Specifically, referring to FIG. 3 , the first database 320 receives and stores the first transaction Tr1 and the first address verification result Va1 from the first service module 310 , and later performs the first verification The result V1 may be provided to the first service module 310 . The first address verification result Va1 may be a verification result for the first address Add1 , and the first verification result V1 may include the first address verification result Va1 and the first transaction Tr1 .

Again, referring to FIG. 11 , it is determined whether an abnormal transaction or a hacker address is present (S230).

Specifically, referring to FIGS. 4 to 7 , in a situation where transactions are connected in a tree form, one of the intermediate wallet addresses may be detected as a hacker address or a suspicious address. In this case, the hacker checker 311_5 may determine the address detected as the hacker address and all addresses connected before and after the hacker address as the hacker address.

Again, referring to FIG. 11, if the abnormal transaction or hacker address is correct, the address is registered as a blacklist (S240), otherwise, an analysis report is prepared (S250).

In this case, the analysis report may mean at least one of the first verification result V1 and the second verification result V2 of FIGS. 1 and 2 .

Then, the analysis report is transmitted (S260).

Specifically, referring to FIGS. 1 and 2 , the virtual asset verification module 300 may transmit a first verification result V1 and a second verification result V2 to the virtual asset service system 400 .

Hereinafter, a deposit transaction processing method of a virtual asset transaction method according to some embodiments of the present invention will be described with reference to FIGS. 12 to 15 . Parts overlapping with the above-described embodiment will be omitted or simplified.

12 is a flowchart for explaining a deposit transaction processing sequence of a virtual asset transaction method according to some embodiments of the present invention, and FIG. 13 is a wallet address level of a virtual asset transaction method according to some embodiments of the present invention. This is a table to explain the deposit processing policy. 14 is a flowchart for explaining a method for calculating the level of a wallet address of a virtual asset transaction method according to some embodiments of the present invention, and FIG. 15 is a step-by-step deposit processing of a virtual asset transaction method according to some embodiments of the present invention. This is a table to explain the policy.

Referring to FIG. 12 , the customer 100 transmits a first transaction (Tr1) and a first address to the block chain 200 (S11).

Specifically, referring to FIG. 1 , the blockchain 200 may receive the first transaction Tr1 and the first address Add1 from the customer 100 . The block chain 200 transfers the received first transaction (Tr1) and the first address (Add1) to the virtual asset service system 400, and the virtual asset service system may wait without processing it immediately for service stability.

Again, referring to FIG. 12 , the first service module 310 transmits the first service module 310 from the block chain 200 to the virtual asset service system 400 and provides transaction filtering (TF) for a pending transaction. to perform (S12).

Specifically, referring to FIG. 1 , the virtual asset verification module 300 may filter pending transactions transmitted from the blockchain 200 to the virtual asset service system 400 by the virtual asset verification module 300 . The virtual asset verification module 300 may filter transactions having a wallet address registered in the whitelist among transactions waiting in the block chain 200 through transaction filtering (TF).

Again, referring to FIG. 12 , the first service module 310 collects the first transaction Tr1 and the first address Add1 received by the block chain 200 (S13).

Specifically, referring to FIG. 1 , the first transaction (Tr1) and the first address (Add1) waiting for the blockchain 200 to transfer to the virtual asset service system 400 by transaction filtering (TF) are virtual assets It may be transmitted to the verification module 300 .

Referring again to FIG. 12 , the first service module 310 transmits the first transaction Tr1 to the first database 320 ( S14 ). Next, the first service module 310 transmits the first address verification result Va1 for the first address Add1 to the first database 320 (S15). Subsequently, the first database 320 transmits the first verification result V1 including the first address verification result Va1 and the verification result of the first transaction Tr1 to the first service module 310 ( S16 ). ).

Referring to FIG. 13 , the first address verification result Va1 may include a plurality of levels. For example, the first address verification result Va1 may be divided into five levels from level 0 to level 4 . However, the present embodiment is not limited thereto. That is, the number of levels through which the first address verification result Va1 is divided may be less than 5, or may be 7 or more.

For example, from level 0 to level 2, the virtual asset verification module 300 may recommend the virtual asset service system 400 to allow deposit processing. Conversely, in levels 3 and 4, the virtual asset verification module 300 may recommend the virtual asset service system 400 to reject the deposit processing. However, this is only an example, and the present embodiment is not limited thereto.

When the step of deriving the first address verification result Va1 of FIG. 12 is described in detail with reference to FIG. 14 , a user is first registered ( S310 ).

Specifically, referring to FIG. 1 , the customer 100 may be registered as a user of the virtual asset service system 400 by registering as a member.

Again, referring to FIG. 14 , the connection is checked ( S320 ).

Specifically, referring to FIG. 1 , the customer 100 may access the virtual asset service system 400 through a login attempt. The virtual asset service system 400 may check the connection of the customer 100 .

Again, referring to FIG. 14 , a virtual asset address is generated ( S330 ).

Specifically, referring to FIG. 1 , the customer 100 may request generation of an internal wallet address of the virtual asset service system 400 . Accordingly, the virtual asset service system 400 may generate a virtual asset address.

Steps S310, S320, and S330 described above may be performed once as a premise before step S340 to be described later.

Again, referring to FIG. 14 , a verification request is received ( S340 ).

Specifically, referring to FIG. 1 , the verification request may be a verification request for the sending address of the deposit request or the receiving address of the withdrawal request when there is a deposit or withdrawal request from the customer 100 in the virtual asset service system 400 . there is.

Again, referring to FIG. 14, it is determined whether the address is a whitelist registered address (S350).

Specifically, referring to FIG. 13 , if the address is a whitelist registered address, the first verification result V1 may be determined as level 0.

If the address is not a white list registered address, referring to FIG. 14 , it is determined whether the address is a black list registered address (S360).

Specifically, referring to FIG. 13 , if it is a blacklist registered address, the first verification result V1 may be determined as level 4 . The blacklist registration address may be determined by the following scenario by way of example. The following scenarios are exemplary and the present embodiment is not limited thereto.

First, if there is a transaction with high hacker relevance, it can be blacklisted. Specifically, when a deposit occurs from a hacker wallet and a wallet with a transaction, or a deposit occurs from a wallet in which transactions are recorded more than a certain number of times a day, it may be registered as a blacklist.

Second, if there is a transaction detected by Fraud Detection System (FDS), it can be registered as a blacklist. Specifically, it can be registered as a blacklist when a deposit occurs within a specific period to an account detected by the FDS system.

Third, if there is a transaction that has already been caught by an investigative agency, it can be registered as a blacklist. Specifically, when a financial accident such as a telecommunication financial fraud is deposited into an account in which it is received, it may be registered as a blacklist.

If it is not the blacklist registered address, referring to FIG. 14 , it is determined whether the address is an abnormal transaction detection address ( S370 ).

Specifically, referring to FIG. 13 , if the address is an aberrant transaction detection address, the first verification result V1 may be determined as level 3 . In this case, the detection of the abnormal transaction may be determined by the following scenario by way of example. The following scenarios are exemplary and the present embodiment is not limited thereto.

First, it can be determined that abnormal transactions are detected when there is frequent deposit. Specifically, it can be determined that an abnormal transaction is detected when more than a certain number of deposits occur within one day.

Second, if multiple transactions are requested at the same time, it can be determined that abnormal transactions are detected. Specifically, it can be determined that an abnormal transaction is detected when a specific number of consecutive deposits occur at the same address or more.

Third, it can be judged that an abnormal transaction is detected when a specific asset is intensively traded. Specifically, it can be determined that an abnormal transaction is detected if the same asset is deposited more than a certain number of times within a specific period.

Fourth, it can be judged that abnormal transactions are detected when suspicious deposits and application cancellations are made. Specifically, it can be determined that an abnormal transaction is detected when a deposit is made from an account that has canceled deposits and withdrawals more than a certain number of times within a specific period.

Fifth, it can be determined that an abnormal transaction is detected when a transaction is made with an unspecified number of people. Specifically, it can be determined that an abnormal transaction is detected when deposits are made with a limited number of wallets in a specific number or more.

Sixth, in the case of a transaction of a newly created wallet, it can be determined that an abnormal transaction is detected. Specifically, it can be determined that an abnormal transaction is detected when a deposit occurs from a newly created external wallet.

Seventh, in the case of a transaction suspected of embezzlement of a large amount, it can be determined that an abnormal transaction is detected. Specifically, it can be determined that an abnormal transaction is detected when more than a certain amount of assets is deposited.

If it is not the address where the abnormal transaction is detected, referring to FIG. 14 , it is determined whether an abnormal investment pattern is shown ( S380 ).

Specifically, referring to FIG. 13 , if an abnormal investment pattern is seen, the first verification result V1 may be determined as level 2 . In this case, the abnormal investment pattern may be determined by the following scenario by way of example. The following scenarios are exemplary and the present embodiment is not limited thereto.

First, it can be judged that an abnormal investment pattern is seen when there is an excess of trading than individual ability. Specifically, it can be determined that an abnormal investment pattern is seen when an asset of a larger size than the transaction amount is deposited within a specific period.

Second, it can be determined that an abnormal investment pattern is seen when there is a customer's transaction without prior transaction. Specifically, it can be determined that an abnormal investment pattern is seen when a deposit is made to a member who has joined within a specific period.

Third, it can be determined that an abnormal investment pattern is seen when there is a sudden change in the trading pattern. Specifically, it can be determined that an abnormal investment pattern is seen when a deposit larger than the average balance of a specific period occurs.

If an abnormal investment pattern is not seen, the first verification result V1 may be determined as level 1.

In addition, it may be necessary to determine the validity of the account of the virtual asset service system 400 in calculating the level of the wallet address. In this case, the determination of the validity of the exchange account may be determined by the following scenario by way of example. The following scenarios are exemplary and the present embodiment is not limited thereto.

First, when there is a change in personal information, it may be determined that there is a problem of account validity of the virtual asset service system 400 . Specifically, if a deposit is made to an account whose password has been changed within a specific period, it may be determined that there is a problem with the validity of the account.

Second, it may be determined that there is a problem of account validity of the virtual asset service system 400 when there is one time password (OTP) initialization. Specifically, if a deposit is made to an account that has initialized OTP within a specific period, it can be determined that there is a problem in account validity.

Third, it may be determined that there is a problem in the account validity of the virtual asset service system 400 when there is a real name exposure avoidance. Specifically, if a deposit is made to an account that has not been issued with a real-name verification deposit/withdrawal account, or if a deposit is made to an account that has not been KYC (Know Your Customer) authentication, it may be determined that there is a problem in account validity.

Third, when there is a transaction related to an important person, it may be determined that there is a problem in the account validity of the virtual asset service system 400 . Specifically, if a deposit is made from a wallet estimated/confirmed owned by the foundation, it can be determined that there is a problem with account validity.

Fourth, when there is a large amount of transaction without opening an account, it may be determined that there is a problem of account validity of the virtual asset service system 400 . Specifically, if an account that has not been issued a real-name verification deposit/withdrawal account has deposited more than a certain amount of assets, it may be determined that there is a problem with the validity of the account.

Fifth, when there is a dormant account transaction, it may be determined that there is a problem of account validity of the virtual asset service system 400 . Specifically, if a deposit is made to a long-term unused/inactive account, it can be determined that there is a problem in account validity.

Sixth, it may be determined that there is a problem of account validity of the virtual asset service system 400 when there is no provision of a transaction source answer. Specifically, if a deposit is made to an account that failed to comply with the request for explanatory data due to the detection of an abnormal transaction in the past, it can be determined that there is a problem with the validity of the account.

Seventh, when there is a suspicious participation transaction, it may be determined that there is a problem of account validity of the virtual asset service system 400 . Specifically, if a deposit is made to an account with more than a specific number of login failures within a specific period, it may be determined that there is a problem with account validity.

Eighth, it may be determined that there is a problem of account validity of the virtual asset service system 400 when there is a frequent or sudden change of customer information. Specifically, if a deposit is made to an account whose member information is changed within a specific period, it may be determined that there is a problem in account validity.

Ninth, it may be determined that there is a problem of account validity of the virtual asset service system 400 when there is a remote transaction. Specifically, when a deposit is made to an account where a login attempt occurs from an overseas IP, or when a deposit occurs to an account where a login attempt occurs from an overseas IP within a specific period, it can be determined that there is an account validity problem.

Referring again to FIG. 12 , the first service module 310 transmits the first verification result V1 to the second service module 410 ( S17 ). Next, the second service module 410 transmits the second verification result V2 to the second database 420 (S18). Next, the block chain 200 transmits a deposit confirmation (DC) to the second service module 410 (S19).

The second service module 410 transmits the first transaction Tr1 corresponding to the deposit confirmation DC to the second database 420 (S20). Next, the second database 420 transmits the first verification result V1 to the second service module 410 (S21).

Subsequently, the second service module 410 may transmit the first approval status Res1 to the customer 100 .

Referring to FIG. 15 , the first approval Res1 may be divided into a plurality of steps. Specifically, the first approval status Res1 has been shown to be divided into steps 0 to 4, but the present embodiment is not limited thereto. That is, the number of steps may be 4 or less, or may be 6 or more. These steps may vary depending on the reason for which the verification result was determined.

Step 0 may be a step in which the deposit is directly reflected. For example, in the case of a transaction related to a whitelisted address, it may be step 0. Step 1 may simply be a step in which the deposit is withheld, and if the problem is resolved over time, the deposit may be reflected later.

Step 2 may be a step in which the virtual asset service system 400 internally performs a first check. If the problem is resolved by checking the internal data again, it may be a step to reflect the deposit later.

Step 3 may be a step in which the virtual asset service system 400 requests the explanatory data from the customer 100 . At this time, if the problem is solved through the explanatory data received from the customer 100, it may be a step of reflecting the deposit later.

Step 4 may be a step in which the virtual asset service system 400 rejects the deposit to the customer 100 . In the case of a transaction with an address registered in the blacklist, the deposit can be directly rejected as described above.

The present embodiment can be subdivided into a plurality of steps as described above, and a corresponding policy can be followed. Through this, the present embodiment can verify the transaction and address more precisely and accurately.

Hereinafter, a withdrawal transaction processing method of a virtual asset transaction method according to some embodiments of the present invention will be described with reference to FIGS. 16 and 17 . Parts overlapping with the above-described embodiment will be omitted or simplified.

16 is a flowchart for explaining a withdrawal transaction processing sequence of a virtual asset trading method according to some embodiments of the present invention, and FIG. 17 is a step-by-step withdrawal processing policy of a virtual asset trading method according to some embodiments of the present invention. This table is for explanation.

Referring to FIG. 16 , first, the first service module 310 performs transaction filtering (TF) on the block chain 200 ( S31 ). Accordingly, the block chain 200 transmits the abnormal transaction (Tr_ab) and the abnormal transaction address (Add_ab) to the first service module 310 (S32).

Next, the first service module 310 stores the abnormal transaction Tr_ab in the first database 320 (S33). Subsequently, when the first database 320 inquires the first service module 310 for the abnormal transaction Tr_ab ( S34 ), the first service module 310 returns the corresponding second address verification result Va2 It is transmitted to the first database 320 (S35).

Subsequently, in this situation, the customer 100 transmits a second request transaction (Req_Tr2) and a second address (Add2) to the second service module 410 (S36). The second service module 410 transmits the second address Add2 to the first service module 310 (S37). The first service module 310 transmits the second address Add2 to the first database 320 (S38).

Then, the second service module 410 transmits a withdrawal confirmation (WC) to the second database 420 (S39). Although steps S38 and S39 are sequentially illustrated in FIG. 16 , the present embodiment is not limited thereto. Steps S38 and S39 may be performed in parallel with each other.

Subsequently, the first database 320 may transmit the second verification result V2 corresponding to the second address Add2 to the first service module 310 ( S40 ). The second verification result V2 may include a previously stored second address verification result Va2 and a transaction verification result.

The second verification result V2 may include a plurality of levels similar to the first verification result V1 . Each of the plurality of levels may be determined according to blacklist, exchange account validity, abnormal transaction detection, and investment pattern detection.

In this case, the blacklist registration address may be determined by the following scenario by way of example. The following scenarios are exemplary and the present embodiment is not limited thereto.

First, if there are FDS-detected transactions, they can be blacklisted. Specifically, it may be registered as a blacklist when a withdrawal request is made within a specific period to an account detected by the FDS system.

Second, if there is a transaction that has already been caught by an investigative agency, it can be registered as a blacklist. Specifically, when a withdrawal is requested from an account in which a financial accident such as a telecommunication financial fraud is received, it may be registered as a blacklist.

Third, if there is a transaction with high hacker relevance, it can be registered as a blacklist. Specifically, when a withdrawal is requested from a hacker wallet and a wallet with a transaction, it may be registered as a blacklist.

In addition, the validity of the exchange account may be determined by the following scenario by way of example. The following scenarios are exemplary and the present embodiment is not limited thereto.

First, when there is a change in personal information, it may be determined that there is a problem of account validity of the virtual asset service system 400 . Specifically, if a withdrawal request is made from an account whose password has been changed within a specific period, it may be determined that there is a problem with the validity of the account.

Second, when there is an OTP initialization, it may be determined that there is a problem of account validity of the virtual asset service system 400 . Specifically, if a withdrawal is requested from an account that has initialized OTP within a specific period or an account that has not set OTP, it may be determined that there is a problem with account validity.

Third, it may be determined that there is a problem in the account validity of the virtual asset service system 400 when there is a real name exposure avoidance. Specifically, if a withdrawal is requested from an account that has not been issued with a real-name verification deposit and withdrawal account, or if a withdrawal is requested from an account that has not been KYC-verified, it may be judged that there is a problem with the validity of the account.

Third, when there is a transaction related to an important person, it may be determined that there is a problem in the account validity of the virtual asset service system 400 . Specifically, when a withdrawal request is made from a corporate account to an external wallet, it can be determined that there is a problem with account validity.

Fourth, when there is a customer transaction without a prior transaction, it may be determined that there is a problem of account validity of the virtual asset service system 400 . Specifically, if a withdrawal request is made from an account that does not have transaction history for more than a specific period, it may be determined that there is a problem with account validity.

Fifth, it may be determined that there is a problem of account validity of the virtual asset service system 400 when there is a suspicious participation transaction. Specifically, if a withdrawal request is made from an account with more than a certain number of login failures within a certain period, it may be determined that there is a problem with the account validity.

Sixth, it may be determined that there is a problem of account validity of the virtual asset service system 400 when there is a frequent or sudden change of customer information. Specifically, if a withdrawal request is made from an account whose member information change time is within a certain period, it may be determined that there is a problem with account validity.

Seventh, it may be determined that there is a problem of account validity of the virtual asset service system 400 when the transaction source answer is not provided. Specifically, if a withdrawal request is made from an account that failed to comply with the request for explanatory data due to the detection of abnormal transactions in the past, it may be determined that there is a problem with the validity of the account.

Eighth, it may be determined that there is a problem in the account validity of the virtual asset service system 400 when withdrawing on the same day or the next day after depositing a large amount. Specifically, if a withdrawal request is made within a specific time after the high-value asset is deposited, it may be determined that there is a problem in account validity.

In this case, the abnormal transaction detection may be determined by the following scenario by way of example. The following scenarios are exemplary and the present embodiment is not limited thereto.

First, it can be determined that abnormal transaction is detected when there is a suspicious withdrawal and application cancellation. Specifically, it can be determined that an abnormal transaction is detected when a withdrawal is requested from an account that has canceled deposits and withdrawals more than a certain number of times within one day.

Second, it can be determined that abnormal transactions are detected when multiple unspecified transactions are requested at the same time. Specifically, it can be determined that an abnormal transaction is detected when a withdrawal request is made from one account to a specific number or more wallets within a specific period.

Third, in the case of a transaction of a newly created wallet, it can be determined that an abnormal transaction is detected. Specifically, it can be determined that an abnormal transaction is detected when a withdrawal is requested from an external wallet that does not have transaction history or a withdrawal is requested from an external wallet created within a specific period.

Fourth, in the case of a split transaction, it can be determined that abnormal transaction is detected. Specifically, it can be determined that an abnormal transaction is detected when a large amount of withdrawal is requested more than a certain number of times within a specific period.

Fourth, it can be determined that an abnormal transaction is detected in the case of a split small amount transaction. Specifically, it can be determined that an abnormal transaction is detected when a withdrawal request is made more than a certain number of times within a specific period.

Fifth, it can be determined that abnormal transaction is detected in case of a specific size division transaction. Specifically, it can be determined that an abnormal transaction is detected when an application is made for withdrawal of the same asset size more than a certain number of times within a specific period.

Sixth, in the case of an exchange transaction, it can be determined that an abnormal transaction is detected. Specifically, it can be determined that a transaction is detected if a withdrawal is requested within a specific period with an asset different from the recently deposited asset.

At this time, the investment pattern detection may be determined by the following scenario by way of example. The following scenarios are exemplary and the present embodiment is not limited thereto.

First, it can be determined that an investment pattern is detected when there is an excess of trades than individual capabilities. Specifically, it can be determined that an investment pattern is detected when a withdrawal of an asset size larger than the accumulated deposit amount is requested.

Second, it can be determined that the investment pattern is detected when there is a sudden change in the trading pattern. Specifically, it can be determined that an investment pattern is detected when a withdrawal request is made for the entire amount of assets held by the account or when withdrawals corresponding to the maximum withdrawal limit of the account are continuously requested within a specific period.

Again referring to FIG. 16 , the first service module 310 transmits the second verification result V2 to the second service module 410 ( S41 ). Next, the second service module 410 propagates the second withdrawal transaction Tr2 and the second address Add2 to the block chain 200 (S42). Next, the second service module 410 transmits the second approval status Res2 to the customer 100 (S43), and stores the second approval status Res2 in the second database 420 (S44).

Referring to FIG. 17 , the second approval Res2 may be divided into a plurality of steps. Specifically, the second approval status Res2 is shown to be divided into steps 0 to 4, but the present embodiment is not limited thereto. That is, the number of steps may be 4 or less, or may be 6 or more. These steps may vary depending on the reason for which the verification result was determined.

Step 0 may be a step to immediately approve the withdrawal. For example, in the case of a transaction related to a whitelisted address, it may be step 0. Step 1 may be a step in which withdrawal is simply withheld, and withdrawal is reflected later when the problem is resolved over time.

Step 2 may be a step in which the virtual asset service system 400 internally performs a first check. If the problem is resolved by checking the internal data again, it may be a step to reflect the withdrawal later.

Step 3 may be a step in which the virtual asset service system 400 requests the explanatory data from the customer 100 . At this time, if the problem is solved through the explanatory data received from the customer 100, it may be a step of reflecting the withdrawal later.

Step 4 may be a step in which the virtual asset service system 400 refuses to withdraw money from the customer 100 . In the case of a transaction with an address registered in the blacklist, withdrawal can be refused immediately as described above.

The present embodiment can be subdivided into a plurality of steps as described above, and a corresponding policy can be followed. Through this, the present embodiment can precisely and accurately determine the approval of the deposit and withdrawal by verifying the transaction and address more precisely and accurately.

18 is a conceptual diagram for explaining a security scenario of a virtual asset transaction method according to some embodiments of the present invention.

Referring to FIG. 18 , in a virtual asset transaction method according to some embodiments of the present invention, a customer 100 has a customer private key 10 and a customer address (Add_user), and the hacker 500 has a hacker address (Add_hacker) It can be assumed that the hacker 500 hacks the customer private key 10 in a state with .

In this case, the hacker withdrawal transaction (Tr_h), that is, the withdrawal to the hacker address is not filtered because it is not a whitelist and may be withheld by the virtual asset verification module 300 and the blockchain 200 . And, it is re-propagated to the user withdrawal transaction (Tr_u), and even when a hacker steals the private key, it is possible to prevent illegal withdrawal.

The above description is merely illustrative of the technical idea of this embodiment, and various modifications and variations will be possible by those skilled in the art to which this embodiment belongs without departing from the essential characteristics of the present embodiment. Accordingly, the present embodiments are intended to explain rather than limit the technical spirit of the present embodiment, and the scope of the technical spirit of the present embodiment is not limited by these embodiments. The protection scope of the present embodiment should be interpreted by the following claims, and all technical ideas within the equivalent range should be construed as being included in the scope of the present embodiment.

Claims (10)

A block chain that receives deposits and withdrawals from a customer's block chain account and stores it as block chain data;
a virtual asset service system for receiving the deposit/withdrawal transaction and a wallet address linked to the deposit/withdrawal transaction to perform deposit or withdrawal according to the deposit/withdrawal transaction; and
a virtual asset verification module that filters the deposit/withdrawal transaction received by the block chain, verifies the deposit/withdrawal transaction and the wallet address of the deposit/withdrawal transaction to the virtual asset service system, and transmits the verification result,
The virtual asset verification module includes a first service module for dividing and classifying the wallet address into a plurality of 0 to fourth levels, generating the verification result, and a first database for storing the verification result,
The first service module,
a job store that generates a check result by checking the transaction verification and hacker address;
and a task manager that receives the check result and performs the filtering,
The job store is
A pending checker that the blockchain transmits to the virtual asset service system and checks pending deposit and withdrawal transactions to perform transaction filtering;
A Proud transaction checker that checks the abnormal transaction by determining the reputation information of the wallet address for the deposit and withdrawal transaction;
a price checker for determining an abnormal transaction by checking the deposit and withdrawal amount of the deposit and withdrawal transaction;
a currency transaction checker for determining the currency of the deposit and withdrawal transaction by checking the currency of the deposit and withdrawal transaction;
A hacker checker that determines whether the wallet address of the deposit and withdrawal transaction is a hacker address,
The 0 to 4 plural levels include whether the wallet address is a whitelist registered by a preset first procedure or a blacklist registered by a preset second procedure, It is determined in consideration of whether the wallet address is an abnormal transaction detection address, whether the wallet address shows an abnormal investment pattern, and whether the account of the wallet address is valid,
The 0th to 4th plurality of levels are,
a 0th level given when the wallet address is a whitelist registered by a preset first procedure;
a fourth level granted when the wallet address is a blacklist registered by a preset second procedure;
A third level given when the wallet address is not the 0th and 4th levels, and the abnormal transaction detection address;
A second level granted when the wallet address is not the 0th, 3rd and 4th levels and shows the abnormal investment pattern;
Including the first level given when the wallet address is not the 0th, 2nd to 4th levels,
The above-mentioned abnormal transaction detection address is when frequent deposits occur to the wallet address, when multiple transactions are requested at the same time, when specific assets are intensively traded, when suspicious deposits and applications are canceled, when transactions with unspecified people, new It is the wallet address that corresponds to at least one case of a transaction in the created wallet or a transaction suspected of embezzlement of a large amount,
The abnormal investment pattern includes at least one of a case in which there is an excess of trading than an individual's ability, a case where there is a customer's transaction without prior trading, or a case where there is a sudden change in the trading pattern,
The virtual asset service system,
a second service module for receiving the deposit/withdrawal transaction and the wallet address from the block chain, and a verification result thereof from the virtual asset verification module;
a second database for storing the verification result and the deposit/withdrawal transaction from the second service module;
The first procedure is
performing, by the second service module, an address inquiry for the wallet address in the second database;
transmitting, by the second database, an address inquiry result to a second service module;
sending, by the second service module, an address registration request to the first service module, when the wallet address is not registered in the whitelist;
Inquiring, by the first service module, whether an address is registered in the first database;
transmitting, by the first database, an address registration response indicating whether the address registration of the white list is successful according to whether the wallet address is included in the blacklist, to the first service module;
and sending, by the first service module, the address registration response to the second service module.
According to claim 1,
The deposit/withdrawal transaction includes a deposit transaction and a withdrawal transaction,
The wallet address is a wallet address for sending virtual assets for the deposit transaction, and a wallet address for receiving virtual assets for the withdrawal transaction.
According to claim 1,
The virtual asset verification module is a virtual asset trading system that recommends allowing or rejecting deposits and withdrawals to the virtual asset service system according to the plurality of levels.
4. The method of claim 3,
The virtual asset verification module,
When the 0th to 2nd level is given to the wallet address, it is recommended to allow deposits and withdrawals to the virtual asset service system,
When the third and fourth levels are given to the wallet address, it is recommended to reject deposits and withdrawals to the virtual asset service system.
Virtual asset trading system.
According to claim 1,
and the second procedure includes determining that the transaction is an anomalous transaction or a hacker address.
Collect deposit/withdrawal transaction and wallet address from the block chain, verify the deposit/withdrawal transaction and the wallet address to generate a verification result, and perform filtering of the deposit/withdrawal transaction according to the verification result. 4 Classifying by dividing into a plurality of levels, a first service module; and
a first database for receiving and storing at least one of the deposit and withdrawal transaction, the wallet address, and the verification result from the first service module, and transmitting the verification result when the first service module inquires later;
The first service module,
a job store that generates a check result by checking the transaction verification and hacker address;
and a task manager that receives the check result and performs the filtering,
The job store is
A pending checker that the block chain transfers to the virtual asset service system to check pending deposit and withdrawal transactions to perform transaction filtering;
A Proud transaction checker that checks the abnormal transaction by determining the reputation information of the wallet address for the deposit and withdrawal transaction;
a price checker for determining an abnormal transaction by checking the deposit and withdrawal amount of the deposit and withdrawal transaction;
a currency transaction checker for determining the currency of the deposit and withdrawal transaction by checking the currency of the deposit and withdrawal transaction;
A hacker checker that determines whether the wallet address of the deposit and withdrawal transaction is a hacker address,
The 0 to 4 plural levels include whether the wallet address is a whitelist registered by a preset first procedure or a blacklist registered by a preset second procedure, It is determined in consideration of whether the wallet address is an abnormal transaction detection address, whether the wallet address shows an abnormal investment pattern, and whether the account of the wallet address is valid,
The 0th to 4th plurality of levels are,
a 0th level given when the wallet address is a whitelist registered by a preset first procedure;
a fourth level granted when the wallet address is a blacklist registered by a preset second procedure;
A third level given when the wallet address is not the 0th and 4th levels, and the abnormal transaction detection address;
A second level granted when the wallet address is not the 0th, 3rd and 4th levels and shows the abnormal investment pattern;
Including the first level given when the wallet address is not the 0th, 2nd to 4th levels,
The above-mentioned abnormal transaction detection address is when frequent deposits occur to the wallet address, when multiple transactions are requested at the same time, when specific assets are intensively traded, when suspicious deposits and applications are canceled, when transactions with unspecified people, new It is the wallet address that corresponds to at least one case of a transaction in the created wallet or a transaction suspected of embezzlement of a large amount,
The abnormal investment pattern includes at least one of a case in which there is an excess of trading than an individual's ability, a case where there is a customer's transaction without prior trading, or a case where there is a sudden change in the trading pattern,
The first procedure is
receiving, by the first service module, an address registration request when the wallet address is not registered in the whitelist;
Inquiring, by the first service module, whether an address is registered in the first database;
transmitting, by the first database, an address registration response indicating whether the address registration of the white list is successful according to whether the wallet address is included in the blacklist, to the first service module;
and the first service module sending the address registration response.

delete delete receiving, by the virtual asset service system, a blockchain wallet address and a transaction;
generating, by a virtual asset verification module, a verification result by verifying the block chain wallet address and the transaction, classifying the wallet address by dividing the wallet address into a plurality of levels 0 to 4; and
sending, by a virtual asset verification module, the verification result to the virtual asset service system, wherein the virtual asset verification module includes a first service module and a first database,
The first service module,
a job store that generates a check result by checking the transaction verification and hacker address;
and a task manager that receives the check result and performs filtering,
The job store is
A pending checker that the blockchain transmits to the virtual asset service system and checks pending deposit and withdrawal transactions to perform transaction filtering;
A Proud transaction checker that checks the abnormal transaction by determining the reputation information of the wallet address for the deposit and withdrawal transaction;
a price checker for determining an abnormal transaction by checking the deposit and withdrawal amount of the deposit and withdrawal transaction;
a currency transaction checker for determining the currency of the deposit and withdrawal transaction by checking the currency of the deposit and withdrawal transaction;
A hacker checker that determines whether the wallet address of the deposit and withdrawal transaction is a hacker address,
The step of classifying by dividing into the 0th to 4th plurality of levels
Whether the wallet address is a whitelist registered by a preset first procedure, a case in which the wallet address is a blacklist registered by a preset second procedure, whether the wallet address is an abnormal transaction detection address, the wallet It is determined in consideration of whether the address shows an abnormal investment pattern and whether the account of the wallet address is valid,
The 0th to 4th plurality of levels are,
a 0th level given when the wallet address is a whitelist registered by a preset first procedure;
a fourth level granted when the wallet address is a blacklist registered by a preset second procedure;
A third level given when the wallet address is not the 0th and 4th levels, and the abnormal transaction detection address;
A second level granted when the wallet address is not the 0th, 3rd and 4th levels and shows the abnormal investment pattern;
Including the first level given when the wallet address is not the 0th, 2nd to 4th levels,
The above-mentioned abnormal transaction detection address is when frequent deposits occur to the wallet address, when multiple transactions are requested at the same time, when specific assets are intensively traded, when suspicious deposits and applications are canceled, when transactions with unspecified people, new It is a wallet address that corresponds to at least one case of a transaction in the created wallet or a transaction suspected of embezzlement of a large amount,
The abnormal investment pattern includes at least one of a case in which there is an excess of trading than an individual's ability, a case where there is a customer's transaction without prior trading, or a case where there is a sudden change in the trading pattern,
The virtual asset service system,
a second service module for receiving the deposit/withdrawal transaction and the wallet address from the block chain, and a verification result thereof from the virtual asset verification module;
a second database for storing the verification result and the deposit/withdrawal transaction from the second service module;
The first procedure is
performing, by the second service module, an address inquiry for the wallet address in the second database;
transmitting, by the second database, an address inquiry result to a second service module;
sending, by the second service module, an address registration request to the first service module, when the wallet address is not registered in the whitelist;
Inquiring, by the first service module, whether an address is registered in the first database;
transmitting, by the first database, an address registration response indicating whether the address registration of the white list is successful according to whether the wallet address is included in the blacklist, to the first service module;
and sending, by the first service module, the address registration response to the second service module.
10. The method of claim 9,
Transmitting the verification result comprises:
Further comprising the step of recommending to allow or reject deposits and withdrawals to the virtual asset service system according to the plurality of levels
How to trade virtual assets.

Images