A blockchain-based bulk commodity transaction system

Abstract

The present application relates to the field of information technology, and proposes a bulk commodity transaction system based on a blockchain, comprising: a parameter and release module that uniformly receives and stores parameters; a uniform approval engine that is isomorphically arranged and gray-scale updated by a configurable template + state machine; a consistency snapshot and recovery that collects snapshots and plays back monotonically in the case of suspension / abnormality, ensuring consistent ordering and windows; a margin risk control that uses DSL + fund DAG to drive freezing / thawing / deduction and reconciliation; blockchain storage and audit execution field-level hash and lineage anchoring to achieve verifiable traceability. The system builds an end-to-end consistency and verifiability framework around "field-level fingerprinting - uniform approval - windowed stable ordering - consistent snapshot and monotonic playback - fund event graphing - contract assembly and signature anchoring - settlement / settlement re-calculation - lineage chaining and offline verification", so that each link maintains consistent caliber, stable ordering and state verifiable and traceable under the conditions of abnormality, recovery and version evolution.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a blockchain-based commodity trading system. Background Technology

[0002] Online commodity trading involves multiple stages and cross-institutional collaborative processes, including trade posting, bidding / matching, contract signing, settlement / reconciliation, and margin management. Existing platforms mostly adopt a loosely coupled "multi-module / multi-system" architecture: front-end posting and parameter configuration, approval workflows, matching engines, payment / custodian interfaces, electronic signatures, pricing, and verification are handled by different services, connected via messaging or APIs. While this heterogeneous, distributed implementation facilitates evolution, it exposes a series of consistency and verifiability issues under high concurrency and stringent regulatory scenarios.

[0003] First, there is inconsistency in data definitions and versions across modules. Transaction parameters often change in fields, definitions, and units as business evolves. Existing systems typically only manage versions within their respective databases, lacking a unified fingerprint and comparable mechanism for "field-value-version". When approval, matching, and settlement read parameters from different versions, it is easy to generate discrepancies in calculation definitions, leading to post-event disputes, and it is difficult to quickly locate the source of the discrepancy technically.

[0004] Secondly, windowed matching suffers from insufficient replayability and sorting stability. Many matching implementations rely on processing time for rapid data entry, lacking hard constraints on "event time" and "window boundaries." They also lack consistent snapshots and monotonic replay mechanisms that ensure "ranking and window length remain unchanged before and after resumption" after pauses / resumptions. In the event of a malfunction or replay, issues such as ranking drift and changes in transaction order often occur, making it difficult to provide verifiable technical explanations to participants.

[0005] Third, the side effects of margin deposits are untraceable and reconciliation is not closed-loop. Existing practices mostly use process engines to drive freezing / deduction / unfreezing, but the causal relationship modeling between financial events such as "registration - transaction / winning bid - default - settlement" is crude. It lacks deduplication and out-of-order control based on idempotent keys, and also lacks verification and discrepancy tracking based on the financial event graph. When there are inconsistencies with reconciliation with third-party payment or custody systems, it often has to rely on manual investigation and log playback, resulting in an incomplete chain of evidence.

[0006] Fourth, the granularity of evidence storage is too coarse, making it difficult to form a verifiable chain of evidence across modules. Some platforms have introduced blockchain for "file hashing on-chain" or "summary registration," but due to the lack of field-level hashing and a commitment structure that aggregates in an orderly manner by field name, it is impossible to independently verify on the chain "which set of fields and their values ​​correspond to a certain settlement / contract / approval result"; the causal path between modules (approval → contract → settlement → deposit → snapshot) lacks a unified spectrum, making it difficult for external entities to verify at low cost.

[0007] Fifth, the impact of approval workflow and template upgrades is extensive, and the rollback boundaries are unclear. Approval templates and state machines are implemented heterogeneously in different business processes, and version switching often requires downtime. Gray-scale testing and circuit breaker thresholds are missing or inconsistent. Once an upgrade fails, it is difficult to accurately roll back to a "verifiable stable state," causing the process to freeze halfway or be executed repeatedly.

[0008] Sixth, differences in contract signing formats lead to drift in signature anchor points and difficulties in offline verification. After template or format changes, keyword positioning and coordinates are prone to shift, resulting in insufficient robustness of signature positioning; at the same time, external contracts, settlement documents, etc., lack machine-readable carriers containing block height and Merkel path, making third-party offline verification costly and prone to errors.

[0009] Seventh, the pricing and settlement of external indices suffers from weak version management and a lack of auditable closed loop for recalculations. The management of index IDs, versions, and applicable ranges is fragmented, and local recalculations caused by changes in historical ranges are difficult to form a closed loop of "difference traceability → verifiable evidence → traceable results," which brings uncertainty to risk control and auditing.

[0010] In summary, the core contradiction faced by existing technologies lies in the lack of a systematic mechanism that can simultaneously guarantee "cross-module consistency, deterministic replayability of sorting and windowing, and end-to-end verifiable auditability" in an environment involving multiple systems, heterogeneous microservices, and external institutions (signature / payment / custody / index) across the entire business chain. Once there is a pause / resumption, version change, or fluctuation in external dependencies, problems such as ranking changes, inconsistent amount calculations, duplicate side effects of funds, or inability to independently verify evidence will occur. Summary of the Invention

[0011] To overcome the aforementioned technical deficiencies, the present invention aims to provide a blockchain-based commodity trading system. This system constructs an end-to-end consistency and verifiability framework around a continuous path of "field-level fingerprinting—unified approval and isomorphic arrangement—windowed stable sorting—consistent snapshots and monotonic replay—funds event graphing—contract assembly and signature anchoring—settlement / reconciliation recalculation—on-chain genealogy and offline verification." This ensures that each stage of the transaction maintains consistent data standards, stable sorting, and verifiable and traceable fund and document status even under abnormal, paused, and recovery conditions, as well as version evolution.

[0012] This invention discloses a blockchain-based commodity trading system, comprising: The parameters and publishing module is used to receive and store transaction parameters; The unified approval engine module, based on configurable process templates and state machines, performs isomorphic orchestration and flow verification for three types of business: transaction release, contract signing, and deposit refund, and supports version updates and canary releases without downtime. The Consistent Snapshot and Recovery module is used to take snapshots when transactions are paused, closed, or abnormally interrupted, and replay them in a monotonic time sequence after recovery to maintain sorting stability and consistency of time windows; The margin risk control module, based on domain-specific language and directed graphs of funding events, freezes, unfreezes, or deducts funds triggered by registration, transaction / winning, default, and settlement events, and performs online and offline reconciliation consistency verification. The blockchain evidence storage and auditing module is used to aggregate multi-source summaries of approvals, contracts, settlements / remittances, margin deposits and snapshots in an orderly manner by field name through field-level hashing to form pattern version fingerprints and mapping commitments, and to construct the root hash of the event genealogy graph, and anchor the root hash to the block header of the consortium blockchain to achieve verifiable traceability.

[0013] Preferably, the unified approval engine module includes: a process template management unit, a state machine execution unit, a compensation and rollback unit, and a versioning and grayscale unit; wherein: The process template management unit is used to create and maintain approval templates in a configurable manner. Each approval template includes at least node type, routing conditions, form validation rules, and a list of atomic operations. It also performs semantic validation and permission binding on the approval template, generates a template version identifier, and provides the validated executable template to the state machine execution unit. The state machine execution unit generates a state transition table based on the executable template and drives the execution of atomic nodes; The compensation and rollback unit is used to perform compensation or rollback when at least one of the following conditions occurs: The state machine execution unit's call to an atomic node returns an error code or throws an exception; Cross-module call exceeded the timeout threshold; Duplicate submissions or out-of-order replays are detected based on idempotent keys; Consistency checks at transaction boundaries failed, including inconsistencies in critical field validations; External dependencies are unavailable or health checks have failed. Versioning and canary units detected an error rate exceeding the error rate threshold or a rollback rate exceeding the rollback rate threshold during canary releases; The blockchain evidence storage and auditing module returned an evidence storage failure or verification failure. The system state is then rolled back to the most recently successfully committed verifiable stable state, which is determined by the persistent checkpoint of the state machine execution unit and the corresponding digest recorded by the blockchain notarization and auditing module. Versioning and canary units release template versions atomically without downtime, and implement canary activation according to tenant, organization or transaction type. At the same time, health monitoring is performed on the error rate, latency and rollback rate of canary instances, and they are controlled by error rate threshold, latency threshold and rollback rate threshold respectively.

[0014] Preferably, the system further includes a transaction processing module: configuring time window boundaries and a stable sorting comparator, wherein the parameters of the stable sorting comparator include price, event timestamp and sequence number; outputting a transaction / winning event when the time window boundary is reached and synchronously generating a sorting snapshot identifier, and passing the sorting snapshot identifier to the consistency snapshot and recovery module.

[0015] Preferably, the snapshot metadata recorded by the consistency snapshot and recovery module includes at least: the quote queue, the parameters of the stable sorting comparator, the time window boundaries, the participant session state, and the timer state. During recovery, the consistency snapshot and recovery module freezes the time window and monotonically replays it according to the event timestamp to ensure that the ranking before and after recovery remains unchanged and that the time window is not enlarged or shortened.

[0016] Preferably, the system also includes a contract assembly and electronic signature module: parsing the contract template placeholders and writing the winning bid data according to the field-format mapping; performing structural difference mapping on the historical versions of the template to achieve forward compatibility; determining the signature anchor point in the PDF or equivalent format by combining keyword positioning and coordinate correction, and correcting the offset through affine correction or anchor word neighborhood matching when the format or page breaks change, wherein the correction result of the signature anchor point is used to improve the robustness of signature positioning.

[0017] Preferably, the system also includes a settlement and reconciliation module: generating daily settlement statements based on the quantity of goods received, transportation losses, and test indicators, and performing outlier removal based on the anomaly detection quantile threshold or equivalent robust criterion; using a family of price adjustment functions including at least one of linear, piecewise, and quantile functions to perform linked price adjustments on test indicators and acceptance thresholds; performing a final reconciliation of multi-day settlement results based on the reconciliation base, triggering partial recalculation and difference recording when the reconciliation base or test re-inspection changes, and incorporating the difference recording into the blockchain evidence storage and auditing module.

[0018] Preferably, the settlement and reconciliation module introduces the external price index as an exogenous factor into the price adjustment function family, and writes the version identifier and applicable range of the external price index into the blockchain storage and audit module; when the version identifier or applicable range of the external price index changes, a partial recalculation is triggered and the recalculation result is recorded on the blockchain.

[0019] Preferably, the margin risk control module includes: a domain-specific language interpreter for parsing and hot-updating the margin strategy and executing it within a secure sandbox; a directed graph construction unit for fund events for modeling registration, transaction / winning, default, and settlement as edges with action labels to drive freezing, unfreezing, and deduction operations; and a reconciliation and alarm unit for connecting with third-party payment or custody systems to perform online and offline reconciliation consistency verification, and generating difference alarms and automatic reconciliation tasks when the reconciliation difference threshold is triggered.

[0020] Preferably, the blockchain notarization and auditing module generates pattern version fingerprints and mapping commitments by orderly aggregating the field-level hashes of standardized transaction data according to field names, and constructs an event genealogy diagram for events such as approval, contract, settlement / reconciliation, margin and snapshot, wherein the root hash of the event genealogy diagram is anchored to the block header of the consortium blockchain through a Merkle tree to achieve consistency verification and traceability across versions and modules.

[0021] Preferably, the blockchain evidence storage and auditing module is also used to generate machine-readable codes containing document hashes, timestamps, block heights, and Merkel paths for margin refund vouchers, settlement statements, and contract copies; when offline or online verification of the machine-readable codes fails, the system blocks the corresponding business flow and writes an alarm to the blockchain evidence storage and auditing module.

[0022] Compared with existing technologies, the above technical solution has the following advantages: 1. Unified and verifiable data across modules. In existing technologies, each module manages its own fields and versions, lacking a unified fingerprint. Approval / matching / settlement often involves reading parameters from different versions, making it difficult to compare sources. In this invention, the parameter and publishing modules calculate summaries for standardized fields and aggregate them in an orderly manner according to field names to form a schema version fingerprint (SchemaID) and mapping commitment. This is transmitted with the publishing event and submitted to the blockchain evidence storage and auditing module, ensuring that each module always operates around the same version baseline. Any object (parameters, contracts, settlements, etc.) can be verified at the field level, eliminating data drift and disputes, and improving the efficiency of evidence collection and location.

[0023] 2. Determinism and Replayability of Sorting and Windowing. In existing technologies, matching depends on processing time and thread sequence. After a fault is recovered, the ranking is prone to change, and the window may be stretched / shortened, making it difficult to reproduce the results. In this invention, the transaction processing module performs unified clearing at the time window boundary and uses a stable sorting comparator (price, event timestamp, sequence number). The consistency snapshot and recovery module collects snapshots at the window boundary and performs "window freezing + monotonic replay" during recovery, ensuring that the ranking and window length remain unchanged before and after recovery. The results are replayable and interpretable, meeting the requirements of supervision and dispute review.

[0024] 3. Isomorphic Approval Process Orchestration and Rollback Capability. In existing technologies, different business processes each have their own approval system. Upgrades require system downtime, and rollback boundaries are unclear after anomalies, easily leading to incomplete processes and repetitive side effects. In this invention, a unified approval engine module uses a template IR-driven state machine to isomorphically orchestrate three types of business processes: transaction publishing, contract signing, and deposit refund. The compensation and rollback units roll back to a verifiable stable state based on a clear trigger set (error / timeout / out-of-order / consistency failure / external dependency anomaly / grayscale indicator exceeding threshold / proof failure). Versioning and grayscale units support non-stop grayscale and circuit breaking, making approvals unified, upgrades secure, anomalies locatable and rollbackable, avoiding repetitive side effects and long downtime.

[0025] 4. Unified Ledger and Fair Allocation Across Multiple Systems. In existing technologies, listing, British / Dutch / sealed bills are implemented separately, resulting in high maintenance costs and unstable allocation when prices are equal. In this invention, a homogeneous ledger of "price table + ordered queue" is used to support multiple systems through a transaction processing module. Unified batch clearing is performed at the end of the window, and equal prices are strictly separated according to queue order and minimum transaction unit. This allows a single system to cover multiple systems, with stable, fair, and easy-to-maintain sorting and allocation.

[0026] 5. Programmable Margin Risk and Closed-Loop Reconciliation. In existing technologies, margin rules are scattered throughout process code, making it difficult to control duplicates / omissions; discrepancies with payment / custody reconciliation lack systematic verification. In this invention, the margin risk control module expresses rules in a domain-specific language (DSL), and maps registration, transaction / winning, default, and settlement into a directed graph (DAG) of fund events to drive freezing / unfreezing / deduction; the reconciliation and alarm unit performs daily quick reconciliation + end-of-day detailed reconciliation, and automatically generates reconciliation tasks and records them on the blockchain when discrepancies exceed the reconciliation discrepancy threshold, making fund side effects programmable, replayable, and verifiable, reducing errors and manual reconciliation costs.

[0027] 6. Field-level and genealogy-level on-chain evidence preservation. Existing technologies often involve "full file hashing on-chain," which is coarse-grained and makes it difficult to prove specific fields and values; cross-module causality is unverifiable. In this invention, a blockchain evidence preservation and auditing module generates field-level summaries and mapping commitments for objects, and then organizes a causal chain of approval → contract → settlement / reconciliation → margin → snapshot using an event genealogy diagram. The genealogy root hash is anchored to the consortium blockchain block header, achieving both precision down to the field-level value and proof of cross-module causal paths, forming an independently verifiable chain of evidence.

[0028] 7. Offline Verification and Automatic Blocking of Bills / Contracts. In existing technologies, it is difficult to verify the authenticity and version of offline documents, and business is usually allowed to proceed when anomalies are detected. In this invention, machine-readable codes containing document hashes, block heights, and Merkel paths are generated for margin refund vouchers, settlement statements, and contract copies. When verification fails, the system prohibits contract transfer, margin refund, or settlement disbursement and issues an alarm according to the blocking rules in this specification. This allows third parties to verify authenticity offline at low cost, and anomalies can be blocked immediately, reducing compliance and financial risks.

[0029] 8. Robust Contract Assembly and Signature Location. In existing technologies, template / format changes can easily lead to signature anchor point drift, and post-signature text rewriting is difficult to detect in a timely manner. In this invention, forward compatibility is maintained through structural difference mapping performed by the contract assembly and electronic signature modules. Keyword location combined with affine / neighborhood correction is used to determine the signature anchor point. After signing, the hashes before and after signing are compared, and the certificate chain and timestamp are verified, making signature location stable and reliable. Post-signature tampering can be automatically detected and blocked, ensuring sufficient contract evidence.

[0030] 9. Settlement / reconciliation is recalculated and differences are verifiable. In existing technologies, index version / range management is weak, and after review and revision, a full recalculation is often performed, making it difficult to explain the source of differences. In this invention, when the external price index version or applicable range changes, or when the reconciliation base and review revision occur, only the affected subset is recalculated, and the difference traces and calculation snapshots are output to the blockchain. This minimizes the scope of recalculation, makes the origin and development of differences clear and verifiable, and reduces the cost of dispute resolution.

[0031] 10. Idempotency and out-of-order control, with no side effects during recovery. In existing technologies, duplicate submissions and out-of-order messages are common in distributed scenarios, easily causing duplicate freezes / deductions or result drift. In this invention, idempotency keys are carried in each key action, and the consistency snapshot and recovery modules skip duplicates during recovery using monotonically replaying and the idempotency book. The funds side uses a second verification with a receipt hash to eliminate the side effects caused by duplicates and out-of-order messages, ensuring "same input → same output".

[0032] 11. Non-stop upgrades and canary circuit breakers. In existing technologies, version switching for approval / matching / risk control often requires downtime and lacks health thresholds, making it difficult to roll back after problems escalate. In this invention, versioning and canary units are used to perform atomic switching of templates / policies and canary activation based on tenant / organization / transaction type. Health monitoring is performed on error rate thresholds, latency thresholds, and rollback rate thresholds. If the thresholds are exceeded, a circuit breaker is triggered to switch back, making evolution risks controllable, ensuring continuous service availability, and limiting the impact of problems to the canary range.

[0033] 12. Improved efficiency in auditing, evidence collection, and operations. In existing technologies, cross-system troubleshooting and auditing require manual splicing of multi-source logs, which is costly, time-consuming, and results in fragmented evidence chains. In this invention, a mapping commitment and event genealogy diagram are used to connect fields, objects, events, subtrees, and root hashes, and key nodes (approval, signature, settlement, funds, snapshots) are put on the chain. All anomalies (evidence storage failure, verification failure, and genealogy incompatibility) form evidence packages, enabling key location of differences and responsibility boundaries, resulting in a high degree of audit automation and significantly reducing operations and compliance costs. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the process of a blockchain-based commodity trading system according to the present invention. Detailed Implementation

[0035] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0037] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0038] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0039] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0040] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0041] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0042] See Figure 1 As shown in this embodiment, a blockchain-based bulk commodity trading system will be described in detail, including: a parameter and release module for receiving and storing transaction parameters; a unified approval engine module for isomorphic orchestration and flow verification of three types of business—transaction release, contract signing, and margin refund—based on configurable process templates and state machines, and supporting version updates and canary releases without downtime; a consistency snapshot and recovery module for collecting snapshots when transactions are suspended, closed, or abnormally interrupted, and replaying them in monotonic order after recovery to maintain sorting stability and time window consistency; a margin risk control module for triggering freezing, unfreezing, or deduction of registration, transaction / winning, default, and settlement events based on domain-specific language and directed graphs of fund events, and performing online and offline reconciliation consistency verification; and a blockchain evidence storage and auditing module for aggregating multi-source summaries of approvals, contracts, settlements / reconciliations, margins, and snapshots by field-level hashing in an orderly manner according to field names to form pattern version fingerprints and mapping commitments, constructing the root hash of the event genealogy graph, and anchoring the root hash to the consortium blockchain block header to achieve verifiable traceability.

[0043] This embodiment will describe the parameter and release module in detail. This module is mainly used to receive and store transaction parameters. As the system's front-end entry point, the parameter and release module operates around a continuous business chain of "collection—verification—standardization—storage and versioning—release—audit and record-keeping": on the one hand, it transforms the raw information submitted by transaction participants into standardized "transaction parameters" that can be reliably processed by machines; on the other hand, it pushes "release events" to the unified approval engine module and transaction processing module in a versioned and verifiable manner, and simultaneously submits them to the blockchain evidence storage and auditing module. For ease of understanding, the following will provide a continuous explanation of the composition and source of "transaction parameters," the methods of receiving and storing them, the verification and standardization rules, the versioning and release process, the exception and rollback strategies, and security and access control. First, transaction parameters are not limited to a single set of fields, but are organized around themes such as target and quality, quantity and granularity, pricing and currency, time and validity period, transaction method, delivery and logistics, contract terms, margin and funds, approval and visibility, auditing and versioning. To enhance feasibility, this implementation provides example fields, type constraints, main sources, and uses. Please refer to Table 1 for details on fields, type constraints, main sources, and uses. Table 1: Fields, Type Constraints, Main Sources, and Usage

[0044] At the input level, the parameter and publishing modules can receive transaction parameters through three parallel channels: First, the front-end interaction channel, where the front-end collects parameters step by step in the natural order of "subject → price → time → delivery → funds → terms → review." When the user selects "index pricing," the interface will force the completion of "index ID, version, and applicable range," and perform pre-validation of units and step sizes in real time. Second, the batch import channel, where the system provides a CSV / Excel field mapping wizard to perform structure and enumeration value validity checks before importing, and generates idempotent keys based on the source system ID and payload summary to avoid duplicate imports. Third, the API / EDI channel, which uses an Idempotency-Key to carry the idempotency identifier in an open REST or gRPC interface, and completes authentication and encrypted transmission with OAuth2 or bidirectional TLS. Regardless of the channel used, all raw parameters will be immediately added to the draft parameter library, and the creator, creation time, and initial version number will be marked.

[0045] Validation and standardization are triggered synchronously early after parameters are entered into the database. At the syntactic level, the system checks required fields, types, ranges, and units. For example, the quantity must be greater than zero, the tax rate should be in the range [0,1], and the price step size should be divisible by the minimum transaction unit. At the semantic level, the system checks cross-domain consistency. For example, when a family of price adjustment functions is enabled, the quality indicators must be complete and the units must be consistent. The selected warehouse and delivery location must exist and be available. The selected domain-specific language (DSL) strategy ID must be resolvable within the strategy database. If an external index is relied upon, the index ID, version, and applicable range are verified to be valid, and its signature or checksum is cached. After completing the syntactic and semantic checks, the system performs standardization: unifying the units of measurement (e.g., t↔mt, kcal / kg↔MJ / kg), unifying currency and decimal precision, denoising the text, and standardizing punctuation. Composite controls are also broken down into atomic fields (e.g., "delivery period" is broken down into start date, end date, and tolerance). Based on this, the module calculates a field-level summary for each standardized field, and then aggregates them in lexicographical order of field names to generate a schema version fingerprint (SchemaID) and mapping commitment. If a new edit results in a SchemaID that is different from the previous version, a list of differences is generated simultaneously to provide a basis for subsequent approval and on-chain evidence storage.

[0046] Regarding storage and version management, this implementation adopts an immutable versioning strategy: each edit or import creates a new version of the parameter snapshot, with draft, submitted, approved, and published states distinguished by a status field. Structured data is stored in a relational database's "parameter header table (containing category, pricing method, time window boundaries, approval template ID, status, schema_id, and version number, etc.)" and several sub-tables (quality indicators, pricing details, funds and margin, contract terms, etc.); large fields and attachments (such as contract preview PDFs or imported original files) are stored in object storage, with the database only storing their metadata and hashes. To ensure traceability, the system maintains a parallel "parameter event stream," writing key events such as Created, Validated, Submitted, Approved, Published, Amended, and Revoked, along with their event timestamps and parameter snapshot summaries, into an event table, providing a basis for subsequent recovery and auditing.

[0047] Once the parameters have been validated and confirmed by the user, the module sends a "submission event" to the unified approval engine module. The payload includes the offer_id, the current schema_id, and a list of differences. After approval, the parameters and the publishing module solidify the "published version" and generate a "published event." When publishing externally, the module sends a "matching parameter package" to the transaction processing module. This package contains only the minimum set necessary for matching (such as offer_id, category, price step size, minimum transaction unit, whether splitting is allowed, time window boundaries, matching mode, and the default priority required by the stable sorting comparator <price, event timestamp, sequence number>, etc.) to ensure the stable sorting and determinism of the matching process. On the other hand, the module sends the "field-level summary list," "schema version fingerprint (SchemaID)," and "published event node" to the blockchain notarization and auditing module, which includes the version in the event genealogy and anchors the genealogy root hash to the consortium blockchain block header. The on-chain receipt (block height, on-chain timestamp, Merkel path) is written back to the parameter audit record for verifiable review at any subsequent time.

[0048] Considering the complexity of the project operation, this implementation provides clear strategies for exceptions and rollbacks: if approval fails or times out, if the blockchain notarization and auditing module returns a notarization failure or verification failure, or if changes to key fields cause the current schema_id to be inconsistent with the approved version, the module refuses to publish and "rolls back to the most recent verifiable stable state." This stable state is jointly determined by the persistent checkpoints in the parameter library and the on-chain digest, and can be independently verified by external auditors; simultaneously, the module issues an alarm event to prompt the responsible party to handle it. For duplicates caused by batch imports, the existence of idempotent keys ensures that only one record enters the effective path, and other duplicate payloads are safely ignored.

[0049] In terms of security and permissions, the module uses OAuth2 or two-way TLS to complete communication encryption and subject authentication. At the authorization level, it combines RBAC / ABAC to grant different field-level read and write permissions to different roles (traders, risk control, reviewers, publishers, auditors). For example, the margin strategy ID is usually only allowed to be modified by the risk control role. All critical operations (submission, approval, publication, and on-chain anchoring) are accompanied by the operator's signature and a trusted time source timestamp, and recorded in the event stream to meet the traceability requirements of regulatory authorities or internal compliance.

[0050] Finally, it should be noted that the above descriptions regarding field sets, database table design, interface type (JSON / Avro / Protobuf), message middleware selection (Kafka / RabbitMQ), and object storage type (S3 / OSS) are all feasible options for implementing the technical solution of this application. They can be equivalently replaced without changing the core technical path of "field-level summary - ordered aggregation to form schema version fingerprint (SchemaID) - versioned release - on-chain anchoring". Similarly, the minimum set of fields in the "matching parameter package" can be fine-tuned according to specific business scenarios, but should at least include parameters related to the stable sorting comparator and time window boundaries to ensure causal consistency and replayability between release and matching.

[0051] This embodiment provides a detailed description of the unified approval engine module. Based on configurable process templates and state machines, it performs isomorphic orchestration and flow verification for three types of business: transaction publishing, contract signing, and margin refund. It also supports version updates and canary releases without system downtime. The unified approval engine module is used for isomorphic approval orchestration and execution control of these three types of business. Its position in the system chain is between the parameter and publishing module and the business execution end: the former sends standardized parameter objects with schema IDs to it through "submission events," while the latter (such as contract assembly, margin risk control, and transaction processing) can only proceed to execution after the unified approval engine module determines "pass" and generates a "pass event."

[0052] First, the process template management unit provides the capabilities for modeling, validating, and publishing approval templates. In one embodiment, the approval template is expressed in a declarative structure, and its core elements include at least: node type (initiator / inheritance / condition / countersigning / termination, etc.), routing conditions (based on field expressions and predicate combinations), form validation rules (required / range / cross-consistency), and a list of atomic operations (such as "generate draft contract", "freeze security deposit", "call electronic signature", "trigger risk control check"). This unit performs semantic validation on the template (loop detection, dangling node detection, dead path detection) and performs permission binding (node-role-permission matrix). After successful validation, a template version identifier is generated and solidified into an executable intermediate representation (IR). To enhance cross-module verifiability, this unit calculates field-level summaries of the template structure and bound key parameters and aggregates them in an orderly manner by field name, writing them into a schema version fingerprint (SchemaID), thereby ensuring that the approval template itself can be independently verified by the blockchain notarization and auditing module. Templates that pass validation enter the "ready" state, and the subsequent effective scope is controlled by the versioning and gray-scale unit.

[0053] Secondly, the state machine execution unit is responsible for expanding the executable template into state transitions and action orchestrations for approval instances at runtime. In one embodiment, this unit loads the template IR as a state transition table, creates an approval instance for each "submission event" (submission or change from the parameter and release module), and proceeds in an event-driven manner: when the routing conditions are met, it enters the next state and triggers the corresponding atomic operation. To ensure replayability and idempotency, each approval instance and each atomic operation is bound to an idempotent key (e.g., case_id + node_id + attempt_no), thereby enabling accurate deduplication during network jitter or duplicate submissions; simultaneously, this unit establishes persistent checkpoints at critical boundaries (e.g., "countersigning completed," "final approval passed," "third-party signature completed") to fall back to the most recently successfully submitted verifiable stable state in case of anomalies. To unify external behavior, the state machine execution unit adopts a consistent confirmation protocol for synchronous calls (HTTP / gRPC) and asynchronous calls (message queues / Webhook): an atomic operation is marked as "successful" only when the peer confirms (ACK) and returns a verifiable receipt hash.

[0054] In actual operation, execution anomalies and cross-module inconsistencies are inevitable. Therefore, the compensation and rollback unit provides closed-loop control based on "trigger conditions—processing actions—rollback boundaries—on-chain interaction." As described in this specification, the configuration of trigger conditions is explicit and closed, including but not limited to: the state machine execution unit returning an error code or throwing an exception when calling atomic nodes; cross-module calls exceeding the timeout threshold; detection of duplicate commits or out-of-order replay based on idempotent keys; transaction boundary verification failure (inconsistent checksums of key fields); external dependency (third-party payment / custody / electronic signature or message queue) health check failure; versioning and canary deployment unit detecting an error rate exceeding the error rate threshold or a rollback rate exceeding the rollback rate threshold during the canary deployment period; and the blockchain evidence storage and auditing module returning evidence storage failure or verification failure. For ease of understanding, a trigger-processing matrix is ​​given below; see Trigger-Processing Matrix Table 2 for details: Trigger-Process Matrix Table 2

[0055] Using the aforementioned matrix, the compensation and rollback unit can roll back the approval instance to the checkpoint of the state machine execution unit and align it with the corresponding digest returned by the blockchain evidence storage and auditing module, thereby ensuring the verifiability of the "stable state". For business actions that need to be reversed (such as frozen deposits or issued signing requests), this unit maintains a "compensation graph", where each atomic action is configured with its opposite compensation action, and secondary damage is avoided through idempotent keys and side effect checks.

[0056] To adapt to non-disruptive changes and multi-tenant differentiation, versioning and canary deployment units provide template version loading, atomic switching, and canary deployment activation control. In one embodiment, template release adopts a "double buffer" mechanism: new version templates coexist with old versions. Versioning and canary deployment units route according to tenant / organization / transaction type, first guiding a small number of instances to the new version and aggregating health indicators in real time (error rate, P95 / P99 at latency thresholds, and rollback rate). When any indicator exceeds the threshold (error rate threshold, latency threshold, and rollback rate threshold, respectively), a circuit breaker is automatically triggered, and the old version is switched back. Once the indicators stabilize and meet the standards, the canary deployment range is expanded until a full switch is achieved. To ensure traceability, the template version's structural summary, routing rules, and key events during the canary deployment process can all be anchored by the blockchain notarization and auditing module.

[0057] Regarding effectiveness and auditing, the unified approval engine module primarily generates two types of events: First, "approval events," carrying the approval result, approval path, and necessary parameter snapshot summaries for downstream business modules to execute; second, "rejection / rollback events," carrying the rejection reason code, triggering conditions, and rollback boundary identifiers for upstream parameter and release modules or manual intervention. These two types of events, along with the approval template's schema_id, the approval instance's event sequence, and timestamp, are submitted to the blockchain evidence storage and auditing module. This module incorporates these events into the event genealogy and anchors the root hash to the consortium blockchain block header, forming a verifiable chain of approval evidence.

[0058] In terms of security and permissions, the unified approval engine module and the process template management unit jointly implement the binding of "node-role-permission": for example, the initial review node can only be processed by the business review role, the countersigning node requires multiple roles to be present before it can be processed, and the final review node requires a second verification of the electronic signature certificate status; at the same time, all approval actions are accompanied by the operator's signature and a timestamp from a trusted time source. To meet the requirements of high concurrency and consistency, the system adopts optimistic locking and idempotent strategies for approval instances, uses a retryable and ordered message mechanism for cross-service communication, and sets timeout thresholds and retry limits for long-running calls.

[0059] In summary, the unified approval engine module, through its integrated design of "template-state machine-compensation-version grayscale-audit anchoring," enables the approval process to achieve isomorphic orchestration for three types of business: on the template side, it ensures the legality of the structure and compliance of permissions; on the runtime side, it ensures the idempotency and replayability of atomic actions; on the exception side, it enables verifiable rollback through a clear set of triggers; and on the change side, it safeguards system stability with grayscale thresholds and puts key evidence on the blockchain to form an objective basis for "verifiable stable state."

[0060] This embodiment describes the consistency snapshot and recovery module in detail. This module is primarily used to collect snapshots when transactions are paused, closed, or abnormally interrupted, and then replays them in a monotonic sequence after recovery to maintain sorting stability and time window consistency. The consistency snapshot and recovery module atomically freezes the matching process state when transactions are paused, closed, or abnormally interrupted, and restores the sorting process in a monotonic replay manner after system recovery, ensuring that the ranking results before and after recovery are completely consistent with the time window length. This module collaborates bidirectionally with the transaction processing module: the former completes snapshot solidification upon receiving the sorting snapshot identifier (generated by the transaction processing module at the time window boundary); the latter continues calculation based on the "window freeze and replay cursor" provided by this module during recovery. Simultaneously, this module submits key snapshot summaries to the blockchain notarization and auditing module for inclusion in the event genealogy, serving as objective evidence for subsequent audits and dispute reviews.

[0061] First, the collection and composition of snapshots are explained. In one embodiment, snapshots adopt a "barrier-alignment-atomic commit" strategy: when the transaction processing module determines that the time window boundary has been reached, it issues a barrier event with a sorted snapshot identifier; after receiving the barrier, the consistency snapshot and recovery module suspends window-related writes and waits for the partition cursor from the matching input stream (such as the quote stream and order cancellation stream) to align to the barrier position. After alignment is completed, the snapshot is fixed in one go. For ease of understanding, the structure of snapshot metadata is shown in Table 3 below: Table 3 of the snapshot metadata structure

[0062] In terms of storage and persistence, this implementation classifies snapshots into two levels: "hot snapshots" and "cold snapshots." Hot snapshots are written to local high-availability storage (such as distributed KV or log-type storage) in binary compressed form and record checksums for second-level recovery. Cold snapshots contain the same content but with additional indexes and more complete audit information (including field-level summaries and receipts of snapshot generation barriers), and are stored in object storage for long-term preservation. Both levels of snapshots calculate snapshot summaries, which are anchored by the blockchain notarization and auditing module. On-chain receipts (block height, on-chain timestamp, Merkel path) are written back to the snapshot directory to ensure independent verification at any point in time.

[0063] The following describes the recovery and monotonic replay process. In one implementation, the recovery process proceeds in the following sequential steps: First, load the target snapshot and verify that the snapshot digest matches the on-chain receipt. Simultaneously, compare whether the SchemaID of the parameter object recorded in the snapshot is equal to the current version. If they are not equal, recovery is rejected and a "parameter inconsistency" report is sent to the unified approval engine module to prevent further matching under erroneous rules. Second, perform window freezing: fix the time window to {start_ts, end_ts} recorded in the snapshot, prohibit any expansion or shortening behavior, and prohibit the introduction of offers or cancellations outside the window. Third, locate the replay cursor: locate the position of the first message after the barrier of each partition based on the "input stream cursor" in the snapshot. Fourth, trigger monotonic replay: read in strictly ordered only according to the event timestamp and the partition order saved in the snapshot. Skip messages that already exist in the idempotency book. In the case of parallel comparisons, strictly follow the parallel solution of the stable sorting comparator. During this process, calculate the difference between the current ranking and the expected ranking before the snapshot in each batch. Fifth, verify consistency: When the replay reaches the end of the window, the restored ranking sequence is compared with the ranking sequence before the snapshot. If there is a difference, the "restoration inconsistency" action is triggered immediately.

[0064] Regarding the handling strategy for inconsistencies in recovery, this module provides two paths: automatic and semi-automatic. In the automatic path, the system first rolls back to the previous available snapshot (i.e., the snapshot at the "previous window boundary"), and replays the data while ensuring the SchemaID parameter remains consistent. If inconsistencies still exist, the system outputs a complete "difference evidence package" (including a snapshot summary, replay cursor, ranking differences, and a set of related order and message IDs) to the blockchain evidence storage and auditing module for on-chain storage, while simultaneously notifying the unified approval engine module to initiate a manual review / rollback process. In the semi-automatic path, auditors can choose to "use the ranking before the snapshot" or "use the replay result," but regardless of the choice, the final selection is recorded on-chain along with the evidence package. It should be noted that recovery failure does not change the time window: the start and end times of the window are still based on the snapshot record, preventing the masking of ranking differences by extending or compressing the window.

[0065] To reduce runtime overhead and shorten recovery time, this implementation introduces incremental snapshots and snapshot intervals: the system allows the generation of incremental snapshots based on fixed transaction volumes or fixed time intervals. Incremental snapshots only record the ordered set of changes since the last full snapshot. During recovery, the most recent full snapshot is loaded first, and then several incremental snapshots are applied sequentially to reach the target state. For scenarios with extremely short windows or extremely dense transactions, the "barrier-alignment-solidification" process can be decoupled from the main matching thread using a lock-free queue to reduce blocking. For scenarios with longer windows, a background "shadow snapshot" can be used to pre-align some partition cursors, shortening barrier pauses.

[0066] Regarding collaboration with other modules, firstly, with the transaction processing module: this module synchronously sends a sorting snapshot identifier when the time window boundary is reached; during recovery, it needs to continue working according to the "window freeze order" and "replay cursor" returned by this module; if this module determines that the replay is inconsistent, the transaction processing module needs to suspend window-related matching and wait for a review decision. Secondly, with the parameter and publishing module: if an inconsistency between the parameter SchemaID and the snapshot is detected during recovery, this module directly refuses replay and sends a "version inconsistency alarm" to the parameter and publishing module to avoid recalculation under the changed rules. Thirdly, with the blockchain evidence storage and auditing module: this module submits summaries and evidence when the snapshot is solidified and the recovery conclusion is formed, incorporates them into the event genealogy, and anchors them to the consortium blockchain block header, ensuring that any review can be completed independently on the chain path.

[0067] Finally, the following explanation addresses anomalies and boundary conditions: When the input stream is out of order or timestamp drifts, this module does not change the original event timestamps of the messages. Instead, it uses a combination of a fixed window and a stable comparator to mitigate uncertainty. When some partitions have been without data for an extended period, causing barrier alignment timeouts, this module performs degradation after exceeding the set timeout threshold: it uses the aligned partitions as the basis for a snapshot, and simultaneously marks the "unaligned partition list" in the snapshot metadata. During recovery, this list will be loaded first and aligned using a "compensation replay" method before uniformly entering consistency verification. To prevent the idempotency book from growing indefinitely, the module uses a Bloom filter and segmented logs to archive the idempotency key set in stages. The fingerprints of the archived fragments are also submitted to the blockchain notarization and auditing module for future sampling verification.

[0068] In summary, the consistency snapshot and recovery module, through a continuous technical path of "barrier alignment - atomic solidification - window freezing - monotonic replay - consistency verification - on-chain anchoring", ensures that the matching ranking and time window remain equivalent before and after recovery after a pause, shutdown or abnormal interruption. Furthermore, it achieves audit traceability and dispute adjudicability through verifiable snapshots and evidence chains.

[0069] This embodiment provides a detailed description of the margin risk control module. Based on a domain-specific language (DSL) and a directed graph of fund events, the module triggers freezing, unfreezing, or deduction of funds for registration, transaction / winning, default, and settlement events, and performs online and offline reconciliation consistency checks. The margin risk control module is used to manage fund risks throughout the entire transaction process in a rule-based manner. Its core responsibilities are: based on the margin strategy described in the domain-specific language (hereinafter referred to as "DSL"), mapping registration, transaction / winning, default, and settlement events to edges with action labels in a directed graph of fund events (DAG), and triggering atomic fund operations such as "freezing, unfreezing, and deduction" within the third-party payment or custody system accordingly; simultaneously, the reconciliation and alarm unit performs consistency checks daily / batch with online (payment / custody API) and offline (bank receipts / financial vouchers). When discrepancies exceed the reconciliation discrepancy threshold, a discrepancy alarm and write-off task are automatically generated, and a key summary is submitted to the blockchain evidence storage and audit module for inclusion in the event genealogy graph. For ease of understanding, the following description focuses on "strategy expression and loading, event graph modeling, atomic operations of funds, reconciliation and write-off, exceptions and rollback, security and permissions, and collaboration with other modules in the system".

[0070] First, let's explain strategy expression and loading. The margin risk control module is equipped with a "domain-specific language interpreter" that supports parsing, validating, and hot-updating margin strategies. Strategies are expressed as a five-tuple: "Trigger Condition—Calculation Formula—Fund Action—Recovery Condition—Audit Field." Trigger conditions can reference transaction parameters (category, pricing method, tax rate), matching context (price, quantity, event timestamp), account attributes (margin account balance, frozen amount in transit), and compliance attributes (KYC / KYB status). The interpreter executes strategies within a secure sandbox, exposing only restricted functions (such as rounding, unit conversion, and fee table queries) to the outside world. It generates a verifiable digest for each strategy (a digest fingerprint consisting of strategy ID, version number, and ordered aggregation of field-level hashes) for cross-validation with the schema ID. Once loaded, a strategy enters a "ready" state. Canary releases are controlled by the upper-level unified approval engine module. When canary release metrics exceed limits (such as error rate exceeding the error rate threshold or rollback rate exceeding the rollback rate threshold), a rollback to the previous stable version is possible.

[0071] Next, the modeling of the directed graph of fund events will be explained. In one implementation, the system abstracts the "main account (counterpartie—platform reserve—custodian account)" as nodes on the graph and the fund actions as directed edges. The mapping relationships of the four types of business events are as follows: Registration events trigger "pre-freeze edge" (calculated based on the number of registrations × margin ratio or a fixed amount); Transaction / winning events trigger "freeze enhancement edge" (raising the pre-freeze to the level required for the transaction) or "direct freeze edge" (such as instant bidding business with pre-freeze for those who have not registered); Default events trigger "deduction edge" (converting the frozen to actual deduction) and "unfreeze edge" (releasing the portion not included in the default amount); Settlement events trigger "unfreeze edge" (releasing excess margin) and "replenishment deduction edge" (replenishing the frozen amount if a shortage occurs during settlement verification). To ensure the graph is replayable and auditable, each edge is labeled with an action tag (Freeze / Unfreeze / Debit, etc.), an amount expression, currency, precision, funding channel (payment gateway / custodian bank), and an idempotent key (such as offer_id+party_id+event_type+sequence_no). The execution result of the edge (success / failure / retry) and the echo hash of the other end are written into the fund flow record so that side effects can be accurately restored during recovery by combining monotonic replay.

[0072] At the atomic operation level, the module initiates controlled calls to the third-party payment / custodian system: Freeze requires the upstream to return "freeze number + amount + validity period", Debit requires referencing the original freeze number to reduce disputes, and Unfreeze requires a release confirmation. To achieve strong consistency, all calls adopt a unified protocol of "idempotency + timeout + retry + receipt verification": the request carries an idempotent key and signature, and if no confirmation is received after the timeout threshold, it will back off exponentially and retry a maximum of N times; if the other end succeeds, it must return a verifiable receipt hash and business transaction number, based on which the module marks the atomic operation as successful and fixes it in the fund transaction record. To avoid double freezing / repeated deduction under concurrent conditions, the module introduces an "account-freeze slot" model: the freeze slot of the same idempotent key can only be in one of {INIT, FROZEN, DEBITED, RELEASED}, and the state transition is completed in the local transaction and persisted in the Write-Ahead Log (WAL) manner; during recovery, it is replayed according to the WAL to the most recent "verifiable stable state", which is aligned with the summary of the receipt of the blockchain evidence storage and audit module.

[0073] Regarding reconciliation and write-off, this implementation method adopts a two-layer reconciliation mechanism of "intraday fast reconciliation + end-of-day detailed reconciliation". Intraday fast reconciliation targets high-frequency anomalies (channel congestion, intermittent failures at the peer end), comparing incremental transaction flows on the platform side and the peer side using aggregated metrics (by channel, currency, and action type); end-of-day detailed reconciliation compares each transaction individually with "freeze number / order number / amount / currency / peer transaction number / status". When the difference ratio or difference amount exceeds the pre-set reconciliation difference threshold, the reconciliation and alarm unit generates a "difference alarm" and automatically derives a "write-off task": if the difference is due to duplicate receipts from the peer end resulting in "unrecorded on the platform side - recorded on the peer side", a supplementary record or reversal is initiated; if the difference is due to deduction on the platform side - not deducted on the peer side, a retransmission and manual review are initiated. After the write-off is completed, a "write-off event" will be generated on the fund flow, and its summary (difference list, write-off action, operator signature, timestamp) will be submitted to the blockchain evidence storage and audit module for inclusion in the event genealogy. For ease of understanding, this embodiment provides an example of reconciliation items, as shown in Reconciliation Item Table 4: Reconciliation Checklist 4

[0074] To address operational anomalies, anomaly and rollback strategies form a closed loop with the approval process: When atomic operations fail consecutively or reconciliation discrepancies cannot be cleared for an extended period, the module notifies the unified approval engine module as a "failure event," which then triggers rollback and compensation as described in this implementation (e.g., revoking the approval of "pending refund of security deposit" or freezing and enhancing compensation on the funds side of "released contracts"). Simultaneously, the module itself executes offsetting actions according to the "compensation diagram" (e.g., if deduction fails, the freeze enhancement is rolled back; if deduction is mistaken, a refund is initiated), ensuring that compensation does not produce secondary side effects in an idempotent manner. If on-chain notarization fails or verification fails, the module marks the relevant fund actions as "pending review," prohibiting further release or deduction until the blockchain notarization and auditing module recovers and notarization is submitted again before unlocking.

[0075] Regarding security and permissions, the module's external API uses OAuth2 or two-way TLS to ensure secure communication. On the authorization side, RBAC / ABAC is used to implement fine-grained control over operations such as "policy maintenance, manual reconciliation, discrepancy confirmation, and refund approval." Key actions (policy release, atomic fund operations, and reconciliation confirmation) all require the operator's signature and a timestamp from a trusted time source, which are simultaneously written into the fund event log. Account credentials (payment keys, custody certificates) are stored in a hardware security module (HSM) or equivalent facility, and are temporarily unsealed according to the "minimum necessary" principle during access, with full traceability.

[0076] Finally, the collaboration with other modules within the system is explained. Collaboration with the parameter and publishing module is reflected in two aspects: First, the strategy can reference the margin ratio, account information, and schema ID from the parameters; when the schema ID changes, a strategy re-evaluation is triggered. Second, the module can write back a "margin usage snapshot" to the parameter side for display during publishing and changes. Collaboration with the transaction processing module mainly involves the near real-time consumption of "trading / winning events": the matching output events carry price, quantity, event order, and sorting snapshot identifiers, allowing the module to complete freeze enhancement or deduction on the same causal chain, avoiding discrepancies between ranking and fund actions. Collaboration with the consistency snapshot and recovery module is reflected in the monotonic replay during abnormal recovery: the risk control side uses idempotent keys and peer receipt hashes to determine effective fund actions, strictly avoiding double deductions or repeated unfreezing. Collaboration with the blockchain evidence storage and auditing module is consistent throughout: strategy summaries, atomic fund operation receipts, reconciliation differences, and write-off events are all incorporated into the event genealogy and anchored to the consortium blockchain block header, providing a verifiable chain of evidence for subsequent audits and dispute resolution.

[0077] This embodiment provides a detailed description of the blockchain evidence storage and auditing module. Primarily, it aggregates multi-source summaries from approvals, contracts, settlements / reconciliations, margin deposits, and snapshots using field-level hashing, forming schema version fingerprints and mapping commitments by field name. It also constructs the root hash of the event genealogy graph and anchors the root hash to the consortium blockchain block header for verifiable traceability. The blockchain evidence storage and auditing module standardizes key objects and events across modules, forming a continuous chain of evidence: field-level hashing—ordered aggregation—schema version fingerprint (SchemaID)—mapping commitment—event genealogy graph—root hash on-chain anchoring—receipt verification. This provides verifiable and traceable auditing capabilities for the parameter and release module, unified approval engine module, margin deposit risk control module, consistency snapshot and recovery module, settlement and reconciliation, and contract assembly and electronic signature. The following continuous narrative, combined with necessary tables, provides a complete explanation of data entry and standardization, fingerprint and commitment generation, genealogy construction and on-chain anchoring, verification and blocking, anomalies and rollbacks, permissions and security, and collaboration with various modules.

[0078] First, there's the data entry and standardization. Whenever any key object or event occurs on any business side (e.g., "submission / approval / publication event," "transaction / winning bid event," "frozen / deducted / unfrozen funds flow," "daily settlement / reconciliation results and difference records," "contract PDF and signature package," "snapshot containing sorting snapshot identifier"), it enters the blockchain evidence storage and auditing module in the form of an "evidence storage request." The entry adaptation layer performs unified standardization on the payload: field names are uniformly named and lowercase, removing spaces and variant characters to ensure "unique and stable field names"; numerical values ​​are normalized in units and currencies according to the system precision table and master data (e.g., t / mt, kcal / kg↔MJ / kg, CNY@2dp, etc.); time is uniformly set to UTC and event timestamps are retained; document objects (contract PDF, settlement statement, deposit refund voucher, etc.) have their document hashes calculated, and structured indexes (document type, template version, signature anchor correction summary, etc.) are extracted for association with structured objects.

[0079] Next comes the generation of field-level hashes, schema version fingerprints (SchemaID), and mapping commitments. For the standardized "field name - standardized value" pairs, the module calculates the field-level hash and aggregates them in lexicographical order by field name to obtain the schema version fingerprint (SchemaID) used to comprehensively characterize the object's "schema and values," as well as a mapping commitment that makes an immutable promise regarding the "field name → field hash" mapping. If the current object differs from the previous version's SchemaID, the module simultaneously generates a "difference list" (added / modified / deleted fields and a summary of old values) for approval and auditing reference. For ease of understanding, the following example is given in this embodiment; please refer to the mapping commitment illustration table 5 for details: Mapping Commitment Illustration Table 5

[0080] The next step is the construction of the event genealogy graph and the anchoring of the root hash. The blockchain evidence storage and auditing module models approvals, contracts, settlements / reconciliations, margin deposits, snapshots, and their causal dependencies as a unified directed acyclic graph (DAG): nodes are object digests (including object ID, version, schema ID, timestamp, document hash, etc.), and edges are causal or dependency relationships (such as "release → transaction / winning bid → daily settlement → reconciliation → margin deposit refund voucher"; "approval passed → contract assembly → electronic signature → contract PDF"). The same order / offer or the same settlement cycle can form an independent sub-genealogy. The module uses node digests as Merkle leaves and constructs a Merkle tree in a deterministic order (e.g., topological order + lexicographical order of node IDs) to obtain genealogy root hashes covering cross-modules and cross-versions. To balance timeliness and cost, the module adopts a micro-batch strategy to periodically submit the genealogy root hashes to be anchored to the consortium blockchain, obtaining receipts such as block height, on-chain timestamp, and transaction hash, and establishing a one-to-one mapping between the receipts and "genealogy root - batch ID" for subsequent verification and auditing.

[0081] Regarding verification and business blocking, the module provides both online and offline verification paths. In online verification, the caller provides the object ID and its SchemaID or document hash. The module returns a field-level hash, a mapping commitment member proof, the Merkel path of the subtree, the anchor batch, and a block receipt. The caller can then perform consistency verification on-chain / off-chain. In offline verification, the module generates machine-readable codes (such as QR / DM) for margin refund vouchers, settlement statements, and contract copies. These codes must contain at least the "document hash, generation timestamp, block height, Merkel path, and verification entry identifier." When offline or online verification fails (e.g., inconsistent document hashes, mismatched Merkel paths, or no corresponding block height receipt), the module immediately blocks the corresponding business flow and writes an alarm as described in this specification, prohibiting contract transfer, margin refunds, or settlement disbursements until the problem is resolved.

[0082] Regarding anomalies and rollbacks, this implementation provides clear system actions and rollback boundaries: First, when evidence storage fails or on-chain verification fails, the module reports an "evidence storage failure event" to the unified approval engine module, which triggers a rollback to the most recent "verifiable stable state" according to a threshold strategy. Second, when offline / online verification fails, the module simultaneously outputs a "blocking instruction" and an "evidence summary," and anchors the discrepancy list and failure receipt to the genealogy. Evidence storage will be resubmitted after the problem is resolved. Third, in scenarios where the consistency snapshot and recovery module report a discrepancy between the recovery ranking and the snapshot, the module incorporates the "snapshot summary, window boundaries, sorting parameters, and comparison conclusions" into the genealogy and anchors a new root, providing evidence for subsequent adjudication. For ease of understanding, this implementation provides an example of the correspondence between anomalies, system actions, and rollback boundaries. See Table 6 for details. Table 6: Correspondence between Anomaly, System Action, and Rollback Boundary

[0083] Regarding permissions and security, the module employs RBAC / ABAC for fine-grained control over operations such as "submitting evidence, viewing genealogy, exporting proofs, and issuing blocks." On-chain private keys and certificates are stored in an HSM or equivalent secure hardware, and all pegged transactions are signed by a service account with operation logs retained. To meet privacy compliance requirements, field-level hashes can be salted or selectively anonymized when necessary (the generation and rotation of salt values ​​are also committed to by this module and can optionally be recorded on-chain), ensuring that third parties cannot deduce the original text from the commitment while maintaining on-chain verifiability.

[0084] Finally, the collaboration relationships with each module are explained. Collaboration with the parameter and release module is reflected in receiving its field-level summary and schema version fingerprint (SchemaID), incorporating release / change events into the genealogy, and writing back block receipts. Collaboration with the unified approval engine module is reflected in incorporating the approval template structure summary, approval instance event sequence, and result summary into the genealogy; if evidence storage fails, a rollback is triggered. Collaboration with the margin risk control module is reflected in storing evidence of atomic fund operation receipts, reconciliation differences, and write-off events to ensure that "post-event review" is verifiable. Collaboration with the consistency snapshot and recovery module is reflected in recording the sorting snapshot identifier, input stream cursor, window boundary, and snapshot summary, and continuing anchoring after the recovery consistency conclusion is formed. Collaboration with settlement and final settlement is reflected in storing evidence of daily settlement / final settlement results, recalculation triggers, and difference traces. Collaboration with contract assembly and electronic signature is reflected in anchoring the contract PDF hash, signature anchor point correction results, and signature certificate status; when necessary, it links with machine-readable codes to provide offline verification. Through the aforementioned continuous path, the blockchain evidence storage and auditing module realizes the closed loop of the evidence chain of "field—object—event—genealogy—block" into an engineeringable and implementable capability. It should be noted that a blockchain-based bulk commodity trading system also includes a contract assembly and electronic signature module. The transaction processing module receives offer objects published by the parameter and publication module and approved by the unified approval engine module. It creates order clusters according to the standardized fields and SchemaID at the time of publication and receives input events such as quotations, order cancellations, qualification changes, and controls within the agreed time window boundaries. After all inputs enter the module, they are normalized in terms of unit and precision, verified by idempotent keys, and uniformly stamped with server-side event timestamps. If an inconsistency is detected with the SchemaID recorded in the publication state, the module rejects the event and sends back a version inconsistency alarm, thereby ensuring that the matching basis is consistent with the publication baseline.

[0085] This module employs a homogeneous ledger in its matching mechanism to reduce implementation complexity: whether listing or bidding, it internally abstracts itself into a unified structure of "price table + ordered queue". Prices are aligned to the step size declared at the time of publication; within each price level, a first-in, first-out (FIFO) bid queue is maintained, with queue items recording attributes such as participant identifier, remaining quantity, price, event timestamp, entry sequence number, idempotent key, and whether splitting is allowed. During the window's runtime, the module only performs bookkeeping and sorting, without generating transactions; only at the end of the window is settlement and result output performed all at once, enabling barrier alignment and monotonic replay with the consistency snapshot and recovery modules.

[0086] The determinism of sorting and liquidation is guaranteed by a stable sorting comparator. The comparator performs stable comparisons using triples (price, event timestamp, sequence number), with the direction of price increase / decrease depending on the transaction direction and system. When primary keys are the same, the time secondary key and the last key of the sequence determine the winner, ensuring total order stability and replayability. In this embodiment, for ease of understanding, examples of primary and secondary key relationships for the comparator under different systems are provided. See Table 7 for specific examples of primary and secondary key relationships for the comparator under different systems. Table 7 shows the primary and secondary key relationships of comparators under different systems.

[0087] When the window reaches the time window boundary, the module first freezes the window, rejecting events outside the window. Then, it generates a unique sorted snapshot identifier (e.g., composed of the window number, wall clock time, and order book fingerprint) based on the ledger and comparator states, and performs batch clearing accordingly: for single lots, supply and demand are allocated according to the comparator from best to worst, allowing partial transactions; for tiered supply or multiple price tiers, the process proceeds from best to second best price tier until the quantity is exhausted or the limit is reached; for sealed bids, the winner set and winning bid price are determined according to the pre-declared pricing rules (e.g., first price or second price), and then the allocation is completed. After clearing, the module generates a set of transaction / winning events. Each event includes at least the offer ID, participants, price, quantity, currency / tax rate precision, system description, comparator summary, sorted snapshot identifier, SchemaID, and the event timestamp at the end of the window. The snapshot metadata of this batch (including price clusters, queue summaries, and comparator parameters) is then handed over to the consistency snapshot and recovery module for solidification, enabling window freezing and monotonic replay in recovery scenarios. For ease of interface integration, please refer to Table 8 for the minimum set of fields for an event: Table 8: Minimum set of fields for events

[0088] In terms of allocation strategy, the module adheres to the principle of balancing determinism and fairness: when items of the same price are listed together, allocation is strictly in accordance with the queue order; when the remaining quantity is insufficient to satisfy the next queue item and the item declares that it can be split, the maximum allocable quantity is given as an integer multiple of the "minimum transaction unit"; if the item does not allow splitting, it is skipped to maintain the overall order stability. The entire clearing process is within a single transaction scope, and the order in which output events are entered into the database is consistent with the order in which they are published externally, with a sequence number attached to facilitate downstream consumption and replay in sequence.

[0089] After the results are output, the transaction processing module sends the minimum necessary set of facts to each business module: to the margin risk control module, it outputs the price, quantity, event timestamp, and sort snapshot identifier to trigger freeze enhancement or deduction; to the contract assembly and electronic signature module, it outputs the minimum set of fields required for the contract to generate a draft contract; to the settlement and reconciliation module, it outputs the basic facts of the transaction as the starting basis for daily settlement / reconciliation; and to the blockchain evidence storage and auditing module, it submits a clearing batch summary (window information, comparator summary, ledger key fingerprint, sort snapshot identifier, and result event hash set) to be included in the event genealogy and anchored to the consortium blockchain block header.

[0090] The anomaly and rollback strategy remains consistent with the upstream: If the SchemaID of the published object is found to be inconsistent with the order cluster record, the comparator parameters are modified by external sources during the liquidation period (which should not happen under normal circumstances), or the interaction with the blockchain evidence storage and audit module fails and the upstream strategy requires evidence first, then this window will not generate a transaction / bid, retain a ledger snapshot, and report the liquidation failure event to the unified approval engine module, which will handle it according to the established compensation mechanism; in the recovery scenario, the module strictly follows the consistency snapshot and the window freeze order and replay cursor provided by the recovery module to perform monotonic replay to ensure "same input → same output".

[0091] In engineering, an ordered mapping / skip list can be used to carry the price table, and a lock-free queue can be used to carry the queue within the price level. The server-side event timestamp is used to unify the clock, and the entry point is used for time difference correction. The same order cluster is cleared in a single thread, while cross-cluster operations are parallel. The event idempotent key and the result ID are used for double deduplication, and the "ranking summary fingerprint" and "allocation detail hash" are output for fast on-chain / off-chain verification. Through the above continuous path, the transaction processing module realizes a stable, replayable, and traceable transaction / calibration process with a stable sorting comparator as its core under multiple systems, and is naturally aligned with each downstream module in terms of data and evidence chain.

[0092] It should be noted that a blockchain-based bulk commodity trading system also includes a contract assembly and electronic signature module. This module undertakes the continuous responsibilities of "template parsing → field-layout assembly → structural difference mapping (forward compatibility) → layout generation → signature anchor point positioning and correction → signature arrangement and receipt → verification and blocking → evidence storage and traceability". Upstream, it receives data snapshots corresponding to the "approval event" and transaction / bid winning event from the unified approval engine module, and completes the assembly of contract text and layout under the field standards given by the parameter and release module. Downstream, it submits the contract PDF and signing evidence to the blockchain evidence storage and audit module to be included in the event genealogy, and provides verifiable signing receipts and status to the business module.

[0093] First, let's explain "Template Parsing and Field-Layout Assembly". In one implementation, the contract assembly and electronic signature module maintains a set of contract templates. Each template contains structured placeholders (such as ${party_name}, ${quantity}, ${pricing_mode}) and layout elements (paragraph styles, headers and footers, table borders). When the unified approval engine module determines a transaction use case as "approved", the contract assembly and electronic signature module loads the corresponding template and parses the placeholders, mapping the transaction / bid-winning events and parameters with the standardized fields of the publishing module to the layout positions. For ease of understanding, this embodiment provides a field-layout mapping example; see Field-Layout Mapping Table 9 for details. Field-Layout Mapping Table 9

[0094] Next, we will explain "structural difference mapping and forward compatibility". In another implementation, the contract template may be iteratively upgraded. To ensure that old orders can still be reproduced under the new template, the contract assembly and electronic signature module performs structural difference mapping on the historical versions of the template: a mapping table is established for newly added / renamed / shifted placeholders, a default rendering strategy is given for deleted placeholders (such as hiding paragraphs or using a "not available" mark), and the mapping rules are written into the contract metadata in the form of a summary. During assembly, the contract assembly and electronic signature module prioritizes rendering with the template version bound when the order is generated; when it is necessary to replay old orders in the new template, structural difference mapping is applied first, and then the layout generation process is entered, thereby achieving forward compatibility and reproducibility.

[0095] The process then proceeds to "Layout Generation and Rendering." In one implementation, the contract assembly and electronic signature module converts structured text into a formatted document (PDF or equivalent format) and records the layout coordinate system (page number, rectangular boundaries, font, and line height, etc.) for each key field or paragraph, facilitating subsequent signature positioning and discrepancy verification. For multi-page tables or variable-length clauses, the contract assembly and electronic signature module employs a "page-aware" layout strategy: it first calculates potential page break points, then performs backflow according to layout rules (such as "headers not on orphan lines" and "table headers follow the page"), and finally outputs the document and element coordinate indexes with a determined layout.

[0096] The core step is "signature anchor point positioning and correction". In one implementation, the contract assembly and electronic signature module uses a combination of "keyword positioning + coordinate correction" to determine the signature anchor point: First, the anchor text area is located in the layout text layer according to preset keywords or regular expressions (such as "legal representative (signature)", "buyer (seal)", "seller (seal)"); if there are multiple candidates for the keyword, the one with the highest confidence is selected by combining adjacent layout elements (such as paragraph numbers or table cell titles); then, based on the element coordinate system recorded during assembly, the anchor text area is mapped to the initial signature coordinates. To cope with changes in layout or pagination, the contract assembly and electronic signature module performs affine correction or anchor text neighborhood matching before signing: when font ratio, page margins, or scaling cause linear deformation of the overall coordinates, affine transformation is used to correct the initial coordinates once; when only local line spacing / reflow differences occur, "anchor text neighborhood matching" (secondary positioning based on text and layout features within an N×M window around the anchor text) is used for refinement, and finally the corrected signature anchor point is obtained. The contract assembly and electronic signature module writes the correction result along with the original location into the contract metadata to improve the robustness and verifiability of the signature location. For ease of understanding, an example of anchor point elements is given in this embodiment; please refer to Anchor Point Elements Table 10 for details. Anchor Point Element Table 10

[0097] After location is completed, the process proceeds to "Signing Arrangement and Receipt Management". In one implementation, the contract assembly and electronic signature module generates a signing process (sequential signing / parallel signing / countersigning) based on approval instructions and role matrix, and initiates a signing request to the signing service according to anchor points and certificate policies: the official seal certificate is used for "stamping", and the personal certificate is used for "signing". For each signing request, the contract assembly and electronic signature module requires the signing service to return a verifiable receipt (signature value, certificate chain, timestamp, signature field coordinates, hash comparison before and after). When the signing returns "success", the contract assembly and electronic signature module recalculates the hash of the document and compares the difference between the hash after signing and the hash before signing. This difference is limited to the signature appearance layer (XObject / annotation layer, etc.). If changes are detected in the text layer or unauthorized objects appear, it is immediately identified as an anomaly.

[0098] To ensure "evidence first," the contract assembly and electronic signature module performs verification and blocking at every critical node. Firstly, during the "pre-signature verification" stage, if the template structure is inconsistent with the order binding version, essential placeholders are not fully assembled, or the "index-priced contract" lacks an index version and applicable range, the contract assembly and electronic signature module refuses to proceed with signing and returns a "rejection / rollback event" to the unified approval engine module. Secondly, during the "post-signature verification" stage, if the certificate chain is invalid, the timestamp is unreliable, or the deviation between the signature field and the signature anchor point exceeds a threshold, the contract assembly and electronic signature module sets the contract to "pending review" and triggers a rollback or re-signing in conjunction with the unified approval engine module. Thirdly, during the "transfer verification" stage, if the blockchain evidence storage and auditing module returns evidence storage failure or verification failure (e.g., the contract PDF hash is inconsistent with the on-chain digest, Merkel path verification fails), the contract assembly and electronic signature module immediately blocks the corresponding business flow according to the constraints described in this manual and generates an alarm to be uploaded to the chain.

[0099] Regarding "evidence preservation and traceability," the contract assembly and electronic signature module submits summaries to the blockchain evidence preservation and auditing module at three points: upon completion of contract assembly, upon each successful signature, and upon finalization. The submitted content includes at least the contract PDF hash, template version ID and structural difference mapping summary, sampled commitment entries for assembly fields, signature anchor point correction results, signature receipt (signature / certificate chain / timestamp), and contract status transition events. Based on this, the blockchain evidence preservation and auditing module incorporates contract-related nodes into an event hierarchy graph and anchors them to the consortium blockchain block header. The contract assembly and electronic signature module writes back the block height, on-chain timestamp, and Merkel path to the contract metadata and can generate a machine-readable code to attach to a copy of the contract for offline verification. If verification fails after scanning the code, the contract assembly and electronic signature module issues a "blocking instruction" to the business side, prohibiting the contract from continuing to circulate or being used as the basis for loan disbursement / refund.

[0100] Finally, the collaboration with other modules and exception rollback are explained. Collaboration with the parameter and release module is reflected in the consistency verification of field standards and SchemaID; if the SchemaID is inconsistent, the signature is rejected and rolled back. Collaboration with the unified approval engine module is reflected in the orchestration and rollback triggering of the signing process; signature failure or verification anomalies will be used as "rollback conditions" to enter its compensation channel. Collaboration with the consistency snapshot and recovery module only occurs in extreme recovery scenarios (e.g., replaying the signature event due to storage anomalies); the contract assembly and electronic signature module avoids duplicate signatures based on the signature receipt hash and idempotent key. Collaboration with the margin risk control module is reflected in writing back the "executable contract hash and signature status" after the contract is finalized for the funding side to release or freeze funds for enhanced reference. Collaboration with the blockchain evidence storage and auditing module is consistent throughout, used for blocking evidence on-chain and verification failures. If there are consecutive failures in the signing chain or the peer's receipt is unavailable for a long time, the contract assembly and electronic signature module will roll back the contract status to the most recent successful "verifiable stable state" (this state is jointly defined by the assembly snapshot and on-chain receipt) and require a re-triggering of approval and signing.

[0101] It should be noted that a blockchain-based commodity trading system also includes a settlement and reconciliation module. This module handles transaction / bid winning events and delivery data, operating along a continuous path: "data collection and standardization → outlier removal → linked price adjustment and unit price calculation → daily settlement statement generation → multi-day reconciliation → partial recalculation and difference tracking → evidence storage and blocking linkage." On the one hand, it maps test indicators and acceptance thresholds to price adjustments based on a family of price adjustment functions. On the other hand, it introduces external price indices as exogenous factors into pricing and, with the support of the blockchain evidence storage and auditing module, forms a verifiable chain of evidence for version, range, and recalculation differences.

[0102] Data Acquisition and Standardization. The settlement and reconciliation module receives raw data daily from arrival / weighing, transportation, and laboratory processes, including arrival quantity (gross weight, tare weight, net weight), transportation loss records, laboratory indicators (such as ash content, sulfur, volatile matter, lower calorific value, moisture, etc.) and their sampling time, batch number, and re-inspection mark. It also receives transaction quantity, unit price form (fixed price / index price / basis), currency and tax rate, delivery method, and parameters, as well as acceptance thresholds and quality templates provided by the publishing module, for each transaction / bid winning event. Before data is entered into the database, all data is standardized in terms of units and precision (measurement is standardized to the system's main unit, amount is standardized to a "currency + decimal place" system, time is standardized to UTC and event timestamps are retained), and the data is aligned with the schema ID bound to the transaction. If a schema ID inconsistency is detected, pricing calculation is rejected and a "version inconsistency alarm" is sent back.

[0103] Outlier removal is then performed. To reduce the irrational impact of extreme values ​​on pricing and daily settlement, the module configures settlement anomaly percentile thresholds (used in settlement scenarios, distinct from error / revert rate thresholds and risk control reconciliation difference thresholds in approval gray-scale testing), such as using P2.5 / P97.5 or P1 / P99 as default boundaries; in scenarios with significantly skewed quality distributions, robust criteria (e.g., median ± K×MAD, Huber / Tukey weighting functions, etc.) are allowed for equivalent removal. The removed detection points, along with the removal reasons, the parameters used in the calculation, and the thresholds, are written into the "Anomaly Removal List," which is subsequently submitted to the blockchain notarization and auditing module for record-keeping along with the calculation results; when the removal rate exceeds the upper limit set by the operations side, the module initiates an "Excessive Anomalies Alarm," prompting a review of the sampling / testing process.

[0104] In the linkage price adjustment and unit price calculation stage, the module applies the price adjustment function family to the standardized test indicators and generates the price increase / deduction for each indicator in conjunction with the acceptance threshold. Common function families include three types: linear, piecewise, and quantile (which can coexist in parallel. For ease of understanding, this embodiment provides examples of linear, piecewise, and quantile functions. For details, please refer to Table 11 for linear, piecewise, and quantile functions).

[0105] Linear, Piecewise, and Quantile Table 11

[0106] If the transaction uses index / basis pricing, the module introduces an external price index as an exogenous factor into the pricing benchmark: For each daily settlement, it reads the currently effective index ID, version identifier, and applicable range, and calculates "benchmark price = index price (version V) + basis"; then, it adds the quality adjustment obtained from the table above to form the "daily unit price". To avoid cross-version misuse, if the version or applicable range returned by the index request does not match the daily settlement date, the module will suspend the settlement for that day and output an "index range mismatch alarm". The index ID, version, and applicable range will be simultaneously written to the blockchain storage and auditing module for subsequent recalculation and proof.

[0107] After the unit price is finalized, the module generates a daily settlement statement: calculating the daily payment based on "daily unit price × qualified inbound quantity" (or according to agreed-upon criteria), and outputting fields such as "pre-tax amount, tax amount, post-tax amount, converted unit price, deduction / addition details, anomaly removal list, index version and range, and calculation snapshot hash"; it also includes a summary of the SchemaID and price adjustment function family configuration used in this calculation. For ease of understanding, this embodiment provides a list of key daily settlement fields, as shown in Table 12: Daily Settlement Key Fields List Table 12

[0108] At the end of a settlement cycle, a multi-day reconciliation begins. The module selects the reconciliation base according to the contract / offer agreement (e.g., based on the total qualified inventory, converted to tons based on weighted calorific value, or according to the contract-specified caliber), summarizes the daily settlements for the entire cycle, and generates "total payable / receivable, average unit price, cumulative deductions / additions for each indicator, loss deductions, and overall statistics for anomaly removal," etc., and generates the reconciliation results. If the reconciliation base changes or laboratory re-inspection corrections occur later in the reconciliation process (e.g., retesting confirms that a batch of sulfur content exceeds the original record), the module only performs a partial recalculation on the affected daily settlements or batches. The smallest scope of partial recalculation is "affected daily settlements + related aggregated indicators"; After recalculation, a "Recalculation Difference Statement" is generated, listing "Reason for Change → Affected Fields → Old Value → New Value → Difference", and establishing a version chain with the original daily settlement / reconciliation statement; The differences (additions / reductions) resulting from the recalculation are written back as "difference trace entries" and submitted to the blockchain evidence storage and auditing module for inclusion in the event genealogy.

[0109] If the version identifier or applicable range of the external price index changes during the settlement period, the module will recalculate the affected daily settlements in batches based on the "version cutoff point" and record the "version switch declaration + summary hash of the previous and previous versions + list of affected items" on the blockchain. If the version rollback affects historical settlements, the module will output "historical supplement / reversal suggestions" and work with the unified approval engine module to complete the approval and execution.

[0110] Regarding the linkage between evidence preservation and business blocking, daily settlement and remittance submit field-level summaries, SchemaIDs, price adjustment function family configuration summaries, anomaly removal list summaries, index metadata, and "calculation snapshot hashes" to the blockchain evidence preservation and auditing module at the "finalization" node. When the blockchain evidence preservation and auditing module returns a verification failure (e.g., Merkel path mismatch, missing block receipt, inconsistent object SchemaID), the settlement and remittance module immediately sets the corresponding daily settlement / remittance status to "blocked," prohibiting the issuance of settlement vouchers and triggering the "refund / deduction" action in the loan disbursement or margin risk control module until the problem is fixed and the evidence is resubmitted. For copies of settlement statements issued externally, the blockchain evidence preservation and auditing module can generate machine-readable codes containing "document hash, block height, and Merkel path" for external offline verification; verification failure also triggers "blocking + alarm."

[0111] To ensure project feasibility, the module provides a local recalculation DAG and version conservation mechanism: each recalculation forms a directed edge in the form of "input: old version object + change factor; output: new version object + difference entry". The DAG prohibits cross-layer writes and loops; the "value conservation" of the same settlement object at any point in time can be verified by "original value + sum of differences = present value". The module also outputs a "recalculation evidence package" (including version chain, difference entry, index version and range, anomaly removal list and calculated snapshot hash) at the interface layer for direct use by auditing and dispute resolution.

[0112] In terms of collaboration with other modules within the system: With parameters and release module: Read acceptance thresholds and quality templates; if SchemaID changes, stop calculation and issue an alarm. With the unified approval engine module: daily settlement / finalization, discrepancy reversal, and historical retrospectives all require "approval of events" before they can be released to the public; With the Consistency Snapshot and Recovery Module: When replay causes the daily settlement calculation to need to be reproduced, the module uses a calculation snapshot and input cursor to ensure "same input → same result"; With the margin risk control module: the "receivable / payable difference, refundable / replenishable margin" from daily settlement and reconciliation are pushed as settlement events to trigger "unfreezing / deduction"; Blockchain-based evidence storage and auditing module: Submit SchemaID, index version and range, anomaly removal summary, recalculation difference and final hash throughout the process, and incorporate them into the event genealogy and anchor them.

[0113] Finally, the exception and rollback strategies are given: When the daily settlement calculation results in an unavailable index, missing threshold configuration, or an excessive exception removal ratio, the module will set the day as "pending review" and will not enter the settlement process; when the recalculation results in a conflict with the historical reconciliation, the module will submit it for approval in the form of a "difference trace entry" and will not update the external statements until approval is obtained; when on-chain evidence storage fails or verification fails, a closed loop of "final draft withdrawal → blocking circulation → supplementary evidence storage → restoration of final draft" will be executed.

[0114] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A blockchain-based commodity trading system, characterized in that, include: The parameters and publishing module is used to receive and store transaction parameters; The unified approval engine module, based on configurable process templates and state machines, performs isomorphic orchestration and flow verification for three types of business: transaction release, contract signing, and deposit refund, and supports version updates and canary releases without downtime. The Consistent Snapshot and Recovery module is used to take snapshots when transactions are paused, closed, or abnormally interrupted, and replay them in a monotonic time sequence after recovery to maintain sorting stability and consistency of time windows; The margin risk control module, based on domain-specific language and directed graphs of funding events, freezes, unfreezes, or deducts funds triggered by registration, transaction / winning, default, and settlement events, and performs online and offline reconciliation consistency verification. The blockchain evidence storage and auditing module is used to aggregate multi-source summaries of approvals, contracts, settlements / reconciliations, margin deposits and snapshots in an orderly manner by field name through field-level hashing to form pattern version fingerprints and mapping commitments, and to construct the root hash of the event genealogy graph, and anchor the root hash to the block header of the consortium blockchain to achieve verifiable traceability; The system also includes a transaction processing module: configuring time window boundaries and a stable sorting comparator, wherein the parameters of the stable sorting comparator include price, event timestamp, and sequence number; outputting the transaction / winning event when the time window boundary is reached and synchronously generating a sorting snapshot identifier, and passing the sorting snapshot identifier to the consistency snapshot and recovery module.

2. The blockchain-based commodity trading system according to claim 1, characterized in that, The unified approval engine module includes: a process template management unit, a state machine execution unit, a compensation and rollback unit, and a versioning and grayscale unit; wherein: The process template management unit is used to establish and maintain approval templates in a configurable manner. The approval template includes at least node type, routing conditions, form validation rules and atomic operation list. The unit performs semantic validation and permission binding on the approval template, generates a template version identifier and provides the validated executable template to the state machine execution unit. The state machine execution unit generates a state transition table based on the executable template and drives the atomic nodes to execute. The compensation and rollback unit is used to perform compensation or rollback when at least one of the following conditions occurs: The state machine execution unit returns an error code or throws an exception when calling atomic nodes; Cross-module call exceeded the timeout threshold; Duplicate submissions or out-of-order replays are detected based on idempotent keys; Consistency checks at transaction boundaries failed, including inconsistencies in critical field validations; External dependencies are unavailable or health checks have failed. The versioning and grayscale unit detects that the error rate exceeds the error rate threshold or the rollback rate exceeds the rollback rate threshold during the grayscale release; The blockchain evidence storage and auditing module returned an evidence storage failure or verification failure. The system state is then rolled back to the most recently successfully submitted verifiable stable state, which is determined by the persistent checkpoint of the state machine execution unit and the corresponding digest recorded by the blockchain notarization and auditing module. The versioning and grayscale unit publishes the template version in an atomic switching manner without downtime, and implements grayscale activation according to tenant, organization or transaction type. At the same time, it performs health monitoring on the error rate, latency and rollback rate of the grayscale instance, and controls them with the error rate threshold, latency threshold and rollback rate threshold respectively.

3. The blockchain-based commodity trading system according to claim 1, characterized in that, The snapshot metadata recorded by the consistency snapshot and recovery module includes at least: the quote queue, the parameters of the stable sorting comparator, the time window boundaries, the participant session state, and the timer state. During recovery, the consistency snapshot and recovery module freezes the time window and monotonically replays it according to the event timestamp to ensure that the ranking before and after recovery remains unchanged and that the time window is not enlarged or shortened.

4. The blockchain-based commodity trading system according to claim 1, characterized in that, The system also includes a contract assembly and electronic signature module: parsing contract template placeholders and writing winning bid data according to field-format mapping; performing structural difference mapping on historical versions of the template to achieve forward compatibility; determining signature anchor points in PDF or equivalent formats by combining keyword positioning and coordinate correction, and correcting offsets through affine correction or anchor word neighborhood matching when the format or page breaks change, wherein the correction results of the signature anchor points are used to improve the robustness of signature positioning.

5. The blockchain-based commodity trading system according to claim 1, characterized in that, The system also includes a settlement and reconciliation module: generating daily settlement statements based on the quantity of goods received, transportation losses, and test indicators, and performing outlier removal based on anomaly detection quantile thresholds or equivalent robust criteria; using a family of adjustment functions including at least one of linear, piecewise, and quantile functions to perform linked price adjustments on test indicators and acceptance thresholds; performing a final reconciliation of multi-day settlement results using the reconciliation base, triggering partial recalculation and difference recording when the reconciliation base or test re-inspection changes, and incorporating the difference recording into the blockchain evidence storage and auditing module.

6. The blockchain-based commodity trading system according to claim 5, characterized in that, The settlement and reconciliation module introduces the external price index as an exogenous factor into the price adjustment function family, and writes the version identifier and applicable range of the external price index into the blockchain storage and auditing module; when the version identifier or applicable range of the external price index changes, the partial recalculation is triggered and the recalculation result is recorded on the blockchain.

7. The blockchain-based commodity trading system according to claim 1, characterized in that, The margin risk control module includes: a domain-specific language interpreter for parsing and hot-updating the margin strategy and executing it within a security sandbox; a directed graph construction unit for fund events for modeling the registration, transaction / winning, default and settlement as edges with action labels to drive freezing, unfreezing and deduction operations; and a reconciliation and alarm unit for connecting to a third-party payment or custody system to perform online and offline reconciliation consistency verification, and generating difference alarms and automatic reconciliation tasks when the reconciliation difference threshold is triggered.

8. The blockchain-based commodity trading system according to claim 1, characterized in that, The blockchain notarization and auditing module generates the pattern version fingerprint and mapping commitment by orderly aggregating the field-level hashes of standardized transaction data according to the field name, and constructs the event genealogy diagram by including events such as approval, contract, settlement / remittance, margin and snapshot. The root hash of the event genealogy diagram is anchored to the block header of the consortium blockchain through a Merkle tree to achieve consistency verification and traceability across versions and modules.

9. The blockchain-based commodity trading system according to claim 1, characterized in that, The blockchain evidence storage and auditing module is also used to generate machine-readable codes containing document hashes, timestamps, block heights, and Merkel paths for margin refund vouchers, settlement statements, and contract copies; when offline or online verification of the machine-readable codes fails, the system blocks the corresponding business flow and writes an alarm to the blockchain evidence storage and auditing module.

Images