Token money transfer control method and device based on block chain, equipment and medium

Abstract

The invention discloses a token money transfer control method and device based on a block chain, equipment and a medium, and the method comprises the steps: obtaining sender identification information, receiver identification information and transfer amount information carried in a token money transfer request through calling the token money transfer request initiated by a token money contract; reading a sender state and a receiver state from a pre-stored state mapping hook Data; calling back the Hook contract according to an independent verification logic Hook contract address stored in the token contract, verifying the sender state and the receiver state based on the Hook contract, and receiving a verification result returned by the Hook contract; finally, if the verification result is that the verification is passed, token money transfer operation is executed according to the sender identification information, the receiver identification information and the transfer amount information; and if the verification result is that the verification is not passed, rolling back the transaction. And the accuracy of token transfer control is improved.

Description

Technical Field

[0001] This application relates to the field of blockchain and financial technology, and in particular to a blockchain-based token transfer control method, device, equipment and medium. Background Technology

[0002] In related technologies, investor suitability management in finance typically involves investors filling out questionnaires in a risk assessment system, calculating their risk level and storing it in a database, setting the risk level of products and storing it in the database, and then querying the database when placing an order in the trading system. If a match is found, the transaction is allowed; otherwise, it is rejected. However, this technology's database can be tampered with by administrators and cannot be verified on a blockchain, resulting in significant management limitations.

[0003] To address the aforementioned issues, related technologies have further proposed a token transfer control scheme based on the ERC-1404 (SimpleRestricted Token Standard) blockchain contract. This scheme includes: an investor initiating a transfer request; the token contract calling the restriction logic; restriction checks and code return; and branch processing results. If the code is 0 (success), the token contract executes the transfer operation and returns true to the investor confirming success; if the code is not 0 (failure), the token contract terminates the transfer. However, this scheme hardcodes the verification logic within the token contract, resulting in strong coupling between the transfer verification logic and the token contract. This leads to situations where changes to verification rules require redeploying the entire token contract, issued tokens cannot upgrade the verification logic, multiple tokens sharing the verification logic require repeated deployment, and the lifecycle of the verification contract is tied to the token contract, lacking flexibility. Summary of the Invention

[0004] This application provides a blockchain-based token transfer control method, apparatus, device, and medium to solve the problem that the strong coupling between the transfer verification logic and the token contract in related technologies leads to poor flexibility in token transfer control.

[0005] Firstly, this application provides a blockchain-based token transfer control method, the method comprising: Receive a token transfer request initiated by calling the token contract, and obtain the sender identification information, receiver identification information and transfer amount information carried in the token transfer request; Based on the sender identification information and the receiver identification information, the sender status and receiver status are read from the pre-stored state mapping hookData; Based on the independent verification logic Hook contract address stored in the token contract, the Hook contract is called back, the sender status and receiver status are verified based on the Hook contract, and the verification result returned by the Hook contract is received. If the verification result is successful, the token transfer operation is executed based on the sender's identifier, receiver's identifier, and transfer amount; if the verification result is unsuccessful, the transaction is rolled back.

[0006] The above technical solution has the following advantages or beneficial effects: This application addresses a series of technical problems caused by the strong coupling between transfer verification logic and token contracts in related technologies, and proposes a token transfer control scheme that decouples the transfer verification logic from the token contract. This application obtains the sender's identifier, receiver's identifier, and transfer amount information carried in the token transfer request by invoking the token contract; it reads the sender's and receiver's states from the pre-stored state mapping hookData; then, based on the independent verification logic hook contract address stored in the token contract, it calls back the hook contract, verifies the sender's and receiver's states based on the hook contract, and receives the verification result returned by the hook contract. In this application, the token contract is only responsible for asset management and has zero business verification logic; the hook contract focuses on verification logic and can be developed and tested independently. This achieves decoupling between the token contract and the hook contract. Finally, if the verification result is successful, the token transfer operation is executed based on the sender's identifier, receiver's identifier, and transfer amount information; if the verification result is unsuccessful, the transaction is rolled back. This achieves a token transfer control scheme based on decoupled token contracts and hook contracts. It improves the accuracy of token transfer control.

[0007] Secondly, this application provides a blockchain-based token transfer control device, the device comprising: The receiving module is used to receive token transfer requests initiated by calling the token contract, and to obtain the sender identification information, receiver identification information and transfer amount information carried in the token transfer request; The reading module is used to read the sender status and receiver status from the pre-stored state mapping hookData based on the sender identification information and the receiver identification information. The verification module is used to call back the Hook contract based on the independent verification logic Hook contract address stored in the token contract, verify the sender status and receiver status based on the Hook contract, and receive the verification result returned by the Hook contract. The transfer control module is used to execute a token transfer operation based on the sender identifier, receiver identifier, and transfer amount information if the verification result is successful; and to roll back the transaction if the verification result is unsuccessful.

[0008] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, used to execute a program stored in memory, implements the method described.

[0009] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described herein.

[0010] Fifthly, this application provides a computer program product comprising an executable program that is executed by a processor to implement the method described. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the workflow of Solution A in the related technology; Figure 2 This is a schematic diagram of the on-chain KYC system architecture in RWA tokenization within related technical solution B; Figure 3 Here is a flowchart illustrating the token transfer control process for related technical solution C; Figure 4 A schematic diagram of the blockchain-based token transfer control process provided for this application; Figure 5 The token contract and verification contract separation architecture diagram provided for this application; Figure 6 A schematic diagram illustrating the process of pre-storing state mapping hookData provided in this application; Figure 7 This is a schematic diagram of the bitmap encoding structure provided in this application; Figure 8 A flowchart illustrating the process for retrieving the freeze flag and membership validity period provided for this application; Figure 9 The diagram illustrating the transfer transaction process provided for this application; Figure 10 A schematic diagram of the blockchain-based token transfer control device provided for this application; Figure 11A schematic diagram of the electronic device structure provided in this application. Detailed Implementation

[0013] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0014] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0015] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0016] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0017] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0018] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0019] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

[0020] First, the token transfer control scheme of the relevant technology will be explained.

[0021] Option A: ERC-1404 Simple Restricted Token Standard.

[0022] Technical Principle: ERC-1404 is an Ethereum token standard proposed in 2018, which adds a transaction restriction interface to the ERC-20 standard. This standard defines two core functions: 1. Transfer restriction detection function (detectTransferRestriction): Input parameters: Sender's address, recipient's address, transfer amount; Return value: Limit code (uint8 type); Code meaning: 0 indicates that the transfer is allowed, and non-zero indicates that it is rejected (different codes correspond to different reasons for rejection).

[0023] 2. Restrict message retrieval function (messageForTransferRestriction): Input parameter: Restriction code; Return value: The corresponding error message string; Purpose: To convert numeric codes into human-readable error messages.

[0024] Figure 1 This is a flowchart illustrating the workflow of Solution A in the related technology, including: 1. Investor initiates transfer: The investor calls the transfer(to, amount) function of the ERC1404 token contract to transfer a certain amount of tokens to the target address (to). 2. Detect transfer restrictions: The ERC1404 token contract calls the detectTransferRestriction(from, to, amount) function of the restriction logic contract, where from is the address of the transfer initiator, to is the target address, and amount is the amount of transfer. This function is used to check whether the transfer is subject to restrictions. 3. Obtain the restriction code: After the restriction logic contract executes the check, it returns a restriction code. If the code is 0, it means that the transfer is unrestricted; if the code is a non-zero value, it means that the transfer is restricted, and this non-zero value is usually an error code. 4. Determine the restriction code: The ERC1404 token contract determines the appropriate action based on the received restriction code: If the code is 0: The ERC1404 token contract executes a transfer operation, transferring a specified number of tokens from the from address to the to address; after the transfer is successful, a success message is returned to the investor; If the code is non-zero: the ERC1404 token contract refuses to execute the transfer operation and displays an error message to the investor explaining why the transfer was rejected (usually related to the returned error code).

[0025] The technical defects of related technical solution A are: 1. No KYC verification: The standard itself does not include an identity authentication mechanism; 2. No distinction between public and private funds: It is impossible to set different admission rules based on product type; 3. Static constraint logic: The constraint rules are fixed in the contract and are difficult to adjust dynamically; 4. No whitelist management: There is no standard implementation of investor whitelists.

[0026] Option B: On-chain KYC system in RWA tokenization.

[0027] Technical principle: Some RWA projects (such as Centrifuge and Polymath) use on-chain KYC credentials, which mainly consist of two contracts: 1. KYC Registry Contract: Function: Stores the KYC verification status of all investors; Data structure: A mapping table (address → bool) is used to record the authentication status of each address; Status type: isKYCVerified: Whether the basic KYC verification has been passed; isAccredited: Whether the investor is an accredited investor; Update mechanism: Authorized verifiers call functions to mark investors as verified; 2. Restricted Token Contract: Function: Check KYC status before transferring funds; Verification logic: Query the KYC registry in the callback function before the transfer; Verification rules: The recipient must pass KYC verification; otherwise, the transfer will be rejected. Error message: If the recipient is not authenticated, the error "Recipient not KYC verified" will be returned.

[0028] Figure 2This is a schematic diagram of the on-chain KYC system architecture in RWA tokenization within related technical solution B. Figure 2 The architecture shown is explained below: Third-party KYC service providers: provide identity verification API interfaces; Verifier: An authorized verification node responsible for writing KYC results into the blockchain; KYC Registry Smart Contract: Stores the KYC status (verified / unverified) of all investors; Token contract: During a transfer, the KYC registration form is queried to verify the identities of both parties; Investor Wallet: The user terminal for initiating transfer operations.

[0029] The technical defects of related technical solution B are: 1. No product-level isolation: All products share the same KYC registry; 2. No public / private fund tiers: Only a simple "verified / unverified" binary status; 3. High on-chain gas consumption: Each KYC update requires an on-chain transaction; 4. Insufficient privacy protection: KYC status is completely open and transparent; 5. Confusing whitelist with KYC: There is no clear distinction between basic certification and product authorization.

[0030] Option C: Traditional financial investor suitability management.

[0031] Traditional securities firms and fund companies follow this process: investor account opening, risk assessment, suitability matching, and product access. Their databases store investor information (t_investors), risk profiles (t_risk_profiles), product suitability tables (t_product_suitability), and whitelists (t_whitelist, manually maintained).

[0032] When placing a transaction order: SELECT FROM t_whitelist.

[0033] Figure 3 Here is a flowchart of the token transfer control process for related technical solution C, such as... Figure 3 As shown, investors fill out a questionnaire in the risk assessment system, calculate their risk level and store it in the database, set the risk level of the product and store it in the database. When the trading system places an order, it queries the database. If a match is found, the transaction is allowed; otherwise, the transaction is rejected.

[0034] The technical defects of related technical solution C are: 1. Centralization risk: The database can be tampered with by the administrator; 2. Unable to verify on-chain: Blockchain transactions cannot access off-chain databases; 3. Poor real-time performance: The whitelist can only be updated on T+1 day; 4. No interoperability between institutions: Each institution maintains its own system and data cannot be shared.

[0035] The above three related technical solutions have the following core technical defects:

[0036] Technical Issue 1: The transfer verification logic is tightly coupled with the token contract.

[0037] Problem Description: Existing restricted token standards such as ERC-1404 hardcode the verification logic within the token contract, resulting in: changes to verification rules requiring redeployment of the entire token contract; issued tokens being unable to upgrade the verification logic; repeated deployments required when multiple tokens share the verification logic; and the lifecycle of the verification contract being tied to the token contract, lacking flexibility.

[0038] Technical root cause: Lack of decoupling mechanism between verification logic and token storage, violating the single responsibility principle.

[0039] Technical Issue 2: Low utilization of user state storage space.

[0040] Problem Description: Existing solutions (such as on-chain KYC registry) allocate storage space separately for each user status field: Membership validity period: 1 storage slot (256 bits); Frozen status: 1 storage slot (256 bits); Other extended fields: each occupying 1 slot; Each status read requires multiple SLOAD operations (21,000 Gas each time), resulting in high computational resource consumption.

[0041] Technical root cause: The failure to adopt compact storage technologies such as bitmap encoding leads to wasted storage space and high read overhead.

[0042] Technical Issue 3: High Gas Consumption for Transfer Verification.

[0043] Problem Description: Traditional solutions require the following steps during transfer verification: calling an external KYC registry contract (cross-contract call overhead ~3000 Gas); reading multiple storage slots (2100 Gas per slot); executing complex conditional judgment logic; gas consumption for a single transfer verification exceeds 150,000; for high-frequency trading scenarios (such as secondary market transfers), gas consumption becomes a bottleneck for system performance.

[0044] Technical root cause: lack of dedicated data structures and access mode optimizations for transfer verification scenarios.

[0045] Technical problem 4: Difficulty in guaranteeing the atomicity of state updates.

[0046] Problem Description: When multiple user states need to be updated simultaneously (such as membership renewal + unfreezing): traditional solutions require multiple independent transactions, which poses a risk of inconsistency in intermediate states; batch updates lack atomicity guarantee mechanisms; and it is difficult to roll back when some updates fail.

[0047] Technical root cause: State data is stored in a scattered manner, lacking a compact data structure that supports atomic updates.

[0048] To address the aforementioned technical issues, this application proposes a blockchain-based token transfer control method, specifically a method and system for implementing differentiated investor access control for public and private offerings on a blockchain. This falls within the intersection of blockchain technology and FinTech. This application is particularly applicable to the issuance and trading of regulated digital assets such as security tokens and tokenized funds, automating compliance requirements such as KYC / AML, qualified investor authentication, product-level whitelist management, and transfer restrictions through smart contracts.

[0049] This application is a pre-access control system for compliant transactions of real-world asset (RWA) products. Based on basic KYC, it determines which investors can purchase public offering products; based on QI certification and whitelisting, it determines which investors can purchase private offering products; which addresses can receive and transfer tokenized shares; and it prevents all non-compliant transactions from occurring; thus providing an executable solution for the implementation of regulated digital assets.

[0050] Table a defines the abbreviations and key terms used in this application:

[0051] Public Offerings: Financial products offered to the general public with low entry barriers; only basic KYC verification is required to invest. Examples include mutual funds and exchange-traded funds (ETFs).

[0052] Private placement products: Financial products offered privately to specific qualified investors. They have high entry barriers, require QI certification, and must be included in a whitelist. Examples include private equity funds and hedge funds.

[0053] Qualified Investor (QI): A professional investor who meets the asset size, investment experience, and other requirements stipulated by regulatory authorities. For example: Individuals: Financial assets ≥ 3 million yuan or average annual income ≥ 500,000 yuan over the past 3 years; Institutions: Net assets ≥ 10 million yuan.

[0054] Whitelist: A list of investor addresses authorized by the issuer for a specific product. Only addresses on the whitelist can invest in that product.

[0055] Transfer Restriction: A compliance check on token transfer operations at the smart contract level; transfers that do not meet the requirements will be blocked.

[0056] On-Chain & Off-Chain Coordination: KYC data is stored in an off-chain database, and the verification results (membership) are updated to the on-chain smart contract through an event synchronization mechanism.

[0057] Hook mechanism (Hook Callback): When tokens are transferred, the contract will call back the external verification logic (Hook contract) and decide whether to allow the transfer based on the verification result.

[0058] Endorsed Address: A platform-level trusted address (such as a custodian contract or exchange) that can be exempted from transfer restriction checks.

[0059] Freeze Flag: An account status bit stored on the blockchain that indicates whether the address is frozen (tokens cannot be transferred out after being frozen).

[0060] Gas / Gas Cost: A unit of measurement for the computational resources required to execute smart contract operations on the Ethereum network. Users pay Gas fees to incentivize miners / validators to package transactions. This application significantly reduces average Gas consumption per user through batch processing, improving economic viability.

[0061] Blockchain contract terminology: ERC-20 (Ethereum Request for Comments 20): Chinese Name: Ethereum Draft for Comments (Draft 20); Technical Positioning: Standard interface for fungible tokens. Core Functionality: It defines a set of common functions and events that smart contracts must implement, enabling tokens issued by different projects to be uniformly identified and processed in applications such as wallets and exchanges. Application Scenarios: The vast majority of fungible tokens (such as USDT, DAI, and various project tokens) are based on the ERC-20 standard. It is the foundation for your "share tokens".

[0062] ERC-721 (Ethereum Request for Comments 721): Chinese Name: Ethereum Draft for Comments 721; Technical Positioning: Standard interface for Non-Fungible Tokens (NFTs). Core Functionality: Unlike ERC-20, each token defined by ERC-721 is unique, indivisible, and non-fungible. It identifies each token through a globally unique tokenId. Application Scenarios: Digital art, collectibles, game items, virtual real estate, membership certificates, etc.

[0063] ERC-1404 (Simple Restricted Token Standard): Chinese Name: Simple Restricted Token Standard; Technical Positioning: A standard for issuing regulated security tokens, extending upon ERC-20. Core Functionality: It adds transfer restriction functionality to ERC-20. Before any transfer operation is executed, a `detectTransferRestriction` function is called to perform a check.

[0064] ERC-7540 (Asynchronous ERC-4626 Tokenized Vaults): Chinese Name: Asynchronous ERC-4626 Tokenized Asset Vault; Technical Positioning: A relatively new standard for building tokenized asset vaults, with a particular emphasis on "asynchronous" operation. Core Functionality: It is based on the ERC-4626 standard but introduces a "request-processing" model. Investors' deposit and redemption requests are not executed immediately, but rather are first "requested" and then "processed" later by the administrator (or automated strategy). This is ideal for financial products that require T+1 settlement, manual review, or batch processing.

[0065] NFT (Non-Fungible Token): Chinese Name: Non-Fungible Token (NFT); Technical Positioning: A type of crypto token representing unique ownership of digital assets. Core Characteristics: Indivisibility: Unlike Bitcoin or ERC-20 tokens, it cannot be divided into smaller units. Uniqueness and Scarcity: Each NFT has a unique identifier and attributes; its scarcity is determined by the issuance rules. Verifiable Ownership: Ownership is recorded on the blockchain, making it public, transparent, and immutable. Technical Implementation: The most commonly used technical standard is ERC-721, etc. Application Scenarios: Digital art, music, land and items in virtual worlds, rare equipment in games, identity credentials, on-chain representation of Real-World Assets (RWA), etc.

[0066] Figure 4 The diagram illustrating the blockchain-based token transfer control process provided in this application includes the following steps: S101: Receive a token transfer request initiated by calling the token contract, and obtain the sender identification information, receiver identification information and transfer amount information carried in the token transfer request; S102: Based on the sender identification information and the receiver identification information, read the sender status and receiver status from the pre-stored state mapping hookData; S103: Based on the independent verification logic Hook contract address stored in the token contract, call back the Hook contract, verify the sender status and receiver status based on the Hook contract, and receive the verification result returned by the Hook contract; S104: If the verification result is successful, execute the token transfer operation based on the sender identifier information, receiver identifier information and transfer amount information; if the verification result is unsuccessful, roll back the transaction.

[0067] The blockchain-based token transfer control method provided in this application is applied to electronic devices, such as computers, smart terminals, and servers.

[0068] This application addresses the problems arising from the tight coupling between transfer verification logic and the token contract, such as the need to redeploy the entire token contract when verification rules are changed, the inability to upgrade verification logic for already issued tokens, the need for repeated deployment when multiple tokens share verification logic, and the lack of flexibility due to the lifecycle binding of the verification contract and the token contract. It provides a verification logic decoupling architecture based on Hook callbacks, solving these problems by externalizing the verification logic.

[0069] This application separates the token contract and the Hook contract (verification contract), using a callback interface to achieve loose coupling. The token contract is responsible for asset management and stores a compact bitmap-encoded data structure of hookData to store multiple user state fields. The Hook contract is responsible for verification logic and can be upgraded independently.

[0070] Based on the respective functions of the token contract and the Hook contract, in this application, the user first initiates a token transfer request by calling the token contract. After receiving the token transfer request, the electronic device obtains the sender's identifier, receiver's identifier, and transfer amount information carried in the request. Then, based on the sender's identifier and receiver's identifier, it reads the sender's status and receiver's status from the pre-stored state mapping hookData. The sender's status and receiver's status include whether the account is frozen, membership expiration time, etc.

[0071] An independent verification logic hook contract address is pre-stored in the token contract. When verification of the sender's and receiver's states is required, the hook contract is called back based on this address, and the sender's and receiver's states are verified using the hook contract. After verification, the hook contract outputs the verification result, which can be either successful or unsuccessful. If the verification is successful, a token transfer operation is executed based on the sender's identifier, receiver's identifier, and transfer amount. If the verification fails, the transaction is rolled back.

[0072] Figure 5 The token contract and verification contract separation architecture diagram provided for this application is as follows: Figure 5 As shown, the architecture consists of a token contract, a Hook contract, and a callback interface (IHook).

[0073] The token contract is responsible for managing token balances and executing transfer operations; it stores: user balance mapping, hookData state mapping, and hook contract address; it does not participate in business verification logic.

[0074] The Hook contract (Verification Contract) is responsible for performing pre-transfer verification and state updates; storage: stateless (all states are stored in the token contract); logic upgrades are achieved by updating the Hook address.

[0075] The status update here includes the following: 1. updateMember (Update Member Status).

[0076] Update the member expiration timestamp (high 64 bits) in hookData: Triggering scenarios: After a user completes KYC verification; or when renewing membership; or after passing Qualified Investor (QI) verification.

[0077] Update details: The high 64 bits of hookData = new expiration timestamp (current time + expiration date).

[0078] For example: Original value: 0x00000000000000000000000000000000 (Not set); Update: 0x000000006772a00000000000000000000 (Expiration date = 2026-01-01).

[0079] The operation is as follows: 1. The event synchronization service retrieves user KYC authentication information from the off-chain database; 2. Calculate the validity period: current time + 1 year; 3. Call updateMember(token, userAddress, expirationTime); 4. The Hook contract encodes the timestamp into the high 64 bits of hookData; 5. Write the hookData mapping to the token contract.

[0080] 2. Freeze / Unfreeze (Freeze Management).

[0081] Update the freeze flag (bit 0) in hookData: Triggering scenarios: Regulatory requirements to freeze suspicious accounts; or the risk control system detects abnormal behavior; or the account is unfrozen and restored to normal.

[0082] Update: The 0th bit of hookData is set to the freeze flag (0 or 1).

[0083] Freeze operation: Original value: 0x000000006772a000000000000000000000 (normal); Update: 0x000000006772a00000000000000000001 (Frozen).

[0084] Thawing procedure: Original value: 0x000000006772a00000000000000000001 (frozen); Update: 0x000000006772a000000000000000000000 (Normal).

[0085] The operation is as follows: 1. The administrator calls freeze(token, userAddress); 2. The Hook contract reads the current hookData; 3. Use bitwise operations to set bit 0 to 1: hookData | 0x1; 4. Write back the hookData mapping of the token contract.

[0086] The callback interface (IHook) includes: the pre-transfer verification view function checkERC20Transfer and the post-transfer notification status function onERC20Transfer.

[0087] Combination Figure 5 The token transfer control process is explained as follows: Step 1: Set the Hook contract address during token contract initialization. This step involves the following input parameters: Hook contract address (hookAddress); verification: hookAddress is a non-zero address; storage: save hookAddress to the token contract's hook storage variable.

[0088] In this application, before receiving a token transfer request initiated by calling a token contract, the method further includes: Obtain the address of the independent verification logic Hook contract. If the address of the independent verification logic Hook contract is a non-zero address, store the address of the independent verification logic Hook contract in the Hook storage variable of the token contract.

[0089] To verify that the contract address is not a zero address, you can follow these steps: Access the blockchain platform: Using Etherscan, OpenZeppelin, or other platforms that support smart contracts, enter the target contract address to view it. Check contract information: Review the basic information of the contract to confirm whether it has been created or has recent transaction records. Confirm that the contract address has a valid token balance, especially if it is in a test environment, ensuring that the tokens have been correctly allocated. View transaction records: Browse the contract's historical transaction records to confirm whether there are active transactions, indicating that the contract may be widely used or enabled. Check for security vulnerabilities: Refer to relevant security announcements or vulnerability reports to confirm whether the contract address has any known security issues affecting its usability. Access permissions: Confirm whether the contract address requires specific permissions or private keys to access, ensuring that permission settings are correct. View recent upgrades: Confirm that the contract address points to the latest version or the correct development version, avoiding the use of older versions. Community and developer support: Check whether there is active developer support or community discussions to confirm the maintenance status and stability of the contract. Token deposit / withdrawal records: Confirm that the relevant tokens have been correctly deposited or withdrawn, ensuring that the contract is operating normally. Compliance check: Confirm that the contract address complies with the platform's usage restrictions and transaction permission requirements.

[0090] By following the steps above, you can verify whether the Hook contract address is a non-zero address and ensure its availability and security.

[0091] Step 2: The user initiates a transfer operation. This step involves the user calling the token contract's transfer(to, amount) function; the token contract checks if the sender has sufficient funds; if the funds are sufficient, the verification process begins.

[0092] Step 3: The token contract reads the state data of both parties. This step involves reading the sender's 128-bit state from the hookData mapping: fromHookData = hookDataOf[from]; reading the receiver's 128-bit state from the hookData mapping: toHookData = hookDataOf[to]; and packaging it into a HookData structure: HookData{from:fromHookData, to: toHookData}.

[0093] Step 4: Callback to the Hook contract to perform verification. This step involves calling the Hook contract's checkERC20Transfer(from, to, amount, hookData) function; the Hook contract executes the verification logic; and returns a boolean value: true indicates permission, false indicates rejection.

[0094] Step 5: Execute the transfer based on the verification result. This step involves: if the return value is false: immediately roll back the transaction and throw a "Transfer restricted" error; if the return value is true: perform a standard ERC20 transfer operation.

[0095] Performing standard ERC20 transfer operations includes: The sender's balance decreases: balanceOf[from] -= amount; The recipient's balance increases: balanceOf[to] += amount; Trigger the Transfer event.

[0096] Step 6: Post-transfer callback notification. This step involves calling the `onERC20Transfer(from, to, amount, hookData)` function of the Hook contract; used for updating the investor list and other subsequent processing; and returning a function selector to confirm success.

[0097] The details of onERC20Transfer updating the investor list: Add address: Addresses that hold tokens for the first time are added to the list; Remove address: The address to be cleared and exited is removed from the list.

[0098] Further processing includes: Trigger a Transfer event and record it in the blockchain log; update holding statistics and the distribution of large and small investors; trigger business events for off-chain system monitoring; record audit logs for compliance traceability; issue alerts for large transfers and trigger the review process.

[0099] The core purpose is to maintain an accurate list of investors for use in scenarios such as dividends, voting, and regulatory reporting.

[0100] Step 7: Hook Contract Upgrade Process. This step involves authorizing the administrator to call the token contract's setHook(newHookAddress) function; verifying the caller's permissions; updating the hook storage variable to the new address; triggering the HookUpdated event record change; and all subsequent transfers automatically using the new Hook contract.

[0101] This application addresses a series of technical problems caused by the strong coupling between transfer verification logic and token contracts in related technologies, and proposes a token transfer control scheme that decouples the transfer verification logic from the token contract. This application obtains the sender's identifier, receiver's identifier, and transfer amount information carried in the token transfer request by invoking the token contract; it reads the sender's and receiver's states from the pre-stored state mapping hookData; then, based on the independent verification logic hook contract address stored in the token contract, it calls back the hook contract, verifies the sender's and receiver's states based on the hook contract, and receives the verification result returned by the hook contract. In this application, the token contract is only responsible for asset management and has zero business verification logic; the hook contract focuses on verification logic and can be developed and tested independently. This achieves decoupling between the token contract and the hook contract. Finally, if the verification result is successful, the token transfer operation is executed based on the sender's identifier, receiver's identifier, and transfer amount information; if the verification result is unsuccessful, the transaction is rolled back. This achieves a token transfer control scheme based on decoupled token contracts and hook contracts. It improves the accuracy of token transfer control.

[0102] It should be noted that if the Hook contract has a bug or is maliciously upgraded, it may cause all transfers to fail and the tokens to be locked. The solutions are: Emergency Stop Mechanism: The token contract provides a removeHook function, allowing authorized administrators to remove the Hook address and restore unrestricted transfers; Hook Whitelist: Only audited Hook contracts are allowed to be deployed; Time Lock Upgrade: Hook address changes require a 24-48 hour time lock to allow the community time to react; Multi-Signature Governance: Hook upgrades require signature confirmation from multiple authorized parties.

[0103] The blockchain-based token transfer control method provided in this application has decoupling, upgradeability, reusability, and high gas efficiency.

[0104] Decoupling: The token contract is only responsible for asset management and has no business logic; the Hook contract focuses on verification logic and can be developed and tested independently; the two communicate through a standard interface and do not depend on each other's implementation details.

[0105] Upgradeability: Verification rule change: Deploy a new Hook contract and update the address; No migration required: Token balance and state data do not need to be migrated; Hot upgrade: Tokens remain available during the upgrade process (only one transaction is needed to update the Hook address).

[0106] Reusability:

[0107] A single Hook contract can serve multiple token contracts; Different products can use different hooks to implement differentiated rules; Reduce deployment complexity and contract maintenance workload.

[0108] High Gas Efficiency: Callback overhead is controllable: Cross-contract calls consume a fixed amount of ~3000 Gas; Compared to embedded logic, there is no additional overhead (due to compiler inlining optimization); View function calls have no state changes, resulting in lower resource consumption.

[0109] To decouple the verification logic without increasing gas consumption, this application implements a method where the token contract reads the hookData from both parties before the transfer (only two SLOAD operations), and passes the hookData as a parameter to the hook contract (eliminating the need for the hook contract to read it repeatedly). The hook contract then executes the view function for verification (no state changes, low resource consumption). The total additional consumption is approximately 3000 Gas, but this comes at the cost of complete decoupling and scalability. The extra 3000 Gas consumption for scalable verification logic demonstrates practical value.

[0110] The comparison between the Hook callback scheme of this application and the related technology ERC-1404 embedded verification is shown in Table 1 below: Table 1 Comparison Table

[0111] The solution provided in this application can be applied to product-level business rule mapping scenarios. The architecture provided in this application supports flexible business rule implementation, taking the tiered access control of public and private equity products as an example:

[0112] Business rule configuration: The product contract stores the Raising Method field: Public Offering / Private Offering; The product contract stores the Investor Requirements field (InvestorType): Retail / Qualified / Professional; The Hook contract implements differential validation logic based on these fields.

[0113] Table 2 Example of Admission Rule Mapping

[0114] This business logic is implemented based on Figure 5 The Hook architecture demonstrates the technical solution's ability to support business needs.

[0115] Preferably, verifying the sender's and receiver's states based on the Hook contract includes: If the current scenario is a public offering product investment scenario, the Hook contract is used to verify the freeze status and membership expiration time status of the sender, and to verify the freeze status and membership expiration time status of the receiver. If the current scenario is a private equity investment, the Hook contract is used to verify the sender's freeze status, member expiration time status, and whitelist status corresponding to the private equity product, and to verify the receiver's freeze status and member expiration time status.

[0116] It should be noted that if the current scenario is a public offering product investment scenario, the verification will pass if the sender's freeze status is normal and the sender's membership expiration time is after the current time, the receiver's freeze status is normal and the receiver's membership expiration time is after the current time; otherwise, the verification will fail.

[0117] If the current scenario is a private equity investment, the verification will pass if the sender's freeze status is normal, the sender's membership expiration time is after the current time, the private equity product token address and investor address are both in the corresponding whitelist, the receiver's freeze status is normal, and the receiver's membership expiration time is after the current time; otherwise, the verification will fail.

[0118] To further improve the completeness and comprehensiveness of the verification, the method also includes: Based on the Hook contract query platform Platform contract, the endorsement addresses of the sender and receiver are verified.

[0119] If the current scenario is a public offering investment, the priority of verifying the sender's and receiver's status based on the Hook contract, from highest to lowest, is: frozen status verification, endorsement address verification, and member expiration time status verification; if the current scenario is a private offering investment, the priority of verifying the sender's and receiver's status based on the Hook contract, from highest to lowest, is: frozen status verification, endorsement address verification, member expiration time status verification, and whitelist status verification. If any priority verification fails, the verification result is determined to be verification failure; if all priorities pass verification, the verification result is determined to be verification success; if the endorsement address verification passes, the verification of subsequent priorities is exempted.

[0120] The process of whitelist status verification and endorsement address verification is explained below: I. Whitelist Verification.

[0121] In the RestrictionManager contract: mapping(address => mapping(address => bool)) public productWhitelist; First-level key: Product token address; Second-level key: Investor's address; value: true = in the whitelist, false = not in the whitelist.

[0122] The verification process is as follows: Step 1: The Token contract calls checkERC20Transfer(from, to, value).

[0123] Step 2: Hook the contract to determine the product type.

[0124] Query: isPrivatePlacement = productConfig[msg.sender].isPrivate; If it is a private equity product, whitelist verification is required; If it is a publicly offered product, skip the whitelist verification.

[0125] Step 3: Whitelist lookup (private equity products only).

[0126] Query the sender: isFromWhitelisted = productWhitelist[msg.sender][from]; Query the recipient: isToWhitelisted = productWhitelist[msg.sender][to]; Gas consumption: 2 SLOADs ~4200 Gas (cold read).

[0127] Step 4: Decision logic.

[0128] If !isFromWhitelisted → returns false (the sender is not in the whitelist); If !isToWhitelisted → returns false (the receiver is not in the whitelist); If all passes → continue with subsequent verification.

[0129] The process for adding or deleting items from the whitelist is as follows: Function: addToWhitelist(address product, address investor); Caller: Product Administrator / Publisher; process: 1. Verify caller permissions (only product administrators can perform this operation); 2. productWhitelist[product][investor] = true; 3. Triggering event: emit WhitelistAdded(product, investor).

[0130] II. Endorsed Address Verification.

[0131] mapping(address => bool) public endorsed; key: address; value: true = endorsed address (exempt from verification), false = ordinary address.

[0132] Verification process: Step 1: Execute in checkERC20Transfer of the Hook contract.

[0133] Step 2: Prioritize checking endorsement addresses (short-circuit optimization); Query: isFromEndorsed = platform.endorsed(from); If isFromEndorsed == true → return true directly, skipping all subsequent checks; Gas consumption: 1 cross-contract SLOAD ~2100 Gas (cold read) or ~100 Gas (hot read).

[0134] Step 3: Recipient endorsement verification; Query: isToEndorsed = platform.endorsed(to); If isToEndorsed == true → skip the recipient's membership check; Gas consumption: 1 SLOAD ~100 Gas (hot read, the same contract has been preheated); Primarily used for exchange custody addresses (frequent trading, requiring exemption), market maker addresses (requiring rapid liquidity), custody contract addresses (technical transfers, not real transactions), and clearing contract addresses (requiring exemption during forced liquidation).

[0135] Setting the endorsement address: Function: setEndorsed(address account, bool status); Caller: Platform super administrator; process: 1. Verify that the caller is a super administrator; 2. endorsed[account] = status; 3. Trigger the event: emit EndorsedStatusChanged(account, status).

[0136] Figure 6 The process diagram for pre-stored state mapping hookData provided in this application includes the following steps: S201: Obtain the user's membership expiration time, encode the membership expiration time to obtain a 64-bit timestamp, the 64-bit timestamp occupies the high 64 bits of the 128-bit data; S202: Obtain the user's frozen status information, and encode the frozen status information to obtain a 1-bit frozen flag, wherein the 1-bit frozen flag occupies the lowest bit of the 128-bit data; S203: Obtain other personal status information of the user, encode the other personal status information to obtain reserved status data, the reserved status data occupies the middle reserved extension bit of 128 bits of data; wherein, the other personal status information includes risk level information and investment limit level information; S204: Invoke the token contract to write 128-bit data into the state mapping hookData.

[0137] To address the issues of low utilization of user state storage space and difficulty in ensuring the atomicity of state updates in related technologies, this application proposes a user state storage mechanism using hookData-128-bit compact bitmap encoding.

[0138] In this application, the high 64 bits of the 128-bit data encoded in the hookData-128-bit compact bitmap store the user's membership expiration time, the low 1 bit stores the user's frozen status information, and the middle 63 bits of the 128-bit data are reserved extension bits. These reserved extension bits can store other personal status information of the user, such as the user's risk level information and investment limit level information.

[0139] To encode multiple status fields within a 128-bit storage space, this application employs the following methods: Membership validity period: uses a 64-bit Unix timestamp, shifted left by 64 bits to occupy the high 64 bits; Freeze flag: uses the lowest bit (bit 0); Reserved extension: the middle 63 bits are reserved for future fields; Bitwise extraction: uses right shift (>>) and bitwise AND (&) operations to extract each field. A single `setHookData` writes all statuses, ensuring atomicity; a single `SLOAD` reads all statuses, reducing gas consumption by 50%; bitwise operations are CPU-level operations, with negligible overhead.

[0140] This application considers that 128 bits of space may not be sufficient if more state fields need to be encoded in the future. The solutions are: Priority design: The current design reserves 63 bits to support at least 20 additional boolean fields or several integer fields; External mapping: If complex data needs to be stored, a mapping table from address to extended data is maintained in the Hook contract; Versioning migration: If necessary, a new version of the token contract can be deployed using a larger storage space (such as 256 bits).

[0141] It should be noted that the design principle of hookData is as follows: the 128-bit hookData only stores the individual user's status information: membership expiration time (validUntil), freeze flag (isFrozen), and other personal statuses that can be expanded in the future (such as risk level, investment limit level). It does not store relational data (whitelists, endorsement addresses, etc.).

[0142] The whitelist, endorsement address, and QI authentication data in the system should not be stored in the 128-bit hookData. The reasons are as follows: The whitelist is a product-level list stored in the RestrictionManager Hook contract.

[0143] Data structure: mapping(address => mapping(address => bool)) (product address => investor address => whether it is on the whitelist); During verification, the Hook contract queries the mapping table instead of reading from hookData.

[0144] This design is because the whitelist may contain tens of thousands of addresses, which cannot be compressed into 128 bits.

[0145] The endorsement address does not exist in hookData.

[0146] Endorsing addresses are platform-level trusted addresses (such as escrow contracts and exchanges); endorsement addresses are stored in the Platform contract: mapping(address => bool) public endorsed; these are privileged addresses that need to be managed separately and should not be confused with user state; verification is achieved by querying the Platform contract.

[0147] In addition, QI authentication is not directly stored in hookData.

[0148] The essence of QI certification is "membership," which is implicitly expressed through validUntil (membership expiration date).

[0149] Logic: If an investor passes QI certification → Sets the membership expiration time (e.g., after 1 year) → In hookData, validUntil > 0; If QI certification fails, validUntil = 0, indicating no membership. Therefore, there is no need to set an additional QI certification flag.

[0150] The QI certification verification (Qualified Investor Verification) process is as follows.

[0151] Data storage (implicit); QI authentication status is implicitly expressed through the `validUntil` field of `hookData`:

[0152] validUntil > Current Time → QI certification is valid and within its validity period; validUntil = 0 → QI certification failed; validUntil < Current Time → QI certification has expired.

[0153] Verification process: Step 1: Read the sender hookData from the Token contract.

[0154] Query: fromData = trancheToken.hookDataOf(from); Gas consumption: 2100 Gas per SLOAD (cold read).

[0155] Step 2: Bitwise operations to extract validUntil.

[0156] Operation: validUntil = uint64(fromData >> 64); Gas consumption: ~3 Gas (displacement operation).

[0157] Step 3: Time comparison verification.

[0158] Judgment: validUntil >= block.timestamp; If validUntil == 0 → return false (QI certification has never been passed); If validUntil < block.timestamp → return false (QI certification has expired); If validUntil >= block.timestamp → validation passes; Gas consumption: ~3 Gas (comparison operation).

[0159] Step 4: Repeat steps 1-3 for the recipient.

[0160] The complete process description of the transfer verification solution provided in this application is as follows: Step 1: The Token contract calls the Hook contract's checkERC20Transfer() method; Step 2: The Hook contract performs multi-layered verification; 2.1: Extract the sender's hookData and check the freeze flag (bitwise operations); 2.2: Query the Platform contract to check if it is an endorsement address (mapping query); 2.3: Extract the sender's validUntil and check the member's validity period (bitwise operations + time comparison); 2.4: [Private Equity Products] Query the whitelist mapping table of RestrictionManager; 2.5: Repeat the checks in 2.1-2.3 for the recipient; Step 3: Return the verification result to the Token contract.

[0161] Figure 7 This is a schematic diagram of the bitmap encoding structure provided in this application. One user corresponds to one hookdata, and each user occupies only 16 bytes of storage space.

[0162] Table 3. Bit segment division table for 128-bit hookData

[0163] The encoding example is as follows:

[0164] Membership expires: 2025-01-01 (timestamp: 1735689600); Freeze status: Not frozen (0); Encoding result: 0x000000006772a000000000000000000000.

[0165] Processing steps:

[0166] Step A: Status coding (writing).

[0167] Step A1: Membership expiration time code; Input parameter: expirationTime (64-bit Unix timestamp, second-level precision); Encoding operation: hookData = uint128(expirationTime) << 64; Bitwise operation description: Shift the 64-bit timestamp left by 64 bits, occupying the high 64 bits; Example: Timestamp 1735689600 (2025-01-01) → hookData = 0x000000006772a00000000000000000000; Step A2: Freeze flag encoding; Read the current user's frozen state: isFrozen = getBit(hookData, 0); If you need to keep it frozen: hookData = hookData | 0x1 (bitwise OR operation); To unfreeze: hookData = hookData & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE (bitwise AND operation); Bitwise operation explanation: Masking operations only modify bit 0 and do not affect other bits; Step A3: Atomic writing; Call the token contract's setHookData(userAddress, bytes16(hookData)) function; Write 128 bits of data to the storage map at once: hookDataOf[userAddress] = hookData; Atomicity guarantee: All states are updated within a single transaction, with no intermediate states.

[0168] In this application, reading the sender's state and receiver's state from the pre-stored state mapping hookData includes: calling the token contract to read the 128-bit state mapping hookData of the sender and receiver; performing a decoding operation on the 128-bit state mapping hookData; shifting the 128-bit data right by 64 bits; reading the 64-bit timestamp of the high 64 bits; and reading the freeze flag of the lowest bit through bit operations.

[0169] Step B: State decoding (reading).

[0170] Step B1: Read the complete hookData; Read from the token contract: hookData = hookDataOf[userAddress]; Storage read cost: 2100 Gas (cold read) or 100 Gas (hot read) per SLOAD operation; Step B2: Extract the membership expiration date; Decoding operation: validUntil = uint64(hookData >> 64); Bitwise operation description: Shift 128 bits of data right by 64 bits and extract the high 64 bits; Return value: 64-bit timestamp.

[0171] Step B3: Extract the freeze marker; Decoding operation: isFrozen = (hookData & 0x1) == 1; Bitwise operation description: Bitwise AND operation extracts the least significant bit; Return value: Boolean value; Step B4: Verify the validity of the status; Time comparison: isValid = (validUntil >= currentBlockTimestamp); If validUntil is 0: it means no membership has been set, isValid = false; Freeze check: If isFrozen == true, refuse the transfer.

[0172] This application implements bit-level operations using bitwise operations: Left shift (<<): Shifts the data to the higher-order bits; Right shift (>>): Extracts the most significant bits of data; Bitwise OR (|): Sets the specified bit to 1; Bitwise AND (&): Clears or extracts the specified bit.

[0173] In related technologies, two fields require two storage slots (512 bits). This application adopts a single storage slot design, with the two fields sharing one storage slot (128 bits), reducing storage space by 75% compared to related technologies. In this application, all status fields reside in the same 128-bit data, and a single setHookData call completes all updates, eliminating intermediate states from partial updates and avoiding inconsistencies caused by concurrent modifications. This application reserves 63 bits for future expansion, which can encode investment limit levels (3 bits, 8 levels), risk tolerance levels (3 bits, 8 levels), and special permission flags (multiple bits).

[0174] This application addresses the issues of bitwise operations being unfriendly to developers, resulting in poor code readability and maintenance difficulties. The solution is: 1. Bitmap Library Encapsulation: Provides BitmapLib library functions to encapsulate bitwise operations. setBit(bitmap, index, value): Sets the specified bit. getBit(bitmap, index): Reads the specified bit. extractUint64(bitmap, offset): Extracts a 64-bit integer; 2. Detailed comments: The contract code includes detailed comments explaining the purpose and encoding method of each bit field; 3. Unit Testing: Write complete unit tests for all bitwise operations to ensure correctness.

[0175] Table 4 Quantitative Analysis of Technological Advantages

[0176] Table 5 Comparison with ERC-721 NFT Membership Certificate Scheme

[0177] The above-mentioned solution can be applied to off-chain KYC data synchronization mechanisms. Bitmap encoding technology supports efficient off-chain and on-chain state synchronization, as illustrated below using KYC authentication as an example.

[0178] Synchronization process: The off-chain database stores complete KYC data (sensitive information such as name and ID number, stored in encrypted form); The event synchronization service periodically scans the database to identify authenticated users. Call the updateMember function of the restriction management contract, passing in the user address and the expiration date; where the user address refers to the user's Ethereum wallet address, which is the user's unique identifier on Ethereum; The restriction management contract encodes the validity period into hookData (using bitmap encoding from Innovation Point 2); Write the token to the token contract in one go and complete the synchronization.

[0179] This application scenario demonstrates the value of bitmap encoding technology in practical business, protecting privacy (sensitive data is not on the blockchain) while achieving on-chain verifiability.

[0180] To address the high gas consumption issue in transfer verification, this application proposes an optimized verification algorithm based on single-slot storage reads, namely, a high-efficiency single-slot verification algorithm based on bitwise operations. By optimizing the data structure and access mode, this application minimizes the number of storage reads required for transfer verification, significantly reducing gas consumption.

[0181] Figure 8 The flowchart illustrating the process for retrieving the freeze flag and membership validity period provided for this application is as follows: Figure 8 As shown, it includes the following steps: Step 1: The investor initiates a transfer transaction; Step 2: Prepare verification parameters (balance check, read hookData from both parties); Step 2.1: Check the balance; Step 2.2: Read the hookData from the form; Step 2.3: Read the hookData of to; Step 3: Callback Hook contract to execute verification logic; Step 4: Sender verification (frozen status, membership validity period); Step 4.1: Extract the from freeze flag (bitwise operations); Step 4.2: Extract the member validity period from (bitwise operations).

[0182] Figure 9 The transfer transaction process diagram provided for this application is as follows: Figure 9 As shown, it includes the following steps: Step 5: Recipient verification (frozen status, membership validity period); Extract the to-frozen flag and validity period; Step 6: Return the verification result; Step 7: Execute the ERC20 transfer and trigger a callback notification; Step 7.1: Execute the ERC20 transfer; Step 7.2: onERC20Transfer (callback notification).

[0183] like Figure 8 and Figure 9 As shown, steps 1-3: The token contract prepares verification parameters; step 4: The callback Hook contract executes multi-level verification; steps 5-7: The transfer is executed or rejected based on the verification results.

[0184] Gas consumption analysis of the relevant technical verification scheme is as follows: Verification process for relevant technical solutions (such as ERC-1404 + external KYC registry): Cross-contract KYC registry call: CALL operation ~3000 Gas; Read sender's KYC status: SLOAD ~2100 Gas; Read sender's frozen status: SLOAD ~2100 Gas; Read receiver's KYC status: SLOAD ~2100 Gas; Read receiver's frozen state: SLOAD ~2100 Gas; Executing the verification logic: computational cost ~1000 Gas; Total: Approximately 12,400 Gas / validation (cold read only).

[0185] The optimized verification algorithm of this application:

[0186] Processing steps:

[0187] Step 1: Batch read the states of both parties (token contract execution); Operation: Read the sender's hookData: fromData = hookDataOf[from]; Gas consumption: 2100 Gas per SLOAD (cold read); Operation: Read the receiver's hookData: toData = hookDataOf[to]; Gas consumption: 2100 Gas per SLOAD (cold read); Packaging: HookData{from: fromData, to: toData}; Total: Only 2 SLOADs are needed to obtain all the necessary states.

[0188] Step 2: Callback Hook Contract Verification (Restricting the Execution of the Management Contract); Input parameters: from address, to address, amount, HookData structure; Function type: view function (does not modify state, low gas consumption).

[0189] Step 3: Sender verification (based on bitwise operations); Operation 3.1: Extract the freeze flag; Bitwise operation: isFrozen = (fromData & 0x1) == 1; Gas consumption: ~3 (bitwise AND operation); Condition: If isFrozen == true, immediately return false; Operation 3.2: Check the endorsement address; Query: endorsed = platform.endorsed(from); Gas consumption: 1 SLOAD ~100 Gas (hot read, platform contract resident in memory); Condition: If endorsed == true, skip subsequent checks (endorsed address exemption); Operation 3.3: Extract member expiration time; Bitwise operations: validUntil = uint64(fromData >> 64); Gas consumption: ~5 (right shift operation); Operation 3.4: Time Comparison; Comparison operation: isValid = validUntil >= block.timestamp; Gas consumption: ~3 (comparison operation); Condition: If isValid == false, return false.

[0190] Step 4: Receiver verification (also based on bitwise operations); Check if the receiving address is a zero address (destroy operation); Condition: If to == address(0), return true (destruction is allowed); Check endorsement address: If to is an endorsement address, return true; Extract the recipient's freeze flag: Bitwise operation: isFrozen = (toData & 0x1) == 1; If frozen, return false; Withdrawal of recipient member's expiration date: Bitwise operations: validUntil = uint64(toData >> 64); Time comparison: isValid = validUntil >= block.timestamp; If invalid, return false.

[0191] Step 5: Return the verification result; All checks passed: Returns true; Any check failed: The previous step returned false.

[0192] This application proposes a data prefetching strategy where the token contract reads both parties' hookData in one go before the callback, avoiding repeated cross-contract readings by the hook contract and reducing the number of cross-contract calls. This application also proposes a zero-copy bitwise operation verification strategy, directly extracting data from 128-bit data through bitwise operations, eliminating the need to split the data into multiple variables; this is a CPU-level operation with extremely low gas consumption. Furthermore, this application designs a short-circuit evaluation optimization strategy, placing freeze checks first for rapid rejection, and endorsement address checks before member verification, reducing unnecessary computation. Check items are sorted from highest to lowest failure probability. Hot data caching is also utilized; hookData is pre-warmed (already cached) during the transfer process, and subsequent reads use a hot read mode (100 Gas vs 2100 Gas), as the endorsement address list is typically hot data.

[0193] To achieve efficient verification of both parties' status during each transfer, this application employs the following methods: Data prefetching: The token contract prefetches the hookData from both parties and passes it to the hook; Bitwise verification: Bitwise operations are performed directly on the 128-bit data for extraction, eliminating the need for splitting; Short-circuit evaluation: Check items are sorted by failure probability to quickly reject invalid transfers; Hot data caching: Utilizing the EVM caching mechanism, subsequent reads consume less power; Quantitative effect: Verification cost is reduced from 12,400 Gas to 7,220 Gas (cold read) or 3,220 Gas (hot read), a reduction of 42-54%.

[0194] Table 6 Gas Consumption Comparison Analysis

[0195] Assuming a token has 1000 holders and 10,000 transactions occur daily. Annual resource optimization: Gas consumption reduced by 54%, significantly improving system scalability.

[0196] Table 7. Gas Consumption Comparison Analysis in High-Frequency Trading Scenarios

[0197] The algorithm complexity analysis of the solution provided in this application is as follows: Time complexity: O(1) - a fixed number of bitwise operations and comparisons; Space complexity: O(1) - using only fixed-size local variables; Storage read count: 2 SLOADs (both sides hook data) + 1-2 SLOADs (endorsement query); Worst case: 5 SLOADs (1 more than the traditional 4, but still lower total cost).

[0198] Table 8 Complexity Comparison Table

[0199] This application achieves the best balance between gas optimization, implementation complexity, and user experience.

[0200] The solution provided in this application is applicable to multi-layered verification strategy scenarios. The efficient verification algorithm supports flexible multi-layered verification strategies, taking the tiered access criteria for public and private funds as an example:

[0201] Validation layering: First level: Freeze status check (quickly reject frozen accounts); Second layer: Endorsement address verification (exempt from verification for escrow contracts, etc.); Third layer: Membership verification (check validity period); Fourth layer: Whitelist verification (additional checks on private equity products).

[0202] Different product types can be configured with different combinations of verification levels, and the Hook contract dynamically executes the corresponding verification logic according to the product configuration.

[0203] The following example illustrates the blockchain-based token transfer control process provided in this application through a complete case study of private equity fund issuance and trading.

[0204] Product Information: Product Name: ABC Private Equity Bond Fund; Fundraising Method: Private Placement; Investor Requirements: Qualified Investors; Minimum Investment: RMB 1 million.

[0205] Participating roles:

[0206] Issuer: ABC Asset Management Company; Investor Zhang San: Financial assets of 5 million, QI certified; Investor Li Si: Financial assets of 800,000, basic KYC only.

[0207] Step 1: Product creation and Hook contract deployment.

[0208] Processing steps:

[0209] Step 1.1: Deploy the restriction management contract (Hook contract); Deploy the RestrictionManager contract and set the platform contract address; Gas consumption: Approximately 1,500,000 (one-time deployment); Step 1.2: Deploy the product token contract; Deploy the Tranche Token contract and set the Hook contract address; Configure product parameters: Fundraising method = private placement, Investor requirements = qualified investors; Gas consumption: Approximately 2,000,000 (one-time deployment); Step 1.3: Verify architectural decoupling; The token contract contains only ERC-20 standard logic; All access verification logic is in RestrictionManager; Future rule changes will only require deploying a new RestrictionManager; The hook address is stored in the token contract and verified during each transaction callback, thus separating logic from data.

[0210] Step 2: KYC authentication and status coding.

[0211] Step 2.1: Zhang San submits his KYC application and passes the review; Off-chain operation: Zhang San submits his ID card, financial proof, and other materials; The auditor approved the application; the database record shows status=3 (approved). Sensitive data is encrypted and stored in an off-chain MySQL database; Step 2.2: Event synchronization service coding status; A database query revealed that Zhang San is a QI certified person. Calculate membership validity period: Current time + 1 year = 1767225600 (2026-01-01); Application of bitmap encoding: validUntil = 1767225600 (64-bit timestamp); hookData = uint128(validUntil) << 64; hookData = 0x000000006772a000000000000000000000 (128-bit); Step 2.3: Write on-chain state; Call RestrictionManager.updateMember(token, Zhang San's address, 1767225600); RestrictionManager writes hookData into the token contract; Gas consumption: Approximately 25,000 (new SSTORE value); Step 2.4: Li Si's status (QI certification not passed); Li Si only passed the basic KYC and did not meet the QI standard; hookData remains at 0 (no membership set); Alternatively, set the freeze flag to 1 to prohibit transfers.

[0212] The 64-bit timestamp is shifted left by 64 bits, occupying the high 64 bits, and the lowest bit is reserved for the freeze flag. All state updates are completed in a single write (atomicity).

[0213] Step 3: Transfer verification executed.

[0214] Scenario A: Zhang San transfers 500,000 yuan to a company (successfully).

[0215] Step 3.1: Read the token contract status; Read Zhang San's hookData: 0x000000006772a00000000000000000000; Read hookData from a certain enterprise: 0x000000006af8e00000000000000000000; Gas consumption: 2 SLOADs = 4,200 Gas (cold read); Step 3.2: Callback Hook contract verification; Call RestrictionManager.checkERC20Transfer(Zhang San, a certain company, 500,000, hookData); Gas consumption: CALL operation = 3,000 Gas; Step 3.3: Sender verification (Zhang San); Bitwise operations to extract the freeze flag: (0x...000 & 0x1) = 0 → not frozen; Check the endorsement address: Zhang San is not the endorsement address; Bitwise operations to extract member validity period: (0x...000 >> 64) = 1767225600; Time comparison: 1767225600 > Current time → Valid; Gas consumption: Bitwise operations + comparisons = approximately 20 Gas; Step 3.4: Recipient verification (a company); Extract freeze flag: 0 → Not frozen; Membership validity period: 1798761600 (2027-01-01); Time comparison: Valid; Gas consumption: Approximately 20 Gas; Step 3.5: Return the verification result and execute the transfer; checkERC20Transfer returns true; Execute ERC-20 transfer: Zhang San's balance -500,000, a certain company's balance +500,000; Gas consumption: Balance update = approximately 15,000 Gas; Total Gas consumption: 4,200 + 3,000 + 20 + 20 + 15,000 = 22,240 Gas.

[0216] Scenario B: Zhang San transfers money to Li Si (failed).

[0217] Steps 3.1-3.2: Same as scenario A

[0218] Step 3.3: Sender verification (Zhang San) - Passed; Step 3.4: Recipient verification (Li Si); Read Li Si's hookData: 0x000000000000000000000000000000000 (all 0s); Bitwise operations to extract member validity period: (0x0 >> 64) = 0; Time comparison: 0 < current time → Invalid; Returns false; Step 3.5: Refuse the transfer; checkERC20Transfer returns false; The transaction was immediately rolled back, displaying "Transfer restricted"; Zhang San's share was not transferred out; Gas consumption: Approximately 7,220 Gas (Verification failed, no transfer operation). A single SLOAD reads the complete state (2 reads totaling 128 bits × 2), bitwise operations extract multiple fields, eliminating the need for multiple storage accesses, short-circuit evaluation, and fast rejection of failed cases.

[0219] Step 4: Regulatory Action - Freezing Accounts. Scenario: Regulatory requirements to freeze suspicious accounts.

[0220] Step 4.1: The issuer executes the freeze; Call RestrictionManager.freeze(token, suspicious address); Step 4.2: Update the freeze flag using bitmap encoding; Read the current hookData: 0x000000006772a00000000000000000000; Bitwise operations to set the freeze bit: hookData | 0x1 = 0x000000006772a00000000000000000001; Write back to the token contract; Gas consumption: Approximately 5,000 Gas (SSTORE modified value); Step 4.3: Verify the freezing effect; The frozen account attempted to transfer funds; Extract the freeze flag during verification: (hookData & 0x1) = 1 → frozen; Immediately return false to refuse the transfer.

[0221] Modify only the lowest bit, keeping other bits unchanged. This is an atomic operation with no intermediate states. Freeze checks have the highest priority and result in fast rejection.

[0222] Table 9. Illustration of Improved Architectural Flexibility

[0223] Table 10. Illustration of Storage Efficiency Improvement

[0224] Table 11 Schematic diagram of verification efficiency improvement

[0225] Table 12 Schematic Diagram of System Maintainability Improvement

[0226] Table 13 Comparison Scheme 1: ERC-721 NFT Membership Certificate Illustration Table

[0227] Table 14 Comparison Scheme 2: Schematic Table of Zero-Knowledge Proof (ZK) Schemes

[0228] The above comparison shows that this application achieves the best balance between gas optimization, implementation complexity, and user experience.

[0229] Figure 10 The schematic diagram of the blockchain-based token transfer control device provided in this application includes: The receiving module 11 is used to receive a token transfer request initiated by calling the token contract, and to obtain the sender identification information, receiver identification information and transfer amount information carried in the token transfer request; The reading module 12 is used to read the sender status and receiver status from the pre-stored state mapping hookData according to the sender identification information and the receiver identification information; The verification module 13 is used to call back the Hook contract based on the independent verification logic Hook contract address stored in the token contract, verify the sender status and receiver status based on the Hook contract, and receive the verification result returned by the Hook contract. The transfer control module 14 is used to execute a token transfer operation based on the sender identifier information, receiver identifier information and transfer amount information if the verification result is successful; and to roll back the transaction if the verification result is unsuccessful.

[0230] The receiving module 11 is also used to obtain the address of the independent verification logic Hook contract. If the address of the independent verification logic Hook contract is verified to be a non-zero address, the address of the independent verification logic Hook contract is stored in the Hook storage variable of the token contract.

[0231] Verification module 13 is specifically used to verify the freeze status and membership expiration time status of the sender and the recipient based on the Hook contract if the current investment scenario is a public offering product; and to verify the freeze status and membership expiration time status of the sender and the recipient based on the Hook contract if the current investment scenario is a private offering product.

[0232] The verification module 13 is also used to verify the endorsement addresses of the sender and receiver based on the Hook contract query platform contract.

[0233] Verification module 13 is specifically used to verify the sender's and receiver's status based on the Hook contract in the following order of priority: frozen status verification, endorsement address verification, and member expiration time status verification, if the current scenario is a public offering investment scenario; if the current scenario is a private offering investment scenario, the verification of the sender's and receiver's status based on the Hook contract in the following order of priority: frozen status verification, endorsement address verification, member expiration time status verification, and whitelist status verification, if the current scenario is a private offering investment scenario. If any priority verification fails, the verification result is determined to be verification failure; if all priorities pass verification, the verification result is determined to be verification success; if the endorsement address verification passes, the verification of subsequent priorities is exempted.

[0234] The reading module 12 is also used to obtain the user's membership expiration time, encode the membership expiration time to obtain a 64-bit timestamp, the 64-bit timestamp occupies the high 64 bits of 128-bit data; obtain the user's frozen status information, encode the frozen status information to obtain a 1-bit frozen flag, the 1-bit frozen flag occupies the lowest bit of 128-bit data; obtain the user's other personal status information, encode the other personal status information to obtain reserved status data, the reserved status data occupies the middle reserved extension bits of 128-bit data; wherein, the other personal status information includes risk level information and investment limit level information; and call the token contract to write the 128-bit data into the status mapping hookData.

[0235] The reading module 12 is specifically used to call the token contract to read the 128-bit state mapping hookData of the sender and receiver, perform a decoding operation on the 128-bit state mapping hookData, shift the 128-bit data right by 64 bits, read the 64-bit timestamp of the high 64 bits, and read the freeze flag of the lowest bit through bit operations.

[0236] This application also provides an electronic device, such as Figure 11 As shown, it includes: processor 21, communication interface 22, memory 23 and communication bus 24, wherein processor 21, communication interface 22 and memory 23 communicate with each other through communication bus 24; The memory 23 stores a computer program, which, when executed by the processor 21, causes the processor 21 to perform any of the above method steps.

[0237] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0238] Communication interface 22 is used for communication between the above-mentioned electronic device and other devices.

[0239] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0240] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0241] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform any of the above method steps.

[0242] This application provides a computer program product, which includes an executable program that, when executed by a processor, implements the method described herein.

[0243] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0244] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A blockchain-based token transfer control method, characterized by, The method comprises: receiving a token transfer request initiated by calling the token contract, obtaining the sender identification information, receiver identification information and transfer amount information carried in the token transfer request; reading the sender state and receiver state from the pre-stored state mapping hookData according to the sender identification information and the receiver identification information; calling the Hook contract according to the independent verification logic Hook contract address stored in the token contract, verifying the sender state and receiver state based on the Hook contract, and receiving the verification result returned by the Hook contract; if the verification result is verified, performing a token transfer operation according to the sender identification information, receiver identification information and transfer amount information; if the verification result is not verified, rolling back the transaction.

2. The method of claim 1, wherein, Before the receiving a token transfer request initiated by calling the token contract, the method further comprises: obtaining an independent verification logic Hook contract address, and if the independent verification logic Hook contract address is a non-zero address, storing the independent verification logic Hook contract address in the Hook storage variable of the token contract.

3. The method of claim 1, wherein, Verifying the sender state and receiver state based on the Hook contract comprises: if it is a public product investment scenario, verifying the frozen state and member expiration time state of the sender based on the Hook contract, and verifying the frozen state and member expiration time state of the receiver; if it is a private product investment scenario, verifying the frozen state, member expiration time state and whitelist state corresponding to the private product of the sender based on the Hook contract, and verifying the frozen state and member expiration time state of the receiver.

4. The method of claim 3, wherein, The method further comprises: verifying the endorsement address of the sender and receiver based on the Hook contract querying the platform Platform contract.

5. The method of claim 4, wherein, If it is a public product investment scenario, the priority of verifying the sender state and receiver state based on the Hook contract from high to low is in turn frozen state verification, endorsement address verification and member expiration time state verification; if it is a private product investment scenario, the priority of verifying the sender state and receiver state based on the Hook contract from high to low is in turn frozen state verification, endorsement address verification, member expiration time state verification and whitelist state verification; if any priority verification fails, it is determined that the verification result is not verified; if all priority verifications are passed, it is determined that the verification result is verified; wherein, if the endorsement address verification is passed, the subsequent priority verification is exempted.

6. The method of claim 1, wherein, The process of pre-storing state mapping hookData comprises: obtaining the member expiration time of the user, performing encoding operation on the member expiration time to obtain a 64-bit timestamp, and the 64-bit timestamp occupies the high 64 bits of 128-bit data; Obtaining the frozen state information of the user, performing an encoding operation on the frozen state information to obtain a 1-bit frozen flag, the 1-bit frozen flag occupying the lowest 1 bit of 128-bit data; Obtaining other personal state information of the user, performing an encoding operation on the other personal state information to obtain reserved bit state data, the reserved bit state data occupying the middle reserved extension bit of 128-bit data; wherein the other personal state information includes risk level information and investment limit level information; Calling the token contract to write 128-bit data into the state mapping hookData.

7. The method of claim 6, wherein, The reading of the sender state and the receiver state from the pre-stored state mapping hookData includes: Calling the token contract to read the 128-bit state mapping hookData of the sender and the receiver, performing a decoding operation on the 128-bit state mapping hookData, right shifting the 128-bit data by 64 bits to read the 64-bit timestamp in the high 64 bits; and reading the frozen flag in the lowest bit through bit operation. 8.A blockchain-based token transfer control apparatus, characterized by, The device includes: A receiving module configured to receive a token transfer request initiated by calling the token contract, and obtain sender identification information, receiver identification information and transfer amount information carried in the token transfer request; A reading module configured to read a sender state and a receiver state from pre-stored state mapping hookData according to the sender identification information and the receiver identification information; A verification module configured to call a Hook contract based on an independent verification logic Hook contract address stored in the token contract, verify the sender state and the receiver state based on the Hook contract, and receive a verification result returned by the Hook contract; A transfer control module configured to execute a token transfer operation according to the sender identification information, the receiver identification information and the transfer amount information if the verification result is passed; and roll back the transaction if the verification result is not passed.

9. An electronic device, comprising: The device includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; The memory is configured to store a computer program; The processor is configured to execute the program stored in the memory to implement the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method of any one of claims 1-7. The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method of any one of claims 1-7.

Images