Blockchain-based financial equity post-investment management system

Abstract

This invention discloses a blockchain-based post-investment management system for financial equity, relating to the fields of blockchain and financial management technology. The system includes a governance token generation module, a proposal initiation module, a privacy voting module, a liquidation execution module, and a regulatory endorsement module. The governance token generation module issues governance tokens mapping to equity shares on a consortium blockchain; the proposal initiation module creates governance proposals and triggers atomic locking operations; the privacy voting module receives zero-knowledge proofs submitted by shareholders, verifies their control over the tokens, updates the token status to "voted," and accumulates weights; the liquidation execution module updates the token status to "expired" or "valid" at the voting deadline, and determines the proposal's passage based on a comparison of the accumulated weights with a threshold; the regulatory endorsement module receives and associates the signature of the root hash from regulatory nodes. This invention achieves on-chain lifecycle management of voting rights through a governance token state machine, improving the opaque voting process and the difficulty in verifying results in post-investment governance.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and financial management technology, and more specifically, to a blockchain-based financial equity post-investment management system. Background Technology

[0002] In the field of financial equity investment, post-investment management involves core governance aspects such as shareholder voting, decision-making on major matters, and equity distribution. Traditional post-investment management relies on offline meetings, email voting, or centralized system notarization, which suffers from problems such as lack of transparency, difficulty in tracing the voting process, and vulnerability to tampering with results. Shareholder voting rights, as the most core governance right in equity, are often not uniquely locked in practice, potentially leading to duplicate voting and the separation of voting rights from ownership due to equity transfers during the voting period. Furthermore, existing technologies struggle to protect shareholder privacy while ensuring the public verifiability of voting results, and regulatory agencies lack effective means to endorse the authenticity of voting results.

[0003] Chinese patent CN118014594A discloses a supply chain finance management method based on the Internet of Things (IoT) and blockchain. This method involves regulatory authorities confirming product information and storing it in the blockchain, while using IoT devices to collect real-time product information, thus solving the problem of information opacity in the supply chain. Chinese patent CN110782350A discloses a blockchain-based enterprise financing risk control method. This method enables financing for non-Tier 1 suppliers by using endorsement records from core enterprises and verification of the rationality of financing requests by financial institutions. The aforementioned existing technologies primarily focus on debt financing management in the supply chain finance field, and none address the governance issues of shareholder voting rights in post-investment equity management, particularly failing to solve technical problems such as status management, privacy protection, and result verification during the exercise of voting rights. Therefore, a blockchain-based post-investment management system for financial equity is proposed to address the above issues. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a blockchain-based financial equity post-investment management system, which aims to solve the problems of opaque voting rights exercise and difficulty in verifying voting results in the post-investment management process of the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A blockchain-based financial equity post-investment management system includes a governance token generation module, a proposal initiation module, a privacy voting module, a liquidation execution module, and a regulatory endorsement module. Among them: The governance token generation module is used to issue a unique governance token for each shareholder on the consortium blockchain based on the investment agreement and business registration information. This governance token is an indivisible, non-fungible token, and its metadata includes shareholder address, share type, and voting weight coefficient. and state variables The state variable Initially in a valid state .

[0006] By mapping equity stakes to on-chain tokens with programmable state variables, a foundation is laid for the dynamic management of voting rights in subsequent governance processes. Specifically, each token represents an equity stake, and its state variables... This records the current lifecycle stage of the token and its voting weight coefficient. This quantifies the weight of the token in voting, thereby achieving on-chain binding and refined management of equity and voting rights.

[0007] The proposal initiation module is used to respond to the request from the proposal initiator and create a proposal ID on the consortium blockchain. and through threshold The governance proposal triggers a smart contract to execute a locking operation, which is an atomic operation that sets the governance token status of all shareholders. From valid state All are converted to frozen state and each frozen state Governance tokens and current proposal IDs Binding.

[0008] By freezing voting rights at the current shareholding status, this prevents the separation of voting rights from ownership caused by share transfers during the voting period. When the locking operation is executed, the smart contract iterates through all states... The tokens are updated one by one to their respective states. The current proposal ID is written to the data; if any update fails, the entire operation is rolled back to ensure the consistency of all token states and the integrity of the lock.

[0009] The privacy voting module is used to receive zero-knowledge proofs submitted by shareholder clients. ,verify To confirm that the shareholder owns the frozen shares And bound to the current proposal ID The smart contract controls the governance token, and that token has not yet been voted on. Upon successful verification, the smart contract will update the status of the corresponding governance token. From frozen state Atomically update to the voted state And based on the voting weight coefficient in the token metadata. The voting weights are added to the corresponding options in the proposal to obtain the cumulative weight for agreement. and opposing cumulative weight .

[0010] By employing a zero-knowledge proof mechanism, the privacy of shareholder identity and voting options is protected while ensuring the unique exercise of voting rights. Specifically, the zero-knowledge proof circuit verifies three conditions: the shareholder holds the private key corresponding to the token (proving control), and the on-chain token state is... It also binds the current proposal (proving it is in a voting state) and the token has not yet been voted on (preventing duplicate voting), without revealing the specific identity of the shareholder and their voting choice.

[0011] The liquidation execution module is used by the smart contract to automatically perform liquidation operations when the voting deadline arrives: liquidating all entities that have already voted. The status of governance tokens Updated to expired status and all those still in a frozen state The status of governance tokens Restored to valid state ;according to , and threshold Determine if the approval vote ratio meets the passing requirement, and generate a voting proof tree containing all final state changes of all tokens. Then, hash the root of the proof tree. Recorded on the consortium blockchain; The sum of the weights of governance tokens that participated in the vote and did not abstain. By using a voting proof tree to solidify the voting results onto the blockchain, any third party can verify the integrity of the results by reconstructing the Merkle tree.

[0012] The liquidation module first processes each token one by one according to the list of tokens locked in the proposal: for tokens that have been voted on, they are marked as invalid, indicating that their voting rights have been used; for abstention tokens that are still frozen, they are restored to a valid state so that they can participate in subsequent voting. Then, the cumulative weight is compared with a threshold to determine whether the proposal passes, and the final state of all tokens (token ID, voting option, weight, timestamp) is constructed into a Merkle tree, with the root hash stored on the blockchain.

[0013] The regulatory endorsement module is used to receive the root hash from the regulatory node. signature and will The root hash serves as a regulatory endorsement certificate, linked to the proposal results. The signature of the root hash by the regulatory node provides authoritative endorsement for the voting results, enhancing their legal validity. As a trusted third party in the consortium blockchain, the regulatory node uses its private key to verify the root hash. Perform ECDSA signing and generate a signature. The signature is linked to the proposal result, and anyone can verify the validity of the signature through the public key of the regulatory node, thereby confirming that the voting result has not been tampered with and has been approved by the regulator.

[0014] Furthermore, the metadata of the governance token also includes historical change records from Merkelgen. Status of the governance token at each stage When a change is made, the smart contract appends the change record (including the change timestamp, the state before and after the change, and the operation proposal ID) to the token's unique historical Merkle tree and updates it. .

[0015] By recording every state change through a historical Merkle tree, any historical state can be traced and verified, meeting audit compliance requirements. Specifically, during a query, the authenticity of a historical record can be quickly verified by providing the Merkle path.

[0016] Furthermore, the locking operation is executed atomically in batches by the smart contract: for each governance token, if its current state... Valid state Then Updated to frozen state And write the current proposal ID. At the same time, the token is prohibited from being transferred or pledged during the freeze period; If any token state transition fails, the entire locking operation is rolled back. Atomicity guarantees ensure consistent state transitions for all tokens, avoiding inconsistencies in voting rights caused by partial locking. This mechanism leverages the transactional nature of smart contracts, checking the lockability of each token in a loop and triggering a rollback in case of any exception, thus ensuring the integrity of the lock.

[0017] Furthermore, in the privacy voting module, the zero-knowledge proof generated by the shareholder client... Based on a zero-knowledge concise non-interactive knowledge argumentation circuit, the circuit verifies: the submitter has control over the private key of a specific governance token, and the current state of that token. Frozen status And the bound proposal ID Consistent with the current proposal, the token has not yet been voted on.

[0018] The circuit simultaneously verifies identity, status, and non-voting conditions to ensure the validity and uniqueness of the vote. The circuit design employs techniques such as bilinear pairing, requiring only the public input of the proposal ID and the proof itself during verification, without exposing private information such as the token ID, private key, and voting options, thus achieving trusted verification while protecting privacy.

[0019] Furthermore, the voting proof tree generated by the liquidation execution module is a Merkle tree, whose leaf nodes are the final state data of each governance token in this proposal. The final state data includes the token ID and voting options. Voting weight coefficient and status change timestamp ; The root hash After being recorded on the consortium blockchain, the supervising node uses the private key pair Sign and generate regulatory endorsement certificate. .

[0020] By organizing the final state of the tokens into a Merkle tree, the voting results can be compressibly verified, while the regulatory signature solidifies the authoritative confirmation of the results.

[0021] When constructing a Merkle tree, all tokens are first sorted by ID, then the leaf hashes are calculated sequentially and merged upwards layer by layer to obtain a unique root hash. Any modification to the leaf data will cause the root hash to change, thus ensuring the immutability of the result.

[0022] Furthermore, the system also includes a state rollback module, which automatically reverts all frozen states in the smart contract when a proposal is cancelled or terminated early. The status of governance tokens Restored to valid state and clear its associated proposal ID. The state rollback mechanism promptly releases locked voting rights when a proposal is abnormally terminated, restoring token liquidity and preventing tokens from remaining frozen for extended periods due to proposal cancellation, which would otherwise disrupt normal trading.

[0023] Furthermore, the status of the governance token Including valid status Frozen state Voting status and expired status Among them, the effective state The governance token can be used for voting and transfer, and is in a frozen state. The governance token can only participate in the voting of the current proposal, and is already in the voting status. The governance token has completed voting and is now in an expired state. The voting rights of the governance token have been used and cannot be used to vote on any subsequent proposals. A complete closed loop for the lifecycle management of voting rights is formed through four-state transformations. Each state corresponds to clear permissions and behavioral constraints, ensuring the standardization and traceability of the voting process.

[0024] Furthermore, the proposal initiation module is also used to encode the governance rules in the company's articles of association or investment agreement into executable logic in a smart contract when creating a governance proposal. These governance rules include the voting weight threshold required for the proposal to pass. The rule of veto power for specific shareholders.

[0025] By transforming legal texts into automatically executable on-chain code, governance rules are proceduralized, reducing human intervention and subjective judgment, and improving governance efficiency. For example, regarding veto rights, during liquidation, the voting options of designated shareholders need to be checked additionally; if they vote against, the resolution is directly deemed invalid.

[0026] Furthermore, the nodes of the consortium blockchain include investment institution clients, invested company clients, regulatory agency clients, and custodian bank clients. Among them, the regulatory agency client, acting as a regulatory node, has the ability to use the regulatory node's private key to hash the root hash of the proposal result. The authority to endorse.

[0027] Through a consortium blockchain architecture with multi-party participation, a mutually trusting post-investment governance environment is built. Each node jointly maintains the blockchain ledger to ensure the transparency and immutability of the data, while the endorsement of regulatory nodes provides legal credibility to the results.

[0028] Furthermore, in the privacy voting module, the smart contract uses zero-knowledge proofs submitted by the shareholder client. The implicit token identifier is read from the voting weight coefficient in the token's metadata. and will Cumulative weight added to the corresponding option or .

[0029] By associating weights with token identifiers parsed from zero-knowledge proofs, accurate weight accumulation is achieved while protecting privacy. Specifically, the proof... The public output contains the token ID and voting options. The contract uses this information to obtain the token's weight and update the corresponding counter, thereby achieving automatic counting of voting rights.

[0030] The technical effects and advantages of this invention are as follows: This invention maps equity shares to on-chain governance tokens with programmable state variables through a governance token generation module. Each token corresponds to one share, and its state can be dynamically changed. When a proposal is initiated, the smart contract performs an atomic locking operation to change the state of all tokens from valid to frozen and binds the tokens to the current proposal. This fixes voting rights at the current shareholding status, preventing equity transfers during the voting period from causing a disconnect between voting rights and ownership. This mechanism helps ensure the uniqueness and stability of voting rights, providing a reliable foundation for the subsequent voting process.

[0031] This invention receives zero-knowledge proofs submitted by shareholder clients through a privacy voting module. While verifying the shareholder's control over the token and that the token is in a voting-eligible state but has not yet been voted on, it does not disclose the shareholder's identity or voting options. The zero-knowledge proof circuit verifies conditions such as signature validity and on-chain state consistency. Upon successful verification, the smart contract updates the token state to "voted" and adds weight. This mechanism helps protect shareholder voting privacy, avoids game theory problems caused by the exposure of voting intentions, and ensures that each voting right is accurately recorded, preventing duplicate voting.

[0032] This invention automatically updates token status at the voting deadline through a liquidation execution module, updating voted tokens to expired and abstaining tokens to valid. It also determines the passage of a proposal based on a comparison of cumulative weight with a preset threshold. Simultaneously, a voting proof tree is constructed, organizing all token final state data into a Merkle tree and storing the root hash on the blockchain. This mechanism facilitates automated liquidation and verifiability of voting results. Any third party can verify the integrity of the results by reconstructing the Merkle tree, ensuring the voting process is open and transparent and the results are tamper-proof. The regulatory endorsement module receives and associates the signature of the root hash from regulatory nodes, providing authoritative endorsement for the voting results and further enhancing their legal validity. Attached Figure Description

[0033] Figure 1 This is a system module framework diagram of the present invention; Figure 2 This is a flowchart illustrating the locking operation of the present invention; Figure 3 This is a flowchart illustrating the implementation process of privacy voting in this invention; Figure 4 This is a flowchart illustrating the implementation process of the liquidation and proof tree generation of this invention; Figure 5 This is a flowchart illustrating the regulatory endorsement implementation process of the present invention; Figure 6 This is a flowchart illustrating the exception handling implementation of the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] Example 1 As attached Figures 1 to 6This embodiment illustrates a blockchain-based post-investment management system for financial equity. In this case, the system is deployed within a consortium blockchain network comprised of multiple participants. The consortium blockchain is built on the FISCOBCOS platform, and its nodes include client-side clients from investment institutions, portfolio companies, regulatory agencies, and custodian banks. Each node collaboratively maintains the blockchain ledger and ensures data consistency through the PBFT consensus mechanism. The consortium blockchain's access control mechanism ensures that only authorized institutions can join, and transaction confirmation time is kept within 2 seconds, meeting the real-time requirements of post-investment management.

[0036] The specific implementation of the system's core data structure design is as follows: In this system, the core data object is the governance token. The governance token follows the ERC721 standard and is an indivisible, non-fungible token. Each token uniquely corresponds to one equity share, realizing the on-chain mapping of equity assets.

[0037] The metadata for the governance token includes the following fields: Shareholder address, 20 bytes, identifies the token holder and corresponds to the shareholder's identity in the business registration.

[0038] ty: Equity type, 1 byte, 0 represents common stock, 1 represents preferred stock, used to distinguish the differences in voting rights between different equity types.

[0039] : Voting weight coefficient, uint8 type, with a value range of 0 to 255, representing the weight of this token in shareholder voting.

[0040] : State variable, enumeration type, value (efficient), (freeze), (Voted) (Expired) is used to identify the lifecycle stage of a token in the current governance process.

[0041] : Proposal ID at the time of locking, 32 bytes, only It is valid for a period of time and records the current proposal to freeze the token.

[0042] vr: Voting records; the structure contains the proposal ID. and voting options ,in The value 0 represents dissent, 1 represents agreement, and 2 represents abstention. Only when... It is valid for a period of time and is used to trace shareholder voting behavior.

[0043] : Historical change record Merkle root, 32 bytes, used for quick verification of token historical status and supports subsequent audit queries.

[0044] Each time the governance token's state changes, the smart contract appends this change record as a leaf node to the token's dedicated historical Merkle tree and updates it. The change log includes the change timestamp. (Unix second-level timestamp), state before change Status after change Operation Proposal ID .

[0045] The historical Merkle tree uses the SHA-256 hash algorithm, and its height grows dynamically. Any historical state can be verified using Merkle proofs. Each time a record is appended, the contract calculates the hash value of the new leaf node and reconstructs the tree structure using it and the existing leaf nodes, ultimately obtaining the new root hash. .

[0046] The specific implementation of the system's core business processes is as follows: The process for this system to process a complete shareholder voting proposal is as follows.

[0047] Step 1: Initialize the governance token The system receives investment agreements and business registration information as input. The investment agreement clearly specifies the shareholding ratio, share type, and corresponding voting weight coefficient of each shareholder. The business registration information is verified and signed by the regulatory node, generating a digital signature that is attached to the registration information and written into the blockchain as the legal basis for token issuance.

[0048] Shareholder identity authentication is completed through a CA: Each shareholder generates a public-private key pair when accessing the system for the first time. The private key sk is securely stored by the client, and the public key pk is signed by the CA to generate a digital certificate. The certificate and signature are uploaded to the blockchain for record-keeping, and all subsequent on-chain operations must be signed using the private key sk.

[0049] The governance token generation module issues governance tokens based on the above information. The issuance granularity can be configured according to the company's articles of association, with one governance token issued for every 0.1% of equity, achieving fine-grained splitting of equity shares.

[0050] The issuance algorithm is as follows: For each shareholder, the number of tokens they should receive is calculated based on their shareholding ratio. Based on a total supply of 1000 tokens, they will be generated sequentially. Each token is assigned a unique global identifier (id). (Metadata) Set as shareholder address, ty and It is set according to the type of equity. Initialize to , And VR is empty. Initialize it as a 32-byte array of all zeros, which is the root hash of an empty tree.

[0051] After all tokens are generated, an issuance transaction is constructed, and after consensus is reached on the consortium blockchain, it is written to the blockchain. The state of each token is stored in the on-chain global state tree. The output of this step is the total governance tokens deployed on the chain. Each token has a unique ID and complete metadata, and its current state can be queried by its ID.

[0052] Step 2: Proposal Initiation and Voting Rights Lock-in The invested company's client, acting as the proposal initiator, constructs a governance proposal transaction and submits it to the consortium blockchain. The data structure of the proposal transaction is as follows: : Proposal ID, generated by the initiating client based on timestamp and random number, in the format of the first 32 bytes of SHA-256 hash value, ensuring global uniqueness.

[0053] tp: Proposal type, an enumeration value, such as 0x01 indicating amendment of the bylaws, 0x02 indicating a major asset sale, used to map preset governance rules.

[0054] : Proposal description text, UTF-8 encoded, no longer than 1024 bytes.

[0055] op: A list of voting options, for example, [0, 1] represents two options: disagree and agree, and each option corresponds to an integer identifier.

[0056] ts: Voting start timestamp, Unix second-level timestamp, accurate to the second.

[0057] te: Voting deadline timestamp, Unix second-level timestamp, requirements .

[0058] The threshold, an integer from 0 to 100, represents the percentage of votes required to be in favor. For example... The percentage of votes indicating agreement must be ≥67%.

[0059] After a proposal transaction reaches consensus, the smart contract verifies the initiator's permissions. If the verification is successful, a proposal object is created and stored in the on-chain proposal table. The initial status of the proposal is "voting," and the global counter for the proposal is initialized simultaneously. , .

[0060] To facilitate quick retrieval of tokens associated with proposals, the contract maintains an index mapping: for each proposal ID... This records a list of all locked token IDs. During a locking operation, the ID of each locked token is appended to the list. A list of keys.

[0061] Subsequently, the contract automatically executes the locking operation. The specific implementation of the locking operation is as follows: the contract iterates through all governance tokens in the global state tree, and for each state... The token performs the following atomic operations: Check if the current status is If not, a rollback will be triggered. Will Updated to ; Will Set to the current proposal ID ; Construction change record Calculate its hash value and append it to the token's historical Merkle tree to obtain a new... ; Write the updated token metadata back to the state tree; Add the token ID to the proposal The list of locked token indexes.

[0062] If any token update fails during the traversal, the entire transaction is rolled back, and the proposal creation fails. After the locking operation is completed, all tokens are in the same state. ,and All point to .

[0063] During the lock-up period, the token's transferFrom function was modified to check the token's identity before execution. Is it If This will directly roll back the operation, thus prohibiting any transfer or staking operations. The output of this step is the state of all tokens that are currently frozen on-chain, as well as the status of the proposal. The associated locking relationship.

[0064] Step 3: Shareholder Privacy Voting After voting begins, each shareholder's client executes their vote based on the tokens they hold. This system uses zk-SNARKs to implement privacy voting, as detailed below: The shareholder client first retrieves a list of all token IDs it holds locally, and then filters them out. and The token. For each token ID to be voted on, the client executes: 1. Determine the voting options 0 against, 1 in favor, 2 abstentions.

[0065] 2. Use the private key sk corresponding to the token to send the message. The signature is performed to obtain the signature sig. The signature algorithm used is ECDSA, where... This indicates byte concatenation.

[0066] 3. Constructing zk-SNARKs circuit input: Public input: Current proposal ID .

[0067] Private inputs: Token ID (id), Private key (sk), Voting options Signature: sig.

[0068] 4. The circuit internally verifies three conditions using elliptic curve pairing operations: Signature verification: PK is derived from SK, which proves that SK does indeed control the token; State verification: Query the current state of the token ID on the blockchain. Is it and Is it equal to ; Unvoted Verification: Check if the voting record (VR) for the token ID is empty when querying on-chain.

[0069] 5. Zero-knowledge proof of circuit output The length is 288 bytes, and the format is R1CS, which is the hexadecimal string after serialization.

[0070] The client will The transaction parameters are submitted to the `vote` function of the smart contract. The contract receives them. Then, the pre-deployed verification contract is invoked. The contract has a built-in circuit verification key, which is verified through bilinear pairing. The effectiveness.

[0071] After successful verification, the contract executes atomic operations: from Parse the token ID and voting options from the public input. The public inputs of zk-SNARKs can contain limited public information; here, id and As part of the public input; Read the metadata of the token ID from the state tree and examine it. Is it and Is it equal to And whether VR is empty; If satisfied, Updated to ; set up ; Construction change record Added to the historical Merkel tree, updated. ; according to The value of the global counter for the proposal is updated: if but ,like but ,like but and All remain unchanged; Write the updated token metadata back to the state tree.

[0072] This process is executed atomically, ensuring the unique exercise of voting rights. and This is stored as a global state variable within the proposal object and persisted immediately after each vote update. This process is repeated until all shareholders have completed their votes or the voting deadline te is reached.

[0073] Step 4: Voting Deadline and Liquidation Execution The system triggers the liquidation execution module at time te using a timer or event listener mechanism. The liquidation module performs the following operations: First, using the proposal A list of locked token indices allows for quick traversal of all tokens. The token. For each token: Read its current state : like Then Updated to Clear Set to null and construct a change record. Update history Merkelgen Write back to the state tree; like If the shareholder abstains, then... Restore to Clear Construct change records ,renew Write back to the state tree.

[0074] like If the value is otherwise specified, ignore it.

[0075] After the traversal is complete, read from the proposal object , and threshold Calculate the total voting weight Determining whether a proposal passes: Use integer comparison; if... If the proposal passes, it is approved; otherwise, it fails.

[0076] Integer comparisons avoid floating-point precision issues, ensuring the determinism of the decision result. The decision result is written to the "Result" field of the proposal object, and an execution credential is generated, containing the proposal ID. Judgment results, pass rate The timestamp, after being signed by a smart contract, serves as on-chain evidence.

[0077] Next, the clearing module generates a voting proof tree. The specific construction algorithm is as follows: Initialize an empty list `leaves`; Iterate through all again For each token, obtain its final state data: token ID, voting options. Voting weight coefficient Status change timestamp ,in Take the timestamp of this settlement; To ensure the uniqueness of the Merkle tree construction result, the tokens are sorted in ascending order by ID; Convert id to a 16-byte binary array Convert a 32-character hexadecimal string to 16 bytes. Convert to an 8-byte big-endian binary array ; Construct leaf node input A total of 16 + 1 + 1 + 8 = 26 bytes; Calculate leaf hash ; Will Add to the leaves list; Construct a Merkle tree for the list of leaves: If the number of leaves is odd, copy the last leaf to make it even; concatenate adjacent leaves pairwise and calculate their SHA-256 hash to obtain the parent node; repeat this process until a unique root hash is obtained. .

[0078] Will Write the "Proof Tree Root" field to the proposal object. The final output of this step is: token final state, proposal decision result, and root hash. Execution credentials; all data is stored on the blockchain.

[0079] Step 5: Regulatory endorsement The monitoring node captures newly completed proposals in real time by listening to on-chain events. When a proposal is detected... After the liquidation process is completed, the regulatory node client executes: Read proposals from the blockchain root hash ; Use the supervisor node's private key right ECDSA signatures are performed using the secp256k1 curve to calculate the signature. ,in and The signature component is 32 bytes. The recovery identifier is 1 byte; the signature algorithm follows the standard ECDSA, i.e. , ,in It is a random number. Based on, For order; Constructing signature data 65 bytes in total; Call the smart contract's `endorseProposal` function to... Passed as a parameter, the contract will Write the "Regulatory Endorsement" field to the proposal recipient.

[0080] When any third party verifies the voting results, the following actions may be taken: Obtain proposals from the blockchain Final state data for all tokens; Reconstruct the Merkle tree according to the rules described in step 4, and calculate the root hash H'. Reading proposals from on-chain Compare H' with Are they equal? Read regulatory endorsements on-chain Use the public key of the regulatory node Verify signature: Whether it is true or false, i.e., calculation , ,verify of coordinates equal to ; If both pass, the result is confirmed to be true and valid.

[0081] Historical lookup queries can be performed by querying the historical Merkel tree using the token ID: the client requests the complete historical change record of the token ID from the node, the node returns all leaf node data, and the client can verify the Merkel path and the current Merkel tree itself. Consistency.

[0082] The specific implementation of the exception handling process is as follows: Proposal Cancellation: If the proposal initiator calls the `cancelProposal` function during the voting period, the contract verifies the initiator's permissions and iterates through all proposals. and The token, its Restore to Clear Update the voting history; voted The status token remains unchanged, but the proposal status is marked as "cancelled," and its voting results are no longer effective.

[0083] Share transfer during voting: due to The token is prohibited from being transferred in transferFrom; any transfer transaction will fail to ensure that voting rights are tied to equity.

[0084] Lock failure rollback: The atomicity of the locking operation is guaranteed by the smart contract's transaction mechanism: if an exception is detected during the loop, revert is executed immediately, and all modified states are rolled back to the state before locking.

[0085] The specific implementation of governance rule coding is as follows: The governance rules in the company's bylaws are pre-coded into a mapping table within the smart contract. The rule ID is the first 4 bytes of the SHA-256 hash of the proposal type name string. The mapping table structure is as follows: Each time a proposal is created, a tp is specified, and the smart contract automatically reads the corresponding tp. And during liquidation, a special rule function is invoked. For example... At that time, after calculating the pass rate, the clearing module calls the checkFounderVeto function, which iterates through all... For tokens that belong to the list of founding shareholder addresses, check if any token has a voting option. If any such result is found, "fail" will be returned directly, overriding the pass rate calculation result.

[0086] Through the above steps, this system, based on the governance token state machine design, transforms equity voting rights from static certificates into on-chain assets with dynamic lifecycles, realizing atomic locking of voting rights, privacy voting, automatic liquidation, and regulatory endorsement. It effectively solves the technical problems of opaque governance processes and difficulty in verifying voting results in post-investment management.

[0087] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based post-investment management system for financial equity, characterized in that, include: The governance token generation module is used to issue a unique governance token for each shareholder on the consortium blockchain based on the investment agreement and business registration information. This governance token is an indivisible, non-fungible token, and its metadata includes shareholder address, share type, and voting weight coefficient. and state variables The state variable Initially in a valid state ; The proposal initiation module is used to respond to the request from the proposal initiator and create a proposal ID on the consortium blockchain. and through threshold The governance proposal triggers a smart contract to execute a locking operation; the locking operation is an atomic operation that sets the governance token status of all shareholders. From valid state All are converted to frozen state and each frozen state Governance tokens and current proposal IDs Binding; The privacy voting module is used to receive zero-knowledge proofs submitted by shareholder clients. ,verify To confirm that the shareholder owns the frozen shares And bound to the current proposal ID The smart contract will verify the control of the governance token, provided that the token has not yet been voted on; once verified, the smart contract will update the status of the corresponding governance token. From frozen state Atomically update to the voted state And based on the voting weight coefficient in the token metadata. The voting weights are added to the corresponding options in the proposal to obtain the cumulative weight for agreement. and opposing cumulative weight ; The liquidation execution module is used by the smart contract to automatically perform liquidation operations when voting closes: liquidating all voted entities. The status of governance tokens Updated to expired status and all those still in a frozen state The status of governance tokens Restored to valid state ;according to , and threshold Determine if the approval vote ratio meets the passing requirement, and generate a voting proof tree containing all final state changes of all tokens. Then, hash the root of the proof tree. Recorded on the consortium blockchain; The sum of the weights of governance tokens that participated in the vote and did not abstain. ; The regulatory endorsement module is used to receive the root hash from the regulatory node. signature and will It serves as regulatory endorsement and is stored in conjunction with the proposal results.

2. The blockchain-based post-investment management system for financial equity as described in claim 1, characterized in that, The metadata for the governance token also includes historical change records (Merkel). ; Status of each governance token When a change is made, the smart contract appends the change record to the token's historical Merkle tree and updates the Merkle root of the historical change record. .

3. The blockchain-based post-investment management system for financial equity as described in claim 1, characterized in that, The locking operation is executed atomically in batches by the smart contract: for each governance token, if its current state... Valid state Then Updated to frozen state And write the current proposal ID. At the same time, the token is prohibited from being transferred or pledged during the freeze period; if the state transition of any token fails, the entire locking operation will be rolled back.

4. The blockchain-based post-investment management system for financial equity as described in claim 1, characterized in that, In the privacy voting module, the zero-knowledge proof generated by the shareholder client... Based on a zero-knowledge concise non-interactive knowledge argumentation circuit, the circuit verifies: the submitter has control over the private key of a specific governance token, and the current state of that token. Frozen status And the bound proposal ID Consistent with the current proposal, the token has not yet been voted on.

5. The blockchain-based post-investment management system for financial equity as described in claim 1, characterized in that, The voting proof tree generated by the liquidation execution module is a Merkle tree, whose leaf nodes are the final state data of each governance token in this proposal. The final state data includes the token ID and voting options. Voting weight coefficient and status change timestamp The root hash After being recorded on the consortium blockchain, the supervising node uses the private key pair Sign and generate regulatory endorsement certificate. .

6. The blockchain-based post-investment management system for financial equity as described in claim 1, characterized in that, It also includes a state rollback module, which automatically reverts all frozen states in the smart contract when a proposal is cancelled or terminated early. The status of governance tokens Restored to valid state and clear its associated proposal ID. .

7. The blockchain-based post-investment management system for financial equity as described in claim 1, characterized in that, The status of the governance token Including valid status Frozen state Voting status and expired status ; valid state The governance token can be used for voting and transfer, and is in a frozen state. The governance token can only participate in the voting of the current proposal, and is already in the voting status. The governance token has completed voting and is now in an expired state. The governance token voting rights have been used and cannot be used to vote on any subsequent proposals.

8. The blockchain-based post-investment management system for financial equity as described in claim 1, characterized in that, The proposal initiation module is also used to encode the governance rules in the company's articles of association or investment agreement into executable logic in a smart contract when creating a governance proposal. These governance rules include the voting weight threshold required for the proposal to pass. The rule of veto power for specific shareholders.

9. The blockchain-based post-investment management system for financial equity as described in claim 1, characterized in that, The nodes of the consortium blockchain include investment institution clients, invested company clients, regulatory agency clients, and custodian bank clients; among them, the regulatory agency client, as a regulatory node, has the ability to use the regulatory node's private key to hash the root hash of the proposal result. The authority to endorse.

10. The blockchain-based post-investment management system for financial equity as described in claim 4, characterized in that, In the privacy voting module, the smart contract uses zero-knowledge proofs submitted by the shareholder client. The implicit token identifier is read from the voting weight coefficient in the token's metadata. and will Cumulative weight added to the corresponding option or .

Images