Enterprise financial resource management method and device, electronic device, computer medium

Abstract

This disclosure provides a method and apparatus, electronic device, and computer medium for managing corporate financial resources, involving the intersection of blockchain technology and supply chain finance. The specific implementation scheme is as follows: In response to an approval event for corporate financial resources, a first digital certificate is created and stored in a consortium blockchain network. The first digital certificate uniquely represents a corporate financial resource and contains control attributes related to the corporate financial resource. In response to a targeted use request initiated for the corporate financial resource, a second digital certificate associated with the first digital certificate is created. The second digital certificate records the payment value specified in the targeted use request, the recipient identifier, and the associated business evidence hash. A set of state management interfaces is provided. These interfaces are used to perform state or structure change operations on the first and / or second digital certificates in response to at least one of the following triggering events: an off-chain execution completion event of the targeted use request; or an authorization instruction.

Description

Technical Field

[0001] This disclosure relates to the intersection of blockchain technology and supply chain finance. Specifically, this disclosure relates to a blockchain-based method and apparatus for managing enterprise financial resources, electronic devices, and computer-readable storage media. Background Technology

[0002] Supply chain finance refers to a financing model in which financial institutions connect core enterprises with their upstream and downstream partners, providing flexible financial products and services. In supply chain finance, targeted management of corporate finance (such as credit) funds is a key technical aspect for ensuring fund security and preventing misappropriation. Summary of the Invention

[0003] This disclosure provides a blockchain-based enterprise financial resource management method and apparatus, electronic device, and computer-readable storage medium.

[0004] According to a first aspect of this disclosure, a blockchain-based enterprise financial resource management method is provided, characterized in that the method is applied to a consortium blockchain network including multiple participating nodes, and the method includes: In response to the approval event of a corporate financial resource, a first digital certificate is created and stored in the consortium blockchain network. The first digital certificate uniquely represents a corporate financial resource and contains control attributes related to the corporate financial resource. In response to a targeted use request for the enterprise's financial resources, a second digital certificate is created that is associated with the first digital certificate. The second digital certificate is used to record the payment amount specified in the targeted use request, the recipient's identifier, and the associated business evidence hash. A set of state management interfaces is provided, which are used to perform state or structure change operations on the first digital credential and / or the second digital credential in response to at least one of the following triggering events: The off-chain execution completion event of the targeted use request; or the authorization instruction.

[0005] According to a second aspect of this disclosure, a corporate financial resource management device is provided, the device comprising: A consortium blockchain network, comprising multiple participating nodes; The first digital certificate unit is used to create and store a first digital certificate in the consortium blockchain network in response to the approval event of corporate financial resources. The first digital certificate uniquely represents a corporate financial resource and contains control attributes related to the corporate financial resource. The second digital certificate unit is used to create a second digital certificate associated with the first digital certificate in response to a targeted use request initiated for the enterprise's financial resources. The second digital certificate is used to record the payment value specified in the targeted use request, the recipient's identifier, and the associated business evidence hash. A state management interface unit is configured to provide a set of state management interfaces, wherein the state management interfaces are configured to perform state or structure change operations on the first digital credential and / or the second digital credential in response to at least one of the following triggering events: an off-chain execution completion event of the directed use request; or an authorization instruction; A digital wallet module for managing blockchain accounts of at least one participant, and the digital credentials held by said blockchain accounts.

[0006] According to a third aspect of this disclosure, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to at least one of the aforementioned processors; wherein, The memory stores instructions that can be executed by at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the enterprise financial resource management method.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the aforementioned enterprise financial resource management method.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the aforementioned enterprise financial resource management method.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a method for managing corporate financial resources provided in an embodiment of this disclosure; Figure 2 This is a flowchart illustrating some steps of another enterprise financial resource management method provided in this embodiment of the disclosure; Figure 3 This is a flowchart illustrating some steps of another enterprise financial resource management method provided in this embodiment of the disclosure; Figure 4 This is a flowchart illustrating some steps of another enterprise financial resource management method provided in this embodiment of the disclosure; Figure 5 This is a flowchart illustrating some steps of another enterprise financial resource management method provided in this embodiment of the disclosure; Figure 6 This is a flowchart illustrating some steps of another enterprise financial resource management method provided in this embodiment of the disclosure; Figure 7 This is a schematic diagram of the structure of an enterprise financial resource management device provided in an embodiment of this disclosure; Figure 8 This is a block diagram of an electronic device used to implement the enterprise financial resource management method of the present disclosure embodiments. Detailed Implementation

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0012] In some related technologies, enterprise financial (such as credit) fund management solutions based on smart contract state management have been proposed. Although these solutions effectively solve the problem of targeted fund payments, there is still room for improvement in the following aspects: The lack of visualization and standardization of corporate financial assets: Corporate financial limits exist in the form of internal contract state variables, which cannot form standardized digital assets and are not conducive to cross-platform identification and circulation.

[0013] Limited flexibility in credit limit management: Fixed credit limit management models are difficult to support complex advanced financial operations such as credit limit splitting, merging, and pledging.

[0014] User rights are not presented intuitively: Financing companies lack intuitive digital representations of their holding, use, and remaining financial quotas.

[0015] The blockchain-based enterprise financial resource management method, apparatus, electronic device, and computer-readable storage medium provided in this disclosure are intended to solve at least one of the above-mentioned technical problems of the prior art.

[0016] The blockchain-based enterprise financial resource management method provided in this disclosure can be executed by electronic devices such as terminal devices or servers. Terminal devices can be in-vehicle devices, user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, in-vehicle devices, wearable devices, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the method can be executed by a server.

[0017] Figure 1 A flowchart illustrating a blockchain-based enterprise financial resource management method according to an embodiment of this disclosure is shown. This blockchain-based enterprise financial resource management method is applied to a consortium blockchain network comprising multiple participating nodes.

[0018] Consortium blockchain networks are blockchain networks jointly maintained by multiple pre-authorized participating nodes, which typically include core enterprises, financing companies, funders (such as banks), and regulatory agencies. Consortium blockchain networks feature node access control, configurable consensus mechanisms, and data privacy protection, making them suitable for supply chain finance scenarios.

[0019] like Figure 1 As shown in the embodiments of this disclosure, the blockchain-based enterprise financial resource management method may specifically include steps S110, S120, and S130.

[0020] S110. In response to the approval event of corporate financial resources, a first digital certificate is created and stored in the consortium blockchain network. The first digital certificate uniquely represents a corporate financial resource and contains control attributes related to the corporate financial resource.

[0021] Corporate finance encompasses all financial activities a company undertakes throughout its lifecycle, including but not limited to: credit financing (including bank loans, letters of credit, bill discounting, etc.), supply chain finance (including accounts receivable financing, order financing, factoring, etc.), bond financing, equity financing, financial leasing, M&A loans, syndicated loans, asset custody, cash management, and other diversified financial services.

[0022] The corporate financial resources disclosed in this embodiment include, but are not limited to, bank credit resources, supply chain finance credit resources, commercial credit, and financial leasing resources. Taking credit as an example, the credit line issued by a bank to a company can be digitized, visualized, and managed throughout its entire lifecycle using the methods of this embodiment; similarly, accounts receivable pledge limits and order financing limits in supply chain finance can also be managed through the same technical framework.

[0023] The first digital certificate is an NFT (Non-Fungible Token) created on a consortium blockchain, such as a token conforming to the ERC-721 or ERC-1155 standard. The first digital certificate uniquely represents a corporate financial resource (i.e., credit line), is immutable and uncopyable, and contains control attributes related to the corporate financial resource.

[0024] Ownership of the first digital certificate is managed through an address on the blockchain, and the address holding the certificate is considered to have the right to use the corresponding enterprise's financial resources.

[0025] Control attributes are structured information related to a company's financial resources and stored in the metadata of the first digital certificate. Control attributes include: the associated smart corporate finance control contract address (used to execute targeted payment control), the total credit line, the current available credit line, the digital identity (DID) of the core enterprise, the digital identity of the financing enterprise, the digital identity of the funding provider, and the validity period of the company's financial resources.

[0026] Control attributes can be updated when conditions are met (e.g., after payment is completed), but the update operation must be performed through a valid state management interface to ensure data consistency.

[0027] S120. In response to a targeted use request for corporate financial resources, a second digital certificate is created that is associated with the first digital certificate. The second digital certificate is used to record the payment amount specified in the targeted use request, the recipient identifier, and the associated business evidence hash.

[0028] The second digital credential is a sub-level non-fungible token created when a targeted use request (i.e., a payment request) is initiated; it is also known as a payment credential sub-NFT. The second digital credential is associated with the first digital credential and records detailed parameters of this targeted use request, including the requested payment amount (payment value), the target recipient's blockchain address or digital identity (recipient identifier), and the associated business notarization hash (e.g., the hash value of a trade contract, invoice information hash, etc.). The second digital credential is locked until payment is completed. After payment, it is updated to a confirmed state through a state management interface and associated with an off-chain execution transaction identifier (such as a bank transaction number).

[0029] S130. Provide a set of state management interfaces, which are used to perform state or structure change operations on the first digital credential and / or the second digital credential in response to at least one of the following triggering events: a directed use request off-chain execution completion event; or an authorization instruction.

[0030] The state management interface is a set of programmable blockchain functions or methods provided by the non-fungible token management contract. It can respond to various triggering events (including off-chain execution completion events and authorization instructions) to perform state changes (such as modifying the available credit limit) or structural changes (such as splitting, merging, staking, and transferring) on ​​the first and / or second digital credentials. This state management interface is the core operational entry point for realizing dynamic management of the entire lifecycle of enterprise financial resources.

[0031] An off-chain execution completion event refers to an event notification sent to the blockchain network by an off-chain system (such as a bank payment gateway or clearing system) after completing a fund transfer operation. This event notification typically includes information such as the payment result, transaction serial number, and timestamp. Upon listening for this event, the smart contract triggers the automatic updating of both the first and second digital credentials.

[0032] An authorization instruction is a management instruction initiated by a participant with the corresponding permissions (such as a financing company) through its digital wallet or other authorized client. Authorization instructions can include splitting instructions, merging instructions, staking instructions, and transfer instructions. Authorization instructions must meet preset permission verification rules (such as identity verification, risk control checks, whitelist verification, etc.) before they can be accepted and executed by the state management interface.

[0033] The method provided in this disclosure deploys a non-fungible token management contract on a consortium blockchain network, converting traditional corporate financial quotas, which exist as internal state variables of smart contracts, into unique, visible, and programmable digital credentials (first digital credentials). Each time a targeted payment is made, an associated payment credential (second digital credential) is generated. Through a unified set of state management interfaces, in response to off-chain execution completion events (automatically triggered) or user authorization instructions (actively triggered), the method updates the value, changes the state, and alters the structure (splitting, merging, staking, and transferring) of the first digital credential. Furthermore, this method also supports tokenizing the release process of surplus funds and displays the entire lifecycle monitoring information of corporate financial resources through a visual interface.

[0034] The following uses credit resources as an example to illustrate each step in detail with specific implementation examples.

[0035] Step 1: Credit resource approval and creation of the first digital voucher (corresponding to step S110) In a typical supply chain finance application scenario, core enterprise B applies for a credit line from bank C on behalf of its upstream supplier A. After completing the credit approval, bank C grants company A a credit line of RMB 1 million for designated payments to purchase components from company B. At this point, this credit line needs to be converted into digital vouchers.

[0036] Implementation details: Bank C calls the minting function (e.g., mintCreditNFT) provided by the non-fungible token management contract deployed on the consortium blockchain. This function accepts the following parameters: Target holder address: Company A's blockchain digital wallet address; The associated smart credit control contract address: This contract address is used to perform logical verification of targeted payments and control fund transfers; Total credit line: RMB 1,000,000; Initial available credit limit: 1,000,000 yuan; Core Enterprise DID: did:example:bcompany; Financing Company DID: did:example:acompany; Funding Party DID: did:example:cbank; Effective date: XXXX-XX-XX; Expiry date: XXXX-XX-XX.

[0037] The minting function first verifies the caller's permissions (only funders or authorized administrators are allowed to call), then generates a unique Token ID (e.g., #001) and creates a non-fungible token, i.e., the first digital credential. The token's metadata is stored in JSON format, containing all the aforementioned control attribute fields. The metadata can be stored on the blockchain (through a smart contract mapping structure) or off-chain (through a distributed storage system, with its storage location recorded in the metadata). In this embodiment, the metadata is written to on-chain contract state variables to ensure immutability.

[0038] After minting, the non-fungible token management contract automatically transfers ownership of the first digital certificate corresponding to Token ID #001 to Company A's digital wallet address. Company A can then view the certificate in its digital wallet interface and intuitively see information such as total quota, available quota, and validity period.

[0039] By casting abstract credit limits into digital certificates in the form of NFTs, a standardized and visual representation of credit assets is achieved. Financing companies can intuitively hold and manage their credit limits as if they were managing digital assets, improving user experience and asset credibility. Simultaneously, the first digital certificate contains complete credit limit attributes and participant identity information, providing a data foundation for subsequent automated management and cross-platform identification.

[0040] Step 2: Targeted use request and creation of the second digital credential (corresponding to step S120) When Company A needs to pay Company B 300,000 yuan for goods, Company A initiates a targeted payment request (payment request) through its digital wallet. This request includes the following key parameters: Payment amount: 300,000 yuan; Recipient Identifier: Company B's digital wallet address or DID; Related business evidence hash: For example, the hash value of this procurement trade contract is 0xabc...

[0041] After the payment request is submitted, the smart credit management contract first: Verify whether Company A holds the corresponding first digital certificate (i.e., Token ID #001); Verify whether the amount of the requested payment does not exceed the currently available credit limit; Verify whether the recipient is on the whitelist (e.g., only payments to core company B or its designated account are allowed). Verify whether the business evidence hash (i.e. the hash value of this procurement and trade contract) has been stored in the system.

[0042] After successful verification but before payment execution, the non-fungible token management contract automatically calls the sub-credential generation function (e.g., createPaymentReceipt) to create an associated second digital credential based on the parent first digital credential (Token ID #001). This second digital credential also uses the non-fungible token standard, but uses a different Token ID (e.g., #001-001), and is recorded in its metadata. Parent credential identifier: #001; Payment amount: 300,000 yuan; Recipient Identifier: Company B's DID or address; Payment timestamp: Current block time; Associated business evidence hash: 0xabc...; Payment status: pending.

[0043] Once generated, the second digital voucher is locked, meaning it cannot be transferred or modified temporarily, and the corresponding funds have not yet been actually transferred. The purpose of locking is to prevent inconsistencies in the status of payments when the outcome is uncertain.

[0044] By generating locked payment credential sub-NFTs before payment execution, each targeted payment request is pre-recorded and immutably documented. This provides a clear chain of evidence for subsequent auditing, tracking, and dispute resolution. The relationship between sub-credentials and parent credentials forms a directed graph of fund usage, enhancing transparency.

[0045] Step 3: Providing the state management interface and triggering updates (corresponding to step S130) One of the core aspects of the method provided in this disclosure is to provide a unified set of state management interfaces, which are implemented by a non-fungible token management contract and are capable of responding to two different types of triggering events: off-chain execution completion events (automatic) and authorization instructions (active).

[0046] (i) Automatic synchronization of payment results for execution completion events under the response chain After the payment request generated in step 2 passes the smart verification, the consortium blockchain will send a payment instruction to the off-chain bank payment gateway. The bank payment gateway will execute the fund transfer (transferring 300,000 yuan from Company A's regulatory account or dedicated credit account to Company B's account) and feed back the execution result (success / failure, bank transaction serial number, etc.) to the blockchain network. This feedback forms an off-chain execution completion event.

[0047] The non-fungible token management contract has a built-in event listener (or an event handler function in the smart contract), which automatically triggers a state update operation when the event is detected. Update the control attributes of the parent first digital certificate (#001): reduce its "current available credit" from 1,000,000 yuan to 700,000 yuan, and increase its "used credit" from 0 to 300,000 yuan; Update the status of the associated second digital voucher (#001-001): change it from "Locked" to "Confirmed", and add a "Bank Transaction Number" field to its metadata, with the value being the transaction number returned by the bank (e.g., BOCTX202310010001). Generate a credit limit change record (optional), which can also be cast as a historical change NFT for auditing purposes.

[0048] All of the above update operations are completed through the status management interface, ensuring a single entry point for modifying the status of the voucher.

[0049] (ii) Responding to authorization instructions – Credit limit management operations initiated by the user In addition to automatically responding to payment results, the status management interface can also receive proactive authorization instructions from authorized users (such as financing company A), including but not limited to splitting instructions, merging instructions, pledging instructions, and transfer instructions. Let's take a splitting instruction as an example: Company A wants to allocate a credit line of 1 million yuan to two different project teams: Project A needs 600,000 yuan and Project B needs 400,000 yuan. Company A calls the splitCreditNFT function of the state management interface through its digital wallet, passing in the parameters: target parent credential ID #001, and a split ratio of 60:40.

[0050] Upon receiving the authorization instruction, the non-fungible token management contract first performs permission verification and status checks (e.g., whether the token exists, whether the available quota is sufficient, and whether the token is in a splittable state). If the verification passes, the splitting operation is executed. The credit resource value represented by the first digital voucher #001 is split into two sub-digital vouchers according to a specified ratio, which are denoted as #001-A (600,000 yuan) and #001-B (400,000 yuan) respectively. Each sub-digital certificate inherits the complete control attributes of the original first digital certificate (including the associated smart contract address, core enterprise DID, funder DID, validity period, etc.), but their respective available limits are set to 600,000 yuan and 400,000 yuan respectively. The original first digital certificate #001 was marked as invalid or destroyed to prevent reuse.

[0051] After being split, Company A's digital wallet displays two independent credit limit NFTs, corresponding to Project A and Project B respectively. Each sub-NFT can independently initiate targeted payment requests, generating its own second digital credential, and their respective available credit limits do not affect each other.

[0052] Similarly, authorization instructions can also be merge instructions (merging multiple first digital credentials associated with the same smart credit management contract into a single master credential), staking instructions (transferring ownership of the first digital credential to the staking contract address in exchange for liquidity), and transfer instructions (transferring credential ownership to other qualified participants under conditions of identity verification and whitelisting). These operations are all implemented through the same set of state management interfaces, ensuring consistency and scalability of the operational logic.

[0053] A unified state management interface enables comprehensive management of both primary and secondary digital credentials, simplifying the system architecture and improving code reusability. Automated responses to off-chain execution completion events ensure consistency between on-chain credit limit status and the actual off-chain fund status, avoiding risks caused by data asynchrony. Support for programmable operations such as splitting, merging, pledging, and transferring significantly enhances the flexibility and applicability of credit limit management, meeting the product innovation needs of complex supply chain finance scenarios. All state changes are recorded on-chain, possessing immutability and traceability, providing a reliable basis for risk control and auditing.

[0054] The method provided in this disclosure also includes preferred steps such as tokenization of the released quota and full lifecycle visual monitoring: Release Processing: When preset release conditions are met (such as the financing company repaying the loan early, causing the balance in the escrow account to exceed the required retention limit), the state management interface will determine the releaseable value share, mint a third digital token (fungible token, such as one conforming to the ERC-20 standard), and allocate it to the financing company's wallet. The financing company can then use this token to apply for the transfer of corresponding funds from the escrow account to its free account, and the token will then be destroyed.

[0055] Visual monitoring: Through a dedicated monitoring platform or blockchain explorer, the lifecycle status changes of the first digital certificate, the transaction relationship of the second digital certificate, the time sequence record of programmable operations, and the efficiency and health indicators of quota usage can be displayed in the form of charts, time sequence diagrams, and relationship graphs.

[0056] In the blockchain-based enterprise financial resource management method, abstract enterprise financial limits are cast into NFT digital certificates, realizing standardized asset expression and intuitive user management; the programmable operation interface supports splitting, merging, pledging, and transferring to meet complex financial scenarios; each payment generates an independent sub-NFT, forming a complete fund trajectory, which is convenient for auditing and supervision; the unified state management interface ensures that all change operations are controlled and tamper-proof, and off-chain events are automatically synchronized to ensure data consistency.

[0057] The following describes in detail other optimization steps included in the blockchain-based enterprise financial resource management method provided in the embodiments of this disclosure.

[0058] In some possible implementations, the first digital credential is a non-fungible token; the control attributes include: the smart contract address associated with the enterprise's financial resources, the total amount of the enterprise's financial resources, the current available amount, the digital identity of the core enterprise, the digital identity of the financing enterprise, the digital identity of the funding provider, and the validity period of the enterprise's financial resources.

[0059] Non-fungible tokens (NFTs) are a type of blockchain-based digital certificate that is unique, indivisible (in the conventional sense), and non-fungible. Unlike fungible tokens (where each token is identical and interchangeable), each NFT represents a unique asset.

[0060] In this disclosed embodiment, NFT is used as the first digital credential because each corporate financial limit has unique attributes (such as different credit amounts, different participants, and different validity periods), and NFT can accurately represent this uniqueness.

[0061] A smart contract address is a unique identifier for a smart contract deployed on a consortium blockchain network. In this embodiment, it refers to the address of a "Smart Enterprise Financial Control Contract." This contract is responsible for executing the targeted payment control logic for enterprise financial funds, including verifying payment requests, invoking bank payment gateways, and updating on-chain states. The first digital credential records this contract address in its metadata, ensuring the binding relationship between the enterprise's financial limit and specific control rules. Even if the first digital credential is split, merged, or transferred, its associated smart contract address remains unchanged, thus ensuring that the limit is always subject to the same set of risk control rules.

[0062] The total amount of corporate financial resources refers to the total amount of corporate financial funds approved and injected into a regulated account by funding parties (such as banks). This value is expressed in legal tender units and may also be pegged to stablecoins or other digital assets. The total amount is determined when the first digital certificate is minted and remains unchanged unless a consolidation operation (the total amount after merging multiple certificates is the sum of the total amounts of the original certificates) or a release operation (the total amount is reduced accordingly after a portion of the amount is released) occurs.

[0063] The current available credit limit refers to the amount of corporate financial funds that a financing company can still use at any given time. Its initial value is equal to the total credit limit. Each time a designated payment is completed, the available credit limit decreases accordingly; if a repayment or release operation occurs, the available credit limit increases accordingly. The available credit limit is dynamic and must be automatically updated after each payment through the state management interface to ensure the accuracy of the on-chain records.

[0064] The core enterprise's digital identity can be a DID (Decentralized Identifier), a new and verifiable digital identity standard. In this disclosed embodiment, the core enterprise, the financing enterprise, and the funding party each possess a unique DID, used to identify their identity on the consortium blockchain network. The core enterprise is typically the dominant enterprise in the supply chain, and its DID is recorded in the enterprise's financial limit NFT, indicating the usage restrictions of that limit (e.g., it can only be used for payments to the core enterprise and its designated suppliers). The DID can be associated with off-chain information such as enterprise qualifications and credit ratings, facilitating risk control verification by smart contracts.

[0065] The digital identity of a financing company refers to the DID of the downstream company (supplier) that receives the financing company's financial credit line. Ownership of the initial digital credential typically belongs to the financing company. The financing company controls this credential through its private key and can initiate authorized instructions such as targeted payments, splitting, merging, pledging, and transferring. Recording the financing company's DID in the credential's management attributes helps quickly identify the current user of the credential and provides a basis for access control.

[0066] The digital identity of a funding provider refers to the DID (Digital ID) of the bank, factoring company, or other financial institution that provides financial funds to a company. The funding provider is the true investor in the company's financial line and possesses the highest level of management authority (such as freezing or canceling the line). Recording the funding provider's DID helps clarify the responsible party and facilitates recourse in the event of risk.

[0067] The credit line validity period refers to the start and end dates during which a company's financial credit line can be used. It typically includes an effective date and an expiration date. Before the validity period begins, the financing company cannot use the credit line; after the validity period ends, any unused credit line automatically expires, and the used portion needs to be repaid according to the agreement. The validity period information is recorded in the NFT metadata, and smart contracts automatically check whether the current time is within the validity period when executing payment requests or authorization instructions.

[0068] In some possible implementations, a "non-fungible token management contract" can be deployed on a consortium blockchain. This contract inherits from or is compatible with standard NFT protocols and extends the data structure with storage control attributes.

[0069] The following uses Solidity (a commonly used language for Ethereum smart contracts) as an example to give the definition of the core data structure: solidity / / Metadata structure of corporate financial limit NFTs struct CreditNFTMetadata { address smartContractAddress; / / Address of the associated smart enterprise financial management contract uint256 totalAmount; / / Total amount (unit: cents, to avoid floating-point errors) uint256 availableAmount; / / Current available amount string coreEnterpriseDID; / / Core Enterprise DID string financerDID; / / Financing company's DID string funderDID; / / Funding provider DID uint256 effectiveTime; / / Effective timestamp uint256 expiryTime; / / Expiry timestamp} When the funder calls the mintCreditNFT function, the contract executes the following steps: Verify whether the caller is an authorized role (only the funder or system administrator).

[0070] Generate a unique tokenId.

[0071] Create an instance of the CreditNFTMetadata structure and fill in the passed parameters.

[0072] Call the _mint function to assign the tokenId to the address of the financing company.

[0073] Trigger the CreditNFTMinted event to record information such as tokenId, address of the financing company, and metadata.

[0074] The "Current Available Amount" in the control attributes is automatically updated upon payment completion. The state management interface provides the `updateAvailableAmount` function, which is triggered by an off-chain execution completion event. To ensure that only legitimate off-chain events (such as trusted messages from a bank payment gateway) can modify the amount, the contract typically employs one of the following mechanisms: Oracle mode: The bank payment gateway signs the payment result and sends it to the oracle contract on the chain. The oracle verifies the signature and then calls the state management interface.

[0075] Multi-party signature: The payment result is jointly signed by multiple trusted nodes (such as funding node and core enterprise node), and the contract is only allowed to be updated after the number of signatures verified reaches a threshold.

[0076] During the update, the contract checks whether the new available credit is less than or equal to the original available credit (reduction in payments) or greater than the original available credit (increase in repayments), and ensures that the value is non-negative. The CreditNFTUpdated event is triggered upon completion of the update.

[0077] Front-end monitoring platforms or the digital wallets of financing companies can obtain complete metadata by calling the `getCreditNFTMetadata(tokenId)` function of the contract. Since the metadata includes identity information such as DID, the front-end can display intuitive information such as credit limit ownership, remaining credit limit, and remaining days.

[0078] By encapsulating corporate financial limits into NFTs with a unified metadata structure, different financial institutions, core enterprises, and financing companies can seamlessly identify and process corporate financial assets, laying the foundation for the interconnectivity of the supply chain finance ecosystem.

[0079] All regulatory attributes are stored on an immutable blockchain, allowing regulators and auditors to access complete information on any amount at any time, including its source, usage restrictions, and current status.

[0080] By identifying participants through DID, smart contracts can quickly verify the identity and permissions of operators, avoiding the need for complex centralized permission table maintenance.

[0081] Financing companies can clearly see key information such as the total amount, remaining amount, and validity period of their financing in their digital wallets, enhancing transparency and trust.

[0082] In some possible implementations, the second digital credential is a payment credential sub-nonfungible token.

[0083] In other words, the second digital certificate is a special sub-NFT associated with the first digital certificate. It uses the same token standard as the first digital certificate but has an independent Token ID, and its metadata includes the identifier of the parent certificate. The main function of the payment certificate sub-NFT is to "solidify" the key parameters of each targeted payment request, forming immutable evidence of payment. This sub-NFT typically does not have value attributes (i.e., it does not represent the company's financial limit itself), but it records the fact of value flow.

[0084] In some possible implementations, creating a second digital credential associated with the first digital credential may specifically include: generating the second digital credential and locking it before the execution of the directed use request; in response to the off-chain execution completion event of the directed use request, updating the state of the second digital credential to the confirmed state through the state management interface, and recording the execution sequence identifier in the second digital credential.

[0085] The locked state is a temporary state that exists after the second digital credential is created, before payment is executed. In the locked state, the credential cannot be altered in any way (such as status updates or ownership transfers). The purpose of the locked state is to prevent improper modification of the credential or claiming that payment has been completed before the payment outcome is determined. The locked state can be implemented by adding the field `status: "locked"` to the metadata.

[0086] The "confirmed" status refers to the final state to which the second digital credential is updated after a successful off-chain payment and receipt of the bank transaction serial number. The "confirmed" status indicates that the payment has been completed, has legal effect, and is traceable. In the updated metadata, the status field changes to "confirmed" and is associated with the bank transaction serial number.

[0087] An execution transaction identifier is a unique transaction identifier generated by a bank payment gateway after the fund transfer is completed. Examples include a bank transaction number or a trace ID within the payment system. The execution transaction identifier serves as a crucial bridge connecting on-chain records with traditional off-chain financial systems, facilitating joint queries during reconciliation, auditing, or dispute resolution.

[0088] State update operations must be performed through the state management interface. This ensures that all modifications to the second digital credential adhere to a consistent security policy and atomicity guarantee, avoiding the risk of bypassing the interface to directly modify the state.

[0089] In some possible implementations, the metadata structure of the payment credential NFT can be defined within the non-fungible token management contract: solidity struct PaymentReceiptMetadata { uint256 parentTokenId; / / Token ID of the parent company's financial NFT uint256 paymentAmount; / / Payment amount string receiverId; / / Receiver identifier (DID or address) uint256 paymentTimestamp; / / Payment request timestamp bytes32 tradeContractHash; / / Hash of the associated trade contract string status; / / "locked" or "confirmed" string bankTxId; / / Bank transaction number (filled in after confirmation)} Once a financing company initiates a targeted usage request and passes the initial verification of the smart enterprise financial governance contract, the non-fungible token management contract automatically calls the internal function _createPaymentReceipt before payment execution. This function performs the following operations: Generate a new Token ID. The naming convention is recommended to be {parentTokenId}-{seq}, for example, #001-001.

[0090] Create a PaymentReceiptMetadata structure and fill it in: parentTokenId: Parent Token ID paymentAmount: The amount of payment requested receiverId: Receiver identifier paymentTimestamp: Current block timestamp tradeContractHash: Business evidence hash (obtained from payment requests) status: "locked" bankTxId: Empty string Call the _mint function to mint the child NFT and assign it to a temporary address (such as the contract's own address or a derivative address of the financing company's address) to ensure that it will not be transferred before payment is completed.

[0091] The PaymentReceiptCreated event is triggered, which includes information such as the child voucher ID, parent voucher ID, and payment amount.

[0092] Once the bank payment gateway completes the fund transfer, it submits an off-chain execution completion event to the blockchain. This event includes: the payment request ID (or the associated second digital credential token ID), the execution result (success / failure), and the bank transaction serial number.

[0093] The non-fungible token management contract listens for this event and verifies the legitimacy of its source (e.g., only authorized bank nodes can send such events). Upon successful verification, it calls the `confirmPaymentReceipt` function of the state management interface. Input parameters: Sub-credential Token ID, Bank transaction serial number.

[0094] The contract first checks if the sub-credential exists and if its current status is "locked".

[0095] Update the status in the metadata to "confirmed".

[0096] Set bankTxId to the passed-in bank transaction serial number.

[0097] Transfer ownership of the sub-certificate from the temporary address to the financing company's address (or retain it in the contract for record-keeping).

[0098] The PaymentReceiptConfirmed event is triggered.

[0099] If payment fails, the contract will update the status of the sub-credential to "failed" or destroy the credential directly to avoid invalid credentials occupying storage.

[0100] The parentTokenId field in the sub-credential metadata allows easy identification of which corporate financial limit the payment belongs to. Similarly, a reverse lookup of the first digital credential can retrieve a list of all associated payment credential sub-NFTs, forming a complete record of fund usage.

[0101] Each payment generates a unique sub-NFT, recording all the key parameters of the payment. Any party can trace the destination of every fund through the blockchain, preventing misappropriation and fraudulent transactions.

[0102] By recording bank transaction serial numbers on the blockchain, data anchoring between the blockchain and traditional banking systems is achieved. Reconciliation only requires comparing the serial numbers in the on-chain sub-NFTs with the records in the banking system, significantly reducing reconciliation costs.

[0103] Since the sub-NFT is generated and locked before the payment is executed, and the state transition after the payment is completed is irreversible, this certificate can serve as electronic evidence with judicial value, proving that the financing company did indeed initiate the payment request and the bank did indeed execute the transfer.

[0104] In some possible implementations, the risk control system can also quickly calculate indicators such as the fund usage pattern, supplier concentration, and average payment cycle of a financing company by traversing all its payment voucher NFTs, thus promptly identifying abnormal behavior. The financing company can also intuitively see the "voucher" for each payment in its wallet and export it at any time for reconciliation purposes, eliminating the need to apply for paper vouchers from the bank.

[0105] In some possible implementations, the authorization instructions include split instructions.

[0106] A splitting instruction is an authorization command initiated by a financing company (or a participant with corresponding permissions) through its digital wallet or other authorized client to split a corporate financial NFT into multiple sub-financial NFTs. Initiating a splitting instruction typically requires meeting preset conditions, such as: the primary digital certificate is not currently frozen, the available amount is greater than the value to be split, and the splitting ratio meets the minimum unit requirement.

[0107] Figure 2 The diagram illustrates a breach of trust mechanism in response to a split command, performed via a state management interface. Figure 2 As shown, it may include steps S210 and S220.

[0108] S210. The first digital certificate is split into multiple sub-digital certificates according to a specified ratio, and the sum of the enterprise financial resource values ​​represented by the multiple sub-digital certificates is equal to the enterprise financial resource value represented by the first digital certificate.

[0109] The specified ratio refers to the splitting ratio set by the financing company itself, such as 60:40 or 1:1:1. The splitting ratio can be a percentage (e.g., 60% or 40%) or a specific numerical allocation (e.g., 600,000 yuan or 400,000 yuan). In practice, it is usually required that the sum of the corporate financial resources represented by each sub-certificate after splitting equals the total amount of the original certificate, and that the amount of each sub-certificate is a positive number and not less than the minimum amount unit set by the system.

[0110] Sub-digital certificates are new digital certificates generated during the splitting process. Each sub-digital certificate is an independent non-fungible token (NFT) with a unique token ID and fully inherits the control attributes of the original first digital certificate (including the associated smart contract address, core enterprise DID, funding party DID, validity period, etc.), but each has its own independent available amount. After the split, the original first digital certificate is usually destroyed or marked as invalid to prevent reuse.

[0111] S220. Each sub-digital voucher inherits the control attributes of the first digital voucher.

[0112] Inheriting the control attributes of the first digital certificate means that when a sub-digital certificate is created, it automatically copies the values ​​of all control attribute fields of the original first digital certificate (except for fields related to the credit limit, which need to be adjusted according to the split ratio; other fields such as smart contract address, core enterprise DID, funding party DID, and validity period are completely identical). The purpose of inheritance is to ensure that each sub-certificate after splitting is still subject to the exact same set of risk control rules and payment restrictions as the original certificate, thereby ensuring the safe closed loop of corporate financial funds.

[0113] In some possible implementations, when the non-fungible token management contract receives a splitting instruction, it first performs a series of checks, including but not limited to: Verify whether the caller is the owner (financing company) of the current first digital credential; Verify that the first digital certificate exists and is in a splittable state (not pledged, not frozen, not expired); Verify the validity of the split ratio: for example, whether the sum of the values ​​corresponding to the split ratio is equal to the original total amount; whether the value of each sub-voucher is positive and not less than the minimum unit; Verify if there is an ongoing payment request associated with the credential (this can be determined by checking if there is a locked second digital credential); if so, splitting is not allowed.

[0114] After successful verification, the contract executes the following steps: 1. Obtain the original voucher metadata 2. Verify the validity of the split. 3. Calculate the value of each sub-voucher. 4. Casting Sub-Documents: Copy the control attributes, cast, and assign to the current owner. 5. Destroy the original voucher. 6. Triggering events After the split, each sub-digital certificate exists independently. The financing company can see multiple independent corporate financial NFTs in its digital wallet, each of which can be used independently to initiate targeted payments, further split, merge (subject to merging conditions), or pledge. The original first digital certificate's Token ID is destroyed, but its historical record is still stored on the blockchain for auditing purposes.

[0115] The following uses credit resources as an example to illustrate the above steps in detail with specific implementation methods.

[0116] Company A needs to allocate a credit line of 1 million yuan to two project teams: Project A: Requires 600,000 yuan; Project B: Requires 400,000 yuan.

[0117] Company A selects the first digital voucher #001 through its digital wallet, clicks the "Split" function, and enters the split ratio of 60:40 (or directly enters the values ​​of 600,000 yuan or 400,000 yuan). The system automatically calculates and confirms that the total is equal to 1 million yuan.

[0118] Smart contract execution splitting operation: Generate sub-voucher #001-A, with a total limit of 600,000 yuan and an available limit of 600,000 yuan; Generate sub-voucher #001-B, with a total quota of 400,000 yuan and an available quota of 400,000 yuan; Destroy the original voucher #001.

[0119] Company A's wallet now displays two separate credit line NFTs: Credit Line NFT #001-A Total credit limit: 600,000 yuan | Available credit limit: 600,000 yuan Core Company: Company B | Funding Provider: Bank C | Validity Period: XXXX-XX-XX to XXXX-XX-XX Credit Line NFT #001-B Total credit limit: 400,000 yuan | Available credit limit: 400,000 yuan Core Company: Company B | Funding Provider: Bank C | Validity Period: XXXX-XX-XX to XXXX-XX-XX The person in charge of Project A (authorized by Company A) can independently make payments up to 600,000 yuan using #001-A, and the same applies to Project B. The two projects do not interfere with each other and are subject to the same set of risk control rules (e.g., payments can only be made to Company B). Once Project A has completed all payments, the available credit limit for #001-A becomes 0, but #001-B can still be used.

[0120] Through the above implementation, financing companies can break down large credit lines into multiple smaller, independent credit lines based on the actual needs of their internal projects, departments, or subsidiaries, thereby achieving precise control and avoiding waste of credit resources.

[0121] The split sub-quotas can be used independently. The failure or abnormality of payment in one sub-quota will not affect the normal use of other sub-quotas, thus reducing the internal fund management risk of a single financing enterprise.

[0122] The splitting process does not require re-approval from the funding party, and the financing company can operate as needed (within the preset allowable range), which improves the speed of business response.

[0123] The splitting process is recorded on the blockchain, allowing regulators to clearly see which sub-quotas the original quota was split into and how each sub-quota was subsequently used, thus preventing covert transfers.

[0124] In some possible implementations, the authorization instructions include merge instructions.

[0125] Among them, the merger instruction refers to the authorization instruction initiated by the financing enterprise (or the authorized participant) to merge multiple first digital certificates associated with the same smart enterprise financial control contract into a single master digital certificate.

[0126] Merging operations typically require that all the documents to be merged currently belong to the same financing company, are not frozen or pledged, are not expired, and have the same smart enterprise financial control contract address.

[0127] Figure 3 The diagram illustrates a specific implementation of an operation performed via a state management interface in response to a merge command, as shown below. Figure 3 As shown, steps S310 and S320 may be included.

[0128] S310. Merge multiple first digital certificates associated with the same intelligent enterprise financial management contract into a single total digital certificate. The enterprise financial resource value represented by the total digital certificate is equal to the sum of the enterprise financial resource values ​​represented by the multiple first digital certificates.

[0129] Specifically, associating with the same smart enterprise financial control contract means that the "smart contract address" field recorded in the metadata of multiple first digital vouchers is exactly the same. This address corresponds to the same smart enterprise financial control contract instance, which contains the same risk control logic and payment rules. The merging operation requires all vouchers to be merged to be associated with the same contract to ensure that the merged total voucher is still subject to the same rules, avoiding system disorder caused by rule conflicts.

[0130] The total digital voucher is a new digital voucher generated by the merge operation. The total limit of the total digital voucher is equal to the sum of the total limits of each original voucher; its current available limit is equal to the sum of the current available limits of each original voucher (Note: If a voucher has already used part of its limit, its available limit is less than the total limit, and the available limit after merging is also the sum of the available limits of each voucher).

[0131] S320, the total digital certificate inherits the control attributes of multiple first digital certificates.

[0132] The master digital voucher inherits the control attributes of each original voucher. When some attributes of each original voucher (such as validity period) are inconsistent, the system usually handles it according to the strictest rules (for example, based on the earliest expiration date).

[0133] In some possible implementations, the following verification needs to be performed after receiving the merge instruction: Is the caller the owner of all the documents to be merged? Each voucher is neither pledged, frozen, nor expired; The smartContractAddress field is identical for all vouchers; All vouchers have the same core enterprise DID (as required by business rules); The total amount after merging must not exceed the upper limit set by the system.

[0134] After verification, perform the following operations: 1. Verify ownership and status consistency 2. Create master voucher If different vouchers have different expiration dates, the system should adopt a conservative strategy, such as using the earliest expiration date as the total expiration date. Additionally, a field can be added to the metadata to record the merging history, facilitating future splitting references.

[0135] The following uses credit resources as an example to illustrate the above steps in detail with specific implementation methods.

[0136] Company A originally obtained credit lines from Company B and another related core enterprise of Company B: #001-A (600,000 yuan, valid until September 30, 2024) and #002 (400,000 yuan, valid until December 31, 2024), respectively. Company A now wishes to merge these two credit lines into a single total credit line of 1 million yuan for unified management.

[0137] Company A initiates a merger instruction, selecting #001-A and #002. Contract verification: Both belong to Company A; The smart credit management contract addresses associated with both are the same (both are the same contract deployed by Bank C). Neither of them has been frozen or expired.

[0138] After the merger, a master voucher #003 is generated, with a total limit of 1 million yuan and an available limit of 1 million yuan (assuming neither is used). The earliest expiry date is set to 2024-09-30. The original #001-A and #002 are destroyed. Company A's wallet displays a single limit NFT #003, which can be used for subsequent payments.

[0139] By merging, financing companies can consolidate multiple fragmented credit lines into a single amount, simplifying account management and payment operations, and reducing management costs. The merged total credit line can be flexibly used for any compliant payment, avoiding the awkward situation where one credit line is not fully utilized while another is insufficient due to fragmented credit lines. The merging operation is recorded on the blockchain, making it traceable and auditable, and eliminating regulatory blind spots. The merging and splitting operations form a complete two-way programmable capability, providing a foundation for more complex financial product innovations (such as credit line combinations and asset packaging).

[0140] In some possible implementations, the authorization instructions include staking instructions.

[0141] A pledge instruction is an authorization issued by a financing company to transfer its primary digital certificates as collateral to a pledge contract address approved by the funding party in exchange for liquidity support or enhanced credit. Pledge operations typically occur when a financing company needs temporary access to additional funds (such as bridge loans) but does not wish to directly utilize its corporate credit line.

[0142] Figure 4 The diagram illustrates a specific implementation of an operation performed via a state management interface in response to a staking instruction, as shown below. Figure 4 As shown, step S410 may be included.

[0143] S410. If the first digital certificate meets the preset risk control rules, transfer the ownership of the first digital certificate to the pledge contract address, and record the pledge status and pledge contract address in the control attributes of the first digital certificate.

[0144] Among these, preset risk control rules refer to a set of conditions predefined by the funding party or system to determine whether a particular digital certificate can be pledged. Typical risk control rules include: The certificate has not been frozen or pledged in any other way; The available voucher amount exceeds the set threshold; The remaining validity period of the certificate is greater than the minimum pledge period; The credit rating of the financing company meets the requirements; The pledged amount shall not exceed a certain percentage of the available credit limit (such as a pledge ratio of 80%).

[0145] A staking contract address is a blockchain address specifically used to receive pledged assets via a smart contract. This staking contract is typically deployed and controlled by the funding party and manages the freezing, release, and liquidation of the pledged assets in the event of default. Transferring ownership of the initial digital certificate to the staking contract address means that the certificate is no longer controlled by the financing company during the staking period, but is instead held in custody by the staking contract.

[0146] Recording the staking status and staking contract address can be achieved by adding two fields to the control properties: pledgeStatus (pledge status, such as "unpledged" or "pledged") and pledgeContractAddress (pledge contract address).

[0147] After a successful staking operation, the `pledgeStatus` will be set to "Staking" and the `pledgeContractAddress` will be set to the target staking contract address. This information facilitates subsequent queries and automatic execution of unstaking or liquidation.

[0148] In some possible implementations, when the non-fungible token management contract receives a staking instruction, it first calls the risk control module (which can be a separate contract or a built-in function of this contract) to perform verification: 1. The voucher has not been pledged or frozen. 2. Available credit is greater than 0 and remaining validity period is >30 days (example) 3. Other risk control rules (such as calling off-chain risk control services)... After successful verification, the contract executes the following steps: Transfer ownership of the first digital certificate from the current financing company address to the pledge contract address (call transferFrom or safeTransferFrom).

[0149] Update management attributes: Set pledgeStatus = PledgeStatus.PLEDGED, pledgeContractAddress = _pledgeContractAddr.

[0150] Trigger the CreditNFTPledged event to record information such as tokenId, staking contract address, and staking time.

[0151] It is important to emphasize that the pledging operation does not change the total amount or available credit of the certificate, only the ownership and pledge status. The financing company can still redeem the certificate through the interface provided by the pledge contract (such as applying to unpledge after repaying interest).

[0152] After the financing company repays the pledged loan, the lender calls the release function of the pledge contract, which then transfers ownership of the pledged assets back to the financing company's address. Simultaneously, the contract calls the state management interface to clear the pledged status. If the financing company defaults, the pledge contract can call the liquidation function to directly transfer or auction the financial limit represented by the pledged assets.

[0153] The following uses credit resources as an example to illustrate the above steps in detail with specific implementation methods.

[0154] Company A, having obtained a credit line of 1 million yuan, encountered a temporary cash flow need and hoped to apply for a 500,000 yuan bridge loan from Bank C by pledging this credit line. Bank C allowed pledging, but required that the pledge ratio not exceed 80% and the remaining validity period be greater than 3 months.

[0155] Company A selects the first digital voucher #001 in its wallet, clicks "Pledge," and enters the pledge amount of 500,000 yuan. The system then calls for risk control verification. The available credit limit for the certificate is 1 million yuan, which meets the pledge ratio requirement (500,000 / 1 million = 50% < 80%). The remaining validity period is 11 months, which meets the requirements; The certificate was not pledged.

[0156] After successful verification, Company A confirms the staking operation. The contract transfers ownership of #001 to the pre-deployed staking contract address 0xPledge... by Bank C, and records pledgeStatus=PLEDGED and pledgeContractAddress=0xPledge... in the credential metadata. At this point, #001 in Company A's wallet becomes "staking" and can no longer be used for payments or splits.

[0157] Bank C issued a bridge loan of 500,000 yuan to Company A based on the pledge certificate (this amount is not within the scope of this patent). After Company A repays the loan, Bank C calls the release function of the pledge contract to transfer ownership of #001 back to Company A, and the pledge status is cleared at the same time.

[0158] Through pledge instructions, financing companies are allowed to use unused corporate financial lines as collateral to obtain additional liquidity, improving capital utilization efficiency. Pre-set risk control rules and the automatic liquidation capability of the pledge contract protect the rights of the funding party in the event of default. The pledge status and pledge contract address are recorded in the certificate attributes, which can be queried by any participant, preventing double pledging or fraud. Ownership is transferred to a dedicated pledge contract, also preventing the financing company from unauthorized use or transfer of the credit line during the pledge period.

[0159] In some possible implementations, the authorization instructions include flow instructions.

[0160] In this context, the transfer instruction is an authorization instruction initiated by the financing company to transfer ownership of the first digital credential to another qualified participant (such as other suppliers in the supply chain). Unlike ordinary NFT transfers, the transfer instructions in this disclosure embodiment are subject to identity verification and whitelisting restrictions to ensure that the transfer complies with financial regulatory requirements.

[0161] Figure 5 The diagram illustrates a specific implementation of an operation performed via a state management interface in response to a flow instruction, as shown below. Figure 5 As shown, step S510 may be included.

[0162] S510. In response to the current holder and target recipient of the first digital certificate meeting the preset identity verification conditions, and the target recipient being an authorized transfer whitelist address, the ownership of the first digital certificate is transferred to the target recipient address, and the current holder address, target recipient address and transfer timestamp are recorded in the control attributes of the first digital certificate.

[0163] The preset identity verification conditions require both the current holder (transferor) and the target recipient to meet pre-defined verification criteria. These typically include: both parties having completed real-name authentication, not being on any sanctions list, and having no negative credit history. Verification can be completed using on-chain DID verification credentials or off-chain risk control services.

[0164] The authorized whitelist of addresses refers to a list of addresses pre-approved by the funding party or system administrator to receive corporate financial NFTs. The whitelist can be set based on factors such as corporate qualifications, relationship with the core enterprise, and historical transaction records. Only addresses on the whitelist can become the target recipients of the transfer, effectively preventing corporate financial funds from flowing to non-compliant third parties.

[0165] After each successful transfer operation, detailed information about the transfer should be recorded in the control attributes of the first digital voucher, including: the sender's address, the receiver's address, and the transfer timestamp. This information forms a complete chain of ownership changes, facilitating auditing and supervision. These records can be stored in an array field of the voucher metadata or in a separate event log.

[0166] In some possible implementations, after receiving the transfer instruction, the non-fungible token management contract performs the following verification: 1. Authentication: The status of the sender (msg.sender) and the receiver (to). 2. Whitelist verification: The recipient must be on the authorized whitelist. 3. Voucher status verification: Not pledged, not frozen, not expired. Once the verification passes, the transfer is executed, and the transfer history is recorded. Specifically, an array field `TransferHistory[]` is added to the `CreditNFTMetadata` structure, where each element contains `from`, `to`, and `timestamp`. To save storage, only the most recent transfer can be recorded, and the historical record can be obtained from the blockchain event log. However, for ease of on-chain querying, it is recommended to retain the most recent transfer records.

[0167] After the transfer, the ownership of the first digital credential changes, but its control attributes remain unchanged except for ownership-related fields (such as the financing company's DID, which may need to be updated). The core control rules (such as the associated smart contract address, core enterprise DID, funder DID, total amount, and validity period) remain the same. This means that when the recipient uses the credential, they can still only make payments to the designated core enterprise for the original purpose and cannot arbitrarily change the use of funds. To achieve this, the contract does not modify fields such as smartContractAddress, coreEnterpriseDID, and funderDID after the transfer; the smart enterprise financial control contract still verifies based on these fields during payment.

[0168] The following uses credit resources as an example to illustrate the above steps in detail with specific implementation methods.

[0169] Suppose that Company D, another supplier of Company B (the core enterprise), also obtained a credit line from Bank C, but the line is insufficient. Company A, having completed its project, has an unused sub-credit line of 200,000 yuan (available credit line of 200,000 yuan) on hand. With Bank C's permission and after KYC / AML verification, Company A can transfer this credit line to Company D.

[0170] Preparations before circulation: Both Company A and Company D have completed real-name authentication on the consortium blockchain and are not on the blacklist.

[0171] Bank C has added Company D's address 0xD... to its whitelist.

[0172] Flow operation: Company A selects #001-B in its digital wallet, clicks "Transfer," and enters Company D's address 0xD... System verification: Company A has passed the verification; Company D has passed the verification; The D address is in the whitelist; The certificate was not pledged or frozen.

[0173] After successful verification, the contract transfers ownership of #001-B from address A to address D. The transaction history is recorded as follows: from: address A, to: address D, timestamp: ...

[0174] After the transfer: Company D now has a credit line of 200,000 yuan (#001-B), and its digital wallet shows: Credit Line NFT #001-B Total credit limit: 200,000 yuan | Available credit limit: 200,000 yuan Core Company: Company B | Funding Provider: Bank C | Validity Period: XXXX-XX-XX to XXXX-XX-XX When Company D pays Company B for goods, the smart credit control contract will still verify rules such as "whether the core enterprise is Company B", "whether the funder is Bank C", and "whether it is within the validity period" to ensure that the credit line can only be used for the original intended purpose.

[0175] By allowing these transfers, companies with idle credit lines can transfer them to upstream suppliers in urgent need of funds, optimizing the capital allocation across the entire supply chain. The transferred credit lines remain subject to the same regulatory rules as the original lines, and the change of ownership does not increase the risk for the funding party. This provides a technological foundation for the establishment of a secondary market for corporate financial assets, and further development of credit line trading platforms can facilitate asset circulation. Each transfer is recorded immutably, allowing regulatory agencies to trace the entire path of the credit line from initial grant to final use.

[0176] Figure 6 The diagram illustrates a flowchart of one implementation method that performs an operation through a state management interface in response to the fulfillment of a preset release condition.

[0177] The preset release conditions refer to a set of logical conditions predefined in the smart enterprise financial management contract or non-fungible token management contract, used to determine whether it is currently permissible to release a portion of funds from the enterprise's financial supervision account to the financing enterprise. Typical release conditions include, but are not limited to: Repayment Trigger: The financing company prepaid part of the loan, causing the balance of funds in the supervision account to exceed the limit that should be retained (that is, the funds corresponding to the used portion of the limit have been locked, and the unused portion of the funds can be released).

[0178] Project completion: The project has passed acceptance and there is still a surplus of special corporate financial funds, which can be released to the financing company for free use.

[0179] Credit line expires: When the validity period of a company's financial credit line expires, the funds corresponding to the unused credit line can be released.

[0180] The core enterprise agrees: The core enterprise confirms that the financing enterprise has fulfilled its contractual obligations and agrees to release the surplus funds.

[0181] Release conditions can be a combination of one or more conditions (AND / OR logic), and in practice, rule engines or configurable assertion functions are typically used.

[0182] like Figure 6 As shown, steps S610, S620, S630, and S640 may be included.

[0183] S610. Determine the share of value that can be released.

[0184] The releaseable value share refers to the amount of funds that can be released, calculated based on the release conditions and the current status of the company's financial resources (such as the balance of the regulatory account, the used quota, and the quota to be reserved). The releaseable value share is usually a non-negative value, and its upper limit cannot exceed the current available quota (i.e., the unused portion) or the surplus in the regulatory account.

[0185] For example, if a financing company has used 500,000 yuan of its quota and repaid 300,000 yuan, the locked funds in the supervision account are 200,000 yuan (net amount used). The unused portion of the total quota of 1 million yuan, 500,000 yuan, and the surplus of 300,000 yuan generated from repayments can both become potential targets for release, but the specific amount to be released still needs to meet the release conditions.

[0186] S620. Based on the releasable value share, create one or more third digital certificates, the third digital certificates representing the releasable value share, and the third digital certificates adopt a different token standard than the first digital certificates.

[0187] The third-party digital certificate refers to a digital certificate created using the fungible token standard, which is completely different from the first-party digital certificate (non-fungible token) in terms of technical standards. The third-party digital certificate is used to quantitatively represent the share of value that can be released, with each unit representing a fixed amount (e.g., 1 yuan). The advantages of using fungible tokens are that they are divisible, accumulative, and easy to circulate and exchange. The number of third-party digital certificates held by a financing company directly corresponds to the amount of funds it can apply to release (usually mapped 1:1).

[0188] The third digital certificate uses a different token standard than the first digital certificate because the first digital certificate is a non-fungible token, where each certificate represents a unique corporate financial asset and is indivisible (in the general sense); while the third digital certificate is a fungible token, where each token is identical and can be divided in fractional form. The explicit "difference" emphasizes the fundamental technical difference between the two: the former is used to represent indivisible credit line identities, while the latter is used to represent quantifiable financial rights.

[0189] S630. Assign the third digital certificate to the address of the financing entity associated with the first digital certificate.

[0190] S640, in response to a redemption request for a third digital certificate, transfers the corresponding value share from a regulated state to a free state and destroys the redeemed third digital certificate.

[0191] A redemption request refers to a transaction initiated by a financing company to the system (usually a smart enterprise financial control contract or a dedicated release management contract) to convert third-party digital certificates into actual disposable funds. The redemption request requires specifying the number of third-party digital certificates to be redeemed (or specifying the number of certificates and having the system calculate the corresponding amount). After verifying the legality of the request (e.g., whether the requester holds sufficient third-party digital certificates and whether the regulatory account has sufficient funds), the system triggers an off-chain fund transfer.

[0192] Regulatory status refers to the restricted state of a company's financial funds before their release. In supply chain finance, the financial funds provided by the funding party are typically held in a special escrow account and can only be used for designated purposes (such as payments to the core enterprise) and cannot be transferred arbitrarily to the financing company's general account. This state is called regulatory status.

[0193] "Free status" refers to a state where funds, after being transferred to the general account of the financing company, are freely disposable by the company and are no longer subject to the rules governing targeted payments. The purpose of the release process is to convert a portion of surplus funds from a regulated state to a free state, serving as a reward to the financing company or as a way to recoup funds.

[0194] Destruction refers to the process of permanently removing redeemed third-party digital tokens from circulation. If tokens are not destroyed after redemption, financing companies may reuse the same tokens to apply for further releases, creating the risk of double-spending. The destruction operation is implemented by calling the `burn` function of the fungible token contract, reducing the total supply.

[0195] In some possible implementations, the release condition detection can have two triggering modes: Active trigger: The financing company initiates a release request. The contract checks whether the preset release conditions are met. If they are met, the releaseable share is calculated and tokens are minted.

[0196] Automatic triggering: The smart contract periodically checks or listens for on-chain events (such as repayment events, credit limit expiration events), and automatically executes the release process once the conditions are met.

[0197] The calculation of the share of releaseable value can be specifically as follows: obtain the actual balance corresponding to the financial limit of the enterprise in the regulatory account (through off-chain oracle or on-chain query), used limit = total limit - current available limit, minimum balance to be retained = used limit (because this part has already incurred debt).

[0198] In addition, the release limit can be calculated based on the repayment behavior of the financing company: if the financing company repays part of the loan, the balance of the supervision account remains unchanged, but the reserve limit should be reduced, thereby generating a release share.

[0199] In this disclosed embodiment, a fungible token contract needs to be deployed, for example, named ReleaseToken. This contract has the following characteristics: Symbol: RLS (Example) Minimum unit: 1 cent or 1 yuan (pegged to legal tender) Minting permissions: Only allowed to be invoked by the non-fungible token management contract (or specific authorized roles). Destruction rights: Allows users to destroy their own tokens, or authorizes the contract to destroy them upon redemption. During minting, `releaseTokenContract.mint(address to, uint256 amount)` is called, where `amount` represents the share of value that can be released (expressed in the smallest monetary unit). After minting, the corresponding number of fungible tokens will be visible in the wallet of the company that received the funding.

[0200] Once a financing company holds a third-party digital certificate, it can initiate a redemption request at any time. The redemption request can be processed by a smart enterprise financial control contract or a release management contract. The implementation logic is as follows: 1. Verify that the user possesses sufficient third-party digital credentials. 2. Check if the escrow account has sufficient funds (obtained via oracles). 3. Triggering off-chain fund transfers 4. Destroy the user's equivalent third-party digital credentials. 5. Update the escrow account record (e.g., reduce the available balance). Off-chain fund transfers can be achieved through the following methods: Oracle + Bank Interface: The contract calls the oracle to send a transfer instruction to the bank system, and the bank transfers the corresponding amount from the regulatory account to the general account of the financing company.

[0201] Multi-signature mechanism: The fund provider node and the core enterprise node jointly sign the transfer instruction and submit it to the bank for execution.

[0202] To ensure atomicity, a process of "locking the token first, then executing the transfer, and then destroying it" is usually adopted, and a rollback is performed in case of failure.

[0203] The release operation will affect the control attributes of the first digital credential: After release, the total amount of the first digital voucher should be reduced by the amount already released (because the released funds no longer belong to the company's financial resources). The current available amount should also be reduced accordingly.

[0204] Therefore, when calculating ReleaseAmount and actually casting the third digital document, it is necessary to simultaneously lock the portion of the first digital document to be released to avoid duplicate releases. A common practice is to reduce the availableAmount of the first digital document by the corresponding release amount before casting and record the releasedAmount field.

[0205] The following uses credit resources as an example to illustrate the above steps in detail with specific implementation methods.

[0206] Suppose Company A obtains a credit line of 1 million yuan, has already used 300,000 yuan to pay Company B, and has 700,000 yuan remaining. Six months later, Company A's business is performing well, and it repays 200,000 yuan of the loan ahead of schedule. At this point: Total amount: 1 million yuan Net amount used: RMB 100,000 (RMB 300,000 paid out - RMB 200,000 repaid) The balance in the escrow account is 300,000 yuan (because 1 million yuan was initially injected, and 300,000 yuan was paid to Company B, leaving 700,000 yuan in the account. However, Company A repaid 200,000 yuan, which was deposited into the escrow account, so the balance became 900,000 yuan). The remaining credit limit equals the used limit of 300,000 (because Company A still owes the bank 300,000). The amount that can be released is 900,000 - 300,000 = 600,000. This 600,000 can be released to Company A for its own use.

[0207] If the preset condition "the repayment of loans by the financing company causes the balance of the supervision account to exceed the amount that should be retained" is met, the value share that can be released is automatically calculated to be 600,000 yuan.

[0208] Minting a third digital credential: The ReleaseToken contract is invoked to mint 600,000 fungible tokens to Company A's address. Company A's wallet displays the newly added 600,000 fungible tokens.

[0209] Cashing out: Company A needs to transfer 600,000 yuan to its general account, so it initiates a cashing request in its wallet, entering 600,000 yuan. The system verifies that Company A holds 600,000 fungible tokens and calls the bank's interface to transfer 600,000 yuan from the escrow account to Company A's general account. After successful transfer, the 600,000 fungible tokens held by Company A are destroyed.

[0210] At this point, the total credit limit of the first digital voucher should be updated to 400,000 yuan (original 1,000,000 yuan - 600,000 yuan already released), and the available credit limit should also be adjusted accordingly to 100,000 yuan (original 700,000 yuan - 600,000 yuan). Thus, Company A's remaining credit limit is only 400,000 yuan, of which 100,000 yuan is available (the released credit limit is only deducted from the unused credit limit; the used credit limit remains unchanged. Therefore, after releasing 600,000 yuan, the total limit becomes 400,000 yuan, the used credit limit remains 300,000 yuan, and the available credit limit is 100,000 yuan).

[0211] By automatically detecting release conditions and minting tokens through smart contracts, the need for manual approval is eliminated, significantly improving capital recovery efficiency and reducing the capital occupation costs for financing companies. Converting the releaseable amount into fungible tokens allows financing companies to flexibly choose the timing and amount of redemption, and also enables them to transfer tokens to other companies in need of funds (if business permits), increasing liquidity. Tokens are immediately destroyed after redemption, ensuring that each token can only be used once and eliminating the risk of duplicate releases. Each release and redemption leaves an immutable record on the blockchain, allowing funding parties and regulatory agencies to verify the legality of the release and the accuracy of the amount at any time. Financing companies can view the releaseable amount in real time, apply for release with one click, and receive funds quickly, significantly improving user satisfaction and the competitiveness of supply chain finance.

[0212] In some possible implementations, monitoring information related to the first and second digital credentials is displayed through a visual interface. This monitoring information includes at least one of the following: The complete lifecycle status changes of the first digital credential from creation to destruction; The transaction relationships of each second digital certificate associated with the first digital certificate; The sequence of operations performed on the first digital voucher; The first digital certificate represents the efficiency indicator or health assessment result of the enterprise's financial resource utilization.

[0213] Among them, (1) Visual interface refers to a graphical user interface built on technologies such as Web (network), desktop application or mobile terminal, which is used to intuitively display the enterprise financial resource data stored on the blockchain in the form of charts, time series diagrams, relationship diagrams, dashboards, etc.

[0214] The visual interface can be embedded in a blockchain explorer or used as a standalone supply chain finance monitoring platform. Its core function is to transform raw data that is not visible on the blockchain (such as transaction hashes and JSON metadata) into easily understandable and analyzable visual components.

[0215] The complete lifecycle state transitions of a first digital certificate (corporate financial credit NFT) from creation to destruction refer to all the key states and state transitions it undergoes throughout its entire existence. Typical lifecycle states include: Cast: The certificate has just been created and has not yet been allocated to the financing company.

[0216] Allocated: The voucher has been transferred to the financing company's wallet and is now available.

[0217] Partial Use: The voucher has been used for at least one targeted payment, and the available credit has decreased but not reached zero.

[0218] Split: The original voucher has been split into multiple sub-vouchers, and the original voucher has been destroyed or marked as invalid.

[0219] Merged: Multiple vouchers have been merged into a single master voucher, and the original vouchers have been destroyed.

[0220] Pledged: The certificate has been pledged to the pledge agreement, and ownership has been temporarily transferred.

[0221] Transferred: Ownership of the credential has been transferred to another whitelisted address via a transfer instruction.

[0222] Released quota: A release operation has occurred, reducing the total quota and available quota.

[0223] Expired: The validity period has expired and the certificate is invalid.

[0224] Destroyed: The voucher has been completely destroyed (e.g., the credit limit has been fully used or liquidated upon expiration).

[0225] State transition diagrams, presented in the form of timelines or state machine diagrams, show the start and end times and triggering events of each state, helping risk control and auditing personnel quickly understand the complete history of a company's financial quota.

[0226] The transaction relationship graph of the various second digital certificates associated with the first digital certificate refers to a directed graph centered on the first digital certificate (parent certificate), with all its associated second digital certificates (payment certificate child NFTs) as nodes, and edges representing payment direction and amount. The transaction relationship graph can be visually represented as follows: To which recipients do the funds flow from the financing company? The amount, time, and associated contract for each payment; Are there any unusually concentrated payment recipients or unusually large payments?

[0227] The graph typically uses a force-directed or hierarchical layout, and users can click on nodes to view details.

[0228] The sequence of operations performed on the first digital voucher refers to the record of all programmable operations performed on the first digital voucher in chronological order, including: splitting, merging, pledging, transferring, and releasing. The sequence record is usually presented in the form of a Gantt chart or list, with each operation including the operation type, operation time, operation initiator, and changes in the amount before and after the operation. The sequence of operations helps analyze the behavioral patterns of financing companies; for example, frequent splitting may indicate diversified use of funds, and pledging operations may suggest temporary funding needs.

[0229] Efficiency indicators are a set of quantitative metrics used to measure how well a company utilizes its financial resources. Common examples include: Credit utilization rate = (Used credit limit / Total credit limit) × 100% Capital turnover rate = Total payments during the period / Average available credit; Average payment cycle = the average time from payment request to completion of fund transfer; Split / merge frequency = the number of splits or merges that occur per unit of time.

[0230] These indicators can help funders assess the activity and credit risk of companies seeking financing.

[0231] The health assessment result refers to a qualitative or quantitative evaluation of the overall financial health of the financing company associated with the first digital certificate, based on a pre-set risk control model and machine learning algorithm. The health assessment result is typically displayed in the form of grades (e.g., A / B / C / D), scores (0-100), or colors (green / yellow / red). Assessment factors may include: Is the credit limit utilization rate too high or too low? Are there any overdue payment records? Are there any abnormal splitting or transfer behaviors? Feedback on core enterprise evaluation; On-chain behavior anomaly detection (such as multiple staking and unstaking within a short period of time).

[0232] The health assessment results can help funders make quick decisions on whether human intervention is needed.

[0233] In some possible implementations, the visualization monitoring platform needs to efficiently retrieve data from consortium blockchain nodes. Since the blockchain's native query capabilities are relatively weak (typically only supporting queries by block number or transaction hash), an off-chain index database needs to be established. A typical architecture is as follows: Blockchain event listener: Listens for all critical events emitted by nonfungible token management contracts and smart enterprise financial governance contracts.

[0234] ETL (Extract-Transform-Load) service: Parses, cleans, and correlates event data, and writes it into a relational database or graph database (such as Neo4j) for easy subsequent complex queries.

[0235] API service layer: Provides RESTful or GraphQL interfaces for front-end visual interfaces to call.

[0236] There are generally two ways for the front-end display lifecycle state transitions: A timeline-based state diagram: This diagram retrieves all state change events for the credential from the indexed database, arranges them chronologically, uses different colored icons to represent each state, and connects them to indicate state transitions. Users can hover over the icons to view details.

[0237] State machine diagram: Predefined state nodes (circles) and transition edges (arrows), dynamically highlighting the current state and historical path based on actual events.

[0238] In some specific implementations, the front end calls the API (Application Programming Interface), and the back end queries all status change records of the credential (which can be aggregated from the event table), returning a JSON array, with each element containing fields such as state, timestamp, eventType, and changedBy.

[0239] The front end uses visualization libraries (such as ECharts, AntV G6, or D3.js) to draw timelines or state machine diagrams.

[0240] The transaction relationship graph needs to show the association between the first digital certificate and multiple second digital certificates. The data structure is a directed graph. Node types: parent voucher node, child voucher node, payee node.

[0241] Edge attributes: payment amount, payment time, status (confirmed / locked).

[0242] The backend queries the database for all second digital credential records where parentTokenId = given tokenId, and then associates them to obtain the company name corresponding to the payee's DID.

[0243] Build a graph data model, the front end calls the graph database to query the results and renders the graph, supporting node dragging, zooming, and clicking for details.

[0244] The operation sequence record is essentially a list of events for all programmable operations (split, merge, staking, transfer, release), sorted by time. Implementation is relatively simple: the backend provides an API that returns an array containing operationType, timestamp, operator, and details (such as split ratio, merged voucher list, etc.). The frontend uses tables or Gantt charts for rendering. Gantt charts can visually display the time span of different operations (such as the start and end times of staking).

[0245] Efficiency metrics need to be calculated in real time, which can be dynamically calculated after data aggregation at the API layer. The calculation results are then returned to the front end and displayed in the form of a dashboard or progress bar.

[0246] Health assessments are typically performed by an independent risk control service, with results calculated and stored periodically (e.g., daily). A visual interface directly displays the latest health level and scoring criteria (with interpretable explanations), presented in card format.

[0247] Based on and Figure 1 The method shown follows the same principle. Figure 7 This illustration shows a structural schematic diagram of an enterprise financial resource management device provided in an embodiment of the present disclosure, such as... Figure 7 As shown, the enterprise financial resource management device 70 may include: The consortium blockchain network 710 includes multiple participating nodes; The first digital certificate unit 720 is used to create and store a first digital certificate in the consortium blockchain network in response to the approval event of corporate financial resources. The first digital certificate uniquely represents a corporate financial resource and contains control attributes related to the corporate financial resource. The second digital certificate unit 730 is used to create a second digital certificate associated with the first digital certificate in response to a targeted use request initiated for corporate financial resources. The second digital certificate is used to record the payment amount specified in the targeted use request, the recipient identifier, and the associated business evidence hash. The state management interface unit 740 is used to provide a set of state management interfaces, which are used to perform state or structure change operations on the first digital credential and / or the second digital credential in response to at least one of the following triggering events: a directed use request off-chain execution completion event; or an authorization instruction; Digital wallet module 750 is used to manage the blockchain accounts of at least one participant, as well as the digital credentials held by the blockchain accounts.

[0248] In the enterprise financial resource management device provided in this disclosure embodiment, the abstract enterprise financial limit is cast into NFT digital certificates to realize standardized asset expression and intuitive user management; the programmable operation interface supports splitting, merging, pledging, and transferring to meet complex financial scenarios; each payment generates an independent sub-NFT, forming a complete fund trajectory, which is convenient for auditing and supervision; the unified state management interface ensures that all change operations are controlled and cannot be tampered with, and the automatic synchronization of off-chain events ensures data consistency.

[0249] In some possible implementations, the first digital credential is a non-fungible token; the control attributes include: the smart contract address associated with the enterprise's financial resources, the total amount of the enterprise's financial resources, the current available amount, the digital identity of the core enterprise, the digital identity of the financing enterprise, the digital identity of the funding provider, and the validity period of the enterprise's financial resources.

[0250] In some possible implementations, the second digital certificate is a payment certificate sub-nonfungible token; the second digital certificate unit is used to: generate the second digital certificate and lock it before the execution of the targeted use request; in response to the off-chain execution completion event of the targeted use request, update the state of the second digital certificate to the confirmed state through the state management interface, and record the execution serial number in the second digital certificate.

[0251] In some possible implementations, the authorization instructions include splitting instructions; the state management interface unit is used to: split the first digital certificate into multiple sub-digital certificates according to a specified ratio, the sum of the enterprise financial resource values ​​represented by the multiple sub-digital certificates is equal to the enterprise financial resource value represented by the first digital certificate; each sub-digital certificate inherits the control attributes of the first digital certificate.

[0252] In some possible implementations, the authorization instructions include merging instructions; the state management interface unit is used to: merge multiple first digital certificates associated with the same smart enterprise financial control contract into a total digital certificate, the enterprise financial resource value represented by the total digital certificate is equal to the sum of the enterprise financial resource values ​​represented by the multiple first digital certificates; the total digital certificate inherits the control attributes of the multiple first digital certificates.

[0253] In some possible implementations, the authorization instruction includes a pledge instruction; the status management interface unit is used to: transfer ownership of the first digital certificate to the pledge contract address when the first digital certificate meets the preset risk control rules, and record the pledge status and pledge contract address in the control attributes of the first digital certificate.

[0254] In some possible implementations, the authorization instruction includes a transfer instruction; the state management interface unit is used to: in response to the current holder of the first digital credential, the target recipient meeting the preset authentication conditions, and the target recipient belonging to the whitelist address for authorized transfer, transfer ownership of the first digital credential to the target recipient address, and record the current holder address, the target recipient address, and the transfer timestamp in the control attributes of the first digital credential.

[0255] In some possible implementations, the state management interface unit is used to: determine the releasable value share through the state management interface in response to the satisfaction of preset release conditions; create one or more third digital certificates based on the releasable value share, wherein the third digital certificate represents the releasable value share and adopts a different token standard than the first digital certificate; allocate the third digital certificate to the address of the financing enterprise associated with the first digital certificate; and, in response to a redemption request for the third digital certificate, transfer the corresponding value share from the regulated state to the free state and destroy the redeemed third digital certificate.

[0256] In some possible implementations, the enterprise financial resource management device also includes a visualization module for: displaying monitoring information related to the first digital certificate and the second digital certificate through a visualization interface. The monitoring information includes at least one of the following: the complete lifecycle status changes of the first digital certificate from creation to destruction; the transaction relationships of each second digital certificate associated with the first digital certificate; the timing of operations performed on the first digital certificate; and the efficiency indicators or health assessment results of the enterprise financial resources represented by the first digital certificate.

[0257] It is understood that the above-mentioned modules of the enterprise financial resource management device in this embodiment of the present disclosure have the ability to implement... Figure 1 The embodiments shown illustrate the functions of corresponding steps in the enterprise financial resource management method. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions. These modules can be software and / or hardware, and each module can be implemented individually or integrated from multiple modules. For a detailed description of the functions of each module in the aforementioned enterprise financial resource management device, please refer to [link to relevant documentation]. Figure 1 The corresponding descriptions of the enterprise financial resource management methods in the embodiments shown are not repeated here.

[0258] In the technical solution disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of user personal information comply with the provisions of relevant laws and regulations, necessary confidentiality measures have been taken, and there is no violation of public order and good morals.

[0259] In the technical solution disclosed herein, the user's authorization or consent is obtained before acquiring or collecting the user's personal information.

[0260] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0261] The electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the enterprise financial resource management method as provided in the embodiments of this disclosure.

[0262] Compared with existing technologies, this electronic device can cast abstract corporate financial limits into NFT digital certificates, realizing standardized asset expression and intuitive user management; it supports splitting, merging, pledging, and transferring through a programmable operation interface to meet complex financial scenarios; each payment generates an independent sub-NFT, forming a complete fund trajectory, which is convenient for auditing and supervision; a unified state management interface ensures that all change operations are controlled and tamper-proof, and automatic synchronization of off-chain events ensures data consistency.

[0263] The readable storage medium is a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute the enterprise financial resource management method provided in the embodiments of this disclosure.

[0264] Compared with existing technologies, this readable storage medium casts abstract corporate financial limits into NFT digital certificates, realizing standardized asset expression and intuitive user management; it supports splitting, merging, pledging, and transferring through a programmable operation interface to meet complex financial scenarios; each payment generates an independent sub-NFT, forming a complete fund trajectory, which is convenient for auditing and supervision; a unified state management interface ensures that all change operations are controlled and tamper-proof, and automatic synchronization of off-chain events ensures data consistency.

[0265] The computer program product includes a computer program that, when executed by a processor, implements the enterprise financial resource management method as provided in the embodiments of this disclosure.

[0266] Compared with existing technologies, this computer program product transforms abstract corporate financial limits into NFT digital certificates, achieving standardized asset representation and intuitive user management; it supports splitting, merging, pledging, and transferring through a programmable operation interface to meet complex financial scenarios; each payment generates an independent sub-NFT, forming a complete fund trajectory for easy auditing and supervision; a unified state management interface ensures that all changes are controlled and tamper-proof, and automatic synchronization of off-chain events ensures data consistency.

[0267] Figure 8 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0268] like Figure 8 As shown, device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage unit 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0269] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0270] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the enterprise financial resource management method. For example, in some embodiments, the enterprise financial resource management method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the enterprise financial resource management method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform the enterprise financial resource management method by any other suitable means (e.g., by means of firmware).

[0271] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0272] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0273] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0274] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0275] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0276] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0277] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0278] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A blockchain-based enterprise financial resource management method, characterized in that, The method is applied to a consortium blockchain network comprising multiple participating nodes, and the method includes: In response to the approval event of a corporate financial resource, a first digital certificate is created and stored in the consortium blockchain network. The first digital certificate uniquely represents a corporate financial resource and contains control attributes related to the corporate financial resource. In response to a targeted use request for the enterprise's financial resources, a second digital certificate is created that is associated with the first digital certificate. The second digital certificate is used to record the payment amount specified in the targeted use request, the recipient's identifier, and the associated business evidence hash. A set of state management interfaces is provided, which are used to perform state or structure change operations on the first digital credential and / or the second digital credential in response to at least one of the following triggering events: The off-chain execution completion event of the targeted use request; or the authorization instruction.

2. The method according to claim 1, characterized in that, The first digital credential is a non-fungible token; the control attributes include: the smart contract address associated with the enterprise's financial resources, the total amount of the enterprise's financial resources, the current available amount, the digital identity of the core enterprise, the digital identity of the financing enterprise, the digital identity of the fund provider, and the validity period of the enterprise's financial resources.

3. The method according to claim 1, characterized in that, The second digital certificate is a payment certificate sub-nonfungible token; The creation of a second digital certificate associated with the first digital certificate includes: The second digital credential is generated and locked before the targeted use request is executed. The method further includes: in response to the off-chain execution completion event of the directed use request, updating the status of the second digital credential to the confirmed status through the status management interface, and recording the execution sequence identifier in the second digital credential.

4. The method according to claim 1, characterized in that, The authorization instructions include splitting instructions; In response to the split instruction, perform the following operations through the state management interface: The first digital certificate is split into multiple sub-digital certificates according to a specified ratio, and the sum of the corporate financial resource values ​​represented by the multiple sub-digital certificates is equal to the corporate financial resource value represented by the first digital certificate. Each of the sub-digital certificates inherits the control attributes of the first digital certificate.

5. The method according to claim 1, characterized in that, The authorization instructions include merge instructions; In response to the merge instruction, perform the following operations through the state management interface: Multiple first digital certificates associated with the same smart enterprise financial management contract are merged into a single total digital certificate. The enterprise financial resource value represented by the total digital certificate is equal to the sum of the enterprise financial resource values ​​represented by the multiple first digital certificates. The master digital certificate inherits the control attributes of the multiple first digital certificates.

6. The method according to claim 1, characterized in that, The authorization instructions include pledge instructions; In response to the staking instruction, perform the following operations through the state management interface: If the first digital certificate meets the preset risk control rules, the ownership of the first digital certificate is transferred to the pledge contract address, and the pledge status and the pledge contract address are recorded in the control attributes of the first digital certificate.

7. The method according to claim 1, characterized in that, The authorization instructions include flow instructions; In response to the flow instruction, perform the following operations through the state management interface: In response to the fact that the current holder and the target recipient of the first digital certificate meet the preset identity verification conditions, and the target recipient belongs to the whitelist address authorized for transfer, the ownership of the first digital certificate is transferred to the target recipient address, and the current holder address, the target recipient address and the transfer timestamp are recorded in the management attribute of the first digital certificate.

8. The method according to claim 1, characterized in that, The method further includes: In response to the satisfaction of the preset release condition, the following operations are performed through the state management interface: Determine the share of value that can be released; Based on the releasable value share, one or more third digital certificates are created, the third digital certificates representing the releasable value share, and the third digital certificates adopt a different token standard than the first digital certificate; The third digital credential is assigned to the address of the financing company associated with the first digital credential; In response to a redemption request for the third digital certificate, the corresponding value share is transferred from a regulated state to a free state, and the redeemed third digital certificate is destroyed.

9. The method according to claim 1, characterized in that, The method further includes: The monitoring information related to the first digital credential and the second digital credential is displayed through a visual interface, and the monitoring information includes at least one of the following: The complete lifecycle state changes of the first digital credential from creation to destruction; The transaction relationships of each of the second digital certificates associated with the first digital certificate; The sequence of operations performed on the first digital voucher; The first digital certificate represents the efficiency index or health assessment result of the enterprise's financial resources.

10. A corporate financial resource management device, comprising: A consortium blockchain network, comprising multiple participating nodes; The first digital certificate unit is used to create and store a first digital certificate in the consortium blockchain network in response to the approval event of corporate financial resources. The first digital certificate uniquely represents a corporate financial resource and contains control attributes related to the corporate financial resource. The second digital certificate unit is used to create a second digital certificate associated with the first digital certificate in response to a targeted use request initiated for the enterprise's financial resources. The second digital certificate is used to record the payment value specified in the targeted use request, the recipient's identifier, and the associated business evidence hash. A state management interface unit is configured to provide a set of state management interfaces, wherein the state management interfaces are configured to perform state or structure change operations on the first digital credential and / or the second digital credential in response to at least one of the following triggering events: an off-chain execution completion event of the directed use request; or an authorization instruction; A digital wallet module for managing blockchain accounts of at least one participant, and the digital credentials held by said blockchain accounts.

11. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

13. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-9.

Images