Transaction order processing system, method for processing transaction order, and transaction order processing program

Abstract

To provide a transaction order processing system that is NFT finance for collecting support from around the world through RWA (real-world asset) NFTs based on real business, and that enables obtaining interest and redemption through legally clean crypto-asset lending.SOLUTION: A transaction order processing system according to the present invention is a transaction order processing system using crypto assets, constructed to include a smart contract for performing crypto-asset lending using a TNF (non-fungible token), and includes: a first smart contract serving as an automatic lending and borrowing program; and a second smart contract serving as an automatic correction program for automatically deploying a contract to the first smart contract, in which, when a user serving as a lender lends to the first smart contract, the first smart contract issues a TNF to the user, receives repayment from a company serving as a borrower, and returns the repayment to the user with a bonus added.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a trading order processing system, a trading order processing system using crypto assets that is constructed with a smart contract for lending crypto assets using TNF (non-fungible tokens), and relates to an NFT finance that gathers support from around the world through RWA (real asset) NFTs based on real businesses, and a trading order processing system, trading order processing method, and trading order processing program that enable users to earn interest and redemption through legally clean crypto asset lending. [Background technology]

[0002] At major commodity exchanges around the world, transactions are conducted in which the economic value of commodities and other assets is expressed in the currencies issued by each country. In recent years, digitalization technology has made it easier to trade digital assets such as tokens, which digitally represent the economic value of assets. For example, Patent Document 1 proposes a trading order processing system that uses digital assets and is capable of combining large and small transactions by combining streaming and leave orders, while streamlining matching processes and dramatically improving processing performance.

[0003] The trading order processing system of Patent Document 1 has a smart computer with the functions of acting as the trading counterparty for streaming orders from customers at rates that vary from customer to customer, and returning executions; the functions of placing all leave orders placed by customers on the order book, acting as the trading counterparty for leave orders at the limit prices of sell and buy leave orders where the price difference between the sell and buy orders on the order book is equal to or exceeds the specified spread to be collected by the exchange 30, and returning executions; and the functions of distributing to all customers the price at which the leave order is instantly executed as a common rate for all customers just before it is executed.This makes matching processing more efficient and significantly improves processing performance, and provides a trading order processing system using digital assets that can combine streaming (market-like orders) and leave orders (limit-like orders) to perform transactions between customers with different markup rates for calculating the markup added when the exchange creates rates, such as transactions that combine large and small trades. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2023-72608 Summary of the Invention [Problem to be solved by the invention]

[0005] However, the technology in Patent Document 1 is an NFT financing system that gathers support from around the world through RWA (real-world asset) NFTs based on real businesses, and cannot be said to be a trading order processing system that allows users to earn interest and redemptions through cryptocurrency lending.

[0006] The present invention has been made in consideration of the above points, and provides a trading order processing system, a trading order processing method, and a trading order processing program for NFT finance that gathers support from around the world through RWA (real asset) NFTs based on real businesses, and that allows users to earn interest and redemptions through legally clean crypto asset lending. [Means for solving the problem]

[0007] In other words, the trading order processing system of the embodiment is a trading order processing system using crypto assets, constructed with a smart contract for lending crypto assets using TNF (non-fungible token), and is equipped with a first smart contract which is an automatic lending and borrowing program, and a second smart contract which is an automatic correction program that automatically performs contract deployment for the first smart contract, and when a user who is a lender lends to the first smart contract, the first smart contract issues TNF to the user, receives repayment from the borrower company, adds a bonus and returns it to the user.

[0008] Furthermore, in the trading order processing system, the first smart contract may have a fund management database and a bonus database.

[0009] Furthermore, in the trading order processing system, users may be able to view support destination data through token-gated access.

[0010] Additionally, the trading order processing system may allow users to sell the crypto assets to external marketplaces, including famous artists.

[0011] Furthermore, in the transaction order processing system, the item leased to the end user by the company that borrowed the cryptocurrency lent by the user may be a vehicle.

[0012] The trading order processing method of the embodiment is a trading order processing method using crypto assets, which is constructed with a smart contract for lending (loaning) crypto assets using TNF (non-fungible token), and includes an automatic lending / borrowing step of performing automatic lending / borrowing using a first smart contract, and an automatic correction step of automatically performing contract deployment on the first smart contract using a second smart contract, and includes a TNF issuing step of issuing TNF to the user when the user lends to the first smart contract, a repayment receiving step of receiving repayment from the borrower company, and a bonus issuing step of adding a bonus and returning it to the user in accordance with the receipt of repayment in the repayment receiving step. Includes.

[0013] The trading order processing program of an embodiment is a trading order processing program using crypto assets, constructed with a smart contract for lending (loaning) crypto assets using TNF (non-fungible token), and is provided on a computer with an automatic lending and borrowing function that performs automatic lending and borrowing using a first smart contract, and an automatic correction function that automatically performs contract deployment to the first smart contract using a second smart contract.When a user lends to the first smart contract, the program executes a TNF issuing function that issues TNF to the user, a repayment receiving function that receives repayment from the borrowing company, and a bonus issuing function that adds a bonus and returns it to the user in response to receiving repayment via the repayment receiving function. [Effects of the Invention]

[0014] The trade order processing system of the present invention is a trade order processing system using crypto assets, constructed with a smart contract for lending crypto assets using TNF (non-fungible tokens), and is equipped with a first smart contract which is an automatic lending and borrowing program, and a second smart contract which is an automatic correction program that automatically deploys a contract to the first smart contract.When a user (lender) lends to the first smart contract, the first smart contract issues TNF to the user, receives repayment from the borrower company, adds a bonus and returns it to the user, thereby creating NFT finance that attracts support from around the world through RWA (real asset) NFTs based on real businesses, and makes it possible to earn interest and redemptions through legally clean crypto asset lending. [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 2 is an explanatory diagram for explaining the concept of trade order processing in the trade order processing system of the embodiment. [Figure 2] FIG. 2 is an explanatory diagram for explaining a trade order processing related to the trade order processing system of the embodiment. [Figure 3] 1 is a flowchart illustrating a method for processing a trading order according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] The trading order processing system of an embodiment is a trading order processing system using crypto assets, constructed with a smart contract for lending crypto assets using TNF (non-fungible token), and is equipped with a first smart contract which is an automatic lending and borrowing program, and a second smart contract which is an automatic correction program that automatically performs contract deployment for the first smart contract.When a user who is a lender lends to the first smart contract, the first smart contract issues TNF to the user, receives repayment from the borrower company, adds a bonus and returns it to the user.

[0017] Therefore, the trading order processing system (trading order processing method) of the embodiment is an NFT financing that gathers support from around the world through RWA (real asset) NFTs based on real businesses, and is positioned as a technology that enables interest and redemption to be obtained through legally clean cryptocurrency lending.

[0018] FIG. 1 is an explanatory diagram illustrating the concept of trade order processing related to a trade order processing system 100 of an embodiment. In a transaction to lease a vehicle using cryptocurrency of a user 200, the trade order processing system 100 receives a trade order from the user 200, and upon receiving cryptocurrency lending (DAI) from the user 200, grants an NFT (non-fungible token) of the vehicle to the user 200. Next, the trade order processing system 100 lends the cryptocurrency received from the user 200 to a leasing company 310 that is the borrower of the loan. The leasing company 300 that is the borrower leases the vehicle to an end user 400 and enters into a loan agreement with the end user 400. The end user 400 repays the loan, including the principal and interest, to the leasing company 300 that is the borrower of the loan. After receiving the loan repayment from the end user 400, the leasing company 300 repays the rental fee and principal to the trade order processing system 100 that provided the loan. The user 200 then receives the interest and redemption from the trade order processing system 100.

[0019] FIG. 2 is an explanatory diagram illustrating the processing of the trade order processing system 100 according to an embodiment. In FIG. 2, when a user 200 lends their crypto asset to the trade order processing system 100, an NFT (non-fungible token) is issued from the first smart contract 110. A leasing company 300 withdraws funds from a fund management database 1100 held by the first smart contract 110. An end user 400 who leases and uses a vehicle repays the principal and interest to the leasing company 300. Upon receiving the repayment, the leasing company 300 adds a bonus to the bonus database 1200. When the user 200 claims (demands) the bonus, the user 200 receives the principal and interest from the leasing company 300. The second smart contract 120 performs contract deployment on the first smart contract 110. Contract deployment is performed on the blockchain by sending an Ethereum transaction containing the compiled code of the smart contract without specifying a recipient, which automatically corrects the processing performed by the first smart contract 110. This process is described below.

[0020] End users 400 provide data to the support destination database 1300. Users 200 can view the support destination data by token-gated access to the support destination database 1300. The support destination data includes the driver's driving status via IoT (Internet of Things).

[0021] Additionally, User 200 sells vehicle data to External Marketplace 500. NFTs enable image data to be tokenized, effectively connecting socially meaningful projects with well-known artists, creating investment opportunities that have a direct impact on the real world and can be enjoyed as art, not just in traditional financial terms. For example, if a user sends an image of an actual vehicle to External Marketplace 500, an artist will draw various images of the vehicle and add text to create a beautiful design.

[0022] Next, we will explain in detail the processing of the first smart contract 110. The NFT contract aims to represent lending contracts as digital certificates (NFTs) and build a mechanism that allows users to claim or redeem rights. The goal of the NFT contract is to improve transparency and convenience by representing TokTok's lending contracts as NFTs.

[0023] First, let's explain Constructor. The purpose of Constructor is to perform the initial configuration of the NFT contract. This function is designed to manage the bonus interest rate of the lending contract. Users can earn a specific amount of DAI as a bonus within a specified period. This bonus interest rate is provided using a linear vesting method in addition to the standard fixed interest rate. As for the function specification, the period during which users can earn the bonus is specified as (**l,r**), and the bonus DAI is distributed within this period. Regarding bonus distribution, the total amount of bonus DAI distributed within a specific period is specified as amount, and this amount is linearly vested within the period and distributed equally to all NFT holders. Regarding bonus management, each bonus is assigned and managed by ID. To remove, the bonus ID is specified and deleted. This function is restricted by the onlyOwner modifier so that it can only be executed by the contract owner (the project's management team).

[0024] Here are the details of the functions. addBonusPool adds a bonus pool for the specified period and returns the index of the pool after addition. The period that can be added must be more than a certain distance from the current time (specify a constant such as 1 week, as there is a possibility that DAI for the bonus will not be available). removeBonusPool deletes the bonus pool with the specified id and returns the total number of pools after deletion. The deletion period is limited to bonus pools that have not yet started (it is not possible to delete those that have already started distribution). calcBonus calculates the total bonus of a user at a specific point in time. It is used in Claim, etc.

[0025] We will now explain how to implement it. As a first, straightforward implementation, all bonus pools registered in the contract are scanned and calculations are performed for each pool. This method is efficient when the number of pools is small, but as the number of pools increases, the amount of calculations increases and processing becomes heavy. As a second implementation, the BIT algorithm is used. A Binary Indexed Tree is used to speed up the addition of intervals and bonus calculations. Calculations can be performed in O(log(T)) regardless of the number of pools. Here, T represents time, and processing can be sped up by setting an appropriate upper limit.

[0026] Here's a use case: Bonus pools are added or removed based on specific events in the lending agreement (e.g., the start or end of a special promotional period). For example, you can set up a 100 DAI bonus from the third to fourth month. This bonus vests linearly until the end of the specified period or upon redemption.

[0027] Next, let's talk about PublicMint. Its purpose is to allow qualified users to mint NFTs during an active public sale. **publicMint** allows users to mint a specified number of NFTs when a public sale is active. Users must pay the correct price and not exceed the maximum number of mints per transaction.

[0028] Next, we will explain the processing flow of PublicMint. Regarding cost calculation, the total cost is calculated based on the publicPrice and mintAmount. Regarding condition verification, the public sale status, presale status, mint limit, and total supply limit are verified. Regarding NFT minting, the NFT is securely minted to the caller's address.

[0029] Next, we will explain PreMint, whose purpose is to allow whitelisted users to mint NFTs with valid signatures during the active presale phase.

[0030] Here is an overview of PreMint: The **preMint** function allows whitelisted users with valid signatures to mint NFTs.

[0031] This section explains the process flow of PreMint. Cost calculation: Calculate the total cost based on **preCost** and _mintAmount**. Signature verification: Verify the user's credentials using a cryptographic signature. Whitelist update: Update the number of mints in the user's whitelist. NFT minting: Securely mint the specified amount of NFTs to the user's address.

[0032] Here are some key points about the implementation: Before executing a mint operation, users must set an allowance for the DAI contract so that the NFT contract can withdraw the specified amount of DAI tokens. The NFT contract will issue the specified number of NFTs to the user based on the received DAI tokens. This process provides users with an opportunity to directly invest in the project by simultaneously providing funds for lending participation and receiving NFTs.

[0033] Please note that users must ensure that they have the required amount of DAI tokens in their wallets for Mint and that the allowance for the NFT contract is set appropriately.

[0034] Next, we will explain the administrator functions (setPresale, setPublicsale, setPresalePrice, setPublicPrice). The purpose of the administrator functions (setPresale, setPublicsale, setPresalePrice, setPublicPrice) is to switch the sale state (presale or public sale) or to set the price for both phases. Regarding arguments, each function takes a Boolean value or price value as an argument to set the state or price. These owner-only functions manage the operational parameters of NFT sales and can adjust the sale state and price to adapt to different phases of the sales process.

[0035] Next, we will explain verifyAddressSigner. The purpose of verifyAddressSigner is to verify whether the specified signature is valid and to check whether the user is authorized to mint based on certain conditions during pre-mint.

[0036] The **verifyAddressSigner** function verifies whether the signature submitted by the user is generated correctly based on certain conditions (user address and maximum mint amount), which restricts NFT minting to only whitelisted users during the presale period.

[0037] Next, we will explain the processing flow. To generate a message hash, a message hash is generated from the combined data of msg.sender (the address of the user who called the function) and **maxMintAmount** (the maximum number of mints a user can make). To verify the signature, the address is restored from the sent signature using the Ethereum standard signature protocol for the generated message hash. It is then confirmed whether this restored address matches the pre-set **signerAddress**.

[0038] As an implementation note, this function is private and is expected to be called only from other functions within the contract. This maintains the security of the internal logic. Signature verification is an important step to ensure that whitelisted users can properly use the minting opportunities to which they are entitled. The signature must be accurate to prevent unauthorized access. The **signerAddress** can only be changed by a trusted source (e.g., the project administrator). This address must be strictly managed to prevent it from being made public or used fraudulently. This function ensures that NFT presales are executed correctly and securely under certain conditions.

[0039] Next, I will explain Activate. The purpose of Activate is to allow users to claim. This is to avoid problems such as the operator not being able to prepare DAI in time when lendAt has passed. This NFT can only be claimed if lendAt has actually passed and activate has been called. Activate is a function that operators execute after the user has prepared the funds to claim. Once this is executed and after lendAt, users can claim it.

[0040] The process flow is explained below. When the management team calls Activate, the internal variable _isActive becomes true. This enables claim claimAll redeem redeemAll. The internal variable _isActive becomes true. This enables claim claimAll redeem redeemAll.

[0041] Here are some points to note regarding implementation: Only the contract owner can execute this function. This is to prevent unauthorized activation by third parties other than the operation team.

[0042] Next, we will explain setBaseURI. The purpose of setBaseURI is to update the base URI used for all token URIs in the contract, thereby changing the location where the NFT metadata is stored or accessed. **setBaseURI** is a function to update the base URI used for all token URIs in a smart contract. This update is important if the storage location of the NFT metadata changes or a redirection is required.

[0043] The process flow is as follows: The verification step verifies that the caller is the contract owner and prevents unauthorized changes. For URI updates, the baseURI variable is updated with the _newBaseURI provided by the caller. The event logging step logs an event to notify off-chain applications of the base URI change, if necessary, to facilitate updates to user interfaces and other dependent services.

[0044] A few implementation notes: This function is restricted to the contract owner via the **onlyOwner** modifier, ensuring that only authorized individuals can change the base URI. It is important to validate the format and correctness of **_newBaseURI** to avoid errors in token URI resolution. Care should be taken to consider the impact of changing the base URI on existing tokens, especially if they are already in use or owned by external users.

[0045] Next, we will explain Claim / ClaimAll. The purpose of Claim / ClaimAll is to claim interest on a specific NFT. The Claim and ClaimAll functions provide a process for NFT holders to claim accumulated interest on a specific NFT or multiple NFTs. This allows users to receive profits generated from lending. The calculation used for claiming interest is as follows:

[0046]

number

[0047] where p is the price of the NFT, r is the annual yield rate, now is the current block timestamp (block.timestamp), lendAt is the timestamp when the lending contract started, YEAR is the time in one year expressed in unixtime, _calcBonus(now) is the total bonus amount at the current time, and claimed_{nftId} is the total amount of interest already claimed for a given NFT (claimed[nft_id]).

[0048] Next, we will explain the processing flow. It checks whether it is Active and fails if not. For Claim, it claims interest for a single NFT. Interest is calculated based on the specified tokenId, and the corresponding interest is paid to the NFT owner. For ClaimAll, it claims interest for multiple NFTs at once. Interest is calculated for each tokenId in the specified tokenIds list, and finally the total interest is paid in one lump sum to the NFT owner.

[0049] Here are some points to note about implementation. The claim process is carried out using DAI tokens. Interest is paid to the NFT owner via ERC20 transfer. If the DAI balance is insufficient to cover the amount required for the claim, the maximum balance will be claimed. If the balance is 0, the claim will not be made and claimed[nft_id] will not be updated. The ClaimAll function reduces transaction costs by processing multiple claims at once. If there are multiple NFT owners, the ClaimAll function will process DAI transfers separately for each NFT owner (although in reality this is not used, so in that case it is acceptable to specify that transfers will not be processed for any NFT owners other than the first one).

[0050] Next, we will explain Redeem / RedeemAll. The purpose of Redeem / RedeemAll is to claim the principal of an NFT at maturity. Interest is also claimed. The Redeem and RedeemAll functions provide a process for NFT holders to claim the principal and accumulated interest when the lending contract reaches maturity. This allows them to recover their investment and realize profits. The principal redemption amount is equal to the selling price of the NFT. The _claim(tokenId) function is also called to calculate and pay interest at maturity. For this interest calculation, refer to the formula detailed in the explanation of the Claim function above.

[0051] Next, we will explain the processing flow. It checks whether it is Active and fails if not. For Redeem, it claims the principal and the interest accumulated by a single specified NFT. For RedeemAll, it claims the principal and interest of each of multiple specified NFTs all at once. These functions allow the redemption of the principal and claim of the interest simultaneously, allowing NFT holders to fully recover their investment.

[0052] Here are some implementation notes. Redeem operations can only be performed on NFTs whose lending contracts have reached maturity. This maturity check is based on the conditions set when the NFT was purchased or when the lending contract was initiated. For a lump-sum redemption using RedeemAll, _redeem(tokenId) is called for each NFT in turn, and all claims are finally added together to perform an ERC20 transfer. This streamlines the processing of multiple claims and reduces gas costs. An interest claim (_claim(tokenId)) is automatically made before the Redeem operation. This is a measure to maximize user benefits. If there are multiple NFT owners, the RedeemAll function will process DAI separately for each NFT owner (although this is not actually used in practice, so in that case, it is acceptable to not process transfers to anyone other than the first NFT owner).

[0053] Next, we will explain Withdraw. The purpose of Withdraw is for operations to withdraw funds. The Withdraw function is used by the NFT project operation team to withdraw funds accumulated in the contract and transfer them to a specified address. This function is used for operational needs, such as managing project revenue and redistributing operating funds.

[0054] Next, we will explain the processing flow. The management team specifies the address (token) and amount (amount) of the token they want to withdraw, and the address (receiver) to which they want to transfer the funds. When the Withdraw function is called, the specified amount is transferred from the tokens held by the NFT contract to the receiver. If a zero address is specified for the token, the native asset will be transferred. This function is restricted by the onlyOwner modifier so that it can only be executed by the contract owner (the project management team).

[0055] Next, we will explain some points to note when implementing this. Only the contract owner can execute this function. This is an important security measure to prevent third parties other than the operation team from fraudulently withdrawing funds. Before performing a withdrawal, it is necessary to confirm that the contract holds a sufficient amount of tokens. If there are insufficient tokens, the transaction will fail. Withdrawals and transfers of funds should be carried out carefully to maintain transparency in the project's financial management. Appropriate records and audits are required. The token address should basically be a DAI address. If the zero address is specified as the token address, the native asset will be targeted.

[0056] Next, we will explain AddBonusToken / RemoveBonusToken / ClaimToken. The purpose of AddBonusToken / RemoveBonusToken / ClaimToken is to grant any ERC20 as a reward to NFT Owners.

[0057] Next, we will explain AddBonusToken. The AddBonusToken function sets up a specific ERC20 token (token address) to be distributed over a specified period (starting at l and ending at r). This function gives NFT holders the opportunity to receive additional token rewards. If this setting is made for an already existing token, the operation will fail.

[0058] Next, we will explain the processing flow. Regarding token transfer, the specified amount of tokens (amount) is transferred from msg.sender to the NFT contract. Regarding saving the settings, the settings are saved in the map as bonusToken[token]=(amount,l,r). This defines the conditions for bonus distribution for the specified token. This function is restricted by the onlyOwner modifier so that it can only be executed by the contract owner (the project's management team).

[0059] Next, we will explain some points to note. Attempting to execute AddBonusToken for a token that has already been set will fail. This is to prevent multiple distribution settings for the same token. msg.sender must approve the token to the NFT contract before the operation and must hold a sufficient amount of tokens.

[0060] Next, we will explain RemoveBonusToken. The RemoveBonusToken function deletes the bonus settings for the specified ERC20 token (token address). When deleting, all balances of the token remaining in the NFT contract will be returned to the operator.

[0061] Next, we will explain the processing flow. When deleting settings, the bonusToken[token] setting corresponding to the specified token address is deleted from the map. The claimedToken[token] map is also deleted. When returning tokens, all token balances of the token address remaining in the NFT contract are transferred to the operator. This function is restricted by the onlyOwner modifier so that it can only be executed by the contract owner (the project management team).

[0062] Next, please note the following: Before deleting a token, please make sure that there is a bonus setting for the target token. After deletion, the related token will no longer be distributed as a bonus.

[0063] Next, let's explain ClaimToken. The ClaimToken function is used by the owner of a specific NFT (tokenId) to claim a bonus for a specified ERC20 token (token address). This function allows the NFT owner to receive the distributed token rewards.

[0064] Next, we will explain the process flow. Regarding the calculation of the claimable amount, the amount of tokens that the NFT owner of tokenId can receive is calculated for the specified token address.

[0065]

number

[0066] Next, please note the following points. If block.timestamp is before the start point l, no processing will be performed. Tokens can only be claimed within the distribution period and if the claiming conditions are met. After claiming, the total amount of tokens claimed will be recorded in claimedToken. Additional DAI will also be granted using this method.

[0067] Next, we will explain pause. The purpose of pause is to temporarily suspend the operation of a smart contract and stop it from accepting new transactions. The pause function temporarily stops the smart contract from processing new transactions. This is used to ensure the safety of the system during emergencies or maintenance.

[0068] Next, we will explain the process flow. For verification, we confirm that the caller is the contract owner. For suspension execution, we set the contract state to suspended so that new transactions cannot be accepted.

[0069] Next, we will explain some implementation points. This function can only be executed by the contract owner due to the onlyOwner modifier. When a contract is paused, all defined transactions and functions are stopped. For this reason, pausing must be used carefully.

[0070] Next, we will explain unpause. The purpose of unpause is to resume the operation of a paused smart contract and resume accepting transactions. The unpause function resumes the operation of a paused smart contract and allows it to accept new transactions. This is used after necessary maintenance has been completed or after the security of the system has been reconfirmed.

[0071] The process is as follows: Validation: verifies that the caller is the contract owner. Resume: sets the contract state to resumed so that new transactions can be accepted again.

[0072] Next, we will explain some implementation points. This function also uses the onlyOwner modifier, so it can only be executed by the contract owner. When the contract is resumed, all previously paused functions will start working again. It is recommended to perform a complete safety check of the system before resuming.

[0073] Next, we will explain setRoyaltyAddress. The purpose of setRoyaltyAddress is to set the address for receiving NFT royalties. The setRoyaltyAddress function updates the address for receiving NFT royalties. The defined royalty will be paid to this address every time the NFT is resold.

[0074] Next, we will explain the processing flow. For verification, confirm that the caller is the contract owner. For address update, save the new address specified in _royaltyAddress to the royaltyAddress variable. For royalty setting update, call the _setDefaultRoyalty function and update the default royalty setting using the updated royaltyAddress and the currently set royaltyFee.

[0075] Next, we will explain some points to note when implementing this function. The onlyOwner modifier ensures that only the contract owner can execute this function. This controls changes to the royalty receiving address and prevents unauthorized changes. It is important to verify that the new royalty address is a valid Ethereum address. If an inappropriate address is set, royalty payments may fail. When updating royalty settings, it is recommended that you double-check that the current royalty rate is appropriate and adjust it if necessary.

[0076] Next, we will explain the helper function: calcRemainBalance. The calcRemainBalance function is used to calculate the minimum balance of DAI that a contract should hold until a certain point in time, until. This calculation takes into account any claimable interest or bonuses, as well as the amount already claimed.

[0077]

number

[0078] Here, p is the selling price (principal) of the NFT, r is the annual yield percentage, totalClaimable is the total amount that can be claimed, until is a specified point in time (a future date), maturity is the maturity date, lendAt is the start time of the lending contract, YEAR is the time in one year expressed in unixtime, totalNotYetClaimed is the amount that has not yet been claimed, totalClaimed is the total amount that has already been claimed, NeedDAIAmount is the amount of DAI needed, and DAI.balanceOf(this) is the balance of DAI currently held by the contract. This function returns three values: totalClaimable, totalNotYetCalimed, and NeedDAIAmount.

[0079] Next, we will explain a usage example. The operation team can use this function to periodically check the amount of DAI that the contract should hold to respond to future claims, and add or adjust funds as necessary. It can also be used to calculate APY taking into account future bonuses. This ensures that user claims are met and maintains the credibility of the project.

[0080] Next, we will explain the key points of implementation. It is recommended that the calcRemainBalance function be calculated in advance off-chain (for example, in a web interface or backend service) and used as reference information when adding funds to the contract as needed. By incorporating this function into the contract, it can be used as part of an automated fund management or audit process.

[0081] Next, we will explain the Helper function: maturity. The maturity function returns the maturity date of this NFT lending contract. To be precise, it returns a timestamp that is LENDING_PERIOD after lendAt (or you can calculate it in advance when using the constructor).

[0082] Next, we will explain the operational procedures. In the operation withdrawal operation, the operation team must withdraw revenue from the project and transfer it to collaborating companies and related partners after the NFTs are sold out and before the claim process begins. This process is essential for managing the project's cash flow and fulfilling the operation's financial responsibilities. This process is carried out as follows: A1: Cryptocurrency lending procedure (ver.1.0: $20,000) Confirmation of NFT Sold Out: The management team will confirm that all NFTs have been sold. Execute Withdraw: Withdraw revenue from the NFT contract. To do this, use the Withdraw function and specify the amount of DAI to withdraw and the destination address. Remittance: Withdraw the DAI and send it to the address of the partner company. The remittance destination should be an OkCoinJP address (please confirm in advance whether deposits are possible). B1: Japanese Yen Loan Procedure (ver.2.0: $1M) Confirmation of NFT Sold Out: The management team will confirm that all NFTs have been sold. Execute Withdraw: Withdraw revenue from the NFT contract. To do this, use the Withdraw function and specify the amount of DAI to withdraw and the destination address. Convert your funds to yen (for pattern B1): Convert your DAI to your desired currency, such as Japanese Yen (JPY). This may be necessary for international transactions or to meet certain financial requirements. Remittance: The converted funds are transferred to the partner company via bank transfer or other financial services.

[0083] Next, we will explain the management of the principal pool. The principal pool is the operation address of the operation, and stores refunds from collaborators and project operation funds. This pool is used for periodic operation and fund reallocation. The operation team also manages DAI transfers to the redemption pool to ensure that users receive the profits they can claim. This requires preparing and managing funds to respond to future claims. The principal pool is managed as follows: Setting up the principal pool: The operation team designates an operational address as the principal pool. Receive interest or principal: Receive interest and principal in DAI from your partner every month. Calculating the required DAI: Use the clalcRemainBalance function to calculate the amount of additional DAI you will need for the next month or so. Deposit and Withdraw: Deposit the amount of DAI you hold minus the value calculated by multiplying the number of DAI by 3 into an official DAI pool such as Summer.fi. If you do not have enough DAI, you can redeem the required amount from the pool. Execute the transfer: Transfer the amount of DAI calculated in step 3 from the principal pool to the TukTuk NFT contract redemption pool. After performing step 5 for the first time, activate the NFT contract so that it can be claimed. You can automate this process by setting up an operation bot to manage these operations for the principal pool.

[0084] One limitation is that the claim and withdrawal operations are not separated, so DAI must be withdrawn once during operation and replenished as needed. By making it impossible to claim without activation, we can avoid user confusion and enforce stricter operation. A whitelist will be created during minting and a whitelist function will be implemented.

[0085] Next, we will explain the risks and challenges. One of the challenges is the operational complexity of managing DAI separately, and the countermeasures include mitigating the risks through automation and clarifying the management process.

[0086] As a side note, we will explain the use of block.timestamp. In Solidity, block.timestamp refers to the timestamp of the block in which a smart contract is executed. In general, block timestamps can be manipulated by miners and may lack reliability, especially in terms of accuracy over short periods (e.g., within 15 seconds). However, for long-term operations such as claim processing and maturity calculations, this accuracy issue does not have a fatal impact. Therefore, calculating time using block.timestamp is an appropriate method in these contexts.

[0087] Next, we will explain the details of the second smart contract. First, this project aims to provide an environment where NFTs can be issued easily and quickly when launching a new series of lending contracts. This will enable lending projects to diversify and respond quickly to the market.

[0088] The main function is deploy, whose purpose is to create and issue a new NFT contract. The deploy function is used to generate a new NFT contract and perform initial configuration. Using this function makes it possible to quickly issue NFTs corresponding to specific lending contracts.

[0089] Next, we explain ClaimAll. ClaimAll is a wrapper function that simultaneously executes claimAll or redeemAll for multiple NFT contracts. The ClaimAll function executes claim operations for multiple NFT contracts at once. This allows users to efficiently collect profits from multiple NFTs. However, please note that the lengths of the nfts and tokenIds lists must be the same. This allows claims to be executed for specific token IDs for each NFT contract. To optimize gas costs, if there are consecutive identical NFT addresses, claim them all at once using claimAll. This can be achieved by properly organizing the list on the front end before calling the function. For expired NFTs, principal and profits can be collected by executing redeemAll. Technical requirements include the use of the Solidity programming language, and this project will be implemented as a smart contract on the Ethereum blockchain. A limitation is the need to create documentation on how to use the NFT Factory contract so that it can be handled by the business side. As for risks and challenges, the complexity of smart contracts poses the risk of bugs, so as a countermeasure, we will conduct rigorous testing and audits of contracts to ensure security. Also, rising gas fees may increase the costs of deploying and operating contracts, so as a countermeasure, we will strive to write gas-efficient code and optimize gas fees.

[0090] Hereinafter, both the trade order processing method and the trade order processing program of the embodiment will be described using the flowchart of Figure 3. Figure 3 is a flowchart showing the trade order processing method of the embodiment. The trade order processing method of the embodiment is executed by the computer of the trade order processing system 100 of the embodiment based on the trade order processing program (see Figure 3). The trade order processing program of the embodiment enables the computer of the trade order processing system 100 to realize an automatic lending / borrowing function, an automatic correction function, a TNF issuing function, a repayment receiving function, and a bonus issuing function. Each function overlaps with the description of the trade order processing system 100 of the embodiment described above, so details will be omitted.

[0091] As shown in FIG. 3, first, the first smart contract 110 automatically processes a lending transaction between the user 200 and the trading order processing system 100 (step S10). Next, the second smart contract 120 automatically corrects the automatic processing of the first smart contract 110 (step S20). Next, the first smart contract 110 issues an NFT to the user 200 (step S30). Next, when the leasing company 300 repays the trading order processing system 100, the first smart contract 110 stores the receipt of the repayment in the fund management database 1100 (step S40). Next, the trading order processing system 100 adds a bonus, stores it in the bonus database 1200, and issues the bonus to the user 200 (step S50).

[0092] In the automatic lending / borrowing function, the first smart contract 110 automatically processes lending / borrowing transactions between the user 200 and the trading order processing system 100 (automatic lending / borrowing step). In the automatic correction function, the second smart contract 120 automatically corrects the automatic processing of the first smart contract 110 (automatic correction step). In the NFT issuance function, the first smart contract 110 issues an NFT to the user 200 (NFT issuance step). In the repayment reception function, when the leasing company 300 repays the trading order processing system 100, the first smart contract 110 stores the fact that the repayment has been received in the funds management database 1100 held by the first smart contract 110 (repayment reception step). In the bonus issuance function, the trading order processing system 100 adds a bonus, stores it in the bonus database 1200, and issues the bonus to the user 200 (bonus issuance step).

[0093] According to each aspect of the present disclosure described above, NFT financing gathers support from around the world through RWA (real asset) NFTs based on real businesses, and makes it possible to earn interest and redemptions through legally clean crypto asset lending.

[0094] The trading order processing program of the embodiment can be implemented using, for example, scripting languages ​​such as ActionScript, JavaScript (registered trademark), Python, and Ruby, or compiler languages ​​such as C, C++, C#, Objective-C, Swift, and Java (registered trademark).

[0095] [Functions and circuits] Next, the functions and circuitry of the above-described trading order processing system 100 will be described. Each unit of the trade order processing system 100 may be realized as a function of a computer processing unit, etc. That is, the first smart contract 110 and the second smart contract 120 of the trade order processing system 100 may be realized as an automatic lending / borrowing function, an automatic correction function, a TNF issuing function, a repayment receiving function, and a bonus issuing function, respectively, by a computer processing unit, etc. The trade order processing program enables a computer to realize each of the above-described functions. The trade order processing program may be recorded on a computer-readable non-transitory storage medium, such as a memory, a solid state drive, a hard disk drive, or an optical disk. The storage medium may also be referred to as a non-transitory computer-readable medium that stores the communication program. The communication program may also be transmitted online. Furthermore, as described above, each unit of the trade order processing system 100 may be realized by a computer's arithmetic processing unit or the like. The arithmetic processing unit or the like is configured, for example, by an integrated circuit or the like. Therefore, each unit of the trade order processing system 100 may be realized as a circuit that constitutes the arithmetic processing unit or the like. In other words, the first smart contract 110 and the second smart contract 120 of the trade order processing system 100 may be realized as an automatic borrowing / lending circuit, an automatic correction circuit, a TNF issuing circuit, a repayment receiving circuit, and a bonus issuing circuit that constitute the arithmetic processing unit or the like of a computer. Furthermore, the first smart contract 110 and the second smart contract 120 of the trading order processing system 100 may be realized, for example, as an automatic borrowing / lending function, an automatic correction function, a TNF issuing function, a repayment receiving function, and a bonus issuing function, which include the functions of a processing device or the like. Furthermore, the first smart contract 110 and the second smart contract 120 of the trading order processing system 100 may be realized, for example, as an automatic borrowing / lending circuit, an automatic correction circuit, a TNF issuing circuit, a repayment receiving circuit, and a bonus issuing circuit, by being configured using an integrated circuit or the like. Furthermore, the first smart contract 110 and the second smart contract 120 of the trading order processing system 100 may be realized, for example, as an automatic borrowing / lending device, an automatic correction device, a TNF issuing device, a repayment receiving device, and a bonus issuing device, by being configured using multiple devices.

[0096] The trading order processing system 100 may be configured as one or any combination of the above-described multiple units.

[0097] [Aspects and Effects of the Present Embodiment] Next, one aspect of this embodiment and the effects of each aspect will be described. Note that each aspect described below is an example at the time of filing, and this embodiment is not limited to the aspects described below. In other words, this embodiment is not limited to the aspects described below, and may be realized by appropriately combining the above-mentioned parts. Furthermore, a lower-level aspect may be able to cite any of the higher-level aspects. The effects of the present embodiment described below are merely examples, and the effects of each aspect are not limited to those described below. Each aspect may, for example, achieve at least one of the effects described below.

[0098] (Aspect 1) One embodiment of the trading order processing system is a trading order processing system using crypto assets, constructed with a smart contract for lending crypto assets using TNF (non-fungible token), and is equipped with a first smart contract which is an automatic lending and borrowing program, and a second smart contract which is an automatic correction program that automatically performs contract deployment for the first smart contract.When a user who is a lender lends to the first smart contract, the first smart contract issues TNF to the user, receives repayment from the borrower company, adds a bonus, and returns it to the user. This will enable the trading order processing system to become an NFT finance system that attracts support from around the world through RWA (real asset) NFTs based on real businesses, and to earn interest and redemptions through legally clean cryptocurrency lending.

[0099] (Aspect 2) In one embodiment of the trading order processing system, the first smart contract may include a funds management database and a bonus database. This allows users to easily obtain interest and redemption from anywhere with intuitive operations.

[0100] (Aspect 3) In one embodiment of the trading order processing system, users may be able to view support destination data through token-gated access. To grant NFT owners access to exclusive information provided by borrowers, address owners who own NFTs can access exclusive information provided by borrowers on their account page. They can determine whether or not they have an NFT on their account page, and if they own it, they can view specific vehicle IoT data, newsletters from the borrower, driver interviews, and more. This allows users to easily earn interest and redeem their NFTs without the need for identity verification.

[0101] (Aspect 4) In one embodiment of the trading order processing system, a user may sell the cryptocurrency to an external marketplace, including to famous artists. NFTs allow image data to be tokenized, effectively connecting socially significant projects with well-known artists and creating investment opportunities that have a direct impact on the real world and can be enjoyed as art, not just in traditional financial terms. As a result, the trading order processing system is an NFT finance system that gathers support from around the world through RWA (real asset) NFTs based on real businesses, and makes it possible to earn interest and redemptions through legally clean crypto asset lending.

[0102] (Aspect 5) In one embodiment of the trading order processing system, the item leased to the end user by the company that borrowed the cryptocurrency lent by the user may be a vehicle. This will promote use in ASEAN countries such as Cambodia, which has a large vehicle leasing / rental market.

[0103] (Aspect 6) The trading order processing method is a trading order processing method using crypto assets, constructed with a smart contract for lending (loaning) crypto assets using TNF (non-fungible token), and includes an automatic lending and borrowing step of performing automatic lending and borrowing using a first smart contract, and an automatic correction step of automatically performing contract deployment to the first smart contract using a second smart contract, and may also include a TNF issuance step of issuing TNF to the user when the user lends to the first smart contract, a repayment receipt step of receiving repayment from the borrower company, and a bonus issuance step of adding a bonus and returning it to the user in accordance with the receipt of repayment in the repayment receipt step. This will enable the trading order processing system to become an NFT finance system that attracts support from around the world through RWA (real asset) NFTs based on real businesses, and to earn interest and redemptions through legally clean cryptocurrency lending.

[0104] (Aspect 7) The trading order processing program is a trading order processing program using crypto assets, constructed with a smart contract for lending (loaning) crypto assets using TNF (non-fungible token), and is provided in a computer with an automatic lending and borrowing function that performs automatic lending and borrowing using a first smart contract, and an automatic correction function that automatically performs contract deployment to the first smart contract using a second smart contract, and when a user lends to the first smart contract, it executes a TNF issuing function that issues TNF to the user, a repayment receiving function that receives repayment from the borrowing company, and a bonus issuing function that adds a bonus and returns it to the user in accordance with the repayment received by the repayment receiving function. This will enable the trading order processing system to become an NFT finance system that attracts support from around the world through RWA (real asset) NFTs based on real businesses, and to earn interest and redemptions through legally clean cryptocurrency lending. [Explanation of symbols]

[0105] 100 Trading Order Processing System 110 First Smart Contract 120 Second Smart Contract 200 users 300 Leasing companies 400 End User 500 External Marketplaces 1100 Fund Management Database 1200 Bonus Database 1300 Supporter Database

Claims

1. A cryptocurrency trading order processing system that is constructed with a smart contract for lending cryptocurrency using TNF (non-fungible token), The first smart contract is an automatic lending and borrowing program; A second smart contract is an auto-correction program that automatically performs contract deployment on the first smart contract; Equipped with When a user who is a lender lends to the first smart contract, the first smart contract issues the TNF to the user, receives repayment from the borrower company, adds a bonus, and returns it to the user. characterized in that A trading order processing system using crypto assets.

2. The trading order processing system using crypto assets as described in claim 1, characterized in that the first smart contract has a fund management database and a bonus database.

3. The trading order processing system using crypto assets as described in claim 1, characterized in that the user can view the support destination data through token-gated access.

4. The cryptocurrency trading order processing system of claim 1 , wherein the user sells the cryptocurrency to an external marketplace including a famous artist.

5. A trading order processing system using crypto assets as described in claim 1, characterized in that the item leased to the end user by the company from which the user borrowed the crypto asset lent is a vehicle.

6. A method for processing trade orders using crypto assets, which is constructed with a smart contract for lending crypto assets using TNF (non-fungible token), an automatic lending and borrowing step of performing automatic lending and borrowing using a first smart contract; an automatic correction step of automatically performing contract deployment on the first smart contract using a second smart contract; Equipped with a TNF issuing step of issuing the TNF to the user when the user lends to the first smart contract; a repayment receiving step of receiving repayment from the borrower company; a bonus issuing step of adding a bonus in response to receiving the repayment in the repayment receiving step and returning the bonus to the user; Including, characterized in that A method for processing trading orders using crypto assets.

7. A cryptocurrency transaction order processing program that is constructed with a smart contract for lending cryptocurrency using TNF (non-fungible token), On the computer, an automatic lending and borrowing function that performs automatic lending and borrowing using a first smart contract; an automatic correction function that automatically performs contract deployment for the first smart contract using a second smart contract; Equipped with A TNF issuing function that issues the TNF to the user when the user lends to the first smart contract; A repayment receiving function for receiving repayments from borrower companies; a bonus issuing function that adds a bonus in response to receiving the repayment by the repayment receiving function and returns the bonus to the user; A trading order processing program that executes

Images