A blockchain-based intelligent revenue sharing system and method

Abstract

This invention relates to the field of blockchain intelligent ledger technology, and discloses a blockchain-based intelligent ledger system and method. The system includes modules for scenario data input, behavior sequence construction, intent recognition and strategy mapping, strategy evaluation and parameterization, and strategy execution and tokenization. It constructs a ledger scenario model, extracts continuous operational behaviors of participants to generate behavior sequences; identifies potential ledger intentions from the behavior sequences through sequence pattern matching, and maps them to candidate ledger strategies; evaluates and parameterizes the candidate strategies to generate specific executable strategy instructions; and finally automatically executes the ledger and generates verifiable tokens on the blockchain. This solution can intelligently identify ledger intentions based on dynamic behavior and generate personalized ledger strategies, improving the adaptability and intelligence of ledger processing in complex business collaborations.

Description

Technical Field

[0001] This invention relates to the field of blockchain smart ledger technology, specifically to a blockchain-based smart ledger system and method. Background Technology

[0002] Currently, blockchain-based smart contract technology is widely used to automatically execute revenue sharing rules. It encodes pre-agreed fixed revenue sharing logic into contract code, automatically completing fund transfers and document storage when conditions are triggered. Typically, the complex, multi-step collaborative interaction process among participants is simply abstracted into a one-time, static transaction result processing. The system can only passively execute preset instructions and cannot perceive or respond to the continuous behaviors of participants during negotiation, performance, and other dynamic processes before a revenue sharing event occurs, nor to the underlying changes in their intentions. This makes the revenue sharing mechanism rigid and difficult to adapt to the flexible, ever-changing, and collaborative scenarios in business practice that rely on continuous contributions and dynamic evaluation.

[0003] Existing revenue-sharing schemes have shortcomings. On the one hand, they lack the ability to deeply analyze the temporal behavioral data of participants, failing to identify revenue-sharing intentions not explicitly defined in the initial contract from behavioral sequences. On the other hand, the system's strategy generation mechanism is static and singular, unable to evaluate, select the best, and adapt in real time among multiple potential revenue-sharing rules. Faced with complex revenue-sharing scenarios involving participants with different attributes and different types of transaction targets, fixed contract logic struggles to generate fair and incentive-compatible personalized revenue-sharing schemes, limiting the depth and intelligence of blockchain revenue-sharing systems in complex collaborative models such as supply chain collaboration and profit sharing. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based intelligent ledger system and method to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides a blockchain-based smart ledger system, the system comprising: The scenario data input module is used to input the initial revenue sharing transaction data and construct multiple independent revenue sharing scenario models based on the attributes of the participants, the type of transaction target, and historical interaction patterns. The behavior sequence construction module is used to parse transaction data in the revenue sharing scenario model, extract the continuous operation behavior of the participants within a preset time window, and generate a behavior sequence containing behavior type, resource changes and status markers in chronological order. The intent recognition and policy mapping module is used to receive behavior sequences, identify potential revenue sharing intents through sequence pattern matching, match the revenue sharing intents with a pre-set policy knowledge base, and map at least one candidate revenue sharing policy. The strategy evaluation and parameterization module is used to evaluate candidate revenue sharing strategies. Based on preset evaluation indicators, it generates a confidence score for each candidate revenue sharing strategy. According to the constraints of the current revenue sharing scenario model, it performs parameterization processing on the candidate revenue sharing strategy with the highest confidence score, and generates a strategy execution instruction containing specific revenue sharing ratio, triggering conditions and execution logic. The strategy execution and tokenization module is used to receive strategy execution instructions, automatically execute the revenue sharing logic when the triggering conditions are met, calculate the share that each participant should receive, and create a unique and verifiable revenue sharing certificate containing revenue sharing details on the blockchain based on the calculation results.

[0006] Preferably, the initial revenue-sharing transaction data is input, and multiple independent revenue-sharing scenario models are constructed based on the attributes of the participants, the type of transaction, and historical interaction patterns, including: Receive original transaction records from external systems or manually input; The original transaction records are formatted and cleaned to separate the participant identifier, asset type identifier, numerical amount, and time information. Based on the formatted and cleaned data, transaction records with the same participant identifier and the same type of asset identifier are aggregated to form an initial transaction data set; Based on the attributes of the participants, the identity features and relationship network features of the participants are extracted from the transaction data set; the value transfer features are extracted based on the type of transaction target; and the behavioral collaboration features are extracted based on the historical interaction patterns. By combining the identity characteristics, relationship network characteristics, value transfer characteristics, and behavioral collaboration characteristics of the participants, the spatial boundaries and core variables of a revenue sharing scenario are defined, thereby completing the construction of an independent revenue sharing scenario model. This process is repeated until the modeling of all aggregated transaction data sets is completed.

[0007] Preferably, the transaction data within the revenue-sharing scenario model is parsed, the continuous operational behaviors of the participants within a preset time window are extracted, and a behavior sequence containing behavior type, resource changes, and status markers is generated in chronological order, including: Access the built revenue sharing scenario model and obtain the timestamps and operation content of all transaction records within the model; Using a single participant identifier as an index, all relevant transaction records within a preset time window are filtered out according to the order of timestamps. Analyze each selected transaction record, categorize its operations into a predefined set of behavior types, and simultaneously record the changes in resource quantity caused by the operations. Each categorized behavior type, the corresponding change in resource quantity, and the transaction status recorded on the blockchain are taken as a basic behavior unit. Following a strict order of timestamps, multiple basic behavioral units are chained together to form a behavioral sequence that describes the complete operational process of the participating parties, from the start time to the end time.

[0008] Preferably, the system receives a sequence of behaviors, identifies potential revenue-sharing intentions through sequence pattern matching, matches these intentions against a pre-defined strategy knowledge base, and maps at least one candidate revenue-sharing strategy, including: Read the behavior sequence generated by the behavior sequence building module; The behavioral sequence is compared segment by segment with a library of common behavioral patterns stored locally or on the blockchain to identify combinations of high-frequency behavioral patterns related to revenue sharing contained in the sequence. Based on the position, repetition frequency, and associated resource changes of high-frequency behavioral patterns in the sequence, the potential revenue-sharing intentions of the participants can be inferred. The inferred revenue sharing intention is used as the query keywords, and full-text search and semantic matching are performed in the strategy knowledge base; Retrieve all strategy templates that match the revenue sharing intent description from the strategy knowledge base, and output the matching strategy templates as candidate revenue sharing strategies.

[0009] Preferably, candidate revenue-sharing strategies are evaluated, and a confidence score is generated for each candidate strategy based on preset evaluation metrics, including: Retrieve all candidate revenue-sharing strategies mapped from the strategy knowledge base; For each candidate revenue-sharing strategy, quantitative indicators are obtained from four dimensions: historical execution success rate, acceptance by participants, computational complexity, and compliance risk. The four-dimensional quantitative indicators are input into a pre-trained scoring model, and the output of the scoring model is the confidence score of the candidate revenue sharing strategy in the current scenario. Sort all candidate revenue sharing strategies and their corresponding confidence scores to generate a list of strategies with scores.

[0010] Preferably, based on the constraints of the current revenue-sharing scenario model, the candidate revenue-sharing strategy with the highest confidence score is parameterized to generate a strategy execution instruction containing specific revenue-sharing ratios, triggering conditions, and execution logic, including: Select the candidate revenue-sharing strategy with the highest confidence score from the list of strategies with scores; Read the revenue sharing scenario model that was used to construct the strategy list, and extract the total amount of the current transaction, the weight coefficient of each participant, and the constraint conditions of the minimum revenue sharing limit from the revenue sharing scenario model; The constraints of total amount, weighting coefficient, and minimum revenue sharing limit are used as input parameters and substituted into the mathematical expression of the candidate revenue sharing strategy with the highest confidence score. By calculating and solving, we can obtain the specific revenue sharing ratio that satisfies all the constraints. The specific revenue sharing ratio, the triggering events defined in the revenue sharing scenario model, and the execution logic code inherent in the candidate revenue sharing strategies are encapsulated into a fixed-format strategy execution instruction data package.

[0011] Preferably, the system receives a strategy execution instruction and automatically executes the revenue sharing logic when the triggering conditions are met, including: Continuously monitor blockchain events or external oracle inputs related to the trigger conditions defined in the policy execution instructions; When the monitored event or input exactly matches the triggering conditions defined in the policy execution instruction, the policy execution process is automatically activated; The execution logic code encapsulated in the strategy execution instruction is invoked, and the specific revenue sharing ratio value contained in the strategy execution instruction is passed to the execution logic code as a core parameter; The execution logic code runs, calculating the share of digital assets that each participant should receive based on the specific revenue sharing ratio and the total assets to be distributed.

[0012] Preferably, the share due to each participant is calculated, and based on the calculation result, a unique and verifiable ledger credential containing the ledger details is created on the blockchain, including: A special smart contract creation transaction is initiated on the blockchain, and the code logic of the smart contract is designed to be used only for storing and verifying the results of this distribution. The calculated digital asset share, blockchain address, asset identifier, strategy execution instruction hash, and timestamp of each participant are written into the smart contract to be created as initialization parameters. The smart contract is deployed to the blockchain network. After successful deployment, a unique contract address is generated on the blockchain. The contract address and its stored initialization parameters together constitute a verifiable ledger voucher. Any external party can read and verify the full details of this revenue sharing by accessing the smart contract address on the blockchain.

[0013] Preferably, the system further includes: The strategy execution backtracking and knowledge update module is used to collect feedback from each participant on the accounting result after the verifiable accounting voucher is generated, and to associate and store the feedback behavior, the accounting strategy used, and the finally generated verifiable accounting voucher. The records stored in association are compared and analyzed with the original policy templates in the policy knowledge base. If the policy execution generates new optimization parameters or resolves new constraint conflicts, the policy execution instruction and its result are added to the policy knowledge base as a new policy knowledge after being formatted, thus completing the iterative update of policy knowledge.

[0014] Preferably, the system includes all the modules and methods of the blockchain-based smart ledger system as described in any of the above.

[0015] Compared with the prior art, the beneficial effects of the present invention are: By analyzing the continuous operational behaviors of participants within a preset time window and generating a behavioral sequence that includes behavior types and resource changes in chronological order, the system can go beyond simple processing of final transaction data. Based on sequence pattern matching technology, proactive analysis of behavioral flows can identify participants' potential and dynamically evolving revenue-sharing intentions. This enables the system to respond to revenue-sharing requests that arise during the collaboration process but are not explicitly stipulated in the initial contract. It transforms the triggering and execution of revenue-sharing logic from relying on static, one-off events to relating to dynamic, continuous behavioral processes, thus achieving the perception and understanding of complex business collaboration relationships.

[0016] After identifying potential intentions, the system maps them to a strategy knowledge base, generating multiple candidate revenue-sharing strategies. Based on preset multi-dimensional evaluation indicators such as fairness and incentive compatibility, a confidence score is calculated for each candidate strategy, enabling quantitative comparison and selection of the best strategy. The system then parameterizes the optimal strategy according to the constraints of the specific revenue-sharing scenario, generating execution instructions containing specific revenue-sharing ratios and triggering conditions. This achieves dynamic generation from general strategy templates to customized solutions for specific scenarios, ensuring that the final revenue-sharing logic accurately adapts to the uniqueness of the current transaction, improving the rationality of the revenue-sharing results and the acceptance by all parties, and enhancing the system's adaptability and flexibility in handling diverse and non-linear business scenarios. Attached Figure Description

[0017] Figure 1 This is a schematic diagram illustrating the working principle of the blockchain-based intelligent ledger system described in this invention. Figure 2 A comparison chart of the revenue sharing ratios of participants before and after parameterization of the revenue sharing strategy; Figure 3 A flowchart for generating a sequence of behaviors; Figure 4 This is a flowchart of intent recognition and policy mapping; Figure 5 This is a diagram showing the result of participant behavior sequence and intent recognition. Detailed Implementation

[0018] 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.

[0019] Please see Figure 1 This invention provides a blockchain-based intelligent ledger system. The system includes: a scenario data input module that receives initial ledger transaction data, which may originate from external business systems or manual input interfaces. This module clusters and analyzes the input data based on participant attributes, transaction type, and historical interaction patterns of each party, constructing multiple ledger scenario models that are independent of each other in terms of participants, assets, and behavioral patterns. A behavior sequence construction module parses the transaction data within each ledger scenario model. From the perspective of a single participant, it extracts their continuous operational behaviors in chronological order within a preset time window. Each operation is parsed into basic units containing the behavior type, the resulting resource quantity change, and the transaction's on-chain status marker. These basic units are concatenated by timestamps to form the participant's behavior sequence. An intent recognition and strategy mapping module receives the aforementioned behavior sequences and identifies the implicit, ledger-related potential intents within the sequences by matching them with a pre-set library of common behavior patterns. This module matches the identified revenue sharing intention with a pre-generated and stored strategy knowledge base. Through querying and semantic comparison, it maps one or more candidate revenue sharing strategies that are logically consistent with the current intention.

[0020] The strategy evaluation and parameterization module quantitatively evaluates all mapped candidate revenue-sharing strategies. Based on a set of preset evaluation metrics, such as historical execution success rate and compliance risk, this module calculates a confidence score for each candidate strategy. The module selects the candidate strategy with the highest confidence score from the evaluation results and, combined with the specific constraints in the current revenue-sharing scenario model, performs mathematical solutions and parameter filling for the strategy, generating a strategy execution instruction containing a precise revenue-sharing ratio, clear triggering conditions, and executable code logic. The strategy execution and certificate generation module is responsible for the final implementation of this instruction. It continuously monitors blockchain events or external inputs. When the monitored situation perfectly matches the triggering conditions defined in the instruction, it automatically activates and calls the execution logic encapsulated in the instruction. This logic calculates the asset share that each participant should receive based on the specific revenue-sharing ratio in the instruction, and then initiates a transaction on the blockchain to create a smart contract, writing all the details of this revenue-sharing as initialization parameters for the contract. After successful deployment, its unique address on the blockchain and the data it stores together constitute an unforgeable and publicly verifiable revenue-sharing certificate.

[0021] Example 1: The scenario data input module receives raw transaction records from external systems or manual input. These records may contain unstructured text or semi-structured data. The module performs formatted cleaning on the raw transaction records. The cleaning process includes removing invalid characters, standardizing the time format, verifying the validity of numbers, and separating participant identifiers, asset type identifiers, numerical amounts, and time information from the raw records. Based on the formatted and cleaned data, the module aggregates transaction records with the same participant identifier and the same type of asset type. This aggregation operation is completed based on exact matching of identifiers or semantic similarity, forming an initial transaction data set around a specific group of participants and a specific asset class. Based on participant attributes, the module extracts participant identity features and relationship network features from the transaction data set. Identity features include role type and credit rating, and relationship network features are derived by analyzing the historical transaction frequency and amount between participants.

[0022] The system extracts value transfer characteristics based on the type of transaction, describing the asset's liquidity, valuation method, and unit of division. It also extracts behavioral collaboration characteristics based on historical interaction patterns, reflecting the cooperation or conflict patterns exhibited by participating groups in past transactions. Combining participant identity characteristics, relationship network characteristics, value transfer characteristics, and behavioral collaboration characteristics, the module defines the spatial boundaries and core variables of a revenue-sharing scenario. The spatial boundaries are defined by the set of participants and the scope of assets, while the core variables include the total amount, the weights of each party, and constraint rules, thus completing the construction of an independent revenue-sharing scenario model. The system repeats this process of data aggregation, feature extraction, and model definition until an independent revenue-sharing scenario model is constructed for all aggregated initial transaction data sets.

[0023] In practical implementation, the scenario data input module receives raw transaction records from external systems or manually input. These records can take the form of order logs from e-commerce platforms, settlement documents from payment gateways, or structured tables manually entered by business personnel. The module performs a formatting and cleaning operation on the raw transaction records. This operation includes removing redundant spaces and special characters, converting timestamps from various formats to the ISO8601 standard format, validating the numerical amount field to exclude non-numeric characters, and precisely separating the participant identifier field, asset type identifier field, numerical amount field, and time information field from the cleaned records. In some embodiments, based on the formatted and cleaned data, the module aggregates transaction records with the same participant identifier and the same type of asset type identifier. The determination of the same participant identifier is based on a complete string match or a normalized unique identification code. The determination of the same asset type identifier is based on a predefined asset classification tree. The aggregation operation forms an initial transaction data set centered on a specific combination of participants and asset categories.

[0024] In some embodiments, the scenario data input module extracts participant identity features and relationship network features from the initial transaction data set based on participant attributes. Participant identity features are obtained by querying registration information databases stored on or off-chain, while relationship network features are calculated by analyzing the historical transaction frequency and total transaction amount between each pair of participants in the initial transaction data set. The scenario data input module extracts value transfer features based on the type of transaction target, involving the asset's pricing unit, minimum divisibility precision, and price volatility parameters within a certain period. The scenario data input module extracts behavioral coordination features based on historical interaction patterns, quantifying these features by statistically analyzing the synchronicity or complementarity of the participant group's behavioral sequences in historical transactions. In specific implementations, the scenario data input module combines the extracted participant identity features, relationship network features, value transfer features, and behavioral coordination features to perform spatial boundary and core variable definition operations for the revenue sharing scenario. The spatial boundary is jointly defined by the participant identifier set and asset type identifier. Core variables include the total amount to be shared, the dynamic weight coefficients of each participant calculated based on the features, and the minimum revenue sharing limit determined by business rules. In practical implementation, after constructing an independent revenue-sharing scenario model, the system repeatedly executes the complete process from data aggregation and feature extraction to model definition until an independent revenue-sharing scenario model is constructed for all initial transaction data sets formed after formatting, cleaning, and identifier matching. It can be understood that the aggregation operation can merge related transaction records based on an aggregation function, and its mathematical expression is:

[0025] in: This represents the initial set of transaction data formed by aggregation. This represents the original record of a single transaction. It is a function that extracts the identifiers of the participants. It is a participant identifier. It is a function that extracts the asset type identifier. It is an asset type identifier. This represents the set of all formatted and cleaned transaction records.

[0026] See Figure 2 This is a bar chart comparing the proportions before and after parameterization of the revenue-sharing strategy, used to demonstrate the effect of adjusting the revenue-sharing proportions of participants in a blockchain smart revenue-sharing system. The chart compares the revenue-sharing proportions of six participants before and after parameterization, and marks the "minimum revenue-sharing limit (8%)". This chart corresponds to the "strategy parameterization" stage in the smart revenue-sharing system. Parameterization adjustment reflects the role of "revenue-sharing scenario constraints" (such as participant weights and minimum amounts); the adjusted proportions are more balanced (e.g., participant 1's proportion increases from 0.20 to 0.22, and participant 3 decreases from 0.25 to 0.23), meeting the "fairness + compliance" goals of the revenue-sharing strategy. The chart's functions include: verifying the rationality of revenue-sharing strategy parameterization, ensuring all participants meet the minimum amount requirements; visually demonstrating the changes in profit distribution before and after adjustment, assisting participants in understanding the revenue-sharing logic; and supporting subsequent strategy optimization.

[0027] Example 2: See Figure 3 The behavior sequence construction module accesses the revenue-sharing scenario model already constructed by the scenario data input module, obtaining the timestamps and operation details of all transaction records within the model. Using a single participant identifier as an index, the module filters all relevant transaction records belonging to that participant and falling within a preset time window, according to the order of the timestamps. The preset time window can be configured by the system or dynamically determined based on transaction frequency. The module analyzes each filtered transaction record, categorizing its operation content into a predefined set of behavior types, including but not limited to "funds transfer," "asset pledge," "share subscription," and "profit claim." Simultaneously, the module records the resource quantity changes caused by the operation, which are reflected as increases or decreases in the quantity of a specific asset. The module packages each categorized behavior type, the corresponding resource quantity change, and the transaction status marker on the blockchain into a basic behavior unit. The transaction status marker includes "success," "failure," or "pending confirmation." The module connects multiple basic behavioral units belonging to the same participant in strict ascending order of timestamps to form a behavioral sequence that describes the complete operation process of the participant within the selected time window, from the start time to the end time.

[0028] In practice, the behavior sequence construction module accesses the revenue-sharing scenario model already constructed by the scenario data input module. Through the application programming interface (API), the module reads all transaction records stored in the revenue-sharing scenario model. Each transaction record contains a timestamp field accurate to milliseconds and detailed data fields describing the operation. Using a single participant identifier as an index, the module filters all relevant transaction records belonging to that participant identifier and falling within a preset time window, according to the order of the timestamps. The start and end points of the preset time window can be statically configured by the system based on the business cycle or dynamically calculated based on the density of transaction records. The module analyzes each filtered transaction record, categorizing the text descriptions of the operation content fields into a predefined set of behavior types. This set includes "funds transferred," "product listing," "service confirmation," "revenue settlement," and "fee deduction." Simultaneously, the module parses and records the resource quantity changes caused by the operation content fields. These resource quantity changes are reflected as increases or decreases in the quantity of specific types of digital assets or rights. The behavior sequence construction module packages and integrates the categorized behavior type, corresponding resource quantity changes, and the transaction status marker of the transaction record on the blockchain into a basic behavior unit. The transaction status marker is the blockchain network's record of the transaction processing result, such as "success," "failure," or "pending confirmation." In some embodiments, the behavior sequence construction module concatenates multiple basic behavior units belonging to the same participant identifier in strict ascending order of timestamps, forming a behavior sequence describing the complete operation process of that participant from the start time to the end time of a preset time window. It can be understood that the generation of the basic behavior unit can be formally represented as:

[0029] in: Represents a basic behavioral unit. This represents the type of behavior categorized from the content of the operation. This represents the change in the quantity of resources caused by this operation. This represents the final state marker of the transaction on the blockchain. Optionally, the chaining process of the behavior sequence can be represented as outputting an ordered list of basic behavior units, the order of which is determined by the timestamp of the transaction record corresponding to each basic behavior unit. In some embodiments, the behavior sequence construction module independently performs the above indexing, filtering, classification, recording, and chaining operations for each participant identifier in the revenue-sharing scenario model, thereby generating an independent behavior sequence for each participant.

[0030] Example 3: See Figure 4The module compares the behavioral sequence segment by segment with a common behavioral pattern library stored locally or on-chain. This library pre-stores various high-frequency behavioral pattern combinations related to revenue sharing, such as "continuous large inflows followed by multiple small outflows." Through comparison, the module identifies high-frequency behavioral pattern combinations related to revenue sharing within the input behavioral sequence. Based on the position, repetition frequency, and associated resource changes of the identified high-frequency behavioral pattern combinations in the sequence, the module infers the potential revenue sharing intentions of the participants. These intentions may be expressed as "revenue sharing at a fixed ratio" or "dynamic revenue sharing based on contribution." The module uses the inferred revenue sharing intentions as query keywords to perform full-text search and semantic matching in a strategy knowledge base. This knowledge base stores various revenue sharing strategy templates and their applicable scenario descriptions in a structured manner. The module retrieves all strategy templates that semantically match the revenue sharing intention descriptions from the strategy knowledge base and outputs these successfully matched templates as candidate revenue sharing strategies.

[0031] The strategy evaluation and parameterization module acquires all candidate revenue-sharing strategies mapped from the strategy knowledge base. For each candidate strategy, the module obtains quantitative indicators from four dimensions: historical execution success rate, participant acceptance, computational complexity, and compliance risk. These indicators can be obtained from historical logs, survey data, performance test reports, and regulatory databases. The module inputs these four quantitative indicators into a pre-trained scoring model, which is trained on historical data. Its output is the confidence score of the candidate revenue-sharing strategy in the current specific revenue-sharing scenario. The module sorts all candidate revenue-sharing strategies and their corresponding confidence scores, generating a strategy list with scores. The module selects the candidate revenue-sharing strategy with the highest confidence score from the strategy list with scores. The module reads the revenue-sharing scenario model used to construct the strategy list and extracts the total transaction amount, the weight coefficients of each participant, and the minimum revenue-sharing limit constraints from the revenue-sharing scenario model. The module takes the total amount, weighting coefficient, and minimum revenue sharing limit as input parameters and substitutes them into the mathematical expression of the candidate revenue sharing strategy with the highest confidence score. The module calculates and solves to obtain a specific revenue sharing ratio that satisfies all constraints, accurate to each participant. The module then encapsulates the calculated revenue sharing ratio, the triggering events defined in the revenue sharing scenario model, and the inherent execution logic code of the candidate revenue sharing strategy into a fixed-format strategy execution instruction data package.

[0032] In practical implementation, the intent recognition and strategy mapping module reads the behavior sequence generated by the behavior sequence construction module. The behavior sequence consists of a series of basic behavior units ordered by timestamps. The intent recognition and strategy mapping module compares the behavior sequence segment by segment with a common behavior pattern library stored locally or on-chain. The common behavior pattern library contains high-frequency behavior pattern combinations such as "sales-settlement-withdrawal" or "purchase-payment-revenue sharing." Through comparison, the intent recognition and strategy mapping module identifies high-frequency behavior pattern combinations related to revenue sharing within the behavior sequence. The identification process uses a sliding window algorithm to match subsequences. In some embodiments, the behavior pattern combinations in the common behavior pattern library are weighted, reflecting the frequency of the pattern in historical data. The mapping module infers the potential revenue-sharing intentions of participants based on the position, repetition frequency, and associated resource changes of high-frequency behavioral patterns in the sequence. Examples of revenue-sharing intentions include "revenue sharing based on sales revenue ratio" or "revenue sharing based on a fixed amount." In some embodiments, the intent recognition and strategy mapping module uses natural language processing technology to parse the text description of the behavioral sequence to assist in intent inference. The intent recognition and strategy mapping module uses the inferred revenue-sharing intention as query keywords and performs full-text search and semantic matching in the strategy knowledge base. The strategy knowledge base indexes various revenue-sharing strategy templates and their applicable conditions. The intent recognition and strategy mapping module retrieves all strategy templates that match the revenue-sharing intention description from the strategy knowledge base and outputs the matching strategy templates as candidate revenue-sharing strategies.

[0033] In practical implementation, the strategy evaluation and parameterization module acquires all candidate revenue-sharing strategies mapped from the strategy knowledge base. For each candidate strategy, this module obtains quantitative indicators from four dimensions: historical execution success rate, participant acceptance, computational complexity, and compliance risk. Historical execution success rate is calculated based on the ratio of successful executions to total executions in historical logs. Participant acceptance is quantified by the acceptance rate of similar strategies by participants in historical transactions. Computational complexity is measured by the units of computational resources required to execute the strategy algorithm. Compliance risk is assessed based on the number of conflict points between the strategy terms and relevant laws and regulations. The module inputs these four quantitative indicators into a pre-trained scoring model. The scoring model outputs a confidence score for the candidate revenue-sharing strategy in the current scenario. The scoring model is trained using historical strategy execution data and its results. The module sorts all candidate revenue-sharing strategies and their corresponding confidence scores, generating a list of strategies with scores. The calculation of the confidence score can be formally expressed as:

[0034] in: The confidence score representing the candidate revenue-sharing strategy. Represents the weight coefficient of the i-th evaluation dimension. The quantitative indicator value represents the i-th evaluation dimension. The evaluation dimensions are, in order, historical execution success rate, participant acceptance, computational complexity, and compliance risk. The weight coefficients are predetermined through model training.

[0035] In practical implementation, the strategy evaluation and parameterization module selects the candidate revenue-sharing strategy with the highest confidence score from the strategy list with scores. The strategy evaluation and parameterization module reads the revenue-sharing scenario model on which the strategy list was constructed, and extracts the total amount of the current transaction, the weight coefficients of each participant, and the constraints of the minimum revenue-sharing limit from the revenue-sharing scenario model. The strategy evaluation and parameterization module takes the total amount, weight coefficients, and minimum revenue-sharing limit constraints as input parameters and substitutes them into the mathematical expression of the candidate revenue-sharing strategy with the highest confidence score. Through calculation and solution, the strategy evaluation and parameterization module obtains the specific revenue-sharing ratio value that satisfies all constraints. Optionally, the mathematical expression is a linear programming model, and the solution process uses the simplex method. Optionally, the strategy execution instruction data packet is serialized in JSON or Protocol Buffers format. In practical implementation, the strategy evaluation and parameterization module uses the total amount of the current transaction, the weight coefficients of each participant, and the minimum revenue sharing limit as constraints for the linear programming model. The model aims to find a specific revenue sharing ratio that satisfies all constraints. The module first sets the initial relationship of decision variables based on the weight coefficients to ensure that the revenue sharing ratio reflects the relative contribution of the participants, while constraining that the sum of the revenue sharing ratios equals the total amount and that each participant's revenue sharing amount is not lower than the minimum limit. Then, the simplex method is applied to solve the problem. By constructing an initial simplex tableau, identifying pivot columns and pivot rows, and performing pivot operations, the solution is iteratively improved until all test numbers are non-negative, thus obtaining the optimal revenue sharing ratio. The solution process ensures that the results not only comply with business rules but also optimize resource allocation. Finally, the obtained values ​​are encapsulated together with the triggering events and execution logic code.

[0036] Example 4: The strategy execution and tokenization module receives a strategy execution instruction data packet from the strategy evaluation and parameterization module. The module continuously monitors blockchain events or external oracle inputs related to the trigger conditions defined in the strategy execution instruction. Blockchain events include specific contract function calls, and external oracle inputs may include market price information. When the monitored event or input data perfectly matches the trigger conditions defined in the strategy execution instruction, the module automatically activates the strategy execution process. The module calls the execution logic code encapsulated in the strategy execution instruction data packet and passes the specific revenue sharing ratio contained in the data packet as a core parameter to the execution logic code. The execution logic code runs, calculating the digital asset share that each participant should receive based on the specific revenue sharing ratio and the total assets to be distributed. A special smart contract creation transaction is initiated on the blockchain. The code logic of this smart contract is designed only to store and verify the revenue sharing result and has no other business functions. The calculated digital asset share that each participant should receive, the participant's blockchain address, asset identifier, strategy execution instruction hash, and timestamp are written as initialization parameters into the constructor of the smart contract to be created. The smart contract is deployed to the blockchain network. Upon successful deployment, a unique contract address is generated on the blockchain. This contract address and its stored initialization parameters together constitute a verifiable transaction credential. Any external party can access the smart contract address on the blockchain to read and verify all details of this transaction, including the participants, their shares, and the basis for execution.

[0037] In practice, the strategy execution and authentication module receives strategy execution instruction data packets from the strategy evaluation and parameterization module. These packets contain structured data encapsulated with specific revenue sharing ratios, trigger event descriptions, and execution logic code. The module continuously monitors blockchain events or external oracle inputs related to the trigger conditions defined in the strategy execution instructions. Blockchain events include the confirmation of smart contract call transactions satisfying specific function signatures on the blockchain. External oracle inputs refer to signed data messages pushed to the blockchain from authorized off-chain data sources. When the monitored events or input data perfectly match the trigger conditions defined in the strategy execution instructions in both logic and value, the module automatically activates the strategy execution process. Activation is achieved by calling an internal state transition function. The module then calls the execution logic code encapsulated in the strategy execution instruction data packet and passes the specific revenue sharing ratio value contained in the packet as a core parameter to the execution logic code. This execution logic code typically exists in the form of pre-compiled smart contract bytecode or an interpretable script. The execution logic code runs, calculating the digital asset share that each participant should receive based on the specific profit-sharing ratio and the total assets to be distributed. This share calculation follows a formula:

[0038] in: This represents the share of digital assets that the k-th participant should receive. This represents the specific revenue-sharing percentage for the k-th participant specified in the strategy execution instruction data packet. This represents the total asset value currently awaiting distribution, which can be obtained from on-chain account balances or oracle inputs. The strategy execution and tokenization module initiates a special smart contract creation transaction on the blockchain. The input data of this transaction includes the initialization code and constructor parameters of the new smart contract. The strategy execution and tokenization module writes the calculated digital asset share due to each participant, the participant's blockchain address, asset identifier, strategy execution instruction hash, and timestamp as initialization parameters into the constructor of the smart contract to be created. During the initialization process, these parameters are permanently stored in the smart contract's storage space. The strategy execution and tokenization module deploys the smart contract to the blockchain network. After successful deployment, a unique contract address is generated on the blockchain. The contract address and its stored initialization parameters together constitute an immutable and publicly verifiable distribution certificate. Any external party can read and verify all details of this distribution by accessing the smart contract address on the blockchain, including participants, shares, asset types, and the basis for distribution. In some embodiments, after performing the calculation, the strategy execution and tokenization module temporarily stores the share calculation results in a structured data format to facilitate the subsequent generation of smart contract initialization parameters. Referring to Table 1, it shows the share that each participant should receive, calculated according to the strategy execution instructions, in a hypothetical digital content platform revenue sharing scenario.

[0039] Table 1: Calculation Table of Profit Sharing Share for Participating Parties Participant Roles Participant blockchain address Specific profit-sharing ratios Total assets currently pending allocation (unit: amount) Deserved share (unit: in units) Content creators 0x742d...C89A 50% 1000 500 Platform operator 0x8bF2...D3E1 30% 1000 300 Promotion partners 0xf1a5...09B4 20% 1000 200 Optionally, when monitoring triggering conditions, the strategy execution and tokenization module subscribes to event logs issued by blockchain nodes using an event listening mechanism. Optionally, the generated verifiable ledger voucher smart contract may include a verification function that allows external input of transaction hashes to verify whether an on-chain transfer is consistent with the ledger result described in this voucher. In some embodiments, when the calculation involves multiple assets, the strategy execution and tokenization module independently performs share calculations for each asset and generates corresponding ledger vouchers.

[0040] Example 5: The strategy execution backtracking and knowledge update module begins operation after the verifiable ledger voucher is generated. The module collects feedback from each participant regarding the ledger result. Feedback includes, but is not limited to, on-chain confirmation signatures of the ledger voucher, subsequent operations on associated assets, or satisfaction ratings reported via an oracle. The module associates and stores the collected feedback, the strategy execution instructions used in this ledger split, and the final generated verifiable ledger voucher, forming a complete strategy application record. The module compares and analyzes the associated strategy application record with the original strategy template in the strategy knowledge base, focusing on parameter differences and execution results. If the strategy execution generates a new combination of optimized parameters under specific constraints, or successfully resolves constraint conflicts not covered by the original strategy template, the strategy execution instruction and its application result are treated as new strategy knowledge. This new strategy knowledge is formatted and added to the strategy knowledge base, thus completing the iterative update of the strategy knowledge base.

[0041] In practice, the strategy execution backtracking and knowledge update module begins operating after the verifiable ledger voucher is generated. This module collects feedback from each participant regarding the ledger results by monitoring blockchain event logs or querying off-chain databases. This feedback includes confirmation transactions initiated by participants on the blockchain for the verifiable ledger voucher smart contract, transfers or staking operations performed by participants on the assets obtained from the ledger, and quantitative scoring data on the ledger results reported by the trusted oracle service. The strategy execution backtracking and knowledge update module then associates and stores the collected feedback, the strategy execution instruction data packet that triggered this ledger distribution, and the contract address of the verifiable ledger voucher generated on the blockchain. This association storage operation creates a timestamped strategy application record in either the on-chain or off-chain database.

[0042] In practical implementation, the strategy execution backtracking and knowledge update module reads strategy application records from storage and compares them with existing strategy templates in the strategy knowledge base. This comparison includes comparing the specific revenue sharing ratio in the strategy execution instruction data packet with the preset parameter range of the corresponding template in the strategy knowledge base, as well as comparing the participant satisfaction expressed in feedback behavior with the expected acceptance level recorded in the strategy knowledge base. In some embodiments, the comparison analysis process calculates the degree of difference between the new strategy application record and existing strategy templates in the knowledge base on key parameters. This degree of difference calculation may involve distance measurements in a multi-dimensional parameter space. If the comparison analysis results indicate that the current strategy execution generated a new combination of optimized parameters under specific constraints, or successfully resolved constraint conflicts not covered by the original strategy template, the strategy execution backtracking and knowledge update module identifies the strategy execution instruction data packet and its corresponding strategy application record together as a new strategy knowledge entry.

[0043] The strategy execution backtracking and knowledge update module formats new strategy knowledge entries according to the format required by the strategy knowledge base. Formatting includes extracting the core logic, parameter constraints, and associated feedback data from the strategy execution instructions. The formatted new strategy knowledge entries are then added to the strategy knowledge base. This addition can be done by adding a new record to the index of the strategy knowledge base, thus completing the iterative update of the strategy knowledge base. It can be understood that the knowledge update decision can be based on a quantitative judgment condition: when the difference between the new strategy application record and the most similar old strategy template in the knowledge base exceeds a predetermined threshold, an update operation is triggered. This condition can be formally expressed as:

[0044] in: Represents a measure of heterosexuality. The first item in the new strategy knowledge entry The normalized key parameter values The first corresponding old strategy template in the strategy knowledge base The normalized key parameter values This represents the total number of key parameters involved in the comparison. This represents a preset update threshold. Optionally, the strategy knowledge base update operation is completed in a separate on-chain transaction to ensure the immutability and traceability of the update process. Optionally, the collection of feedback behavior can be set within a time window, collecting only relevant behaviors within a specific time period after the generation of verifiable ledger vouchers. In some embodiments, the strategy execution backtracking and knowledge update module periodically clusters and summarizes all newly added strategy knowledge entries to merge similar strategy variants and extract more general strategy templates.

[0045] See Figure 5 This is a scatter plot showing the relationship between participant behavior sequence length and revenue sharing intent type in an intelligent revenue sharing system. It illustrates the correlation between participant behavior characteristics and revenue sharing intent. This chart corresponds to the "intent recognition and strategy mapping" stage in the intelligent revenue sharing system. The behavior sequence length reflects the activity level of participant operations; the differences in the distribution of intent types can assist in the targeted matching of subsequent revenue sharing strategies. The functions of this type of chart include: quickly identifying participant groups with different revenue sharing intents, supporting the accuracy of strategy recommendations; analyzing the correlation between behavioral activity and revenue sharing intent; and assisting in optimizing the intent recognition model.

[0046] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0047] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based intelligent ledger system, characterized in that, The system includes: The scenario data input module is used to input the initial revenue sharing transaction data and construct multiple independent revenue sharing scenario models based on the attributes of the participants, the type of transaction target, and historical interaction patterns. The behavior sequence construction module is used to parse transaction data in the revenue sharing scenario model, extract the continuous operation behavior of the participants within a preset time window, and generate a behavior sequence containing behavior type, resource changes and status markers in chronological order. The intent recognition and policy mapping module is used to receive behavior sequences, identify potential revenue sharing intents through sequence pattern matching, match the revenue sharing intents with a pre-set policy knowledge base, and map at least one candidate revenue sharing policy. The strategy evaluation and parameterization module is used to evaluate candidate revenue sharing strategies. Based on preset evaluation indicators, it generates a confidence score for each candidate revenue sharing strategy. According to the constraints of the current revenue sharing scenario model, it performs parameterization processing on the candidate revenue sharing strategy with the highest confidence score, and generates a strategy execution instruction containing specific revenue sharing ratio, triggering conditions and execution logic. The strategy execution and tokenization module is used to receive strategy execution instructions, automatically execute the revenue sharing logic when the triggering conditions are met, calculate the share that each participant should receive, and create a unique and verifiable revenue sharing certificate containing revenue sharing details on the blockchain based on the calculation results.

2. The blockchain-based intelligent ledger system according to claim 1, characterized in that, Input the initial revenue-sharing transaction data, and construct multiple independent revenue-sharing scenario models based on participant attributes, transaction type, and historical interaction patterns, including: Receive original transaction records from external systems or manually input; The original transaction records are formatted and cleaned to separate the participant identifier, asset type identifier, numerical amount, and time information. Based on the formatted and cleaned data, transaction records with the same participant identifier and the same type of asset identifier are aggregated to form an initial transaction data set; Based on the attributes of the participants, the identity features and relationship network features of the participants are extracted from the transaction data set; the value transfer features are extracted based on the type of transaction target; and the behavioral collaboration features are extracted based on the historical interaction patterns. By combining the identity characteristics, relationship network characteristics, value transfer characteristics, and behavioral collaboration characteristics of the participants, the spatial boundaries and core variables of a revenue sharing scenario are defined, thereby completing the construction of an independent revenue sharing scenario model. This process is repeated until the modeling of all aggregated transaction data sets is completed.

3. The blockchain-based intelligent ledger system according to claim 1, characterized in that, The transaction data within the revenue-sharing scenario model is analyzed to extract the continuous operational behaviors of the participants within a preset time window. A behavior sequence containing behavior type, resource changes, and status markers is then generated in chronological order, including: Access the built revenue sharing scenario model and obtain the timestamps and operation content of all transaction records within the model; Using a single participant identifier as an index, all relevant transaction records within a preset time window are filtered out according to the order of timestamps. Analyze each selected transaction record, categorize its operations into a predefined set of behavior types, and simultaneously record the changes in resource quantity caused by the operations. Each categorized behavior type, the corresponding change in resource quantity, and the transaction status recorded on the blockchain are taken as a basic behavior unit. Following a strict order of timestamps, multiple basic behavioral units are chained together to form a behavioral sequence that describes the complete operational process of the participating parties, from the start time to the end time.

4. The blockchain-based intelligent ledger system according to claim 1, characterized in that, The system receives behavioral sequences, identifies potential revenue-sharing intentions through sequence pattern matching, matches these intentions against a pre-defined strategy knowledge base, and maps at least one candidate revenue-sharing strategy, including: Read the behavior sequence generated by the behavior sequence building module; The behavioral sequence is compared segment by segment with a library of common behavioral patterns stored locally or on the blockchain to identify combinations of high-frequency behavioral patterns related to revenue sharing contained in the sequence. Based on the position, repetition frequency, and associated resource changes of high-frequency behavioral patterns in the sequence, the potential revenue-sharing intentions of the participants can be inferred. The inferred revenue sharing intention is used as the query keywords, and full-text search and semantic matching are performed in the strategy knowledge base; Retrieve all strategy templates that match the revenue sharing intent description from the strategy knowledge base, and output the matching strategy templates as candidate revenue sharing strategies.

5. The blockchain-based intelligent ledger system according to claim 1, characterized in that, The candidate revenue-sharing strategies are evaluated, and a confidence score is generated for each candidate strategy based on preset evaluation metrics, including: Retrieve all candidate revenue-sharing strategies mapped from the strategy knowledge base; For each candidate revenue-sharing strategy, quantitative indicators are obtained from four dimensions: historical execution success rate, acceptance by participants, computational complexity, and compliance risk. The four-dimensional quantitative indicators are input into a pre-trained scoring model, and the output of the scoring model is the confidence score of the candidate revenue sharing strategy in the current scenario. Sort all candidate revenue sharing strategies and their corresponding confidence scores to generate a list of strategies with scores.

6. The blockchain-based intelligent ledger system according to claim 5, characterized in that, Based on the constraints of the current revenue-sharing scenario model, the candidate revenue-sharing strategy with the highest confidence score is parameterized to generate a strategy execution instruction containing specific revenue-sharing ratios, triggering conditions, and execution logic, including: Select the candidate revenue-sharing strategy with the highest confidence score from the list of strategies with scores; Read the revenue sharing scenario model that was used to construct the strategy list, and extract the total amount of the current transaction, the weight coefficient of each participant, and the constraint conditions of the minimum revenue sharing limit from the revenue sharing scenario model; The constraints of total amount, weighting coefficient, and minimum revenue sharing limit are used as input parameters and substituted into the mathematical expression of the candidate revenue sharing strategy with the highest confidence score. By calculating and solving, we can obtain the specific revenue sharing ratio that satisfies all the constraints. The specific revenue sharing ratio, the triggering events defined in the revenue sharing scenario model, and the execution logic code inherent in the candidate revenue sharing strategies are encapsulated into a fixed-format strategy execution instruction data package.

7. The blockchain-based intelligent ledger system according to claim 1, characterized in that, Receive policy execution instructions and automatically execute revenue sharing logic when trigger conditions are met, including: Continuously monitor blockchain events or external oracle inputs related to the trigger conditions defined in the policy execution instructions; When the monitored event or input exactly matches the triggering conditions defined in the policy execution instruction, the policy execution process is automatically activated; The execution logic code encapsulated in the strategy execution instruction is invoked, and the specific revenue sharing ratio value contained in the strategy execution instruction is passed to the execution logic code as a core parameter; The execution logic code runs, calculating the share of digital assets that each participant should receive based on the specific revenue sharing ratio and the total assets to be distributed.

8. The blockchain-based intelligent ledger system according to claim 7, characterized in that, Calculate the share due to each participant, and based on the calculation results, create a unique, verifiable ledger credential containing the ledger details on the blockchain, including: A special smart contract creation transaction is initiated on the blockchain, and the code logic of the smart contract is designed to be used only for storing and verifying the results of this distribution. The calculated digital asset share, blockchain address, asset identifier, strategy execution instruction hash, and timestamp of each participant are written into the smart contract to be created as initialization parameters. The smart contract is deployed to the blockchain network. After successful deployment, a unique contract address is generated on the blockchain. The contract address and its stored initialization parameters together constitute a verifiable ledger voucher. Any external party can read and verify the full details of this revenue sharing by accessing the smart contract address on the blockchain.

9. The blockchain-based intelligent ledger system according to claim 1, characterized in that, Also includes: The strategy execution backtracking and knowledge update module is used to collect feedback from each participant on the accounting result after the verifiable accounting voucher is generated, and to associate and store the feedback behavior, the accounting strategy used, and the finally generated verifiable accounting voucher. The records stored in association are compared and analyzed with the original policy templates in the policy knowledge base. If the policy execution generates new optimization parameters or resolves new constraint conflicts, the policy execution instruction and its result are added to the policy knowledge base as a new policy knowledge after being formatted, thus completing the iterative update of policy knowledge.

10. A blockchain-based smart ledger sharing method, characterized in that, It includes all modules and method processes of the blockchain-based smart ledger system described in any one of claims 1 to 9.

Images